About a month ago Antony Reynolds and myself were interviewed for ArchBeat which provides an online forum for the Oracle Technology Network (OTN) Architecture Community. The interview was carried out by Bob Rhubart around our latest book the Oracle SOA Suite 11gR1 by Bob Rhubart.
The interview not only covers the book, but takes an opportunity to examine how things have changed in SOA since we released our original book covering the 10g platform. In addition to covering what we believe are the key changes in the Oracle SOA Suite, we also give our views on how SOA has matured as an approach as well as its adoption by customers.
The first part of this interview, has now been released as a pod cast and can be found here. Have a listen see what you think, and see whether you agree with Antony and myself!
Saturday, 16 October 2010
Friday, 16 July 2010
SOA Suite 11gR1 Developer’s Guide Published!
Well I'm both delighted (and relieved) to announce the publication of the 11gR1 version of the SOA Suite Developer’s Guide. As with the original version, this was jointly written by Antony Reynolds and myself; in fact in many ways this is the book that Antony and I originally intended to write, when we first put pen to paper (or finger to keypad) back in May 2007. At this point the 11gR1 version of the Oracle SOA Suite was still in the initial stages of development, with the ‘goal’ being to time the publication of the book with the release of 11gR1.
Then in early 2008 Oracle announced the acquisition of BEA, which it finalized in July; at this point future timings around the release of 11gR1 were very much up in the air. So we re-focused the book on 10gR3, of course no sooner had this been published and Oracle released 11gR1! So after a brief pause to catch our breath and restore our sanity, Anthony and I pulled out the original manuscripts and started again.
As with most books, there is a huge amount of support and effort behind the scenes. We had a great team of reviewers who provided invaluable feedback and encouragement:
In addition we had great support from the SOA product management team at Oracle, and the editorial team at Packt Publishing who played a key role in keeping us on schedule!
The new book contains approximately 40% new content and is slightly larger than the original. But we made a very conscious effort to try and stop the book from getting to big, so as we introduced new content, we tried to condense (and in some cases remove) material in other areas. We hope we have the balance right, and that readers will get as much (or more) benefit from this version as they did the last.
Monday, 6 July 2009
Downloading the SOA Design Time for JDeveloper 11G
Oracle Fusion Middleware 11G Release 1 was officially launched by Oracle on the 1st July 2009; included in this release are the 11G version of WebLogic, SOA Suite, WebCenter and Identity Management. You can download all of the required components from http://www.oracle.com/technology/software/products/middleware/index.html.
Installing the Oracle SOA Suite is pretty straight forward; however the one gotcha is the install of JDeveloper 11G does NOT install the SOA Design Time. This is not really an issue as JDeveloper automatically checks for updates (including the SOA Design Time) and will prompt you to download and install them (alternatively select Help->Check for Updates).
However the SOA Design Time is 200+ MB in size. So not a trivial download, particularly if you are installing JDeveloper in multiple environments. Ideally it would be nice to be able to download a local copy of the SOA Design time extension which can then be installed in each environment that is required. Well fortunately you can do this by going to the Oracle JDeveloper product updated center shown below. From here click on the download link for the SOA Oracle Composite Editor (circled below).
To install the design time, within JDeveloper select Help->Check for Updates. Click Next and Select Install from Local File and browse to where you saved soa-jdev-extension.zip. Click Open, click Next and then Finish. JDeveloper will then install the extension; finally restart JDeveloper when prompted.
Installing the Oracle SOA Suite is pretty straight forward; however the one gotcha is the install of JDeveloper 11G does NOT install the SOA Design Time. This is not really an issue as JDeveloper automatically checks for updates (including the SOA Design Time) and will prompt you to download and install them (alternatively select Help->Check for Updates).
However the SOA Design Time is 200+ MB in size. So not a trivial download, particularly if you are installing JDeveloper in multiple environments. Ideally it would be nice to be able to download a local copy of the SOA Design time extension which can then be installed in each environment that is required. Well fortunately you can do this by going to the Oracle JDeveloper product updated center shown below. From here click on the download link for the SOA Oracle Composite Editor (circled below).
To install the design time, within JDeveloper select Help->Check for Updates. Click Next and Select Install from Local File and browse to where you saved soa-jdev-extension.zip. Click Open, click Next and then Finish. JDeveloper will then install the extension; finally restart JDeveloper when prompted.
Saturday, 13 June 2009
Arch2Arch Podcasts
The Oracle Technology Network Arch2Arch Podcast brings together architects and other experts from across the Oracle community and beyond to discuss the issues, tools, and technologies that are a daily part of the software architect's ever-changing world. I've always enjoyed these podcasts and find them an extremely useful and convenient source of information.
Their latest podcast, is part one of a two part interview by Bob Rhubart (the host of Arch2Arch) with Antony Reynolds and myself about our book the Oracle SOA Suite Developer's Guide. The interview is truly international with Bob carrying out the interview based in California, Antony in the UK and myself from a hotel room in Sydney, Australia (about 8am in the morning).
It's quite strange hearing yourself speak, but what struck me is how English Antony sounded! Have a listen and see what you think (and whether I’ve picked up an Aussie twang) and whilst you’re their check out some of the other excellent podcasts as well.
Their latest podcast, is part one of a two part interview by Bob Rhubart (the host of Arch2Arch) with Antony Reynolds and myself about our book the Oracle SOA Suite Developer's Guide. The interview is truly international with Bob carrying out the interview based in California, Antony in the UK and myself from a hotel room in Sydney, Australia (about 8am in the morning).
It's quite strange hearing yourself speak, but what struck me is how English Antony sounded! Have a listen and see what you think (and whether I’ve picked up an Aussie twang) and whilst you’re their check out some of the other excellent podcasts as well.
Saturday, 18 April 2009
Top 5 Insights for Maximizing Returns with SOA
Oracle are hosting a live webcast on some of the key insights gained by customers who have successfully implemented SOA based solutions within their organization.
They will be covering areas such as; building a business case for SOA, strategies for adopting SOA, critical success factors as well as some of the efficiency drivers and cost savings achieved through the deployment of SOA based solutions.
Participating executives include:
The webcast is scheduled for April 23 8:00 a.m. PT / 11:00 am ET / 4.00 pm GMT. To register click here.
They will be covering areas such as; building a business case for SOA, strategies for adopting SOA, critical success factors as well as some of the efficiency drivers and cost savings achieved through the deployment of SOA based solutions.
Participating executives include:
- Job Simon, Senior Director, NetApp
- Dan Goerdt, Director, Schneider National Inc.
- Jennifer Briscoe, CTO and VP, Collect America
The webcast is scheduled for April 23 8:00 a.m. PT / 11:00 am ET / 4.00 pm GMT. To register click here.
Saturday, 11 April 2009
Writing a 'Singleton' BPEL Process
A typical use case in BPEL is connecting to an external resource / system which only support a single connection at a time. In such a case we need to protect against parallel BPEL instances submitting concurrent requests to that resource.
This implies that we need some way to serialize requests for that resource (probably on a first in first out basis). A common design pattern for achieving this is the Singleton, first documented in the Gang of Four's patterns book (where they use a print spooler as an example).
Now BPEL doesn’t explicitly support the notion of a Singleton, however it does allow you to simulate one, which for the purpose of what we are trying to achieve is good enough.
The basic idea is to have an explicit initiateSingleton operation which is used to instantiate a single process instance, and then have a separate invokeSingleton operation which is used to submit each actual request. The invoke operation is then placed in a loop, so as soon as it’s processed one request it loops back round for the next one.
For this example, I’ve just created a simple process which keeps track of the number of times it’s been called. It takes a single parameter, name and returns a string of the following format:
Hello <name>. You are caller number <count> of this singleton.
Pretty simple, but it illustrates the point. The basic process is shown in the screenshot below:
The first activity in the process is a receive activity, InitiateSingleton, which is used to instantiate the process. We then have a simple assign which just sets the count to zero. The remainder of the process, which handles the invokeSingleton operation is contained within the ProcessRequest scope, which itself is placed inside a while loop, that loops for ever. This contains the following activities:
The reason is that when we invoke an operation on a BPEL Process, the message is received by the Oracle BPEL PM Message Handler, depending on the operation it will either invoke a new process to handle it (as with the initiateSingleton operation) or route it through to the appropriate instance of an already running process.
This is where it gets a bit convoluted, when we receive the message for the invokeSingleton operation, even though we only have a single instance of the BPEL process running how does BPEL PM know that it is the correct instance to route the message to? The answer is it doesn’t.
Now under “normal” circumstances, where we have an asynchronous interaction between two processes, Oracle BPEL PM defaults to using WS-Addressing to ensure that messages are successfully routed between two process instances. However in these cases, it’s typical that the interaction between the two processes (say A and B) began by process A initiating process B and passing it details (using WS-Addressing) about itself so that when process B sends back a response it contains sufficient information for it to be routed to the appropriate instance of process A.
However with our Singleton process, any process calling the invokeSingleton operation will have no prior knowledge of that process, so for our purposes we can’t use WS-Addressing to correlate the message.
Fortunately for situations where WS-Addressing isn’t appropriate or available BPEL provides the concept of correlation sets. Essentially correlation sets allow you to use a unique value present in the message body of all exchanged messages (e.g. orderId) to link that exchange of related messages together.
You do this in BPEL by first defining a property which corresponds to the unique value, and then defining a property alias for each message in the exchange, that defines where that property is located within the message. Next you define a correlation set which can consist of one or more properties (see the product documentation or the Oracle SOA Suite Developer's Guide
for more details on how to create Correlation Sets).
For our purpose, I’ve defined a simple element called singletonId which is contained in both the initiateSingleton and invokeSingleton operations.
Next we have defined a correlation set SingletonCS which is used in the InitiateSingleton and InvokeSingelton operations.
On the initiateSingleton operation I’ve defined this to initiate the correlation set (see screenshot below), this means whatever value is contained with the singletonId in the start operation must be present in the invokeSingleton operation for it to be routed through to this process instance.
The next part of the problem is to return the response back to the appropriate caller of the process. This at first may seem strange, but recall we may have several processes calling the singleton at the same time, and thus all waiting for a response. We need to ensure that each response is returned to the appropriate instance.
Now you’ve probably already guessed that we need to use correlation sets again (as we have disabled WS-Addressing for this Partner Link). This time the calling process will need to generate a unique key that it passes in the request (requestId) to the singleton. The singleton will then return this in the response to the requester.
If we look at the SingeltonAccessor process, we use the XPath operator generateGUID to generate this value.
Now it turns out that this is quite a rational behaviour for the simple reason that the Singleton doesn’t actually know where to send its callback to. This is because at design time the caller of an asynchronous process typically isn’t known, and thus the callback address needs to be specified at runt time. In fact if you log into the BPEL Console and examine the WSDL for the call back operation, you will see that the soap:address location for the endpoint is defined as:
http://set.by.caller
Now by default Oracle BPEL PM uses WS-Addressing to handle this, thus when I invoke an asynchronous process, part of the SOAP payload contains a return address for the asynchronous process, however we’ve just disabled WS-Addressing for this message exchange as we are using correlation sets.
So how do we provide the reply to address? Well one way would be to pass this in as part of the request message and then use dynamic partner links to set the replyToAddress.
However a simpler way is to define the replyToAddress property on the partnerlink to point to the reply address. This takes the format:
<wsdl endpoint>/partnerLinkTypeName/[rollName]
So in our case:
http://server:port/orabpel/default/SingletonAccessor/1.0/Singleton/SingletonRequester
Now if we deploy this it should finally work. To run the example, first go into the BPEL Console and initiate the Singleton process (set Singleton Id to "Singleton/1.0").
From the console initiate the SingletonAccessor entering whatever value you like for the name. You could kick off a number of these to see what happens.
Actually the solution to this is very straight forward; you use the SingletonAccessor as the entry point for accessing the Singleton. Thus the real client will always call the SingletonAccessor.
Thus the client never needs to know the SingletonId, and secondly as WS-Addressing remains turned on between the “real” client and the SingletonAccesor the client doesn’t need to worry about correlation sets or specifying a replyToAddress.
One final question you may have is how do I prevent multiple instances of the Singleton process being kicked-off by mistake? Well why not try it? You will see that as long as you specify the same value for the SingletonId, BPEL PM will throw a “Conflicting Receive” fault as an equivalent receive activity has already been enabled by the original Singleton.
As we can see, implementing a Singleton within BPEL is relatively straight forward. Whilst this is not a totally clean solution, it does achieve the desired effect.
Click here to download working example.
This implies that we need some way to serialize requests for that resource (probably on a first in first out basis). A common design pattern for achieving this is the Singleton, first documented in the Gang of Four's patterns book (where they use a print spooler as an example).
Now BPEL doesn’t explicitly support the notion of a Singleton, however it does allow you to simulate one, which for the purpose of what we are trying to achieve is good enough.
The basic idea is to have an explicit initiateSingleton operation which is used to instantiate a single process instance, and then have a separate invokeSingleton operation which is used to submit each actual request. The invoke operation is then placed in a loop, so as soon as it’s processed one request it loops back round for the next one.
For this example, I’ve just created a simple process which keeps track of the number of times it’s been called. It takes a single parameter, name and returns a string of the following format:
Hello <name>. You are caller number <count> of this singleton.
Pretty simple, but it illustrates the point. The basic process is shown in the screenshot below:
InvokeSingleton – This receives the next request to be processed by the singleton. Wait – This waits for a period of 5 seconds. It is just to simulate going out to an external system. It also enables us to see how multiple requests for the singleton are queued up by the Oracle BPEL PM Server. SetResult – Here we just set the result and increment the count by one. CallbackClient – Finally we just send back the result to the client; before looping back round to process the next request.
Message Correlation
At first glance this all looks deceptively simple, however the complexity comes when you try and call the invokeSingleton operation.The reason is that when we invoke an operation on a BPEL Process, the message is received by the Oracle BPEL PM Message Handler, depending on the operation it will either invoke a new process to handle it (as with the initiateSingleton operation) or route it through to the appropriate instance of an already running process.
This is where it gets a bit convoluted, when we receive the message for the invokeSingleton operation, even though we only have a single instance of the BPEL process running how does BPEL PM know that it is the correct instance to route the message to? The answer is it doesn’t.
Now under “normal” circumstances, where we have an asynchronous interaction between two processes, Oracle BPEL PM defaults to using WS-Addressing to ensure that messages are successfully routed between two process instances. However in these cases, it’s typical that the interaction between the two processes (say A and B) began by process A initiating process B and passing it details (using WS-Addressing) about itself so that when process B sends back a response it contains sufficient information for it to be routed to the appropriate instance of process A.
However with our Singleton process, any process calling the invokeSingleton operation will have no prior knowledge of that process, so for our purposes we can’t use WS-Addressing to correlate the message.
Fortunately for situations where WS-Addressing isn’t appropriate or available BPEL provides the concept of correlation sets. Essentially correlation sets allow you to use a unique value present in the message body of all exchanged messages (e.g. orderId) to link that exchange of related messages together.
You do this in BPEL by first defining a property which corresponds to the unique value, and then defining a property alias for each message in the exchange, that defines where that property is located within the message. Next you define a correlation set which can consist of one or more properties (see the product documentation or the Oracle SOA Suite Developer's Guide
for more details on how to create Correlation Sets).For our purpose, I’ve defined a simple element called singletonId which is contained in both the initiateSingleton and invokeSingleton operations.
Next we have defined a correlation set SingletonCS which is used in the InitiateSingleton and InvokeSingelton operations.
On the initiateSingleton operation I’ve defined this to initiate the correlation set (see screenshot below), this means whatever value is contained with the singletonId in the start operation must be present in the invokeSingleton operation for it to be routed through to this process instance.
Now you’ve probably already guessed that we need to use correlation sets again (as we have disabled WS-Addressing for this Partner Link). This time the calling process will need to generate a unique key that it passes in the request (requestId) to the singleton. The singleton will then return this in the response to the requester.
If we look at the SingeltonAccessor process, we use the XPath operator generateGUID to generate this value.
Specifying the Reply to Address
So now everything looks fine, so we can go ahead and run the process; well not quite! If you do you will notice that request from the SingeltonAccessor successfully reaches our Singleton process. But for some reason the response from the Singleton never reaches the SingeltonAccessor, in fact if you take a closer examination of the Singleton Audit trail for the callback activity you will see that it actually skipped the callback!Now it turns out that this is quite a rational behaviour for the simple reason that the Singleton doesn’t actually know where to send its callback to. This is because at design time the caller of an asynchronous process typically isn’t known, and thus the callback address needs to be specified at runt time. In fact if you log into the BPEL Console and examine the WSDL for the call back operation, you will see that the soap:address location for the endpoint is defined as:
http://set.by.caller
Now by default Oracle BPEL PM uses WS-Addressing to handle this, thus when I invoke an asynchronous process, part of the SOAP payload contains a return address for the asynchronous process, however we’ve just disabled WS-Addressing for this message exchange as we are using correlation sets.
So how do we provide the reply to address? Well one way would be to pass this in as part of the request message and then use dynamic partner links to set the replyToAddress.
However a simpler way is to define the replyToAddress property on the partnerlink to point to the reply address. This takes the format:
<wsdl endpoint>/partnerLinkTypeName/[rollName]
So in our case:
http://server:port/orabpel/default/SingletonAccessor/1.0/Singleton/SingletonRequester
Now if we deploy this it should finally work. To run the example, first go into the BPEL Console and initiate the Singleton process (set Singleton Id to "Singleton/1.0").
From the console initiate the SingletonAccessor entering whatever value you like for the name. You could kick off a number of these to see what happens.
Loose Ends
So that all works, however there are two basic problems with this approach:Firstly to invoke the Singleton you need to know the value of the SingletonId. This in our case is fixed within the SingltonAccessor process. Secondly, the Singleton process will only ever return a result to the SingletonAccessor process (as this is fixed by specifying the replyToAddress). What if we want to call it from another process or web service client?
Thus the client never needs to know the SingletonId, and secondly as WS-Addressing remains turned on between the “real” client and the SingletonAccesor the client doesn’t need to worry about correlation sets or specifying a replyToAddress.
One final question you may have is how do I prevent multiple instances of the Singleton process being kicked-off by mistake? Well why not try it? You will see that as long as you specify the same value for the SingletonId, BPEL PM will throw a “Conflicting Receive” fault as an equivalent receive activity has already been enabled by the original Singleton.
Conclusion
As we can see, implementing a Singleton within BPEL is relatively straight forward. Whilst this is not a totally clean solution, it does achieve the desired effect.
Click here to download working example.
Saturday, 7 March 2009
Oracle SOA Suite Developer's Guide
It's been way too long since I last posted a blog. It's not that I've been too busy to write which would be the normal excuse!Rather quite the opposite; I've actually been busy writing a book with Antony Reynolds on the Oracle SOA Suite.
We actually finished writing the book back in January, but since then have been busy finishing up the sample application that comes with the book (which we have now completed).
- The book itself covers all the key components of the Oracle SOA Suite, namely:
- Service Bus (formerly the Aqualogic Service Bus)
- BPEL Process Manager
- Human Workflow
- Business Rules
- Business Activity Monitoring
- Web Services Manager
The book itself is bang up to date with all examples built on version 10.1.3.4 of the Oracle SOA Suite, and covers areas that are not that well documented in the official manuals such as the Workflow Service API, BPEL Fault Management Framework, etc.
So now the books is finished, I’ll actually have some more time, so expect to see a few more blogs in the next couple of months :-)
Subscribe to:
Posts (Atom)
