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

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.
Well, Alek, English is not my native language, and i hope my expressions are
not causing misunderstandings, have a very nice day:)
Best Regards
robin
在06-3-31，Aleksander Slominski <[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]>>:
> >
> >     邹志乐 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
>
>