Weblog for the AMIS Technology corner
Posts tagged soa suite 11g
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.
OOW 2009: Introducing SOA and Oracle SOA Suite 11g for Database Professionals
Oct 11th
The Oracle Open World 2009 conference is almost underway. On Monday 12th October I will do two presentations, and I am done preparing the first one of them (the one that has actually sold one – probably scheduled in a small room).This presentation is one in which I introduce the key concepts and objectives of SOA (Service Oriented Architecture) as well as the Oracle SOA Suite 11g to an audience of database professionals. Whether DBA or Database Developer, SOA is unavoidable. But what (exactly) is it? And how does it impact – positively or negatively – the work and lives of database professionals? What can a database professional do to work well with SOA and the SOA technology once that starts being implemented in her or his organization?
SOA Suite 11g – Composite instance as WebService Result Cache using BPEL Correlation
Sep 17th
This article describes an architectural pattern, implemented in the Oracle SOA Suite 11g, that is somewhat similar to the Oracle Database 11g Function Result Cache. It introduces a SOA Composite Application in the role of Result Cache. In its most simple form, the result cache is initialized – loaded with values -, used by other SOA applications that need the cached values, refreshed/reset when required and terminated. Through this ‘result cache’ – frequently used and not-so-frequently changed values that are published by (possibly remote, expensive or slow-reacting) web services or adapter services can be made available to local consumers in a simple, cheap and fast manner. We achieve this using the fast native SCA binding used for invoking in-container services exposed by fellow composite applications (that’s for speed) and the BPEL correlation mechanism (that’s for finding the result cache in the first place).
What the actual value of this pattern and implementation are is not yet entirely clear to me. Your feedback is appreciated. What I do know is that this article is also a good demonstration of using correlation and of applying some of the XML manipulation techniques available in BPEL processes.
In a single picture, here is what I created: one or more Composite Instances are initialized; each instance is a cache, identified through its name. Upon initialization, the cache is loaded with values – supposedly important, frequently reused, hard-to-get-by values. Composite applications that are interested in these cached values can retrieve them from the cache, by calling the exposed service and passing the name of the cache (here is where correlation kicks in) and passing the name of the cache entry. The BPEL process looks for the entry and returns the value when found or null and an appropriate message when not found.
Chatting from SOA Suite 11g – how BPEL processes can use the XMPP protocol to notify the world
Aug 25th
Various scenarios may require sending email messages or other types of notifications to users as part of the process flow. For example, certain types of exceptions that cannot be handled automatically may require manual intervention. For example, a BPEL process can use the notification service to alert users by voice, IM, SMS, or email.
In a previous article (http://technology.amis.nl/blog/6019/configure-soa-suite-11g-for-sending-email-notifications-with-google-mail) I described recently how the fairly new SOA Suite 11g can use GMail or other public Email servers to send notifications, for example from BPEL processes or the Human Workflow Service. The SOA Suite 11g works with the User Messaging Service (UMS) to perform that feat and the essence of said article is to configure the email driver in UMS to use GMail – or any other email server for that matter.
This article looks at one of the other communication channels available in UMS, and also available to BPEL processes: Instant Messaging or Chat. After configuring the UMS XMPP driver in the Enterprise Manager console, the Chat channel is available to any BPEL process. We will discuss how to configure – and with which configuration details for Jabber.org – and subsequently how to make use of that communication channel from a BPEL process.
SOA Suite 11g (TP4) – Create Mediator based SCA Composite Application from XSD – write to output file using File Adapter
Jan 22nd
A quick overview of you can create an SCA Composite Application that publishes a WebService interface, accepts SOAP Messages and write their contents to a file, appending a new record to the current contents. In the center of the composite sits a Mediator. Its interface is based on a WSDL that is created directly from an XSD document that describes the XML messages that have to be processed. The Mediator is then exposed as Service through a simple drag & drop operation. An outgoing file adapter service is created that writes its input in a comma separated record format to an existing file. Finally with another drag and drop, the Meditor is wired to this File Adapter Service and – with more dragging & dropping – the mapping between the incoming XML message and the outgoing CSV record is created.
This is all done using Oracle 11g SOA Suite, Technology Preview 4.
