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.
Thanks,
Nirmal.
| Paul Duffin <[EMAIL PROTECTED]>
02/20/2003 01:42 PM
|
To: [EMAIL PROTECTED] cc: Subject: Re: Using XML to represent web service invocation. |
Nirmal Mukhi wrote:
>
> Hello Paul,
>
> This is an XML language that allows you to specify parameters (the WSDL
> being referenced, the message to be used as input, the port type and
> operation being targetted) for dynamic invocation of a web service. Is
> that an accurate statement?
>
Yes.
I was not intending to specify the port type as my understanding was
that within a specific WSDL file the operation names where unique (apart
from overloading). Is this not correct, i.e. can two different port
types within a single WSDL contain operations with the same name that
are not overloaded.
> If so, your problem is how to convert the message the user specified
> into a format the target web service can consume, if I understand
> correctly.
Exactly.
> In order to do your invocation using WSIF, you will need to
>
> 1. parse your XML
> 2. identify the endpoint programmatically (you will create a WSIFService
> object using the WSDL information, then get to a WSIFOperation object
> using the port type and operation name information - see samples and tests)
> 3. create the WSIF message from your XML message. You would extract the
> information from your XML and convert into java objects, then populate a
> WSIF message. You would need to deserialize the values from your XML
> language into a java type. If you use a standard encoding such as SOAP
> encoding or literal encoding (see SOAP encoding styles in the WSDL spec
> or section 5 of the SOAP spec for details), this conversion from the XML
> into java can be automatic.
> 4. do the invocation
>
I would like to use WSIF but do not think that turning the request from
XML to Java back to XML and then doing the reverse for the response
would result in a very nice or performant solution. Also I do not want
to require the user to write Java code to do the serialization.
One very important restriction for this code is that it will be running
on a server and the author of the abstract message may have limited
access and skills.
As a "... message binding describes how the abstract content is mapped
into a concrete format." I think that it should be possible to transform
my abstract content into the concrete format using information in the
message binding. In fact I think that this should be easier than
handling the Java aspect.
Is it possible to use the code within WSIF that identifies the correct
web service to use and chooses the binding without using the
serialization code as well ?
What about creating a java object to simply wrap the XML part of the
message and then when it is serialized it simply writes out the XML.
> An alternative is to just convert your XML into a SOAP message directly,
> using XSLT or some java code. This is possible as long as the encoding
> style you use for message parts matches that expected by the target web
> service. You can actually redefine your XML syntax so that messages look
> more like SOAP messages, in which case the transformation will be
> simple.
This is very possible.
> The drawback to this approach is that you will not be able to
> access services unless they have SOAP bindings (fortunately it is rare
> for a web service to not have a SOAP binding).
>
That is not really that big a problem.
> For more information on the Google web service APIs, you can refer to
> http://www.google.com/apis/. If you download the developer kit from
> there, the soap-samples directory shows some example SOAP messages.
>
> Thanks,
> Nirmal.
>
