Stellan Arpenstr\u00f6m

As of today there will be information added on OTN for the Oracle BEA products. Here are some links to get started with:

Oracle BEA Product Downloads
http://www.oracle.com/technology/software/products/ias/bea_main.html

Architects Center
http://www.oracle.com/technology/architect/index.html

Oracle Service Bus Federation with JMS Store-and-Forward and Dynamic Routing in SOA
http://www.oracle.com/technology/pub/articles/rusman-alsb.html

Deploying The SRDemo ADF Sample Application on WebLogic Servers
http://www.oracle.com/technology/products/jdev/howtos/weblogic/deployingwls.html

This week I'm running a SOA HA class, and one question that usually comes up during these sessions is the one about the Oracle ESB design time instance. As you probably are aware of, this instance can only run in an Active-Passive setup (I will not dwell about the details of that in this post), so the obvious follow-up question, which isn't answered in the Enterprise Deployment Guide, is how do you specify which one of the instance you have configured and deployed the ESB design time on is going to be the default one?

Well, if you follow the instructions in the EDG 3.1.16, where you set:

<process-type id="OC4J_ESBDT" module-id="OC4J" service-failover="1" status="enabled">

you cannot really tell. If you start the instances at approximately the same time, you cannot really say which instance that will be started, for example, suppose that you have configured the instances to be brought up at boot time, and you start the machines at the same time. This might be fine, but under most circumstances you probably would like to select which one that will be the default running ESB design time instance. Well, you obviously always have the option to manually start the selected default instance first, and this problem will then go away.

Using the "service-weight" parameter can help you a bit with this task. The details of this parameter are described in the Process Manager and Notification Server Administrator's Guide. Basically, the higher value of this parameter, the higher priority to use this instance.

So, suppose that you configure the instance on machine Apa as:

<process-type id="OC4J_ESBDT" module-id="OC4J" service-failover="1" service-weight="200" status="enabled">

and the instance on machine Bepa as:

<process-type id="OC4J_ESBDT" module-id="OC4J" service-failover="1" service-weight="100" status="enabled">

OPMN will start the instance on machine Apa, given that they are started approximately at the same time. However, if the instance on machine Bepa has already been started and is up & running, and you then start the instance on machine Apa, OPMN will not bring down the instance on machine Bepa. So, using this solution will only work if the instances are started at approximately the same time.

If you really want to be sure that a specific instance is primary used, like the instance on machine Apa in the example above, you will have to create an event-script in the pre-start section for the instance running on Apa that brings down the instance running on Bepa. This way the instance on Apa will always will be used, regardless if Bepa is already running. There are some drawbacks with this solution that are documented in the OPMN documentation that you should be aware of if considering this solution.

The Coherence 3.4 developer pre-release is now available for download. Please note that this release is only available via Oracle MetaLink for customers with CSI numbers.

Some of the new features are:

• Coherence C++ API
• New Coherence Serialization Framework
• New and Improved Coherence Data Grid Functionality
• Management Framework Enhancements
• and many, many more...

Please refer to the release notes for a full list & complete details on the new features

To obtain the Oracle Coherence 3.4 Developer Pre-Release 1 product, logon to MetaLink and lookup Note 602553.1 and follow the directions.

For further details about the Oracle Coherence 3.4 Developer Pre-Release please refer to this OTN page.

If you read the Database Adapters User's Guide you will sooner or later get to the Performance section, and there you will find DirectSQLPerformance briefly mentioned. However, it is not described in details, so here are some additional comments on this feature.


The Default Behaviour

The normal way for the Database Adapter to work is to use TopLink between the adapter and the Database. This is transparent to the end user when creating a database adapter in either ESB or BPEL. The only hint that you will get that TopLink is involved is in your source project. Here you will find a generated TopLink mapping file and some additional classes used by TopLink within your project. In most cases you will not have to worry about this at all. TopLink behaves like a good citizen within your process, and things work fine.


What is DirectSQL?

This is a feature of the Database Adapter that let it bypass the TopLink framework, and instead use direct JDBC SQL calls to the database. Well, it will not totally bypass TopLink, it will still be used for generating the SQL, obtaining connections, and table introspection. However, other functions of TopLink (for example the cache) will not be used under DirectSQL.

So, why bother about DirectSQL at all? Well it can, under some circumstances, give you better performance. I have found that it is very hard to identify these circumstances and predict when it will and when it won't improve the performance. The advice is basically just to test it, and see if improves the performance or not.


What are the Gotchas?

There are some requirements that need to be fulfilled in order for this feature to work. If you have configured DirectSQL, but some of the requirements are not fulfilled, the adapter will fallback and use TopLink. It will in these cases also log a warning message why it didn't work.

The restrictions that needs to be taken into account are listed below:

• For an Inbound Adapter you must have DeletePollingStrategy.
• For an Outbound Adapter you can only use it with Insert.
• It only works for flat table structures.
• It is limited to work with String, Number, Clob, Blob and Date & Time Types only.
• It does not work with the DetectOmissions feature.

How is it Configured?

It is configured in the adapter WSDL file:

<jca:operation
InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
DescriptorName="myService.PerfOut"
DmlType="insert"
DetectOmissions="false"
UseDirectSql="true"
OptimizeMerge="true"
MappingsMetaDataURL="myService_toplink_mappings.xml" />

Note that you in addition to setting UseDirectSql="true" you must also set DetectOmissions="false", this because DetectOmissions defaults to true.

There are many reasons to like Coherence, below are five of my favourite reasons why I like this product. I have taken away some of the most obvious ones, like it's performance & scalability, and will try to point out a few ones that might be missed at the first glance.

1. It's a Very Cool Product
The last time I ever saw a product that made me raise my eyebrows was when I first saw TopLink, which I guess was sometime back in 2002. At that time I remember that it was a struggle to efficiently map Java objects to relational data. Using pure JDBC calls and populate the objects from the result sets were the common way of doing this back then. It often took efforts & resources to achieve this somewhat effective. TopLink solved that problem so nicely, and all of a sudden the problem no longer existed. Today I feel that with the emerge of SOA applications, we see more and more problems related to performance & scalability and I firmly believe that Coherence will be one product that will help greatly here. (Sorry, I could not resist mentioning performance & scalability...)

2. It's Designed to Handle Failure
At any time any given Coherence node can be taken away from the cluster, and the cluster will still continue to work without interruption. The idea is not to protect individual nodes from failing, but to keep the cluster as a whole alive. In order to do so, Coherence has at any given point in time a pre-defined backup plan on what to do with the data in case of failure of an individual cache node and how to distribute the load among the other cluster members. This is a nice one. Most applications works the other way, they are designed to stay up and does everything to prevent them from dying, even if this means dropping client connections, for example. The clients were lost, but the process managed to stay up. Reminds me of the saying "Won the battle, but lost the war...". I think this approach is one that more applications should take; don't worry if you loose an individual component of the application as long as the application as a whole stays up.

3. It's Easy to Install
It's a small zip archive, ~8M. You just download & unzip, and the installation is finished and you are ready to run. No installers, no product registry, nothing. I really prefer these types of installations to others. It's simple, it's easy and it works.

4. It's Configurable
...and it has reasonable default values. As far as I can recall, I have never came across an application that has such a vast amount options of options in order to alter the configuration to get it to work as you want to. Sure, most applications have the option to alter some of the behaviour with Java and/or XML configurable parameters in order to tweak it, but so far I have not seen any application that comes even close to Coherence on the amount of options you have. Oh, I almost forgot to mention that you could for the options use either Java or XML; you are not restricted to only one of them, which unfortunately is quite common. Did I mention that I also think that most default values make sense, which is unfortunately not so common?

5. It's Extensible & Modular
Suppose that you don't like some parts of how Coherence works. For example, you don't think that none of the default caching schemas that Coherence provides really provides what you want. Well no problem, Coherence provides you with a vast set of Interfaces that you can use in order to build you own implementation that behaves the way you want. Some examples are CacheMap, CacheStore, CacheLoader, and AccessController etc, just to mention a few. This is something that I'd like to see more of in other applications as well.

Deepak Vohra has published a very nice tutorial on OTN on using Coherence from JDeveloper. It gives you a step-by-step guide on how-to get started using Coherence from within JDeveloper.

One thing that you should keep in mind going through this tutorial is if you are running this tutorial on a machine with multiple network cards. For example, you have installed the Loopback Adapter on your PC. As long as you are running a single cache (as in the example) this doesn't give you any issues, but if you startup another cluster node outside of JDeveloper and you want to ensure that they belongs to the same cluster then you should specify the IP address that you want the cluster nodes to bind to, otherwise it could happen that they end up binding to different IP addresses on your machine, for example one binds to your NIC and another one binds to you Loopback Adapter, and in this case they won't belong to the same cluster. By default Coherence will attempt to obtain the IP to bind to using the java.net.InetAddress.getLocalHost() call, so it shouldn't happen, but I've seen this happening, so it can happen.

You can solve this issue by specifying the IP address to bind to by using the Java parameter tangosol.coherence.localhost, like -Dtangosol.coherence.localhost=192.168.96.1 on the command line when starting the external cache. In JDeveloper this would be done in the 'Run Configuration' configuration as described in the tutorial.

Moved this blog to a new address. The new address is http://selectedthoughts.com, the old link should still continue to work.

Had a discussion yesterday about Java & .Net integration. Of course, the usual suspects came up; JNI, J-Integra , JNBridge, JuggerNET, OOJNI etc. However if you do not only need to convert the objects, but also need to have the objects cached for fast transparent access from both Java and .Net, using Coherence is definitely an option.

Coherence provides transparent conversion to and from Java and .Net data types, including custom application user types. This enables .Net applications to access cached Java objects as native .Net objects and Java applications, including data grid members and Java clients, to access cached .Net objects as native Java objects.

Here you can find more details about Coherence for .Net. It is available for download on OTN. The download includes a .Net demo. To run this demo you either need Visual Studio, or you can use SharpDevelop (an open source IDE for the .Net platform).

The latest cumulative patch for SOA Suite 10.1.3.3 is out now (MLR#8). All MLR Bundle Patches also include previous Bundle Patches and the base 10.1.3.3.1 patch, so you need only to apply the latest MLR patch either on top of the main SOA Suite 10.1.3.3 release or on any previous 10.1.3.3.1 MLR patch.

For additional details please have a look at the MetaLink note 553914.1.

The patch number is 6906880 (SOA Suite 10.1.3.3 MLR#8) and is available for download on MetaLink.

The Coherence pages on OTN have been reorganized and updated with a lot of new content. The URL is:

http://www.oracle.com/technology/products/coherence/index.html

A common issue that occurs in all projects is the question about moving an Application between different environments; for example, moving from the Development environment to the Test environment or from the Test environment to the Production environment. Normally this is not a big issue, you just make some modifications to your build scripts (Ant, Maven or whatever you use), or you already have different targets within them for the different environments, and within these targets you point the Application to use the appropriate resources (like Databases) for the different environments. Quite convenient. For most type of resources this approach works fine, however when you use an ADF Application that accesses Web Services via a DataControl exactly how-to do this is not that obvious.

Suppose that you have a Web Services available in a Test and in a Production environment. The URLs are:

Test:
http://MyTestHost/myContext/TheWebServiceSoapHttpPort?WSDL

Production:
http://MyProductionHost/myContext/TheWebServiceSoapHttpPort?WSDL

Now, you create a new JDeveloper project with a Web Service DataControl that point to the Test URL. You then start to browse the project and you find a file called DataControls.dcx. Within this file you find a pointer to a WSDL file (under DataControlConfigs -> AdapterDataControl -> Source -> definition). Great! This must the pointer to my Web Service you think, which is reasonable to believe cause there is no single other reference to a WSDL available within your whole project. So, you modify your Ant build script, creates deployment targets for the different environments that points to the respective WSDL and you deploy to the Test environment. This works fine (well, since the Web Service was generated towards this WSDL, it should). Next, you deploy to the Production environment but now when you run the Application, you still see data from the Test environment. What the ¤%&" going on???

The answer here is that there is a little more to the story then what appears at first sight. If you have a look in the WAR file for the Application, you will notice a file called connections.xml, sounds promising, right, as the connections seems to be the problem here? If you open it, you will find some interesting information, but first...

If you go back and have another look at your DataControls.dcx under the definitions section, you see an element like:

<service name="TheWebService" namespace="http://testwsdcx/" connection="ClientService">

as the connection here is the same as the name in the definition it is easy to believe that this point to the definition, however, that is not the case. The connection attribute points instead to the corresponding Reference element in the connections.xml file. Further, in the Reference section, you will find the real pointers that the DataControl uses to communicate with the Web Service. I said pointers, cause there are two for each Reference element; one to the WSDL (under wsconnection) and one to the Port (under service -> port -> soap).

I might at this point just add for reference that JDeveloper adds this file automatically to the WAR file during deployment; however, I think you have figured that one out already...

So, based on the above discussion we can now solve the problem in two ways:

Option A: Let your build script modify the connections.xml file and point to the correct.

Option B: Copy the whole Reference section for your Web Service connection and give it another name, for example ClientServiceTest and ClientServiceProd. You can then choose which connection to use by pointing the connection attribute in the DataControls.dcx to the correct definition, like:

<service name="TheWebService" namespace="http://testwsdcx/" connection="ClientServiceTest">

Or:

<service name="TheWebService" namespace="http://testwsdcx/" connection="ClientServiceProd">

and of course, you need to handle this in your build script. So far I haven't found any major differences between the approaches, however I think that Option B looks a bit cleaner, but the choice is really yours.

Oh, I almost forgot... The connections.xml file is found on the Application level, not on the Project level, for JDeveloper. It is not visible in the IDE, but you can find it in the .adf/META-INF folder for your Application.

I'm assuming that the Web Services in the example above are identical; just that they are deployed to different machines...

If you try to invoke an asynchronous BPEL process that is deployed to Oracle BPEL Process Manager 10.1.3.3 or later you may end up with an ORABPEL-02118 error. Also, this problem was not seen in earlier versions of Oracle BPEL Process Manager.

This problem occurs due to that the default behaviour regarding variables for completed instances has changed between these versions. In pre 10.1.3.3 release the default behaviour were to keep global variable information along with the instance information for completed BPEL processes. In 10.1.3.3 this behaviour changed for performance reasons, so that the default behaviour is now not to keep any global variables for a BPEL process once the BPEL process has completed.

Note that you can configure this behaviour on a process level basis by using the parameter keepGlobalVariables in the bpel.xml file for the specific process:

<BPELSuitcase>
<BPELProcess src="..." id="...">
<configurations>
<property name="keepGlobalVariables">true</property>
</configurations>
</BPELProcess>
</BPELSuitcase>