SOAInvokerBean not binding to default composite when new version is coming

Question

Hello,
we are using SOAServiceInvokerBean in order to invoke composite form Java application.
We are using SOA Suite 11.1.1.1.5 (PS4)
This is working but when we redeploy a new default version (2.0) of the original (1.0) called composite, invocation of the composite trought SOAServiceInvokerBean invoke the old composite (1.0) and not the new default version (2.0)
Is that the expected behavior ?
Getting a new instance of the SOAServiceInvokerBean from the context doesn't solve anything. We have to restart the soa_server in order for SOAServiceInvokerBean to bind to the new version (2.0).
Edited by: user2514892 on Aug 26, 2011 3:57 AM

Answer 1

Hello Clemens,
In fact we are using [SDO-Based Enterprise JavaBeans Client to Invoke Oracle SOA Suite|http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_sdo_ejb.htm#CCGFEIIC] as indicated in "Developer's Guide for Oracle SOA Suite".
As far as I know, there is no way to specify the version as API is
serviceFactory.createService("MyTestEJBService", HelloInterface.class);So even if rebinding to the default version was performed, there is no way to specify the version form the API. From my point of view this is a missing feature.
For a workaround, I start to explore a way using the oracle.soa.management.facade.Locator in order to search for Composite with default version property then query services of this composite and get the "versioned" service name and then use this name in the “createService” function.
But this method would require the service name to be unique so it would require to modify the composite to introduce an version pattern in the service name like
MyTestEJBServicev1.0
MyTestEJBServicev1.1
MyTestEJBServicev2.0
This is not very good as we are losing functionality to easily deploy a new version (with Jdev integration or through soa ant task) due to multiples modifications required in the composite.
Maybe you have a better way to invoke a composite using some easy way as SDO (in order to not manage the heavy "String" XML message and just stick to java objet) but allowing to specify the version.
We also think about exposing the composite thought a web service (but introducing small security issues as we have to secure this url from outside the server) then use a web-service wrapper (like JAX-WS) in java and invoke the composite like this.
Regards,
Guillaume