With BPEL, we can define both simple and complex business processes. BPEL offers constructs such as loops, branches, variables, assignments, and so on, which allow us to define business processes in an algorithmic way. The most important BPEL constructs are related to the invocation of services. BPEL makes it easy to invoke operations of services either synchronously or asynchronously. We can invoke operations either in sequence, or in parallel. We can also wait for callbacks. BPEL provides a rich vocabulary for fault handling, which is very important, as robust business processes need to react to failures in a smart way. BPEL also provides support for long-running process and compensation, and allows us to undo partial work done by a process that has not terminated successfully. The following are the most important features that BPEL provides:

It is also important to know how service interfaces are defined. The interface of a service defines a set of public operation signatures. The interface is a contract between the service provider and the service consumer. Interface is separated from the implementation, is self-describing, and is platform-independent. In order to define business services, we need to focus on the correct granulation of operations. SOA services are best modeled with coarse granulation.

Service operations are defined as a set of messages. Messages specify the data to be exchanged and describe it in a platform-and language-independent way, using schemas. Services exchange only data, which differs considerably from object oriented and component approaches, where behavior (implementation code) can also be exchanged. Operations should also be idempotent (operations are idempotent if repeated invocations have the same effect as one invocation).

Service consumers can use synchronous or asynchronous communication modes to invoke operations of services. In synchronous mode, a service operation responds to the service consumer after the processing is complete. The service consumer has to wait for its completion. Usually, we use synchronous mode when operations complete processing after a short period of time. In asynchronous mode, a service operation does not respond to the consumer, although it may return an acknowledgement so that the consumer knows the operation has been invoked successfully. If a response is needed, a callback from the service to consumer is used. In such a scenario, message correlation is needed.

Loose coupling of services is achieved through self-describing interfaces, coarse granulation, the exchange of data structures, and support for synchronous and asynchronous communication modes. Loosely-coupled services are services that expose only the necessary dependencies and reduce all kinds of artificial dependencies. This is particularly important where services are subject to frequent changes. When a service is modified, minimal dependencies ensure that changes made to other services are minimal. Such an approach improves robustness, makes systems more resilient to changes, and promotes re-use of services.

For developing truly re-usable services, it is also important that we care about attributes, such as availability, performance, security, and so on. These are called quality of service attributes. Quality of service attributes are important in large information systems. In web services, quality of service attributes are covered by WS-* specifications such as WS-Security, WS-Addressing, WS-Coordination, and so on.

The Enterprise Service Bus (ESB) addresses the communication between the services and the processes. We have already mentioned that for services, we can use various technologies. In most cases however, we will use web services. Web services communicate using the SOAP protocol, which can be mapped to one of the transport protocols, most likely to HTTP. HTTP is an unreliable protocol, and is therefore not well-suited to mission-critical applications.

ESB addresses this problem and provides a reliable mechanism for communication between services. In addition, it offers protocol mapping capabilities. This means that ESB can translate different protocols, such as SOAP to JMS (Java Message Service) or vice versa. This is important because in enterprise information systems, we usually have some components already developed in different technologies. We might even have a kind of middleware, such as a message broker. ESB helps to connect and integrate these systems.

ESB can also enable reliable message delivery and provide other value-added features, which are very useful in mission critical systems. Usually, ESB also addresses aspects of security and transaction management. It allows us to configure secure access to the services and processes, and to monitor the access. It also allows the definition of services that should participate in transactions. Some ESBs even allow us to choose between ACID (WS-AtomicTransactions) and compensating transactions (WS-BusinessActivity).

Services in SOA are described in WSDL, and use input and output messages, which are formatted using XML Schema. In the ideal world, all services would use the same schema definitions. In the real world however, this is not the case. Therefore, we often have to transform the XML payload from the output schema of one service to the input schema of another service. For such transformations, we often use XSLT, XPath, or XQuery. ESB provides the ability to do such transformation transparently, on the bus, without having to modify existing services or processes. This capability to transform XML payloads is particularly valuable when new versions of services or processes are deployed. New versions might change the interface or the message schemas somehow. With ESB, we can mask these differences without having to modify all related clients.

Related to transformations is message enhancement. Sometimes, it is not enough just to transform the XML payload. We may need to add or even alter certain information in order to make the message compliant with the service definition. Such alterations may can be simple, such as altering the representation of date, or perform more complex operations such as calculating data, translating types, and so on.

ESB can also serve as a message router. Sometimes, we might want to route messages to certain services. Such routing is usually done based on some deterministic business rules, or can be based on message content, user information (which user created the message, or which user is the receiver of a message), or the time when the message was created. Routing messages on the bus gives us the advantage of doing this in the Good ESBs are integrated with Rules Engines, and allow us to use the rules from the engine for routing.

Routing is related to service mapping. ESBs can also be used to dynamically map a service implementation to the corresponding WSDL interface. On ESBs, this can be done in run time, which gives us greater flexibility over which implementation we will use. If this feature is used with care, it can improve overall flexibility.

In future, we believe that SOA will introduce another important concept: business events. This will extend the way services and processes interoperate. Instead of invoking services by calling their operations, we will simply trigger a business event. Such events will be consumed by those services and processes that have subscribed to the event. ESB will play a central role in this scenario, because it will monitor, route, and manage events in the same way as service invocations.

A very important aspect of SOA is re-use. Re-use at the service level means that when we compose executable processes (in BPEL), we re-use existing services as far as possible. Successful re-use is not easy to achieve and requires at least the following:

Another very important aspect is the deployment process. A professional deployment has three environments:

When an application is ready for production use, it is deployed into the production environment. Controlled deployment of processes requires that a process starts using the production version of services instead of the development or test version. If references to services (partner links) are hard-coded into the BPEL processes, such migration can be very painful, as it might, in the worst case scenario, require manual changes to URL addresses. When deploying a service, we might want to know which processes use this service, because we might want to retest those processes.

Addressing all of the aspects mentioned above is very difficult if we have no list of the available services, or when processes and services are tightly coupled (for example, when a process uses the direct URL of a service in the partner link).

Registries and repositories address these aspects. They are used to register services in a central location. Once registered, we can search and locate appropriate services at design time and at run-time. The more metadata we include for a service, the better the search capabilities that the registry and the repository can provide.

The rule of thumb is that once we have more than 50 services, we will desperately start needing the registry and the repository. However, sometimes it might be wise to introduce it from the beginning, because once developers get used to a certain development process, it will be very difficult to change their behavior.

A powerful registry and repository should have the following features:

Business rules are an important part of each enterprise. Experience has shown that business rules change; sometimes very often, sometimes not that often. Today, business rules are coded into different applications and are tightly-coupled with the implementation of an application system. Changing business rules is therefore very difficult, and requires modifications to applications. Each modification requires testing and deployment, which makes things even more complicated. The major challenge today, however, is to identify the applications into which the same business rule is coded, and to modify all applications where this rule has been used. If we forget some applications, this could lead to unpredictable results, which we do not want to happen.

Business rules are very common in business processes. The idea of SOA has been to extract these rules from the executable code (from BPEL, Java, C#, and so on) and to store them in a central place, where:

Often, business processes manage business rules. Therefore, putting business rules into a central place, the Rules Engine, is appropriate because the same rule is used very often in more than one process. This might not be obvious at the start, when we will have just a few processes automated, but it will become important when the number of processes start to grow. However, similar as it is to the registry and repository, it makes sense to introduce business rules early. This is because if rules engines are introduced after we have implemented several processes, we will have to:

With the introduction of Rules Engines, SOA now addresses the particular challenge of changes in business rules.

Business Activity Monitoring (BAM) helps in answering the question "Where to optimize business processes? Once a process is automated end-to-end, we can use the SOA platform to provide quantitative data about the performance of the process.

A BAM solution gathers information about the time required to complete different activities of a process. It can then provide reports with average values for each activity. Having these numbers can be very helpful, because we can use them to identify which activities take the longest time to execute. With this, we can identify those parts of a process, where we will realize the largest benefits from optimization.

BAM solutions can provide other useful information. They can show us how many process instances are active at a specific time, and how long, on an average, it takes to complete a process. They can also show us which users (employees) have started how many process instances, and so on.

Please note that BAM is not just related to automatic activities (those implemented by services). It can be related to human activities as well. In such a case, we can use BAM to observe the productivity of the employees.

This brings us to the next important part of SOA—the human activities or user tasks: user interactions.

User interactions in business processes are very common. It is true that SOA's objective is to automate as many activities as possible. However, this cannot be done overnight. Therefore, we will need to model certain activities of a process as user interactions—human tasks.

User interactions in business processes can be simple, such as approving certain tasks or decisions, or complex, such as delegation, renewal, escalation, nomination, or chained execution. Task approval is the simplest and probably the most common user interaction. For example, in a business process, say for opening a new account, a user interaction might be required to decide whether the user is allowed to open the account. If the situation is more complex, a business process might require several users to make approvals, either in sequence, or in parallel. In sequential scenarios, the next user often wants to see the decision made by the previous user. Sometimes, particularly in parallel user interactions, users are not allowed to see the decisions taken by other users. This improves the decision's potential. Sometimes, a user does not even know which other users are involved, or even whether any other users are involved at all.

A common scenario for involving more than one user is workflow with escalation. Escalation is typically used in situations where an activity doesn't fulfill a time constraint. In such a case, a notification is sent to one or more users. Escalations can be chained, going first to the first-line employees and advancing to senior staff if the activity is not fulfilled.

Sometimes it is difficult or impossible to define in advance which user should perform an interaction. In this case, a supervisor might manually assign the task to an employees. A group of users or a decision-support system can also assign a task.

In other scenarios, a business process may require a single user to perform several steps that can be defined in advance, or during the execution of the process instance. Even the simplest processes might require that one workflow is continued with another workflow.

User interactions are not limited only to approvals. They may also include data entries or process management issues such as process initiation, suspension, and exception management. This is particularly true for long-running business processes where, for example, user exception handling can prevent costly process termination and related compensation for those activities that have already been successfully completed.

As a best practice for human workflows, it is usually not wise to associate human interactions directly with specific users. It is better to connect tasks to roles and then associate those roles with the individual users. This gives business processes greater flexibility, allowing any user with a certain role to interact with the process, and allowing changes to users and roles to be made dynamically.

User Interaction in BPEL

To interleave user interactions with BPEL processes, we can use a workflow service, that interacts with BPEL processes using standard WSDL interfaces, as any other service. This way, the BPEL process can assign user tasks and wait for responses by invoking the workflow service using the same syntax as any other service. The BPEL process can also perform more complex operations such as updating, completing, renewing, routing, and escalating tasks.

After the BPEL process has assigned tasks to users, users can act on the tasks by using the appropriate applications. The applications communicate with the workflow service by using WSDL interfaces or another API (such as Java) to acquire the list of tasks for selected users, render the appropriate user interfaces, and return the results to the workflow service, which then forwards them to the BPEL process. User applications can also perform other tasks such as reassigning, escalating, routing, suspending, resuming, and withdrawing tasks. Finally, the workflow service may supports other communication channels such as email and SMS, as shown in the following figure: