Re: Is there any opensource library can do the work JROM does?

hi, alek, if you use XML directly, it is fine for the document/literal case,
however, can this be suitable for the rpc/encoding case?
Instead, i will follow the steps below.
1 for a specific operation, i parse the WSDL to find out the input message
definition, and the parts declared, and the order that these parts should
follow if necessary.
2 given a piece of XML data corresponding to the input message, transform
the XML Data into JROM objects corresponding to the parts of the input
message.
3 invoke the operation with WSIF.

I am still thinking about the details, but these are the general steps that
i may follow. Maybe i am not understanding your solution well, and i wonder
if your approach can handle the rpc/encoding case, or if the binding details
can be transparent to the users^_^
Best Regards:)
robin

在06-4-2，Aleksander Slominski <[email protected]> 写道：
>
> 邹志乐 wrote:
> > Well, i am not providing some client invocation tools, just as you
> > mentioned, there has been a lot, such as the one contained in the
> > eclipse WTP. I want to offer a java library to fasilitate the service
> > invocations in most cases, so that we only need to provide the
> > following information for each invocation:
> > 1 the location of the wsdl document
> > 2 the names of the port and the target operation
> > 3 the input and output in suitable forms.
> > And we don't have to care about anything else.
> hi robin,
>
> OK i think i my be missing something :) but it looks to me that XML is a
> 'suitable form'? just let client pass input XML even as a string then
> parse it to some representation (DOM) and send it. i did something like
> this in XWSIF (my experimental/prototype version of WSIF) that you may
> find interesting in this context - it allows to send any XML as
> WSIFMessage extends XmlElement - there is more to it but that is the
> gist of it - see http://www.extreme.indiana.edu/xgws/xsul/ and check
> advanced samples and unit test cases (XWSIF is different than Apache
> WSIF as in the Apache implementation what you could get is to have a
> part inside WSIFMessage to be DOM Element but not the whole WSIFMessage)
>
> though there may be other approaches to get what you need ...
> > Only with WSIF, we have to generate the classes for the complex
> > datatypes, and then register the mapping between the xml schema
> > element and the java mapping. This is fine, but for those cases, I
> > don't want to generate the java classes for the complex datatypes.
> > JROM may be a solution, it can deal with the XML or XMLSchema
> > directly, and we can represent the complex-typed values without
> > generating the corresponding java classes, and it comes with a
> > Serializer to solve the ser/deserialization problems, the only thing
> > not good enough is that it is not open source software, and have a
> > relatively restrict liscense. Please give me your valuable
> > suggestions, thanks:)
> is it possible you give more concrete example of what you try to do in
> Java code? why you can not manipulate XML and use XML directly to
> represent complex datatypes (this way you do not need serializer ...)?
>
> best,
>
> alek
> > l
> > 在06-4-1，*Aleksander Slominski* <[email protected]
> > <mailto:[email protected]>> 写道：
> >
> >     邹志乐 wrote:
> >     >
> >     > Well, i am not saying RPC/encoding is recommended, but it is
> indeed
> >     > used a lot. The interoperability issue among all SOAP toolkits
> >     can not
> >     > be covered by a single tool and this is not my keypoint. As you
> >     > mentioned, for very complex data structures, it recommded to use
> >     > Doc/literal style, this is transparent. We don't have to care
> about
> >     > the binding details, and this is what the WSIF offers:). As to the
> >     > schema-based validation, it does not belong to the
> interoperability
> >     > issue, but something on the "application level", and it not
> >     necessary
> >     > all the time. A validation failure may cause a fault message by
> the
> >     > code, just like that caused by interoperability. So it is better
> to
> >     > guarantee that the messages passed back and forth are just valid
> >     > before you send them, and this can be done easily with the tools
> >     you
> >     > mentioned, such as XMLBeans, etc.
> >     > My tool is aimed at providing direct runtime invocations of
> >     artitrary
> >     > services, and this is the case that may be found in the BPEL
> engine.
> >     > However, this may not be a good choice for another case.
> >     in the case BPEL engine you would have XML messages already as
> >     they are
> >     received in XML format - right? then you just need to provide some
> XML
> >     manipulation required by BPEL (XPath and <copy>) and then send XML
> >     content wrapped in SOAP envelope (here is where WSIF can help) - did
> i
> >     miss something?
> >
> >     if you aim to have some kind of User Interface to call a web service
> >     than you may need to parse XML Schema embedded in WSDL and maybe do
> >     introspection on Java classes to actually construct XML message
> >     content
> >     and then build UI elements based on structure of XML message to
> >     fill by
> >     user.
> >
> >     tools such as online WSDL invokers works well with just WSD/XML
> >     schema
> >     without Java introspection (ex. http://soapclient.com/soaptest.html
> >     though I do not know any other than Xydra that comes with source
> >     code -
> >     i could not find a list of such tools ...).
> >
> >     for GUI tools that use reflection on Java you may take a look on
> >
> http://svn.apache.org/repos/asf/webservices/wsif/trunk/swingWsInvoker/
> >     <
> http://svn.apache.org/repos/asf/webservices/wsif/trunk/swingWsInvoker/>
> >     (it is only in SVN - post to the mailing list if you run in any
> >     problems
> >     building this tool)
> >     > Well, Alek, English is not my native language, and i hope my
> >     > expressions are not causing misunderstandings, have a very nice
> >     day:)
> >     i hope that i answered your questions and have a nice day too :)
> >
> >     best,
> >
> >     alek
> >     >
> >     > 在06-3-31，*Aleksander Slominski* <[email protected]
> >     <mailto:[email protected]>
> >     > <mailto: [email protected] <mailto:[email protected]>>> 写道：
> >     >
> >     > 邹志乐 wrote:
> >     > > hi, alek, thanks for writing:)
> >     > > you mentioned "sending actual XML wrapped in SOAP is simple
> >     compared
> >     > > to XML Schemas and such.". But i think it is only suitable for
> the
> >     > > document/literal case, and if the service specifies rpc/encoding
> >     > > binding, this may not work.
> >     > > I am trying to code something to facilitate the service
> >     > invocation. I
> >     > > want to make the service operation invocation as simple as the
> >     > object
> >     > > method invocation. You see, the most paining part is the dealing
> >     > with
> >     > > the complex types. JROM provide a generic approach to
> >     represent the
> >     > > xml datas, which is quite different from DOM, JDOM,
> >     > XMLBeans,etc. And
> >     > > with WSIF, the invocation may greatly be simplied, and it is
> >     > possible
> >     > > to achieve my goal.
> >     > if you are working with WSDL the invocation should conform to WSDL
> >     > messages/types and that is main reason that "simple" rpc/encoding
> >     > is not
> >     > recommended when sending more complex data structures - it is very
> >     > hard
> >     > to make sure that client and server will be able to interact if
> >     > they use
> >     > different languages or toolkits as there is enough "freedom" (of
> >     > interpretation) in SOAP encoding to make it very hard to
> >     > understand each
> >     > other (and validation of XML messages is very hard ...)
> >     > > As to the "sending actual XML wrapped in SOAP" case, i can
> >     also work
> >     > > with it, and even be simplified. You only need to specify the
> >     > name of
> >     > > the service operation, pass the xml fragment like method
> >     parameters,
> >     > > then a piece of xml fragment will be returned like the method
> >     return
> >     > > value, and that's all.
> >     > yes but you may also want to *validate* XML that it conforms to
> >     > WSDL/messages/types and that can be done with plethora of tools
> for
> >     > doc/literal that uses XML Schemas (for example using XmlBeans) ...
> >     > maybe
> >     > even RelaxNG in future ...
> >     > > I think it is greatly useful to hide the complexity, and only
> >     > let the
> >     > > user focus on the abstract definitions in WSDL, just like what
> >     > WSIF is
> >     > > aimed at.
> >     > complexity is "hidden" somewhere: it is either in Java code that
> is
> >     > automatically generating XML for SOAP encoding or in XML Schemas
> >     > constructs when they are represented in Java - TANSTAAFL [1].
> >     however
> >     > this complexity can be a good thing if it is to create a detailed
> >     > contract with WSDL/messages/types to describe *exactly* what
> >     > messages a
> >     > service can take (so they can be validated) and more rigid the
> >     > description is there the better chance WSIF will get it right when
> >     > invoking such a service described in WSDL ...
> >     >
> >     > best,
> >     >
> >     > alek
> >     >
> >     > [1] http://en.wikipedia.org/wiki/Free_lunch
> >     > > 2006/3/30, Aleksander Slominski <[email protected]
> >     <mailto:[email protected]>
> >     > <mailto: [email protected] <mailto:[email protected]>>
> >     > > <mailto:[email protected] <mailto:[email protected]>
> >     <mailto:[email protected] <mailto:[email protected]>>>>:
> >     > >
> >     > > 邹志乐 wrote:
> >     > > > Hi, I am using JROM to facilitate the dynamic invocation of
> the
> >     > > > services, but it is not an open source project, and the docs
> >     don't
> >     > > > contain enough information. So I wonder if there is any open
> >     > source
> >     > > > project can do the same work as JROM does.
> >     > > > Best Regards:)
> >     > > >
> >     > > hi robin,
> >     > >
> >     > > could you give some examples of what you want it to do?
> >     > >
> >     > > in general as soon as you convert your data to some form of XML
> >     > > (including DOM) you did the hardest part of dynamic invocation -
> >     > > sending
> >     > > actual XML wrapped in SOAP is simple compared to XML Schemas and
> >     > such.
> >     > > unless i am missing something i do not think JROM would help you
> >     > > with that?
> >     > >
> >     > > best,
> >     > >
> >     > > alek
> >     > >
> >     > > --
> >     > > The best way to predict the future is to invent it - Alan Kay
> >     > >
> >     > >
> >     >
> >     >
> >     > --
> >     > The best way to predict the future is to invent it - Alan Kay
> >     >
> >     >
> >
> >
> >     --
> >     The best way to predict the future is to invent it - Alan Kay
> >
> >
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>