Versioning an Oracle ESB service

We recently had a case that required a new version of an Oracle ESB service alongside the old version to provide backwards compatibility. Unfortunately, this is not supported for 10g (10.1.3.4.0) ESB service; it will be with composite services in the 11g SOA suite. One way to accomplish this is to include both service interfaces, but that’was not possible in our case. Another, more rigorously, is to create a new service.
Fortunately, there is another way…

id=”attachment_6596″ align=”alignnone” width=”186″ caption=”Both versions of the HelloWorldService next to each other”

Figure 1 : Both versions of the HelloWorldService next to each other

Normally, when a service is changed and deployed to the ESB, the current version is undeployed first, both from JDeveloper and with the so called esbdeployautomation ant tasks. So it seems we cannot deploy our service a second time .

However, the identification, and undeployment, of the service on the server is done by its GUID that is stored in the .esbsvc file. So if you change the guid you can the deploy the modified server without undeploying the old one and have them both running. Make sure to have them organized in different services or service-groups, as they are included in the URL of the endpoint and both services are thus available on different endpoints. You must change the GUID outside JDeveloper, because the .esbsvc file is read-only in JDeveloper and always opened with the wizard\editor.

We tried to automated this process, e.g. with ant or maven, but that is quite complicated because the servicegroups are also referenced by its guid. In addition, when you change the servicegroup in JDeveloper, the .esbsvc file still contains references to the old situation, e.g. for the soapEndpointURI. Only after deployment from JDeveloper or a sync with the esb does it reflect the latest situation. Another issue is that the namespace and the xsd location remain the same. So you must really take care to test and verify that both services are still functioning as expected.

Some screenshots of my, very simple, HelloWorld database adapter service(s) :

id=”attachment_6604″ align=”alignnone” width=”911″ caption=”HelloWorldService version 1″

Figure 2 : HelloWorldService version 1_0

id=”attachment_6606″ align=”alignnone” width=”913″ caption=”HelloWorldService version 2″

Figure 3 : HelloWorldService version 2_0

Part of the .esbsrv file. Note the updated service guid and the soapEndpointURI that includes the servicegroups :

<?xml version = '1.0' encoding = 'UTF-8'?>
<service name="HelloWorldDAS" guid="XXXC930FE20DA9F11DE8F45BB6A953363AF" qname="MyServices.HelloWorldService.2_0.HelloWorldDAS" status="ENABLED" serviceType="OutboundAdapterService" serviceSubType="DB" typeDescription="oracle.tip.esb.console.servicetype.outbounddbadapterservice" isWSDLEditable="false" soapEndpointStatus="ENABLED">
<versionInfo>
<ID>1259249082393</ID>
<lastModifiedTime>Thu Nov 26 16:24:42 CET 2009</lastModifiedTime>
<lastModifiedUser>JDev_myServices_HelloWorldService</lastModifiedUser>
</versionInfo>
<parent guid="A89250B0DA9F11DE8F45BB6A953363AF" qname="MyServices.HelloWorldService.2_0" type="serviceGroup"/>
<serviceDefinition>
<wsdlURL>HelloWorldDAS.wsdl</wsdlURL>
<portType xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/db/HelloWorldDAS/">tns:HelloWorldDAS_ptt</portType>
<endpointDefinition>
<concreteWSDLURL>/esb/wsil/MyServices/HelloWorldService/2_0/HelloWorldDAS?wsdl</concreteWSDLURL>
<soapEndpointURI>http://localhost:80/event/MyServices/HelloWorldService/2_0/HelloWorldDAS</soapEndpointURI>
</endpointDefinition>
</serviceDefinition>