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.

Oracle SCA Composites Visualized By MS Visio

An Oracle SCA Composite is described through an associated configuration file called composite.xml. This file uses a standardized XML-based format called the Service Component Definition Language (SCDL, commonly pronounced “skiddle”) to describe the artifacts this SCA Composite contains and specify how they relate to one another. The composite.xml mainly includes the SCA Components, exposed and external referenced services implemented via adapter and the wires between these artifacts.

The composite.xml file is rendered in JDeveloper with the Visual SCA Composite Editor. This editor works for development and offers a “drag & drop” way of SCA programming.

Unfortunately Oracle offers no image export feature on this editor. This feature could be similarly to the “Create JPEG Image …” feature on the BPEL Editor. An image export would be very helpful for the creation of documentation. Additionally it would be helpful to discuss a SCA Composite structure without starting always JDeveloper (or even to have JDeveloper on the disk). Composite screenshots are often do not capture the whole composite and keep only a section of the composite. It would be desirable if SCA Composites are zoomable on Composite Editor. This feature could be similarly to the “Zoom” slider on the BPEL Editor.

For all these reasons, I developed a “SCA to Visio” application. This application takes the composite.xml, parses the content and creates a MS Visio diagram. This diagram reflects the SCA Composite. The application uses ActiveX or COM automation components natively on the Windows COM and Win32 libraries. A COM Automation server controls Microsoft Visio which has to be installed on the same machine. I tested the “SCA2Visio” application with a JRE6 version on a Win7 system with Microsoft Visio Premium 2010.

The generated Visio diagrams could be printed, re-layouted, stored in several graphical formats, enriched with additional information and could be zoomed in and out. It’s ideal for any documentation and architectural discussion. Additionally it’s a good way to show Composite-to-Composite overview diagrams.

This diagram is an SCA2Visio example of the last Calculator application used on my Spring Bean blog entry.

Download of SCA2Visio application is available here (Zip, 5.73 MB). Try it!

Oracle SCA Spring Bean Transactional Behavior

My last blog was about Oracle SCA Spring Beans with own database access instead of using the provided JCA DB Adapter. It’s always a tradeoff to use the Oracle JCA Database Adapter or to implement own database access by the means of the Spring Framework. The DB Adapter in combination with the JDeveloper configuration wizard is easy to use and enable DML SQLs like quick data retrieval. Behind the DB Adapter runs the JPA persistence framework Oracle Toplink and the application could benefit from Toplink (Unit of Work Concept, declarative query result set caching, etc.). On the other side complex SQL commands are difficult if not impossible to build with the DB Adapter. Some SQL commands are even not supported on the DB Adapter (for example set-operators). Therefore it’s very helpful to build the SQL command in a programmatic way without any adapter limitations on the Spring Bean. Additionally if a Spring Bean uses a DB Adapter the performance is suffering from the XML marshaling overhead. A direct database access inside of the Spring Bean is much more efficient.

But in both ways it’s important to understand the transactional behavior inside of the Oracle SCA Container for Spring Beans. Transactional behavior could be influenced by declarative transaction management on the Spring Bean context configuration or in a programmatic way. For Spring Beans there is no property configuration available on the SCDL (like for example the bpel.config.transaction property for BPEL process transaction configuration).

Spring Beans used on Oracle SCA Composites are always taking part in running transactions as default behavior. If there is no caller transaction running, the Spring Bean Component starts a new transaction. This behavior needs no additional configuration and would be the desired behavior in most use cases.

If the Spring Bean should deviate from the default transactional behavior the Spring Beans needs some special configuration on the context configuration file. Therefore a transactional proxy has to be defined on Spring Bean context. The bean definition should state the transaction manager that should be used and the transactional attributes for the service object (referenced by the target property).
The following example is showing a transactional proxy configuration for the Calculator Service Bean. The example assumes existing audit tracking method(s) which should not take part in running transactions (PROPAGATION_REQUIRES_NEW).


The PROPAGATION_REQUIRES_NEW transactional attribute uses a completely independent transaction and will not affect outer transactions. Set the key attribute on “*” in order to set the transaction attribute for all methods.

This is a list of valid transaction attributes supported by the Spring Framework:

• PROPAGATION_MANDATORY: Supports a current transaction; throw an exception if no current transaction exists.
  
• PROPAGATION_NESTED: Executes within a nested transaction if a current transaction exists, behaves like PROPAGATION_REQUIRED else.
  
• PROPAGATION_NEVER: Does not support a current transaction; throws an exception if a current transaction exists.
  
• PROPAGATION_NOT_SUPPORTED: Does not support a current transaction; rather always executes non-transactionally.
  
• PROPAGATION_REQUIRED: Supports a current transaction; creates a new one if none exists.
  
• PROPAGATION_REQUIRES_NEW: Creates a new transaction, suspends the current transaction if one exists.
  
• PROPAGATION_SUPPORTS: Supports a current transaction; executes non-transactionally if none exists.

This approach could even manipulate the isolation level of transactions. Therefore you have to set on the Spring transaction manager bean the allowCustomIsolationLevels property flag to true (the default value is false). Afterwards you could specify the custom isolation level on the transactional attributes settings. For more details please take a look at the excellent developerWorks article “Specify custom isolation levels with the Spring Framework”.

Another alternative way to the declarative solution is the programmatic approach. A Spring Bean can get a reference to the running transaction, whenever the Spring Bean needs to have programmatic access to the transaction in order to do commit, rollback, suspend or resume a running transaction.

The following listing shows an example on how a Spring Bean could get access of the running transaction. In this example the auditTracking operation is not part of the running global transaction.

Transaction transaction = null; TransactionManager txMg = null; try { ctx = new InitialContext();    // getting the transaction manager    txMg = (TransactionManager)       ctx.lookup("javax.transaction.TransactionManager");    // suspending the thread's transaction    transaction = txMg.suspend();    // call audit tracking method      // this operation is not part of the global transaction    auditTracking(msg); } catch (NamingException e) { … } catch (Exception e) { … } finally { try {    // resuming the transaction       txMg.resume(transaction);    } catch (…) {      … }

Listing: Programmatic access to the running transaction

Note that in the example above, the auditTracking operation on the given example will not start an own transaction by default. This is a programmatic approach and the programmer has to take care of all kinds of transaction aspects. In my opinion the declarative approach is much more elegant because it lets the code free of any transactional requirements and centralize the configuration on the Spring Bean context.

In a composite to composite calling scenario take care that Local Optimization happens (take a look on the blog from Ramkumar Menon on how to check if Local Optimization is kicking in the WS Binding) because otherwise the normal composite to composite transaction propagation is not supported. The Oracle documentation mentions that even WS-AT will not help in this scenario (chapter 35.1.1.1.2: “WS-AT transactions are not supported in composite-to-composite calls, even with the oracle.webservices.local.optimization property set to false.”). I’m not sure if this statement is in general true.

Thanks to Clemens Utschig-Utschig who was pointing me on the declarative solution. Also thanks to Silviu Leahu who figured out the programmatic solution.

That’s it. For more details take a look at the Spring JDBC documentation.

Oracle SCA Spring Bean With Own Persistence

My last blogs are around the Oracle SCA Spring Bean basics illustrated with a calculator example. We already implemented the four basic forms of calculation by own Spring Bean implementations which are wired on the Calculator Bean (bottom-up blog, top-down blog). Additionally we called an EJB for the square and square root operation (blog).


But good calculators have the most familiar trigonometric functions sine, cosine, and tangent on them. So we extend your Calculator Service example with these new mathematical operations.

But instead of using again the Math Java functions we utilize the Oracle Database for these functions. The implementation of mathematical function by using an Oracle Database is a kind of artificial, but I want to show the direct access of Spring Beans on the database.

This is a practice-relevant topic because Oracle SOA applications sometimes have to ignore the DB Adapter because of complex query creation, special result set handling or just because of performance reasons. But the “normal” way of accessing a database should use the matured DB Adapter (also easy usable from a Spring Bean).

Oracle SCA Spring Beans are running inside of the SCA Container on top of the WebLogic application server (we ignore IBM WebSphere on this example). The data source configuration with appropriate connection pooling happens on the WebLogic Application Server Console. Our Spring Bean should use the existing data source configuration instead of doing own data source configuration on the context configuration file.

The Spring Framework offers an easy way to do a JNDI lookup. The <jee:jndi-lookup> can be used to retrieve and expose JNDI objects. In our case we reuse the existing SOA/MDS data source configuration (jdbc/SOALocalTxDataSource). Real world use cases will do a lookup on own data source or multi data source configurations. The data source will be injected on the Calculator Bean (setter DI).


Inside of the bean implementation the easiest way to do JDBC calls is the usage of the JDBCTemplate (out-of-the-box implementation of the Template-Pattern). Without the abstraction of JdbcTemplate the usage of JDBC would be much more complex and error-prone. Therefore we create a JdbcTemplate instance on the data source setter method and passing the data source.


The JdbcTemplate offers several methods to execute SQL Statements. The methods execute(), query(), update() and batchUpdate() are available for all kind of DML commands. Our use case needs to do execute a select command therefore we use the query() method. If the query returns only one value from the database the queryForInt() or queryForLong() method could be used. Unfortunately Spring don’t offer a queryForDouble() method, so we have to use the more generic queryForObject() method which takes the expected return type as parameter.


In case that the select returns several values the queryForMap() has to be used. The map collection assigns to each column name a value. Finally when we retrieve several rows from the database the queryForList() method has to be used. The list collection contains for each row a map collection.
Finally test the new Calculator Service operations sine, cosine, and tangent (I’m using SOAPUI).


The source code is available as 7-zip here.

That’s it. We created the access on the database inside of a Spring Bean on the Oracle SCA Container. This blog only touches the Spring JDBC topic very briefly. For more details take a look at the Spring JDBC documentation.

Oracle SCA Spring Bean Talks To EJB

My last two blogs are setting the foundation of Oracle SCA Spring Bean development for the next steps on the Calculator Service example. First we build a “bottom-up” Calculator Service based on a given interface class in order to learn the Spring Bean basics (go to blog). The second blog example was giving the Calculator Service a “top-down” interface and re-used the existing mathematical operations as given Spring Bean (go to blog). 

Now we extend the Calculator Service example with an EJB access. This is a practice-relevant topic because Oracle SOA applications running on a SCA Container have to interact with existing EJBs. As the authors of the book “Understanding SCA” Jim Marino and Michael Rowley rightly point out that there are many enterprises which have mission-critical Java EE applications that will remain in production for years to come. The authors further describe SCA as schizophrenic in reference to EJBs. On the one hand, SCA offers a competing technology to EJB, but on the other, SCA extends EJB technology.

In order to extend the Calculator Service we implement a Stateless Session Bean EJB (SLSB) which offers two mathematical operations which we reuse on our Calculator SCA Composite. The EJB offers a square operation and the inverse square root operation.


Access on existing EJBs could be implemented on several ways on the Oracle SOA Suite platform. An easy way of integration would be to annotate the existing EJB with JAX-WS annotations and offer the EJB methods as Web Service operations (assumed that the EJB is implemented on the 3.x EJB standard). On this integration scenario a WS Adapter would be placed on the “External References” swim lane of the SCA Composite.

Another way of integration would be the usage of the EJB Service Adapter. This approach is working well if the EJB is based on the 3.x specification. EJB 2.x access has problems to interact with the EJB Service Adapter based on my experiences. Anyway, if a Spring Bean should talk to an EJB the EJB Service Adapter seems to be unnecessary overhead. The Spring Bean could act as EJB Client in an easy way.

Spring makes it much easier to access EJBs. Additionally, using Spring Beans to access services provided by EJBs allows the implementation of those services to later transparently be switched between local EJB, remote EJB, or POJO (plain java object) variants, without the client code client code having to be changed.

Spring is working with EJB proxy objects for accessing local or remote SLSBs. The configuration of the proxy is shown on the following Spring Bean context file.


The EJBCalculator bean definition creates a proxy for the EJB, which implements the business method interface. The EJB local home is cached on startup, so there’s only a single JNDI lookup. Each time the EJB is invoked, the proxy invokes the create() method on the local EJB and invokes the corresponding business method on the EJB. The ICalculatorServiceBean definition sets the ejbCalculator property to this proxy.

Access on local SLSBs are realized with LocalStatelessSessionProxyFactoryBean proxies and access on remote SLSB are implemented with SimpleRemoteStatelessSessionProxyFactoryBean proxies (commented out on the given context snippet). Read also on the Spring Framework documentation the chapter about EJB Integration.

It’s important to take the matching JNDI binding name. The right jndiName setting on the Spring Bean context file could be taken from the JNDI Tree view of WebLogic.


If the JNDI Name is not matching the right EJB binding name you will not be able to deploy the SCA Composite. A Exception “NameNotFoundException” will stop your deployment.


On the next step the new “square” and “squareRoot” operations have to be added on the Calculator WSDL.


Put the EJBCalculator JAR on the SCA Composite lib folder (\SCA-INF\lib) and define the dependency (Project Properties -> Libraries and Classpath -> Add JAR/Directory). Rewire the WS Adapter with the Spring Bean CalculatorServiceComponent. This will cause a re-generation of the Calculator Service Interface classes.


Add the setter method for the EJBCalculator business interface class on the CalculatorServiceImpl class.


Last step is the implementation of the “square” and “squareRoot” methods which reuse the existing SLSB EJB by a fast local EJB call.


Finally test the new Calculator Service operations (I’m using SOAPUI).


The source code is available as 7-zip here.

That’s it. We created the access on an SLSB EJB and reuse existing operations with a Spring Bean on the Oracle SCA Container.

Oracle SCA Spring Bean Contract-First

My last blog was showing the Oracle SCA Spring Bean basics via a Calculator example application. The example application idea was taken from the Apache Tuscany “Getting Started” web page and demonstrates how easy it is to implement the Calculator example on the SCA Container of the Oracle SOA Suite 11g.


The calculator example had a SCA Composite external Web Service interface bottom-up generated on the Calculator interface class. I don’t want to take part at the religious war on the usage of the top-down (also called contract-first) versus the bottom-up (contract-last) Web Service generation approach. I personally prefer the "contract first" approach, because of interoperability and the control on „data types“ (avoid „type inflation“). But I don‘t damn bottom-up Web Services. It always depends on the intended usage scenario.

The following describes the top-down Web Service interface approach for Spring Beans used on the Oracle SOA Suite 11g in a step-by-step approach. I assume that you have installed the “Oracle SOA Composite Editor” and “Spring & Oracle WebLogic SCA” extension on Oracle JDeveloper. Furthermore I will not repeat the creation of the SCA Components for the AddService, SubtractService, MultiplyService and DivideService services from the last blog example. Keep the already developed CalculatorServiceComponent with the Calculator Components wiring. The CalculatorServiceBeanDef.xml should have no sca:service element and the CalculatorServiceComponent.componentType file has only reference elements.


After setting the start position the first step is the creation the WSDL file. The WSDL file keeps the schema declaration for the WSDL messages and defines the Port Type operations. Only the devide operation has an additional fault message in order to provide a SOAP Fault on a division by zero exception.


Drag and drop a Web Service Adapter from the Component Palette on the Exposed Services swim lane of the SCA Composite canvas. A Web Service interface for the SCA Composite is generated and the Web Service wizard is asking for the name and WSDL URL.


Name the Web Service Adapter CalculatorService and search for the new created Calculator WSDL file (Calculator.wsdl). Because we have only one Port Type the ICalculatorService Port Type is pre-selected. On this example we do not care about the Transaction Participation (default is NEVER).


Wire the WS Adapter with the Calculator Service Spring Bean. This will cause the generation of the necessary Java code.


The interface ICalculatorService class is generated based on the Port Type ICalculatorService. An information popup window will inform you.


Additionally a warning popup window will inform you about necessary changes on the Spring Bean Context Definition file.


That’s the composite.xml view after the creation of a Web Service Adapter on the exposed services swim land and the wiring to the CalculatorService Spring Bean.


Take a look at the Application Navigator view and the generated packages and classes. A new package named calculator.example.suchier was generated. That’s the WSDL targetNamespace (targetNamespace="http://suchier.example.calculator/") in the reverse order. The WSDL port type name ICalculatorService is the name giver of the Java Interface class. All WSDL Message definitions get equivalent Java classes. All generated classes are JAX-WS annotated.


The WSDL SOAP Fault declaration DivideFault becomes a Java Exception class which extends the java.lang.Exception class. That’s the exception which has to be thrown on a division by zero exception. The Web Service client will receive a SOAP Fault response.


The next step is the generation of the CalculatorServiceImpl class which implements the generated ICalculatorService interface class.


Instead of rewriting the existing Calculator Service operations we reuse the existing Spring Bean on the calculator package. So we have to inject the pre-existing Calculator bean. Take a look at the necessary changes on the Spring Bean Context Definition file.


Afterwards we create calculatorService setter and the implementation operations. The divide operation has an additional implementation part for checking the divisor on zero (and throwing an DivideFault exception in case of a zero value on the divisor parameter).


Last step is test the new Calculator service. On the divide operation we could check the “good day” scenario (where the divisor is different from zero).


And we could check the “bad day” scenario (where the divisior is equal zero).


Unfortunately there seems to be a bug on the Spring Bean SOAP Fault implementation. The SOAP Fault is just setting the faultstring element. But the fault detail element is not on the SOAP Envelope (I expected the DivideErrorType faultInfo information on the detail element).

The source code is available as 7-zip here.
That’s it. We create the first contract-first Web Service with Spring Beans on the Oracle SCA Container.