Custom Search SOABYTE here

Friday, June 25, 2010

Understanding WSIF

Performance and Transactional Differences Between SOAP and WSIF Bindings
Invoking Java resources is usually faster than invoking Web services. Particularly when using plain Java classes, the performance of method invocations is several orders of magnitude better. Java classes are loaded in the application server process and BPEL processes can access their methods directly.
When using EJBs you in general have the choice of using local or remote interfaces. Local interfaces are almost as fast as plain Java classes. The difference arises from the fact that there is a certain overhead of the EJB container. If on the other hand you use remote EJB interfaces, then the performance penalty is larger (but according to my measurements still lower than with Web services, as I will explain shortly). EJB remote interfaces are accessed through RMI-IIOP, which requires a stub on the client side and uses the skeleton on the server side. The remote method invocation has to pass several layers before it reaches the EJB, which takes time. Therefore when using remote interfaces you should use coarse-grained methods and become familiar with other J2EE patterns that influence performance. And keep in mind that some application servers optimize the communication with EJBs if they are deployed within the same application server. With Web services the situation from the performance perspective is even more complicated. In general the communication with Web services is comparable to that with remote interfaces of EJBs. In contrast to EJBs, Web services use SOAP, which is less efficient than binary IIOP. Thus, more processing overhead related to constructing and parsing of SOAP messages and XML serialization is required on the caller and receiver sides. My test have revealed that invoking a Web service is ˜5 to ˜9 times slower than invoking a session bean. Using WSIF to invoke Java resources also provides advantages with transactions. Java resources, such as EJBs and JCA, support transactions through JTA, which makes use of JTS. JTS is based on CORBA Object Transaction Service, which provides support for distributed transactions based on the X/Open DTP standard. Java resources, which support transactions through JTA (EJBs, JCA, etc.), can participate in distributed transactions using the 2PC (Two-Phase Commit) protocol. WSIF supports automatic propagation of transactional context between involved Java resources using the XA interface (automatically exposed by JTS). This means that if you would use several transaction-aware resources from your BPEL process through WSIF (two EJBs, for example), the transaction context would be automatically propagated between resources. Should an exception occur the whole transaction would roll back automatically without the need to define a compensation handler in the BPEL process. Without WSIF-enabled Java resources—or if using Web services only, or first converting Java resources to Web services—you could not take advantage of this feature. Rather, you would have to manually define compensation handlers for each Web service. This is very important for mission-critical processes and simplifies their design and development.
Consider a business process for buying books. This asynchronous process has three Web services: a Book Rating Web service, which returns the rating of a specific book ranging from 0 to 5 (best), and Web services for two identical Book Store services, which return the book price. The process selects the lower price and makes the book purchase.

  In this example fault handlers are defined and the process is divided into scopes (Check 1_BuyBook\BuyBook.bpel). Assume that to obtain a book rating you would prefer to use a Java class, EJB (session bean), service from an enterprise information system that can be accessed through JCA, or a similar Java resource. To incorporate such resources (and possibly any other resources for which a binding exist) into BPEL processes using Oracle BPEL Process Manager, you need only modify the service binding (WSDL), not the BPEL process itself. Thus to replace the Book Rating Web service with a Java class, you only have to modify the WSDL of the Web service (more on that later). WSIF, an Apache technology originally developed by IBM alphaWorks as a part of its Web Services Toolkit, is the underlying technology that makes this approach possible. It extends the Web services model by allowing you to describe services in WSDL, even if it's not a Web service that communicates through SOAP. WSIF also allows you to map such a service to the actual implementation and protocol. In other words, you can bind the abstract description of any partner Web service used in the BPEL process to a corresponding resource, which can communicate using one of the supported WSIF bindings. The WSIF used by Oracle BPEL Process Manager 10.1.2 supports Java classes, EJB, JCA, HTTP GET and POST, and sockets; you can also define custom WSIF bindings and use practically any resource from BPEL. This approach makes BPEL very useful for EAI as well as B2B. Enterprise information systems usually consist of many different software pieces, such as legacy applications accessible though JCA, EJBs, Web services developed on different platforms, and so on. To integrate all these pieces you have to deal with different protocols. For example, if software migrates to a different server or has been upgraded to use a new technology, you have to upgrade the integration code—unless you use WSIF. WSIF offers other important benefits:
  • Invoking services through WSIF maintains the performance of native protocols. Thus, when invoking Java resources, native Java classes, EJBs, or any other resources, you do not have to pay the performance penalty of Web services.
  • WSIF enables automatic propagation of transactional contexts between invoked transaction-aware Java resources using Java Transaction API (JTA). That way Java resources can participate in distributed transactions.
To learn how WSIF works, here you'll modify our BPEL process for buying books and invoke a Java class and then an EJB. Remember that with WSIF you will only have to modify the WSDL of the service, not the BPEL code. Through the modifications in WSDL you will bind the call to the Java resource instead of a Web service. First, we'll focus on using a Java class instead of the Book Rating Web service. To replace the Web service you need to have a Java class with the exact same interface as the Web service; this will require development of a Java class based on the WSDL contract. The other possibility would be to adapt the WSDL to an existing Java class (or other resource, let’s say EJB). The first approach is better, because it is a so-called contract-first approach. This way the interface of the service is adapted to the needs of the BPEL process and not vice versa.


Augustin said...


Nice article. Do you know if in Oracle SOA 11g you may keep same approach? It seems that an EJB Adapter appeared.

Do you know how is possible to define business faults in BPEL which can be mapped to Business Faults raised from EJB?

Thank you,

Post a Comment

Blogger Profile