This recap of some interesting OOW2008 sessions is posted a bit later than expected since my baggage -including notes- was stuck on the airport for a few days. Coincidentally my baggage was stranded at the same airport for which I codesigned the new baggage handling system. Maybe software can have a grudge against its creator after all? Luckily it was another terminal than the one I transferred through.
BPEL PM
There were several interesting sessions on BPEL PM by Clemens Utschig and Robin Zimmermann on the new features in 10.1.3.4, upcoming features in 10.1.3.5, and some useful tips and tricks for problem solving BPEL projects. A summary of the new and improved features in the Oracle BPEL PM 10.1.3.4 patch can be found here. The main objective of this patch is to make the BPEL Console a one-stop-shop. It therefore mainly introduces administrative improvements. The most interesting of these are:
Lost BPEL instances
Actually these instances are not lost, they just don’t show up in the BPEL Console. This is due to rollbacks in asynchronous process instances that are not yet dehydrated. This can e.g. be the case when a time-out occurs and the global BPEL transaction is rolled-back. The problem is solved by using a separate transaction for dehydration and not doing the actual instance’s work in the same transaction as the dehydration.
Deployment plans
This looks very much like the deployment plans already available in Oracle ESB. These plans are used to extract most of the configurable process information that differs per environment. Such information includes URL’s and ports of invoked services, adapter-specific information like inbound file names, JNDI locations of JMS queues, database adapter names, etc. etc. Ant tasks can be used to deploy BPEL processes to a target environment with the configuration of that specific environment. This information is wrapped in a BPEL suitcase. Part of the environment-specific information -not all, especially adapter-related information- could already be externalized using customized Ant builds. When an ESB is used to wrap adapter functionality, the need for deployment plans is not as urgent.
Other improvements in the 10.1.3.4 patch include improved visibility of engine threading model, improved statistics collection, minimization of XML coding errors through compliance testing and enhanced debugging of XML payloads, improved automated recovery agent (this feature was disabled in previous releases), and collection of support information when creating service requests.
Note that some of the latest 10.1.3.3 MLR’s are not included in the 10.1.3.4 patch. You’ll need to apply patch 10.1.3.4 followed by some additional MLR’s to update to the newest version. A preview of the new 10.1.3.5 features are also available in the PDF.
Some other cool stuff presented at OOW2008:
Beehive
Oracle Beehive is launched. Beehive is an integrated, open, and secure collaborative platform. Sort of a new and improved OCS, but then build from scratch. It provides seamless integration with -and abstraction of- all kinds of collaborative tools and technologies such as mail, file system, content management, feeds, calendar, mobile devices, chat, protocols, etc., etc. This is done through the notion of team and personal workspaces. Beehive also includes a Web based interface. Integration with existing user-interfaces or building more advanced user-interfaces can be achieved through its Java API and/or WebCenter Suite. That way you would have a WebCenter frontend communicating with a Beehive backend. See the Beehive website and the Beehive forum.
Enterprise Repository
Some products that were lacking from the Oracle stack prior to the BEA acquisition were related to governance. In the beginning of smaller, integration-aimed, and not enterprise-wide SOA projects technology usually poses a bigger risk than governance. However, in the course of SOA-projects lack of governance quickly becomes the main risk. Next to the runtime Service Registry product from Systinet, Oracle Web Service Manager, and the Enterprise Manager SOA Management Pack that Oracle offers, governance support now also includes the former BEA product Enterprise Repository. This product supports and enables governance at design-time. With this product you can -among others- “harvest” BPEL projects to retrieve artifacts such as processes, WSDL’s, XSD’s, and so on. Enterprise Repository creates a taxonomy out of this and graphically presents this. This way one can see for example what XSD is used by what processes, what policies are attached to what processes, and if these policies are met. Later versions will automate the retrieval of runtime information to automatically determine whether policies such as service response times are met. Publishing repository information to the development environment instead of the other way around should also be possible in future releases.
And this was just a small portion of all the OOW2008 news! See OTN for more information!
Friday, August 29, 2008
Friday, August 22, 2008
The feared “demo-effect” – bluescreen just before our OOW session
Yesterday I arrived in San Francisco to attend and present on Oracle Open World 2008. After a really nice dinner with most of the ODTUG presenters, I quickly went to sleep. The day after -today as I’m writing this blog-, Lonneke and I were going to present the Oracle versus BEA shootout session in Moscone West. Exciting, moreover since the session was fully booked, with more than fifty people on the waiting list. So naturally we wanted to prepare, test, and fine-tune our demo’s this morning.
The day starts good. I had slept for more than 10 hours, my jetlag -that I really felt during the ODTUG dinner- was reduced to a minor disorientation. So far so good. I met with Lonneke to go over the demo’s. First thing that happens when I start my laptop is that I see the feared bluescreen of death telling me that a fatal core dump has occurred (sounds just like Star trek). Meanwhile the presentation was only a couple of hours away. Aarrrgghhh! To keep in Star trek terms, I only needed to realign the dilithium matrix to stabilize the warp field to fix this “coredump”. My laptop caught the demo-effect in its worst form: half our presentation is demo and my laptop is dead! That’s when my heart rate doubled and my blood pressure went to a new all-time high. Lonneke -normally making jokes to cheer you up when something goes wrong- kept quiet this time and looked at me alarmingly. Luckily, restarting computers when they’re broken or don’t do what you want can result in miracles: no bluescreen this time. Guess my computer had a jetlag too. After fixing our BEA demo’s and a quick rehearsal we left for Moscone. Luckily, the demo-virus stayed in the hotel and all demo’s worked perfectly during our presentation!
Later on this week we’ll post more on our Oracle Open World. We’ll also post the demo’s from our presentation later on.
Lonneke at OOW 2008.
Collect all the ribbons and become a fout-star general!
The day starts good. I had slept for more than 10 hours, my jetlag -that I really felt during the ODTUG dinner- was reduced to a minor disorientation. So far so good. I met with Lonneke to go over the demo’s. First thing that happens when I start my laptop is that I see the feared bluescreen of death telling me that a fatal core dump has occurred (sounds just like Star trek). Meanwhile the presentation was only a couple of hours away. Aarrrgghhh! To keep in Star trek terms, I only needed to realign the dilithium matrix to stabilize the warp field to fix this “coredump”. My laptop caught the demo-effect in its worst form: half our presentation is demo and my laptop is dead! That’s when my heart rate doubled and my blood pressure went to a new all-time high. Lonneke -normally making jokes to cheer you up when something goes wrong- kept quiet this time and looked at me alarmingly. Luckily, restarting computers when they’re broken or don’t do what you want can result in miracles: no bluescreen this time. Guess my computer had a jetlag too. After fixing our BEA demo’s and a quick rehearsal we left for Moscone. Luckily, the demo-virus stayed in the hotel and all demo’s worked perfectly during our presentation!
Later on this week we’ll post more on our Oracle Open World. We’ll also post the demo’s from our presentation later on.
Lonneke at OOW 2008.
Collect all the ribbons and become a fout-star general!
Thursday, August 21, 2008
Remotely invoking clustered BPEL Worklist application
Oracle BPEL PM provides a Java API -the BPEL Worklist API- to connect to its Worklist application. There are several blogs that provide sample code on how to use it.
In production-like environments, components invoking the Worklist application can run on different servers for reasons of scalability and failover. This is also the case in one of our projects, where we have a SOA Suite cluster running ESB and BPEL, and another cluster running the ADF and WebCenter front-end. A custom front-end component presents task-related information to the users through a portlet. Tasks are queried and refreshed frequently and a user can have access up to several thousand tasks -not only user-assigned tasks are displayed but also tasks assigned to groups they belong to.
For remotely connecting to the BPEL Worklist application from the front-end components we considered the SOAP and RMI clients that are provided with the Worklist application. The type of client can be specified in the Java code accessing the Worklist application:
or
Note that when using a SOAP client you have to add the statement
The actual configuration containing the information for the client on the Worklist web service endpoints and Worklist Java application is in the
One of the advantages of the SOAP client is that we can use WebCache as software load-balancer for HTTP requests. WebCache is already used in the project to load-balance and failover HTTP calls to external web services, ESB services, BPEL composite services and processes, etc. During stress-testing we found out that using a SOAP client -instead of RMI- roughly results in a 1.5 seconds response time penalty when querying 1500 tasks. That does not include other operations such as rendering tasks. The delay is most likely caused by XML marshalling and de-marshalling. RMI serializes object variables, but does not use the verbose XML format nor does it have to build a DOM tree in memory.
One of the questions that arises is whether failover is achievable using an RMI client. We don’t want a front-end component to be “tied” to only one SOA Suite runtime instance. It turns out this is possible by correctly configuring the
The following piece of code from the
For reasons of standardization a SOAP client is preferable. However low response times and other performance issues are important for good user-interaction. An additional delay of 1.5 seconds every time a user retrieves his or her tasks isn’t acceptable. Instead of using RMI -that is a less standardized protocol- to improve response times, you can also use the Worklist API to not query the entire collection of tasks, but only a certain range. This can then be used in combination with a SOAP client while maintaining acceptable reponse-times. The front-end component does need some modification though to handle navigation and iteration through these task subsets.
In production-like environments, components invoking the Worklist application can run on different servers for reasons of scalability and failover. This is also the case in one of our projects, where we have a SOA Suite cluster running ESB and BPEL, and another cluster running the ADF and WebCenter front-end. A custom front-end component presents task-related information to the users through a portlet. Tasks are queried and refreshed frequently and a user can have access up to several thousand tasks -not only user-assigned tasks are displayed but also tasks assigned to groups they belong to.
For remotely connecting to the BPEL Worklist application from the front-end components we considered the SOAP and RMI clients that are provided with the Worklist application. The type of client can be specified in the Java code accessing the Worklist application:
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.REMOTE_CLIENT) or
WorkflowServiceClientFactory.getWorkflowServiceClient(
WorkflowServiceClientFactory.SOAP_CLIENT)Note that when using a SOAP client you have to add the statement
Predicate.enableXMLSerialization(true) to make sure that predicate information for querying tasks is marshalled and sent to the Worklist application.The actual configuration containing the information for the client on the Worklist web service endpoints and Worklist Java application is in the
wf_client_config.xml file. That file is located in %ORACLE_HOME%/bpel/system/services/config.One of the advantages of the SOAP client is that we can use WebCache as software load-balancer for HTTP requests. WebCache is already used in the project to load-balance and failover HTTP calls to external web services, ESB services, BPEL composite services and processes, etc. During stress-testing we found out that using a SOAP client -instead of RMI- roughly results in a 1.5 seconds response time penalty when querying 1500 tasks. That does not include other operations such as rendering tasks. The delay is most likely caused by XML marshalling and de-marshalling. RMI serializes object variables, but does not use the verbose XML format nor does it have to build a DOM tree in memory.
One of the questions that arises is whether failover is achievable using an RMI client. We don’t want a front-end component to be “tied” to only one SOA Suite runtime instance. It turns out this is possible by correctly configuring the
wf_client_config.xml file. The serverUrl element in the configuration file defines the location of the Worklist application. You can use a comma-separated list of locations like you do when building an RMI initialcontext: java.naming.provider.url = "server1,server2".The following piece of code from the
wf_client_config.xml file achieves failover when using an RMI client to a clustered Worklist application:<ejb>
<serverurl>
opmn:ormi://server01:6003:oc4j_soa/hw_services, opmn:ormi://server02:6003:oc4j_soa/hw_services
</serverurl>
<user>oc4jadmin</user>
<password>welcome1</password>
<initialcontextfactory>
oracle.j2ee.rmi.RMIInitialContextFactory
</initialcontextfactory>
</ejb>For reasons of standardization a SOAP client is preferable. However low response times and other performance issues are important for good user-interaction. An additional delay of 1.5 seconds every time a user retrieves his or her tasks isn’t acceptable. Instead of using RMI -that is a less standardized protocol- to improve response times, you can also use the Worklist API to not query the entire collection of tasks, but only a certain range. This can then be used in combination with a SOAP client while maintaining acceptable reponse-times. The front-end component does need some modification though to handle navigation and iteration through these task subsets.
Subscribe to:
Posts (Atom)