邹志乐 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
