Re: [service-orientated-architecture] Is the WS- vision achievable?

Fri, 16 Sep 2005 08:40:06 -0700

Aleksander Slominski wrote: 
XSUL2 <www.extreme.indiana.edu/xgws/xsul> [1] has all of this stuff 
(including improved WSIF APIs, more dynamic AXIOM-like API, handlers for 
security) and more - but it is also research OSS code (under BSD-like 
license) so it has no industry heavyweight to support it but just few 
graduate students ...
Thanks for this Alek.  XSUL2 looks very interesting.  I looked at the link you provided, and found this section:

Dynamic Client: Generating XML-on-the fly

We have very simple to use WSDL dynamic invoker that works fine for simple types, for example:

java -Dlog=trace xsul.dii.XsulDynamicInvoker "http://localhost:3333/decoder?wsdl" runDecoder Topic File Dir 1

If you have complex types you need to generate XML and then apss it to the WSIF runtime The main program uses the xsul WSIFProvider which provides a generic way to talk to any service with only knowledge of the service's WSDL. The WSIF framework automatically generates all the client classes need to make the call on-the-fly. The only part that is specific to our application is in the runClient method: TODO: TBW fill in

The important thing to notice here is the way we create the input message. We are really creating an xml document on the fly. An interesting part in this example is given for the parameter that is an array of strings. In this case the appropriate code is 

        WSIFMessage in = op.createInputMessage();
        WSIFMessage out = op.createOutputMessage();
        WSIFMessage fault = op.createFaultMessage();
        in.setObjectPart("Topic", args[1]);
        String argstring = "";
        for(int i = 2; i < args.length; i++) {
            argstring= argstring+"<item>"+args[i]+"</item>";
        }
        XmlElement sarray = builder.parseFragmentFromReader(
        new StringReader("<StringArr>"+argstring+"</StringArr>"));
        in.setObjectPart("StringArr",sarray);

In this case we are creating an array of strings by explicitly creating an xmlstring and parsing it into a basic XmlElement.

There is nothing in this code about interrogating the schema to build an object model, though (a la JROM).  I also found this in the "Programming with XSUL" presentation elsewhere on your site:
Java client code example: DecoderPortType is Java Interface
generated from WSDL and dynamic stub is client based on service
WSDL and Java Interface that is used to invoke “runDecoder”
operations
DecoderPortType client = (DecoderPortType)
XmlBeansWSIFRuntime
.newClient(“http://somehost/decoder?wsdl”)
.generateDynamicStub(DecoderPortType.class);
responseMsg = client.runDecoder(inputMsg);
Using WS (Client Side APIs)
which looks closer to what I need - it seems to be building a stub class on the fly from arbitrary WSDL found on the Web - but the previous slide suggests that the "DecoderPortType" interface itself is generated via an ANT task at compile time rather than run time.  Have I understood this correctly?  If so, it is not what I need, since my requirement is to build the in-memory object representation of inputs/outputs entirely at runtime so as to offer the user the chance to map attributes in these objects onto data items in their process context.  But perhaps XSUL offers a way to do this?
-- 

All the best
Keith

http://keith.harrison-broninski.info






  





  

  

  YAHOO! GROUPS LINKS









  


































					Reply via email to