Re: [service-orientated-architecture] Is the WS- vision achievable?

[Keith Harrison-Broninski]

Wow!  Great response to this thread. Some people seem to be broadly in agreement with my original posting. A couple of others have written saying that their company makes products that solve the problem - to these latter may I reply in the spirit of Ron to me (about RADs), and ask for details?  I appreciate that the technical details of how this wizardry is accomplished may be confidential (if not, let's have them) but use cases would be appreciated. And thanks, Sanjiva, for the fascinating insight into JROM.  It's an unexpected bonus to get a response from a JROM team member!  You write: There's no inherent reason whatsoever that you need to take every bit of XML and map it to an object. In fact, XML Schema has all kinds of stuff which doesn't map naturally to normal language type systems. Well, you can capture anything in an object type system, can't you.  Even MOF is being cut down to EMOF for most purposes.  You just need an appropriate mapping, which may be more or less complex depending on the capabilities of the language used. In fact, your comment seems to corroborate my original assertion - that JROM doesn't, and cannot possibly, do what it says on the tin.  Whatever is in the XML representing Web service inputs/outputs must be there for a reason, so you need at least to present it to the user for potential use in dynamic invocation (they may choose not to use it, but this should be up to them).  Hence you need to capture all the XML in object form somehow.  My assertion is that an XML schema alone fails to provide the semantic relationships between data items that would allow a piece of software to do this on its own, and I take your comment as a tacit agreement that yes, JROM cannot do it. My suspicion was that some people in IBM realized this.  You write: IBM wanted was a unified data model for *any* kind of data, not just XML. Only a more generic data model could solve the deep XML problem, by also including the semantic relationships necessary to interpret the data.  Such a model would provide the clue as to what was missing in XML alone, and could then be mapped onto XML plus something that told you how to interpret it.  But XML-based Web services, at least in their current form based on WSDL, do not include this extra something. Finally, you write: In Axis2 (http://ws.apache.org/axis2) we have built a new data model called AXIOM which is used internally for all XML stuff. I'm hoping to re-do WSIF one of these days using that as the internals .. think of it as a much improved JROM. (JROM's difference was that it was schema aware natively- AXIOM isn't but it has sufficient flexibility to compensate for that plus we do have a data binding part too to handle that fully). In any case, we haven't ruled out adding native simple type support into AXIOM. Once we have that done, with Axis2 modules etc., you will be able to invoke a service fully dynamically, engage security/RM etc. dynamically (even negotiate those policies dynamically). If all goes well we'll have all this working this year. In its current form, isn't AXIOM just JDOM plus pull parsing?  As you say, it is not schema aware - it deals with XML documents rather than with XML schemas.  Hence you cannot construct template input/output objects from WSDL as required for true dynamic invocation. But if you do extend AXIOM to add JROM-type functionality, I'll be very grateful and will certainly use it!  Although my view is that such an effort cannot fully work for theoretical reasons, I don't see why it can't work "enough".  Any form of truly dynamic invocation must be caveat emptor - the odd data misalignment between consumer and producer just has to be taken with a pinch of salt. -- All the best Keith http://keith.harrison-broninski.info YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.