Products >> Elixa BPEL Engine
Elixa is used to facilitate end user interaction with specific process activities. Because this revolutionary solution allows the definition of roles and permission levels for employees at every stage of a business process, the solution presents a workspace that is automatically customized for each participant.

How is Elixa Different ?
Fundamental BPEL4WS Concepts
Over the last decade, corporations have made substantial investments in packaged applications designed to automate business processes and tasks. Whilst these investments have solved particular pain points, they rarely appear to users as a single, integrated system.
re-use don't rebuild 
Organizations need to protect the investments already made in multiple applications, but they also need to constantly align systems more closely to business and user needs. Elixa helps to reuse the presentation and business logic of existing systems but combine them in a way that makes them simpler and faster to use. This is done in a non-invasive way that does not alter the functionality or integrity of underlying applications.
Our approach ensures that you keep the best of your existing applications, whilst making them even more relevant to your business specific needs.
Today Web services can communicate with each other, advertise themselves, and be discovered and invoked using industry-wide specifications. However, until recently, linking these services together into a business process or a composition gave the user a number of conflicting specifications to choose from -- as was the case with WSFL from IBM and XLANG from Microsoft. The Business Process Execution Language for Web Services (BPEL4WS) represents the merging of WSFL and XLANG, and with luck, will become the basis of a standard for Web service composition. BPEL4WS combines the best of both WSFL (support for graph oriented processes) and XLANG (structural constructs for processes) into one cohesive package that supports the implementation of any kind of business process in a very natural manner. In addition to being an implementation language, BPEL4WS can be used to describe the interfaces of business processes as well -- using the notion of abstract processes.
BPEL has built-in support for synchronous and asynchronous activities, XML manipulation, parallel processing, conditional branching, exception management, compensating transactions and non-structured events. A flexible and open WSDL-based binding framework allows BPEL processes to reach out to XML web services but also JCA, JMS, user workflow, email, EDI, etc.
The Elixa BPEL Engine is a scalable and easy-to-deploy infrastructure for modeling, connecting, deploying and managing BPEL processes.
Elixa comes with a BPEL4WS Designer to create process definitions in BPEL. The designer has a web based user interface and allows Visio style drag and drop functionality. Using this business analysts and system administrators can start creating new processes with minimal training. It provides web based interface for process life cycle management (deployment, pause, resume, termination, logging and tracing).
BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. BPEL4WS defines interoperable integration model that should facilitate the expansion of automated process integration in both intra-corporate and the business-to-business spaces.
BPEL is a standard promoted by Microsoft, IBM, SIEBEL, SAP AG and BEA.

Build Composite Web services 
Wrap parts of your existing systems and applications into coarse-grained, XML-driven BPEL services. Publish synchronous, asynchronous, composite and transactional Web services using the BPEL standard.
Integrate asynchronous services 
BPEL4WS <invoke> and <receive> activities and the Elixa patented 2-way proxy make it easy to invoke remote Web services and receive asynchronous callbacks.
Coordinate multi-step business processes
The <flow> and <sequence> activities and the link construct allow developers to define parallel paths of execution and sophisticated join patterns within a BPEL Process.
Publish BPEL processes as Web services 
When deployed, a BPEL Process is automatically published as an XML Web service which can be easily integrated into larger applications and business processes.

Manipulate XML documents
The Elixa BPEL Server offers bi-directional mapping between XML-Schema defined data structures and XML Java Facades, reducing significantly the complexity of parsing, marshalling and manipulating XML documents. 
Integrate into 100+ back-end systems 
Elixa offers a rich WSDL/WSIF binding framework which allows developer to reflect JCA adapters as web services. 
Leverage your existing J2EE assets
Elixa's BPEL exec extension allows developers to extend the reach of BPEL processes to Java classes and EJB components. BPEL Processes also offer a clean and non-intrusive separation between presentation logic and flow logic allowing enterprises to leverage their existing investment into JSPs or frameworks such as Struts.
Send and receive messages from JMS queues and topics  
Elixa's 2-way messaging service reflects JMS queues and topics into asynchronous services that can be easily integrated into BPEL Processes.
Interoperate with Microsoft .Net and BEA Workshop   
Initiate a BPEL Process from a .Net application or a BEA jws component. Invoke a .Net or BEA service from within a BPEL Process. Receive asynchronous callbacks from BEA Workshop jws components.
Collaborate using email with attachments
Integrated SMTP, POP and IMAP 2-way services and Excel data bean reduces the cost and complexity of interacting with people and/or external application through email with attachments.
Catch exceptions
Exceptions can be thrown and managed using BPEL's throw activity and faultHandler/catch construct.
Coordinate compensating business transactions
Built-in support for WS-Transaction reduces the complexity of managing distributed transactions and exceptions.
Define manual activities
Integrated work list service allows developers to define steps/activities within the BPEL process where a manual intervention (aka user task) is required. Users can interact with a BPEL process through a portal, an email or a custom JSP application.
Track execution (audit trail)
Integrated audit trail service captures the history of a BPEL process. This information is available through HTML interface or Java API.
Test/debug BPEL process
Examine the state of in-flight BPEL process instances, drill down into active BPEL code and inspect XML variables.
Integrate multiple BPEL servers inside a logical cluster. Increase reliability and throughput.
Side-by-side versioning
Integrated versioning and hot deploy capability reduces the complexity of updating and deploying new versions of a BPEL process.
BPEL Monitoring
Aggregate statistical information regarding the execution of a BPEL process.
How is Elixa Different?
The Power of an Open Standard
By capturing your business processes in BPEL, you protect your intellectual property and investments while avoiding vendor lock-in. BPEL is to business process management what SQL was to data management.
Unparalleled visibility and administration
The BPEL Console reduces the cost and complexity of deploying and managing your business processes: Visually monitor the execution of each BPEL process, drill down into the audit and view the details of each conversation or debug a running flow against its BPEL implementation.
Dramatic Cost Savings
The Elixa BPEL Server is 60-80% less expensive to buy and maintain than traditional EAI solutions.
Open and Flexible Binding Framework
Orchestrate XML Web services, but also Java/J2EE components, portals, JCA interfaces and JMS destinations. Tie into 100+ back end systems. Leverage your Java skills and application server investments.
Fundamental BPEL4WS Concepts
BPEL4WS supports two distinct usage scenarios:
  • Implementing executable business processes.
  • Describing non-executable abstract processes.
This article focuses on the first scenario only; a future article in this series will consider the abstract process concepts of BPEL4WS.
As an executable process implementation language, the role of BPEL4WS is to define a new Web service by composing a set of existing services.Thus, BPEL4WS is basically a language to implement such a composition. The interface of the composite service is described as a collection of WSDL portTypes, just like any other Web service. The composition (called the process) indicates how the service interface fits into the overall execution of the composition. Figure 1 illustrates this outer view of a BPEL4WS process.
Figure 1. View of a Web service implemented as a BPEL4WS process

The composition primitives found in BPEL4WS come primarily from many years of experience in workflow and business process integration, hence its positioning as a business process composition language.
Implementing the service
What's in the cloud in the figure above? Unlike a traditional programming language implementation of a WSDL service, each operation of each portType does not map to a separate piece of logic in BPEL4WS. Instead, the entire type of the service (that is, the set of portTypes of the service) is implemented by one single BPEL4WS process. Thus, specific "entry-points" corresponding to external users invoking the operations of the interface are indicated within the BPEL4WS description. These entry points either consume WSDL operations' incoming messages from input-only or input-output operations. In the latter case, the process must also indicate where the output message is generated. BPEL4WS only uses and supports input-only and input-output (request-response) operations of WSDL; output-only (notification) and output-input (solicit-response) operations are not required nor supported.
The BPEL4WS process itself is basically a flow-chart like expression of an algorithm. Each step in the process is called an activity. There are a collection of primitive activities: invoking an operation on some Web service (<invoke>), waiting for a message to operation of the service's interface to be invoked by someone externally (<receive>), generating the response of an input/output operation (<reply>), waiting for some time (<wait>), copying data from one place to another (<assign>), indicating that something went wrong (<throw>), terminating the entire service instance (<terminate>), or doing nothing (<empty>).
These primitive activities can combined into more complex algorithms using any of the structure activities provided in the language. These are the ability to define an ordered sequence of steps (<sequence>), the ability to have branching using the now common "case-statement" approach (<switch>), the ability to define a loop (<while>), the ability to execute one of several alternative paths (<pick>), and finally the ability to indicate that a collection of steps should be executed in parallel (<flow>). Within activities executing in parallel, one can indicate execution order constraints by using the links.
BPEL4WS allows you to recursively combine the structured activities to express arbitrarily complex algorithms that represent the implementation of the service.
Interacting with others: Partners
As a language for composing together a set of services into a new service, BPEL4WS processes mainly consist of making invocations to other services and/or receiving invocations from clients (the users of the service in Figure 1). The prior is done using the <invoke> activity and the latter using the <receive> and <reply> activities. BPEL4WS calls these other services that interact with a process partner. Thus, a partner is either a service the process invokes (invoked partners) as an integral part of its algorithm, or those that invoke the process (client partners).
The first kind of partners is obvious -- the process must clearly invoke other services to do things. The <invoke> activity indicates the partner to invoke and what operation of which of the partner's portTypes to invoke on that partner. Notice, however, that invoked partners may end up being clients as well -- it may be the case that the process invokes an operation on the partner to request some service. Later on, the partner may invoke an operation on the process to provide the desired data.
The reason for treating clients of the process as partners may not be so obvious. There are actually two reasons for it: the first is that in sometimes the process may need to invoke operations on one of its client partners. This is primarily how asynchronous interaction is supported: the client invokes an operation on the process to request some service. Upon completion, the process invokes an operation on the client partner. At that point, there is no distinction between a client partner and an invoked partner.
The second reason is that the service offered by the process may be used (wholly on in parts) by more than one client. In addition, the process may wish to distinguish between these different users of the service. For example, a process representing a loan servicing system offers a single Web service, but only parts of it are accessible to the customer applying for the loan, other parts for the customer service representative and finally the entire service to the loan underwriters. Depending on whether an operation is invoked by the customer or by the underwriter, the returned behavior may be quite different. Furthermore, the approach of using partners to model clients allows the process to indicate that certain operations may only be invoked by certain clients.
So, partners are one of the following:
  • services that the process invokes only.
  • services that invoke the process only.
  • or services that the process invokes and invoke the process (where either may occur first).
The first two are straightforward invoked partners and client partners, respectively. Consider the relationship between the process and the service for the third case when the process invokes the service first. That means that the service provides (or publishes) a portType (PT1) and the process invokes an operation of that portType. Also, the process must provide a portType (PT2) that the service invokes an operation out of. Thus, from the point of view of the process, the process requires the portType PT1 from the service and provides the portType PT2 to the service. Looking at the same relationship from the point of view of the service leads to opposite statement: The service offers the portType PT1 to the process and requires the portType PT2 from the process. The situation is the same whether the process invokes the service first or vice-versa.
Service link types
Modeling the third kind of partners is what gives rise to service link types. Instead of defining the relationship between the service and the process from the point of view of one of these participants, a service link type represents a third party declaration of a relationship between two (or more potentially) services. A service link type defines a collection of roles, where each role indicates a list of portTypes. The idea is that when two services interact with each other, the service link type is a declaration of how they interact -- essentially what each party offers.

BPEL4WS uses service link types to define partners. Basically, a partner is defined by giving it a name and then indicating the name of a service link type and identifying the role that the process will play from that service link type and the role that the partner will play. In the pure invoked partner and pure client partner cases, the service link type will have just one role in it and, hence, only one is indicated at partner definition time. The partner name is then used in <receive>, <reply> and <invoke> activities to indicate the desired partner.

Service references
How does a partner work at runtime? In order for it to work at runtime, the partner must resolve to an actual Web service. Thus, a partner is really eventually just a typed service reference, where the typing comes from the service link type and the roles. The BPEL4WS process itself does not indicate how a partner is bound to a specific service; that is considered a deployment time or runtime binding step that must be supported by the BPEL4WS implementation.
Dealing with problems
Developers need ways to handle and recover from errors in business processes. BPEL4WS has exceptions (faults) built into the language via the <throw> and <catch> constructs. The fault concept on BPEL4WS is directly related to the fault concept on WSDL and in fact builds on it.

In addition, BPEL4WS supports the notion of compensation, which is a technique for allowing the process designer to implement compensating actions for certain irreversible actions. For example, imagine a travel reservation process. Once a reservation has been confirmed, one must perform some explicit operations to cancel that reservation. Those actions are called "compensating actions" for the original action.

Fault handling and compensating is supported recursively in BPEL4WS by introducing the notion of a scope, which is essentially the unit of fault handling and/or compensation. Understanding compensation and fault handling in detail is a topic on its own and will be covered in a future article.

Lifecycle of services
What about the lifecycle of these services? Web services implemented as BPEL4WS processes have an instanced life cycle model. That is, a client of these services always interacts with a specific instance of the service (process). So how does the client create an instance of the service?

Unlike traditional distributed object systems, in BPELWS instances are not created via a factory pattern. Instead, instances in BPEL4WS are created implicitly when messages arrive for the service. That is, instances are identified not by an explicit "instance ID" concept, but by some key fields within data messages. For example, if the process represents an order fulfillment system, the invoice number could be the "key" field to identify the specific instance involved with the interaction. Thus, if a matching instance isn't available when a message arrives at a "startable" point in the process, a new instance is automatically created and associated with the key data found in the message. Messages can only be accepted at non-startable points in a process after a suitable instance has been located; that is, in these cases the messages are in fact always delivered to specific instances. In BPEL4WS, the process of finding a suitable instance or creating one if necessary is called message correlation. Message correlation will also be covered in a future article.