Weblog for the AMIS Technology corner
Posts tagged soa suite 11g
Invoke SOA Composite application through RMI as remote EJB (using binding.adf)
Jun 15th
In a recent post I described how we can use the EJB Binding in SOA Suite 11g PS2 to invoke a SOA Composite application through RMI as a remote EJB. This interaction can be fully based on Java interfaces – no WSDL or XML required. However convenient that is, I have not yet been able to make it work for complex arguments or return parameters: methods that use simple types work fine, but using custom POJOs as input or return value did not result in a properly exposed EJB (even though deployment seems successful).
There is another way to invoke a SOA Composite as EJB via RMI. This other way is through the binding.adf binding type. The main difference with the inbound EJB binding is that we communicate in terms of XML (over RMI) with the SOA Suite’s generic Client API – and not directly to a service specific EJB. I was able to get this to work thanks to articles by Edwin Biemond (http://biemond.blogspot.com/2009/11/invoking-soa-suite-11g-service-from.html) and Changjae Lee (http://blogs.oracle.com/jaylee/2009/08/invoking_composite_from_javajs.html). They laid the foundation – and I adapted it for SOA Suite 11g R1 PS2.
The steps we go through:
Expose the Composite service through the binding.adf:
1. Create the SOA Composite application like you always do.
2. Duplicate the service with SOAP binding (binding.ws) and configure the clone as binding.adf (based on the same WSDL).
3. Deploy the composite with this new service of type binding.adf
Publish SOA Composite application as EJB to be invoked from Java applications using EJB Binding
Jun 14th
With the recent (April 2010) SOA Suite 11g R1 Patch Set 2 (11.1.1.3.0), several new capabilities have been added to the SOA Suite. One these is the EJB Binding. Or rather, an enhanced version of this binding. In previous releases, this binding was available to provide interaction with SDO enabled EJBs – based on a WSDL interface and XML messages. The PS2 release added full Java support to the EJB binding. This means that we do not have to concern ourselves with WSDL and XSD that maps to the Java interface we want to invoke or expose, nor with sending a XML based payload when we invoke the composite service. All we need is the Java interface that describes either the EJB that we want to invoke (for an EJB Binding Reference) or that we want to expose (for an EJB Binding Service).
Steps:
1. Create Composite like always
2. Create a Java Interface (and possibly Java domain classes or bean types describing the structure of the input and ouput of the methods on the EJB (that should correspond with the operations available in the Composite application)
package nl.amis.utilities;
public interface FilterAndTranslate {
public String translate(String input);
}
Note: steps 1 and 2 can be reversed; especially when you want to work according to the contract (or design) driven approach, that would probably be best.
Note: thusfar I have only been successful with a Java interface that only uses simple types (my own domain objects and beans prevented deployment of the EJB for some reason)
3. Create an EJB Binding in the Services lane, based on this Java interface. Specify the JNDI Name for this EJB. For example: FilterAndTranslateEJB
Calling an EJB from a SOA Composite Application using the EJB Binding based on Java Interface
Jun 13th
I am currently reworking Chapter 12 for the SOA Suite 11g Handbook. This chapter describes various types of interaction SOA Composite Applications can have with Java applications and components. Since the initial creation of this chapter – some 6 months ago – we have had the Patch Set 2 release of the SOA Suite. This patch set introduced some additional functionality in this particular area of the SOA Suite, including the EJB Binding directly based on a Java Interface rather than on an SDO service created for the EJB. While that last option did the job, it requires manipulation of the EJB that is to be invoked – to SDO enable it – and that was undesirable and sometimes even impossible.
This article describes about the simplest way to get going with the EJB Binding – Java based – in Patch Set 2 (11.1.1.3.0). Building on this example, you will probably find yourself able to do useful things with it.
The steps we will go through are:
1. Create the EJB that is to be invoked from the Composite application through EJB Binding. Make sure the remote interface is created as well.
2. Deploy this EJB (in this simple example to the same WebLogic Managed Server that is running the SOA Suite)
3. Create a new SOA Composite Application
4. Copy the remote interface to the SCA-INF/src directory (or copy a JAR containing that interface to SCA-INF/lib)
5. Create an EJB Binding Reference. Configure it to invoke the EJB created and deployed above; specify the Java Interface that describes the interaction
6. Create a Mediator that is wired to the EJB Binding Reference; create mappings from the input and output of the Mediator to the XML structure derived by JDeveloper from the Java Interface definition
7. Finish the composite application; from here on it is ‘business as usual’ since none of the other components in the applications are aware that the Mediator talks to something ’special’ like an EJB.
Book review of: Getting Started With Oracle SOA Suite 11g R1: A Hands-On Tutorial
Apr 18th
Getting Started With Oracle SOA Suite 11g R1: A Hands-On Tutorial
Authors: Demed L’Her, Heidi Buelow, Jayaram Kasi, Manas Deb, Prasen Palvankar (aka Oracle Product Management for SOA Suite)
A hands-on tutorial is what the cover of the book promises, and that is exactly what you get. A quick, very hands-on introduction into the most important components in the SOA Suite 11g. In no time at all, readers will be able to get a composite application up and running. An application that leverages many of the essential features and functions in the SOA Suite.
Some books are primarily an introduction into a certain topic, with lots of theory, background and explanations of what, why and how. Other books are mainly reference material that you use to look things up when you need them. This book is neither – it offers very little in the way of explanation and background and it would be fairly useless as reference guide. It is however a very good way to get to know the SOA Suite – both design time and run time – and get a feel for how to develop for it and run applications in it.
The book contains a large number of informative screenshots and also provides the salient code snippets. It is very focused on getting specific jobs done, and for these jobs it has all the information and illustrations you may need. It is hard to not get it to work following the very detailed instructions.
The book – or at least the paper copy I am holding – is written for the very first 11gR1 release, that was published on July 1st 2009. The functions made available with PS1 release (November 2009) are not discussed therefore.
Java Callout in Mediator to Automatically Deal With Empty Elements
Mar 18th
One of the most annoying things with XML Schema validation is that it will not accept empty elements of certain types, like xsd:date and xsd:double, even though the element is defined as optional (minOccurs=”0″). OK, I do understand that an empty element _does_ occur, and that this behaviour is therefore correct, but the implication is that developers will have to add <xsl:if> tags in their XSLT transformations around each and every element where this may cause a problem.
This article will show how using a small and generic Java class and the “Java Callout” feature of the 11g Mediator, we can automatically “fix” these empty elements so that they will not cause problems with schema validation any more. Read the rest of this entry »
Automatic testing Oracle Service Bus using Hudson, maven and SoapUI
Feb 23rd
A lot of current projects are implementing some sort of service based architecture. Testing in this architecture becomes more complex. When implementing an OSB project with Scrum you test-automation is imperative. Scrum will require more frequent testing of your system. This is only feasible (in time and money) when you automate as much as possible.
Using soapUI you are able to create visually SOAP tests on your OSB implementation and running them against the defined infrastructure (develop, test, acceptance). SoapUI enables with easy tools to implements verification and validation of the responses of your OSB implementation. When running the test you are also able to set limits in SLA response times on all the calls. This way you are able to monitor depreciation of performance in older parts of your OSB implementation when adding new services.
You can record and edit your SOAP test easy with the soapUI interface and edit it later. When you maven-enable your project it is quite easy running your tests when you implement the “maven-soapui-plugin” (see my other posting http://technology.amis.nl/blog/3061/automated-soap-testing-with-maven). In the meantime version 3.0 of this plugin is released.
When implementing this with Hudson you do not have to convert the results.xml into a Surefire report. Hudson will manage this for you. Hudson will also enable you with an historical overview of all your test results.
SOA Suite 11g – Using Spring Component to mimic Http Binding and integrate RESTful services
Dec 16th
In an earlier post, I showed for the Oracle SOA Suite 11g how we can use the Mediator's Java Callout functionality to integrate RESTful services into our SOA Composite applications, even though we currently have no Http Binding Service nor WSIF support (SOAP Java Binding) at our disposal in the SOA Suite – link to article. In SOA Suite 11g PS1 – released in November 2009 – is the preview (not yet officially supported and only available for PoC and early trials – of Spring components. This feature provides another way of integrating Java classes into our SOA Composite applications.
This article demonstrates how we can use the Spring component to bind our SOA Composite Application to the RESTful Translation service provided by Google.
The Oracle SOA Suite 11g HttpBinding or another way to call RESTful services from SOA Composite Applications
Dec 15th
I wanted to take a quick look at REST(ful) WebServices and see how those can be integrated into the SCA based SOA Composite Applications that we create with the Oracle SOA Suite. Currently, it does not have the HTTP binding that the 10.1.3 release of the SOA Suite used to have. So what are the alternatives?
In this article, I want to demonstrate a way of calling RESTful (simple http request based) services into a SOA Composite application. I show one way of doing so using the Google Translation Service, a RESTful service described at http://code.google.com/apis/ajaxlanguage/documentation/ and to be accessed at http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=hello%20world&langpair=en%7Cit. This service takes a string to translate and an indication of a source and a destination language. Though maybe not formally resource oriented enough to be called REST-style (or RESTful) service by some, it is a service that does not require SOAP or WS* but simply a HTTP Get request. So at least quite restful.
In this article I will use the work I did and described in the previous article: Leveraging RESTful Services from Java application using Jersey (Introduction). Using project Jersey's support for clients of RESTful services and the JSON-SIMPLE library to interpret the response I get from the GoogleTranslation service, I will hook up with the RESTful Service. Then I will leverage the Mediator Java Callout mechanism to integrate this REST-service-client into a SOA Composite application. The Mediator I create will be the fully SOA Suite integrated front-end of this RESTful Service.
SOA Suite 11g – introducing Mediator Java Callouts for debug, audit and …
Dec 13th
The Mediator component in SOA Suite 11g has a the option to specify a Java Callout, one for every WSDL operation. The Java Callout refers to a Java Class, either on the SOA Suite's classpath or deployed as part of the SOA Composite application. This class should implement interface oracle.tip.mediator.common.api.IJavaCallout and a convenient way of doing so is by extending AbstractJavaCalloutImpl in package oracle.tip.mediator.common.api.
The Java Callout is invoked by the Mediator on a number of times, prior to and after performing the Routing Rule and each of the cases in it. The Java Callout class can implement a number of methods, one for each specific event or stage in the Mediator process. These methods get access to the input message as well as the transformation result. That means that the callout class can inspect, validate, log, audit and even manipulate these messages, their payloads, headers and properties. Interestingly enough, the methods are not static what I thought might be the case. The first one to be called is an initialize() that has you initialize the callout class instance to prepare the object for further callout processing. This means that all stages in a single Mediation action are processed by the same callout object. This allows you to compare for example the pre and post transformation values.
The methods that the callout interface specifies are: initialize, preRouting (before any routing rule cases are processed), preRoutingRule (before one specific routing rule is processed), preCallbackRouting (This method is called before Mediator finishes executing callback handling. You can customize this method to perform callback auditing and custom fault tracking.) , postCallbackRouting, postRoutingRule, postRouting.
This article shows a simple example of creating a SOA Composite Application – the simplest one you can create I believe using the new 11g feature of Echo – with use of the Java Callout class.
SOA Suite 11g – Oracle BPEL Master and Detail process coordination using signals
Dec 9th
A BPEL process can communicate with another BPEL process just like it can communicatie with any Web Service – as BPEL processes expose WebService interfaces to the world – or at least to their fellow components in the same Composite Application. When one process – the master in tis discussion – calls another one – it can have several types of interaction and dependency on that other process – we will call it the detail process for the purpose of this article:
- it is not interested at all in the detail process – its call was a one-way fire and forget
- it is interested in the response and it will wait for the response before it can continue processing (synchronous calls will always do this, asynchronous calls could have some activity going on while the detail process is churning away)
- it is interested in the fact that the detail process has reached a certain stage – but it does not actually need a response (it wants a signal but no data)
The Signal and ReceiveSignal activities are Oracle extensions to BPEL – that only work on the Oracle BPEL engine – that help us to implement the third scenario.
As part of the Invoke activity from a BPEL process to another process, we can specify that the called process should be considered a Detail process (and therefore the calling process as the Master process). When we have established this Master-Detail relationship, we can next create a Signal-ReceiveSignal connection between the two. These connections can be created in both directions: the Master sends a signal to the Detail (and the Detail waits to receive the signal) and vice versa the Detail process sends a signal that the Master is waiting for. Unfortunately, as we will see in this article, we cannot have multiple such interactions between a Master-and-Detail pair.
Typical use cases for the signal pattern are situations where a master process can only proceed when detail processes have completed or at least reached a certain state (the master process should only send the email to the customer when the detail process has handed the order to the shipping department) or when a master process calls a detail process to start processing and then needs to do some additional work before the detail process(es) can continue to their next step (master process asks detail to start gathering quotes from car rental companies, than continues to establish the credit-worthiness of the customer and when that has been taken care of indicates to the detail process that it may continue processing).
Note: there is nothing signal .and receiveSignal can do that we cannot also achieve using asynchronous, correlation driven calls. However, when we can achieve our goals using signaling, it is usually much easier to implement and lighter-weight to execute than the full blown correlation based solution.
