The following video demonstrates how the use case described in my previous blog article has been developed.
You can again download the original video if you like to follow it in better quality!
The completed solution can be downloaded from here.
The following video demonstrates how the use case described in my previous blog article has been developed.
You can again download the original video if you like to follow it in better quality!
The completed solution can be downloaded from here.
Update 15.8.2010: Just uploaded the video for this blog article.
In Part 1 of this blog article series I presented how to use the Database Adapter with Oracle SOA Suite 11g in an outbound scenario. I showed a way to keep the JDeveloper project required to define the Database Adapter wrapped inside the Eclipse OSB project. That will become handy when extending the use case as presented in Part 2 now.
In this article I will extend the use case from Part 1 by an Inbound Database Adapter, which should poll the database for changes. The extended scenario is shown in the image below using the notation from the Integration Blueprint book. The elements shown in blue are the new ones added to the use case from part 1.
The Database Adapter will be configured to listen on the PERSON_CHG_T helper table for new records. This table is filled by a trigger on the PERSON_T table and will hold one row for every change to the PERSON_T table.
For each new row in PERSON_CHG_T I want an new OSB service to be called. This new service will use the data from the inbound request and enrich it by re-using the PersonService proxy service we have built in Part 1.
The prerequisites for the 2nd part are obviously the same as in Part 1. The following software needs to be installed and available:
Additionally you need the completed OSB project from Part 1. The solution can be downloaded from here.
The project setup has been done in Part 1. We will reuse the same Eclipse OSB project with the nested JDeveloper SOA Project and just continue where we have left in Part 1.
First let’s create a new Database Adapter.
For that we don’t need a new JDeveloper project, we can reuse the same project we created in Part 1, wrapped inside the adapter folder. I think it’s a good practice to keep all the adapters necessary for one OSB project in only one JDeveloper project.
Let’s go to JDeveloper an open the composite.xml to show the SCA composite view.
This finishes the creation of the Inbound Database Adapter and our work in JDeveloper. We can see the Adapter on the right hand swimmlane.
The adapter is now prepared to poll the PERSON_CHG_T table for new records every 5 seconds. Each row being read will be send to the service linked to the adapter. So let’s switch to the OSB project in Eclipse and create a new service to handle these messages.
When working with Inbound Adapters, an OSB proxy service needs to be used. The adapter will invoke the proxy service whenever a new message “is created” by the adapter.
We can see that the polling Database Adapter worked. A message has been sent to the OSB proxy service holding the ID of the changed PERSON_T row and a timestamp!
In a real world scenario you would now want to do something more meaningful with this information than just logging it to the console, i.e. you want to inform another system about the change. In order to do that, you might need to send more information than just the ID of the person. The system to inform maybe require the person information, similar to the information returned by the PersonService we developed in Part 1. So let’s reuse that proxy service to enrich our message, implementing the Content Enricher design pattern.
To enrich our message, we want to call the PersonService proxy service from the Message Flow of the PollingPersonServiceDB proxy service.
The Content Enrichment worked an the complete and up-to-date person information could now be sent to any system interested.
This finishes the 2nd part of this blog article series.
We have added an Inbound Adapter to the use case to get informed whenever the information changes in the PERSON_T table. By re-using the PersonService from a Service Callout in the Message Flow we were able to enrich the incoming message to a more meaningful “change message”, which could now be used to inform potential external systems of changes happening on the PERSON_T table.
We have used the OSB to implement parts of a typical integration scenario. Similar to one of the scenarios documented in our Integration Blueprint book!
The implementation of a dynamic publish-subscribe mechanism on the OSB, in order to inform the systems interested could be a topic of a next blog article.
The source code for the solution can be downloaded from here. I will again provide a video showing how this extension of the use case has been developed.
The next couple of months will be interesting with lots of exiting events.
Here a list of events I will attend together with the sessions I will give:
Some interesting topics to talk about! Preparing the different topics will definitely keep me busy for the next few weeks.
Would be nice to meet at one of these events!
The following video demonstrates how the use case described in my previous blog article has been developed.
Sorry for the quality of the video. The original is of much better quality but VideoPress seem to have “optimized” it. You can download the original video if you like to follow it in better quality!
Please let me know if you find this kind of video tutorial helpful.
Update 9.8.2010: Just uploaded a video showing how the use case described in this blog has been developed.
Update 15.8.2010: Part II: Using an Inbound Database Adapter has been published today.
The JCA adapter framework we know from SOA Suite is supported by the Oracle Service Bus (OSB) since 10.3.1. The Database Adapter fills one gap of the Oracle Service Bus: there is no OSB transport for accessing a database and accessing the database was previously only possible from an XPath function in read-only mode.
Many blog articles have already been published about using the JCA adapters with Oracle Service Bus. There are two good blog articles from Edwin Biemond and from James Taylor about how to use the Database Adapter with Oracle 10g and 11g. Additionally the Oracle Service Bus Samples page holds a viewlet that demonstrates the usage of the DB adapter with 10.3.1. So why another blog article?
First the Database Adapter is a feature, which deserves many blog articles and second when I went through the samples mentioned above, I’ve found a way to better integrate the definition of the JCA adapter with the OSB proxy service and business service development, which makes the handling much easier.
One of the difficulties when using the JCA adapter framework with the OSB is the two different IDE’s being necessary. The adapter wizards are only available in JDeveloper and therefore for the definition of the adapters JDeveloper needs to be used. After that only the artifacts generated by the adapter wizard (WSDL, XSD, JCA config, toplink mappings, ..) are necessary.
The approaches described by the sources mentioned above show how to create a JDeveloper project first, create the adapters and then copy the necessary files into the OSB projects. What I don’t like about that is the copying of the resources. Of course this can be automated, but when you have to go back an forth between the adapters and the OSB project during development, because you need to change the settings of the adapters multiple times, its just a matter of time until you for once work with an non-actualized version of some files. So how can we avoid that?
Of course we can not change the fact that we have to work with Eclipse and JDeveloper in parallel, until Oracle has moved the whole OSB development environment to JDeveloper, probably with 11R2.
The approach I present here is actually quite simple. Instead of having to separate projects, I just create the JDeveloper project embedded inside the OSB project in a special folder (adapter) as shown in the image below.
By that, all the adapter for one OSB project can be placed in one single JDeveloper SOA project and by that all the generated artifacts are always local to the OSB project. This way they can be used to generate a proxy or a business service directly.
If an adapter needs to be changed, then a refresh on the adapter folder is good enough to pick up the new version of the adapter files. No more copying of files between the two projects is necessary!
Some of the older sample available on the Web show how to use the OSB console to import the artifacts generated by the adapter. This is also no longer necessary! Everything can be done directly in Eclipse in 11g.
The use case I will demonstrate is rather simple. The idea is to make the data of 3 tables in an Oracle DB accessible as a web service in a contract-first approach.
I will use the Database Adapter to access the data, wrap it by a business service and use a proxy service with two XQuery transformation to publish it as a SOAP WebService with its own WSDL and XSD. By that the data is immediately available to any SOAP WebService consumer. I will use SoapUI to demonstrate that.
The scenario is shown in the image below. I’m using the notation from our Integration Blueprint book.
In order to follow the tutorial below, the following software has to be available:
On the Oracle Database you have to install the SOA_SAMPLE schema available in download here. Just execute the cr_obj.sql located inside the database folder.
The Web Service interface (WSDL and XSD) to be published by the proxy service are available in the misc folder in the download. If you follow the tutorial then it’s assumed that this two files are available in c:\temp.
Let’s first create the Oracle Service Bus project and inside in the adapter folder the nested JDeveloper SOA project
All the JCA adapters used by one OSB project can be defined in the same SOA project.
With the project setup in place, let’s now configure the Database Adapter by going through the adapter wizard.
This finishes the work in JDeveloper. Let’s switch back to Eclipse and the OSB project created before.
In order to use the Database Adapter from OSB, we either need a business or proxy services configured to use JCA transport. For outbound adapters, a business service is necessary, whereas for inbound adapters, a proxy service is used.
By that the business service is created and ready to be used. It could already be tested from the OSB console, but we want the service to be reachable from outside via a SOAP Web Service. So let’s create the proxy services doing exactly that.
When creating the proxy service it’s good to first think about the service interface it should provide. A SOAP based WebService interface is what we want, but what format do we use? Can’t we just use the WSDL generated by the Database Adapter also for the proxy service? It’s so easy, isn’t it?
It would be possible, but by that, we would expose information from the database to the outside and by that create a much stronger coupling between the service consumer and the database than necessary. We would use a contract-last approach, where the contract is just generated based on some artifacts already available! A change on the database (table name, column name, data type) would almost for sure have an impact on the interface, something we definitely want to avoid when using the service in a larger context in a Service-Oriented Architecture (SOA).
What we want to use is a contract-first approach, where we can independently define the service contract first. Fortunately that’s well supported by OSB and easily achieved by defining a new WSDL, using it when defining the proxy service and creating two transformation operation to translate to/from the new format.
The WSDL and XSD forming the service contract PersonService is available in the download. It uses a canonical format of a person and its addresses which is somehow different to the format used on the database and independent of any backend service.
For the transformation of the request and of the response we need one XQuery transformation each.
Now the only thing left to do is inserting the two transformations into the message flow.
Before we can deploy and use the OSB service we need to create the necessary objects in WebLogic.
Don’t forget to update the DB Adapter in order to activate the configuration changes.
Now it’s time to deploy and test the OSB service.
Deploy the OSB service to the OSB server and then start soapUI.
This finishes the tutorial of using the Database Adapter with the Oracle Service Bus.
I hope I was able to show how easy it is to integrate the JCA adapter framework with Oracle Service Bus 11g. Although there are two IDE’s involved, the strategy of embedding the JDeveloper SOA project inside the OSB project helps in keeping the OSB project in sync with the SOA project. By that it’s much easier to maintain the adapter, just change the settings by restarting the adapter wizard and after refreshing the OSB project everything is in sync.
In a next blog article I will show how to use the Database Adapter in an inbound scenario, where the adapter will trigger an OSB proxy service whenever a new row is added to the database.
The source code with the implementation of this use case can downloaded from here.