I’m working to resolve a couple of issues with the Integration Server’s (6.5) handling of namespaces in relation to Doc/Literal Web Services and the Integration Server’s use of the Doc/Literal Wrapped convention.
As we know there are several variations of how an xml schema can be represented within the Integration Server. There are three scenarios in particular I want to address. A fully qualified namespace, a default namespace, and a partially qualified namespace for elements. I’m going to give examples of each from an instance document point of view instead of the xml schema. I’ll then give examples of how they look in Integration Server form.
Elements are fully qualified with a namespace. In this example there is no default namespace. Here is some ref. material on namespace qualification if your are curious or having trouble sleeping - http://www.xfront.com/DefaultNamespace.pdf and http://www.xfront.com/BestPracticesHomepage.html .
<?xml version="1.0"?> <ser:ServiceResponse xmlns:ser="urn:www.pgn.wbmethod.service.request"> <ser:ticketnumber>han</ser:ticketnumber> </ser:ServiceResponse>
Elements belong to an established default namespace. The lack of a prefix designates a default namespace in xml.
<?xml version="1.0"?> <ServiceResponse xmlns="urn:www.pgn.wbmethod.service.request"> <ticketnumber>han</ticketnumber> </ser:ServiceResponse>
The element ticketnumber is not namespace qualified and is not in the scope of “urn:www.pgn.wbmethod.service.request”. In this scenario namespace qualification applies to the element it is declared on and all children of that element unless a fully qualified namespace has been given. In that case the ticketnumber element would have to have the prefix “ser” to become namespace qualified.
<?xml version="1.0"?> <ser:ServiceResponse xmlns:ser="urn:www.pgn.wbmethod.service.request"> <ticketnumber>han</ticketnumber> </ser:ServiceResponse>
In the Integration Server, the documents that correspond to the above scenarios are given below.
Scenario 1 – In addition to the prefix, the namespace properties for each element are set.
Scenario 2 – This is what it would look like, but you can’t use it in Integration Server without the prefix on the root node. The xml conversion services will bomb out when trying to get it into valid soap message format. It is a valid representation and it does work in other soap processors (it actually works for inbound soap messages to Integration Server) found in .Net and others just not in the Integration Server. Anybody got a default namespace working? (That means no prefixes on this root node). The namespaces are set on the element properties but it doesn’t matter, it does not work without the prefixes.
Scenario 3 –In this scenario the ServiceResponse element is fully qualified but the ticketnumber element does not belong to any namespace. It is local in scope which is valid. However other soap processors (works fine within Integration Server), namely .Net, seem to have problems with this. .Net seems to expect the response to be either fully qualified or have a default namespace. Namespace properties for each element are set in the elements below. I used VS2003 and VS2005 to test this, using their default web services client stub generation program.
I’m curious about scenario 2 and 3. Has anyone been able to get a document in SOAP format using a default namespace? Has anyone tested interoperability with Scenario 3 with .Net using the default .Net web services client stub generator, the add web reference thingy? I know you could handle it by hand.
My thinking here is that you should probably always fully qualify your elements to maximize reuse and avoid potential namespace collisions. What do you think about that? I’m curious as to how others are doing it.
Okay on to Doc/Literal Wrapped style.
The Integration Server has this thing where the input message element name has to match the local name of the service that is being called within the Integration Server. It does this so it can associate an inbound message with the service that is supposed to receive it.
This is all well and good but unfortunately it also corresponds to another spec. which is already out there. https://jax-rpc.dev.java.net/docs/wsdl-bindings.html#doc/litWSDL It is the doc/literal wrapped style.
The unfortunate side affect of this is the way other client stub generators will interpret the WSDL. Instead of generating beans for the input and output messages, the signature of the messages become parameters, similar to a RPC style of message ie createPO(String 1 , String 2, String 3, String 4, etc) . This can get to be very cumbersome to work with especially when there are a lot of elements. The client stub generators are actually working correctly according to the spec but I don’t think that was the effect webMethods was going for when they chose this format. It is possible to turn off wrapped support in some of the client stub generators such as Axis, and even .Net. There is no switch in Eclipse to turn this off.
Anyone else running into this? Sorry for the long post but I had a lot of questions.