Keith Harrison-Broninski wrote: > 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.
thanks! > >> 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? both are supported (but not overly tested): you only need to generate DecoderPorType to make your Java code look "nice" when you want static typing otherwise everything is done in runtime including creation of service skeleton dispatcher and WSIF-like based stub and you can access WSIF-like API to do anything you want with WSDL-described service. > 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? so the runtime layer of XSUL2 that does generation of input/output actually does introspection of XML Schema (embedded in WSDL) to create parameter placeholders so if you want you can get input from command line or show a GUI with input parts (you know what is expected in input) - if you combine this with Xydra it could actually build whole GUI widgets (including nested form inputs for nested complex types). input message is an XmlElement and placeholder are XmlElements (or XmlAttribute) embedded in the input message - the input message XmlElement is special in that it implements WsifMessage interface and has inside XML placeholder fragments built by introspecting XML Schema (right now it is very simple and follows current practices of doc/literal WSDL with complexType/sequence etc). XmlElement is an ultra flexible container and support not only XML Infoset items but also storing any Java objects - the only requirement being that there is some way the Java objects convert themselves into XML infoset when XML message (that contains XmlElement) is materialized for invocation etc. so you can attach any metadata in XmlElement - i use this quite often to attach XML-invisible object that are metadata descriptors but are not to be materialized into XML when sending (conversion is to nothing :)). this kind of flexibility comes very handy when you want to process XML messages in a pipeline and for example do incremental data binding of XML subtrees to Java objects, metadata annotations, etc. best, alek -- The best way to predict the future is to invent it - Alan Kay ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
