Multiple servies in a single application.

Here are some simple step by step instructions to be able to package two Web Services that implement the same service with different SEI, using a single contract (the wire format as described in the WSDL).

Here is the Ant task once would write to achieve this:


<o:topdownassemble uri="PojoPricer"
output="./to_hide"
classname="com.siebel.ordermanagement.quote.psp.PojoPriceCalculator"
input="./classes"
wsdl="./etc/calculateprice.wsdl"/>
<o:topdownassemble uri="XmlPricer"
output="./to_hide"
classname="com.siebel.ordermanagement.quote.psp.XmlPriceCalculator"
input="./classes"
wsdl="./etc/calculateprice.wsdl"
ear="./dist/${app.name}.ear"
databinding="false"
appendtoexistingdds="true/>


Unfortunately, this will not work, as the two service endpoints are using the same service name.


[o:topDownAssemble] oracle.j2ee.ws.common.tools.api.ValidationException:
Could not update web.xml because "CalculatePricePort"
already exists. The value of generated by wsa is port name.
If bottom-up assembling approach is used, please specify a portName argument
value that does not already exist. If topdown assembling approach or genDDs is
used, put the two webservices in different wars so they do not share deployment
descriptors.



First, you will need to develop the first service instance, using the basic Top-Down assemble method. For now, we will assume that you have already done this. Check the WS User's Guide on OTN.

Now, here are the few steps in question:
  1. make a copy of the primary WSDL, into the one that would be used for the second service endpoint - in our case xmlcalulateprice.wsdl.

  2. change the following names in the new WSDL:

    • the service
    • the binding
    • the port

  3. add a second assemble task on your Ant file. now that you are using a new name for the service and binding, the names are not going to clash, and WSA assemble command will be working just fine. The sample above gives a template of the two top-down assemble command - just remember to use a different WSDL filename.

  4. assemble and deploy the updated application.

It's that simple ;-)


Now, we have two service endpoints packaged in a single .ear/.war file. You can use this in two scenario:

  1. compare the performance of different XML-Java binding options.

  2. deploy a new revision of your service without to break backward compatibility.
You will notice that the changes I have described in step #2 above do not have any impact on the format of the SOAP message on the wire.

To be able to compare the two WSDL files, there is a cool feature in JDeveloper, that will be a time saver for you, if you get acquinted with, before you need to debug broken services - it's the file comparaison utility: select your two files, using the contextual right click menu, uses 'Compare With' -> 'Each Other'. To work well with XML files, the trick is to use the 'Reformat ' option first on both files, so that they have similar linefeed breaks and overall layout.


Comments

Popular posts from this blog

Changing the version of JDK used by JDeveloper

Connection reset from a WCF Web Service

unexpected null value for literal data