Nirmal Mukhi wrote:
Hello Paul,
You do need the port type in addition to the operation name to resolve the operation, since operation names can certainly be duplicated in different port types. WSDL also allows operation overloading within a port type, so you often need the names of the input and output messages as well for resolution.
The simplest way to use WSIF for your needs is to define your own implementation of the WSIFMessage interface that, instead of mapping message part names to java objects representing their values, instead maps the part names to XML elements (or even text strings representing the literal XML). You can then override existing serializers for those schema types with your own serializer implementation (so you just essentially create a SOAP message by adding the namespace declarations etc. and then stick in the XML from the various message parts).
WSIFMessage objects are created by WSIFOperations, which are in turn created by WSIFPorts, which are created by WSIFServices. The WSIFService object is created using a factory. We always desired this kind of flexibility (plugging in your own implementations of these various interfaces), but currently the factory mechanism doesn't allow alternative implementations to be plugged in, so doing what you need will most likely be impossible or at the very least not straightforward. So I would suggest you go for the XSLT approach if you have an immediate need, until we can make WSIF flexible enough to accomodate alternative ways of modeling messages and the like.
I thought that would probably be the case. Thanks for your help.
A couple more questions relating to this.
Considering that for now we will only be using SOAP bindings how hard is it to find a suitable SOAP binding for a given abstract operation ?
Do I need to use WSIF, or would WSDL4J do just as well ?
I have not yet had a look at what is involved in creating an RMI binding in a WSDL file as it is not that important at the moment. It may however be needed in future so I just wanted to ask a couple of questions about it.
As I see it the RMI binding should provide all the information for an application to automatically map from the abstract message syntax to the appropriate Java objects, invoke the remote method and then convert the resulting Java objects back into an abstract message. i.e. it should provide the following:
1) Names of Java classes to serialize / deserialize Java objects to and from the abstract message parts.
2) Locations of jar files containing classes. Obviously there are security implications with this so the classes would need to be used within a sandbox and be digitally signed.
3) Locations of the remote methods.
Is this the way that the RMI binding works or does an application have to pre-specify the jars on the class path ?
The reason that I ask is just to see how possible it will be to provide a generic application that takes an XML message invoke the operation and output the resulting XML message. In a similar way to how the dynamic invoker works on simple types.
