X

Antony Reynolds' Blog

  • November 1, 2004

BPEL - More than Web Services

Antony Reynolds
Senior Director Integration Strategy

BPEL - More than Web Services


A common misconception I come across when talking with customers is that BPEL is only for Web Services.  Whilst BPEL perhaps works best with Web Services it is also possible to access other kinds of service.  Using the WSIF standard it is possible to invoke services exposes as simple HTTP interfaces.  It is also possible to invoke Java classes or, with the Oracle BPEL Process Manager it is possible to embed Java code within a BPEL process.


HTML/XML Across HTTP


Using WSIF it is possible to treat an HTML service as a Web Service and invoke it directly from BPEL..  This is illustrated in the diagram below.





A WSIF file is basically WSDL but with support for HTTP requests.  Parameters can be specified in the WSIF together with the type of request, a GET or a POST.  If the request will return an XML document then the schema of the document can be specified.


If the HTTP service does not return XML then the result will most likely be a string, such as the current stock price. The returned string can also be manipulated in the BPEL process.


Accessing existing HTTP services directly from BPEL allows you to jumpstart your service oriented architecture with components you already have "lying around".


Java Access using WSIF


In addition to making HTTP services appear as Web Services, you can do the same with Java code.  It is possible to call a Java class as though it were a Web Service.


This typically is a two step process.  First you define XSchema types (XSD) for the input and output parameters of all the methods you want to invoke.  You then use a tool to generate the equivalent Java classes.  You now have a shared transfer syntax between the BPEL world (XSchema type) and the Java world (equivalent Java class).


The second step is to create a Java wrapper class that exposes the methods you want to call and packages the shared transfer request input parameters into the correct format for the existing Java code.  You can now invoke the Java code from BPEL as though it were a web service.


Note that the Java wrapper class can be built using the IDE of your choice - I use JDeveloper - giving you full Java syntax checking, code completion, import management and all those other useful features that you come to rely on an IDE for.


The final flow is shown in the diagram below.  The BPEL process invokes what appears to be a web service, but is actually a Java class in the same container as the BPEL process.





This is obviously a very efficient way to invoke Java code, much more efficient than wrapping the Java as a web service and invoking it across SOAP.  There is no SOAP call involved and no need for a seperate JVM (the Oracle BPEL process manager already runs in a JVM).


Java Access Direct from BPEL


Sometimes you just need to invoke a very small snippet of Java code and you don't see a need to re-use it elsewhere.  In this case going to the effort of creating a WSIF file and wrapping your Java code for easy re-use just doesn't seem worth the hassle.  If this sounds like you then you need the "embed" tag.  This allows you to embed non-BPEL code inside a BPEL process.  The Oracle BPEL Process Manager supports the embed tag for Java code.  This allows you to embed Java code directly inside your BPEL process definition, in the same way you can embed Java code directly inside a Java Server Page (JSP).


This use-case is illustrated in the diagram below.





Like code in a JSP, embedded code in a BPEL process can access the environment in which it is running.  This means that you can access variables in the surrounding BPEL process.  These variables can be accessed using XPath expressions, as used elsewhere in BPEL.  Alternatively I find it convenient to generate Java mappings for the variables I need to access, using the same tool used to generate Java mappings in the Java-WSIF case.


The Small Print


There is not much in the way of limitations to calling non-Web Services through the WSIF bindings or the embed tags.  In the Java world you can do pretty much as you want, although the perennial problem of conflicting class libraries may haunt you it is unlikely to be much of a problem.  In the HTTP world the WSIF bindings currently provide no access to the HTTP header fields, if you need this then you will need to drop into Java.  This limitation means that if your HTTP service relies on cookies then it won't work with the current WSIF bindings.  This is something that the Oracle BPEL development team are currently looking at.  Apart from this minor limitation there is not much else that will limit your direct use of HTTP or Java bindings in your BPEL processes.


Summary


There is more to BPEL than just invoking other Web Services.  With the Oracle BPEL Process Manager we can invoke HTTP processes directly as well as calling a native Java code in a simple and efficient manner.  This considerably simplifies the task of orchestrating your existing services in a BPEL environment.  So why not give it a try.  In the Oracle BPEL Process Manager Sample directory there are examples of using WSIF to wrap existing code.  Take a look at it in <BPEL_HOME>samplestutorials702.Bindings for how to do it.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.