Using Coherence with JDeveloper on Machines with Multiple IP Addresses

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.

New Address

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

Integrating Java & .Net

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).

Cumulative Patch #8 for SOA Suite 10.1.3.3 Out Now

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.

Coherence OTN Page Updated

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

Re-Configuring a Web Service DataControl to Point to Another WSDL

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...

Calling Asynchronous BPEL Process Results in ORABPEL-02118

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>

'Version Mismatch' Problem when Invoking a BPEL Partner Link that has Both SOAP 1.1 and SOAP 1.2 Endpoints

During a recent project we encountered a strange problem. When invoking a Partner Link that is defined towards a Web Service that has both SOAP 1.1 and SOAP 1.2 endpoints defined we got a Version Mismatch fault back. This was quite unexpected, and I assumed that doing some searches on the famous search engine using terms like 'VersionMismatch Oracle BPEL' would yield some relevant hits, but it didn't.

Suppose that you have created a Web Service that have multiple ports and bindings, for example, you have both a SOAP 1.1 and a SOAP 1.2 endpoint defined for the Web service. You have also tested the Web Service using a plain Java Client and that works fine. However, when you try to invoke the Web Service as a Partner Link from BPEL you get the following exception instead of the (expected) result:

<fault>
<remoteFault xmlns="http://schemas.oracle.com/bpel/extension">
<part name="code">
<code>VersionMismatch</code>
</part>
<part name="summary">
<summary>Version Mismatch</summary>
</part>
<part name="detail">
<detail>null</detail>
</part>
</remoteFault>
</fault>

It doesn't matter which endpoint (the SOAP 1.1 or the SOAP 1.2) you define the Partner Link to use. You end up with the exception in both cases. At a first glance it looks like BPEL is either sending a SOAP 1.1 message to the SOAP 1.2 port or sending a SOAP 1.1 message to the SOAP 1.2 port. If this occurs then the SOAP spec requires that a "Version Mismatching" fault is raised for such usage; but if this was the case - why does the error occurs regardless of which endpoint that is chosen???

Also, if you remove either of the ports & bindings from the Web Service WSDL (it doesn't matter which one) and then configures the Partner Link to use the other one, all works fine.

I do not have an explanation for this error, and have only tested it on Oracle SOA Suite 10.1.3.3.

However, there is an easy workaround to the problem:

1. Download 2 local copies to your project of the WSDL for the Web Service.
2. Remove one port & binding (not the same...) from each of the local WSDL copies.
3. Define 2 Partner Links in your BPEL project, one based on each of the local WSDL copies.
4. Implement a Switch to invoke the appropriate Partner Link in your BPEL process.

If you just have the need to invoke either of the endpoints, you of course just need to create one local copy, remove one of the ports & bindings and use this local copy of the WSDL for the Partner Link.

Maintaining Changes to Web Services

A common problem that occurs when working with Web Services is how-to maintaining changes to the WSDL and/or XSD files that are used by the service. The problem occurs when performing changes to the WSDL (or XSD) files like removing operations, renaming operations, changing the structure of data types etc. As you might always not be aware of which clients that are using your service(s); you want to make sure that they continues to work even after you have implemented changes to your service. As support for dealing with this has not been built into the Web services architecture / standards; it is basically left to each implementer to deal with this problem.

One way of dealing with this problem is to use Namespaces versions. The approach for this is as:

1. Use different XML namespaces for different version of the service.
2. Send a specific namespace value along with every SOAP message and result.
3. Based on this value a Web Service implementation (mediator) can then correctly determine what to do with the incoming message.

You first need to ensure that the namespace for the XML elements resulting from that document is unique, for example, suppose that you now are using a namespace like:

targetNamespace="http://example.com/mySchema.xsd".

You then need to change this to:

targetNamespace="http://example.com/2007/11/01/mySchema.xsd"

Where the numbers are year, month and date (it is not likely that you will alter the namespace more than once a day...).

Now each request will be accompanied with a reference to a namespace thus leaving it up to the Web Services to deal with what to do with requests that come in for any particular namespace.

Next thing is to decide what to do with the various types of incoming requests. One approach here is to generate an error if a request for an older namespace is received, and leave it up to the client to deal with this. Another approach is to use a mediator, as mentioned earlier in the post. The task of the mediator is to determine what to do with Web service requests that come in for any particular namespace. This is done by examination of the date stamp on the namespace (introduced in the previous steps) and then route requests from the older namespace to the older version of the Web service, while routing requests from the newer namespace to the new version of the Web service. This means that the URL to the Web Service (the mediator) will always be the same to your external clients, while you are routing it to different services internally.

As a mediator you could either use a Web Service that you write the code yourself for to handle this, or you could look into using our ESB (Enterprise Service Bus) product for this task.

Building a Web Service from a XSD using JDeveloper 11

A few days ago I wrote a post about building a Web Service from a XSD using JDeveloper 10.1.3.3. As a result of this I got a mail from Gerard Davison who informed me that this will be even easier in JDeveloper 11 using the WSDL editor and the top down generator:

1. Create a new WSDL
2. Put the XSD somewhere nearby in the project
3. Tile the editors
4. Pick up the country info element and drop in the empty "PortType" column. The tool will prompt you for the name of the portType, and generate a single operation that takes this types as the input and output message.
5. Pick up and drop the portType on the binding, then the new binding on the services column. You should now have a valid WSDL
6. Now use the generate Java web service from WSDL wizard.

This will now generate all the right code and binding classes in one step without you needing to do any JAXB work.

Thanks a lot for the information Gerard!

It also turns out that we are having a demo for this on OTN, check the one under 'WSDL Editor New Features'.