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

瑰涔 wrote:
> 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^_^
i think this should work. you are right that i pretty much gave up on
rpc/encoding (and i did lot of it in past including SoapRMI that
supported completely transparent encoding of Java Beans to rpc/encoding
XML ...)

however if you use rpc/encoding you could skip JROM - why not generate
directly XML for SOAP encoding from Java Beans? that of course assumes
that somehow you know that Java Beans types corresponds to WSDL part
types but this problem exist also for JROM as far as i can tell ...

best,

alek
> 06-4-2锛*Aleksander Slominski* <[email protected]
> <mailto:[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/
>     <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]>
>     > <mailto: [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/
>     <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]>>
>     > > <mailto: [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]>>>
>     > > > <mailto: [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
>
>


-- 
The best way to predict the future is to invent it - Alan Kay