Oracle SOA Suite: BPELmania (BPEL vs. Spring Beans vs. Mediator)

The current Oracle SOA Suite 11g PS4 (11.1.1.5) offers several SCA Component types for service implementation (BPEL, Human Task, Spring Context, Business Rule and Mediator). All these different SCA Component types raises the question what component to use in which context. Quite clear is the usage scenario of the Human Task and Business Rule Components. But the BPEL, Spring Context and Mediator Components have overlapping functionality. Too often an implementation based on BPEL Components is chosen instead of weighing against the other two available SCA implementation types. This fact is probably explicable form the history of the Oracle SOA Suite where version 10g only offered BPEL. Whereas Spring Context and Mediator Components are introduced starting with 11g and the SCA concept. 
 
Let’s do a short introduction of the three SCA component types and weigh the pros and cons. 
 
BPEL
BPEL (Business Process Execution Language) is an OASIS standardized orchestration and executable language for specifying actions within business processes. BPEL constructs and execute workflows by assembling discrete services into a complete process flow. Beside the standardized basic and structured activities to define BPEL processes, in addition Oracle also defines several extension (proprietary) activity types.

BPEL describes processes on a true business process level (future wise covered by executable BPMN coming with the Oracle BPM Suite on top of the Oracle SOA Suite). And the graphical representation makes processes tangible for business users.

In general I agree with the Wikipedia description that BPEL aims to enable “programming in the large”. But there is the potential danger that inexperienced SOA designer/developer use BPEL components for all kind of service implementation on the Oracle platform (especially the “Java Embedding” activity opens the door on ill-considered implementations). BPEL's control structures such as “if-then-else”, “while” and “repeat until” as well as its variable manipulation facilities together with the Oracle enhancements tends Oracle BPEL to become a “programming in the small” language.

Spring Beans
The Spring Framework is a popular application framework on the Java platform. It aims to reduce the complexity of the programming environment based on the four key concepts of focusing on POJO (Plain Old Java Objects), Dependency Injection (DI), AOP (Aspect-Oriented Programming) and the simplified API Abstraction.



Normal Java Objects (POJO) is at the center of the Spring Framework. POJOs are cross-linked by Dependency Injection (bean dependencies on other objects are not hard-coded, instead object references described as bean properties on a XML context configuration file are injected by setter methods). POJOs will be supplemented in a non-intrusive way with cross-cutting aspects by using AOP (aspects like logging, monitoring, security, transactions). And finally POJOs communicate with other APIs via the simplified API abstraction (like JDBC, JMS, EJB, Quartz, etc.).

The SCA Spring Component Implementation Specification specifies how the Spring Framework can be used as a component implementation technology in SCA. Since Oracle SOA Suite 11g Patch Set 2 it is possible to have Spring Beans as part of the Spring Framework on the Oracle SCA Container as first-class citizen (use Spring Beans like any other SCA Component). Spring Beans makes it possible to run Java implemented services on the Oracle SCA Container.

Compared with BPEL Components the intensive usage of Spring Beans entails risk the other way round. People with a strong JEE or Spring Framework development past will tend to use Spring Beans for all kind of implementations even for the “programming in large” concerns. Especially the possibility to use the matured and out-of-the-box available JCA Technology Adapter is often pushed into the background. Developers really don't have to keeping re-inventing the wheel.

Mediator
As the name suggests the Mediator Component is about intra-composite mediation between various SOA Suite Components. The Mediator brings Enterprise Service Bus (ESB) aspects inside of the SCA Composite. The main task is to route data and sequencing messages between consumers and producers. Defined routing rules could filter, transform and validate data. Additionally the Mediator Component could act as an “echo” service component. Which means that the Mediator is echoing directly back to the initial caller after transformation, validation or enrichment activities. Together with so-called Mediator Java Callout Handler which enables “pure” Java based message manipulation the Mediator starts to compete with BPEL and Spring Beans.

BPELmania – don’t forget the “evil” side of BPEL
It is somewhat similar with the famous Hammer-Nail quote from Abraham Maslow (“If you only have a hammer, you tend to see every problem as a nail.”). For some people BPEL is the hammer with the purpose to implement every service exclusively with BPEL (using BPEL as “glue”, not as programming language). The right approach is to weigh pros and cons of BPEL, Spring Beans and Mediator in a certain usage scenario.
The BPEL main major advantages are the graphical business process visibility, the flexibility for quick process changes and the support for long running business processes.

Business processes can run for several minutes, hours or days (or even longer). With pure Java it’s cumbersome to handle long running processes. It makes the application complex and complicated for the developers to maintain the process.

BPEL also supports compensation in a relatively easy way. Compensation, or undoing non-transactional steps in the business process that have already completed successfully, is one of the most important concepts in business processes. The goal of compensation is to reverse the effects of previous activities that have been carried out as part of a business process that is being abandoned.

Business processes may also have to react on certain events. Such events can be message events or alarm events. Message events are triggered by incoming messages through operation invocation on port types (onMessage Event Processing). Alarm events are time related and are triggered either after a certain duration or at a specific time (onAlarm Event Processing). Oracle BPEL provides good support for managing events in business processes.

Another advantage of BPEL is the portability. BPEL can be executed on other process engines running on different vendor platforms. The prerequisite however is that the BPEL process is only using standardized basic and structured activities.

List of BPEL advantages (on the Oracle SOA platform)

• Graphical business process visibility
• Flexibility for quick process changes
• Support for long running business processes
• Business compensation handler (“UNDO”)
• Oracle’s good integration of Human Workflow (Human Task Components)
• Oracle’s good integration of the Business Rules Engine (Business Rule Components)
• Support of events and EDN (Event Delivery Network)
• Portability to other standard-based process engines (if obeying the BPEL standards)
• Support of synchronous, asynchronous and one-way (asynchronous) process interaction with the caller

It’s obvious that BPEL has been designed to address the requirements of defining business processes. But a BPEL process will cause definitely more load on the application server and the database, because of the BPEL process engine overhead causing a lot of transactions on the SOA/MDS database. It’s possible to minimize the additional load but it’s a complex endeavor. Developers have to deal with dehydration (storing the current status of the BPEL process into the database is known as dehydration), delivery service configuration for incoming messages, audit tracking configuration, the configuration of the completion persist policy, etc.

Additionally Oracle BPEL could handle technical transaction but proper transactional behavior demands deep understanding of the platform behavior (transaction property configuration and dehydration causing activities which causes transaction commits).

Dealing with BPEL variables will require knowledge of XPath and XSLT for transformations. XSLT transformations will cause slowing-down because of Oracle XSLT processor calls. But one of the major weaknesses is the memory consumption caused by XML BPEL variables kept in memory as DOM class (Document Object Model). A DOM class is an in-memory representation of an entire document and the complete infoset state for an XML document. In memory DOM-tree provide good flexibility for developers, but the cost of this flexibility is a potentially large memory footprint and significant processor requirements, as the entire representation of the document must be held in memory as objects for the duration of the document processing (acceptable for small documents , but memory and processor requirements can grow rapidly with document size).

List of BPEL disadvantages (on the Oracle SOA platform)

• JDeveloper provides no BPEL debugging features
• JDeveloper provides no BPEL refactoring support
• BPEL process engine caused additional load (app server, DB)
• Complex and non-transparent configuration for performance tuning
• Complex and non-transparent configuration of technical transactions
• Deep XPath and XSLT knowledge is needed (assign and transformation activities)
• XSLT transformation performance overhead (overhead on Oracle XSLT processor calls)
• Inapplicable for large XML document processing (because of memory and CPU consumption)
• Risk of using BPEL for doing “programming in small”
• Oracle extension (proprietary) activity types make processes non-portable
• Compared with Spring Beans or Mediator Components, a single BPEL Components offer “only” one service operation (it’s in the nature of BPEL)

Alternatively, in case of a straight forward sequenced process without any control flow, the usage of Spring Beans or Mediator should be considered to achieve higher performance and throughput.

Spring Beans for “programming in the small”
Spring Beans complement the Oracle SCA Components rather than competing on BPEL Components. In fact they are in a strong competition on SLSB EJBs (Stateless Session Bean). Spring Beans and EJBs implement self-contained business services invoked by BPEL. But Spring Beans operate inside of SCA Composites running on the SCA Container whereas EJBs are outside of the SCA Container running on the EJB Container.

The Spring Framework leads to flexibility and modularization of the design because smaller (Spring Beans) components can be easily wired to more complex components (Spring Bean to Spring Bean wiring), following the principles of the SCA composite framework. Spring focuses on “wiring in the small” in traditional applications. On the Oracle SCA Container Spring Beans could be “wired in the small” and “wired in the large”.



EJBs could be used through the SCA EJB Adapter (placed on the external references swim lane), but direct EJB to EJB wiring couldn’t happen on a SCA composite which blocks the architectural modularization concept. Additionally, EJBs could not leverage the Oracle SCA Adapter Framework (for example make use of the DB Adapter or File Adapter) which leads to additional development efforts.

It is even possible to give Spring Bean implemented SCA Services an EJB interface (binding.ejb) in case that services have to interoperate with an EJB application landscape.

One principal reason for the usage of Spring Beans instead of EJBs is SCA’s way to wrap Spring Beans with other SCA Components into one SCA Composite in order to have only one single deployment unit and artifact of versioning (the SCA Service Archive, SAR). This SAR can be versioned as one, deployed as one, tested as one and managed as one instead of worrying about individual pieces. Finally already before the SCA era started Spring Beans become very popular in the Java Community as an alternative and replacement of EJBs (perceived as too heavy-weighted and complex with a lot of unnecessary boilerplate overhead).

An important advantage is the usage of Spring Beans in complex scenarios because Spring Beans could be easily debugged (not possible with BPEL or Mediator Components) and service mocking could happen in a declarative manner (on the context configuration file).

Despite the completeness and maturity of the Oracle SOA platform, projects will run into a situation in which the Oracle SOA Suite cannot provide a solution. Spring Beans are working like a “Swiss army knife”. In other words, Spring Beans can provide the lever to code for patches in the Oracle SOA components. Spring Bean could help on certain scenarios like high performance requirements (on <PS5 make sure you have patch 12402061 or one of the following patches running) or non-working DB Adapter queries (like the range operator BETWEEN, multiple value operator IN on where conditions, dealing with XMLType columns or just very complex SQL commands).

Spring Bean Advantages (on the Oracle SOA platform)

• Spring is SCA standardized
• Easy debugging and testing (isolated testing and interface mocking)
• Spring development is simple-n-short, on-point and easy to read (because of DI, AOP and especially because of the Simplified APIs)
• High performance scenarios (“lean and mean”, no overhead like for example dehydration)
• Enables easy Java logic reuse on custom-build and standard third-party libraries (packaged and deployed with the SCA Composite)
• Flexibility and modularization by “wiring in small” and “wiring in large”
• “Swiss army knife” of all missing platform features and necessary workarounds
• Concept of “Pre-defined” and “global” Spring Beans (>=PS3) which provides out-of-the-box functionality and global spring context definitions
• Compared with BPEL and Mediator, the Spring Bean Component is easy portable
• Well integrated on the Oracle SCA environment (leverage SOA Suite build-in features)
• Support of synchronous, asynchronous and one-way (asynchronous) Spring Bean interaction with the caller

But because of the all-purpose aspects of Spring Beans there is a risk of non-consideration of BPEL components, Mediator components or already existing JCA Adapter. Using Spring Beans for “programming in large” and especially for long-running process coordination will be the wrong approach. Doing all kinds of “backend access layer” programming and disregard the existence of out-of-the-box JCA Adapter is a misunderstanding of the Oracle SOA platform offering. Developers need to resist the temptation of doing everything with Spring Bean components.

Spring Bean disadvantages (on the Oracle SOA platform)

• No Audit Tracking information
• Difficult to implement AOP aspects and Springs dynamic language support
• Risk of using Spring Beans for doing “programming in large”
• Risk of not using JCA Adapter for connectivity

Mediator as “jack-of-all-trades”
The Mediator is a “fallen” ESB (former ESB on the 10g platform), now working as an intra-composite component. This light-weight Service Bus mainly competes with the OSB, the Oracle Service Bus (former AquaLogic Service Bus on the BEA platform). The Mediator could be used as a “composite proxy” behind the exposed service interfaces. In reverse, the Mediator could be used as an “external reference proxy” for any external service invoked by a composite. But virtualization of services is also a main task of the OSB. Antony Reynolds and Matt Wright describe three basic approaches on the usage of Mediator and OSB in inter-composite application communication.

• Centralized topology (go always via OSB)
• Peer-to-Peer topology (go directly via the service infrastructure- called Oracle Fabric)
• Hybrid topology (combine both upper approaches)

It’s almost impossible to recommend only one approach. It always depends on the requirements in a given project. All approaches have pros and cons but the Peer-to-Peer topology has same key advantages.

• All invocations are optimized, resulting in significant improved performance
• Transactions are propagated in composite-to-composite calling scenarios
• Complete audit trails across the whole composite calling chain

Finally the OSB is adding an additional layer of complexity in combination with additional communication overhead. OSB could be used for example handling service security aspects, service throttling and service result set caching (internal implemented by Coherence). But it certainly makes sense to use the OSB in an enterprise application (for example ERP systems) calling scenario. These are applications in their own right. Little sense makes the usage of the OSB in a composite-to-composite calling scenario where one composite is calling a “private” composite for service implementation (running on the same SCA Container). Private composite means an internal used composite implementing an internal re-used entity or utility service.

Mediator is powerful and could be used on several scenarios were designer/developer primarily think of using BPEL or Spring Beans. First of all the Mediator could replace efficiently BPEL Components in a simple straight forward orchestration use case. If simple service invocations have to happen in sequential or parallel the Mediator might be an alternative. Especially in “low” level invocations on the JCA Adapters like the Database Adapter (for example to implement an Entity Service).



The Mediator could execute the calls in sequence or in parallel (for example Insert DML commands on the DB Adapter). Whilst implementing the mediation enrichment pattern, the reply from one target service can be forwarded to another target service without going back to the original caller (Lucas Jellema calls it “small-time enrichment”).

Beside the “normal” XML payload validation, the Mediator could also do more complex Schematron validations (for doing cross XML document validation). The Mediator implements the feature of echo services. This means the Mediator is directly going back to the requester without the need to route to another target service. The echo feature of the Mediator provides the opportunity to implement utility services for complex transformation or validation. Even more interesting is the Java Callout Handler, which can act as a kind of Java backdoor capability. Java callouts enable you to use external Java classes to manipulate messages flowing through the Oracle Mediator. At this point the Mediator strongly overlaps with Spring Bean functionality. For example the Mediator Component could implement a complex Java based transformation or validation as echo service (complex validation implementation overlaps on the other side with the Business Rules Component).

Finally the Mediator is absolutely necessary in a SCA Composite design where several exposed service operations are implemented by BPEL Components. A BPEL Component could only offer one service interface.

Mediator advantages (on the Oracle SOA platform)

• Resequence messages capability
• Support of EDN (Event Delivery Network)
• Mediator Asynchronous Messaging (synchronous to asynchronous)
• Mediator supports Domain Value Maps
  (DVM helps significantly when utilizing Canonical Data Models)
• Mediator provides the VETRO capabilities intra-composite
  (VETRO stands for Validate, Enrich, Transform, Route, Operate)
• Echo Service feature (independent service implementation)
• Java Callout Handler (door-opener to the powerful Java world)

The Oracle Mediator is an Oracle proprietary SCA Component Implementation Type. Portability of BPEL (without using Oracle extension activities) and Spring Beans to a new SOA platform could be reached easily. There is no SCA standard on Mediator Components therefore it would require large rework on a platform move.

Sometimes it’s necessary to handle SOAP Faults on Mediator Java Callouts. Without patching the system it’s not possible to handle proper SOAP Faults (<=PS4). Designer and Developer should be also aware that the parallel execution type will cause a new transaction. This fact is (hidden) on the documentation but could cause long trouble-shooting sessions.

Mediator disadvantages (on the Oracle SOA platform)

• Mediator is a highly Oracle proprietary component
• Mediator SOAP Fault Handling on Java Callouts (only with patch possible)
• Mediator parallel execution type initiate (in-transparent) a new transaction
• Deep XPath and XSLT knowledge is needed (assign and transformation)
• XSLT transformation performance overhead (overhead on Oracle XSLT processor calls)

Summary
Use the Oracle SCA Components as originally conceived. BPEL is not the answer on all design/implementation scenarios. Ugly “back door” Java implementation through BPEL Java Embedded Activities should be buried in the past. Future Java based service development on the SCA Container is not a matter of SLSB (Stateless Session Bean) EJB development. These concerns are clearly pointing on the usage of Spring Beans. The Mediator component is a light-weight intra-composite ESB, but in selected use cases also a valid alternative on BPEL or Spring Bean development.

On an architecture layer diagram the BPEL Component is placed on the Business Process Layer. A BPEL Component could call multiple Sub-BPEL processes on the Business Process Layer. BPEL processes shouldn’t implement business services, they should orchestrate them. New Business Services on the SCA Container should be implemented by Spring Beans or Mediator Components as Echo Service (for sure, Human Task and Business Rules Components are also excellent candidates to implement business services). Reuse of existing Business Services implemented by SLSB EJB is possible via EJB Adapter or direct calls from Spring Beans. The Mediator Component is used for intra-composite and composite-to-composite (using the peer-to-peer topology) routing scenarios.



The diagram doesn’t contain Human Task and Business Rules Components. Also the OSB is left out in order to reduce complexity. Layer bridging by skipping the Business Process Layer is a real-world scenario.

The Oracle SOA Suite offers a rich construction kit on SCA Components and several ways to use these components. It’s the task of the architects, designer and developers to use these components in the right way.