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

瑰涔 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