Sanjiva Weerawarana wrote: >On Tue, 2005-09-13 at 09:55 +0100, Keith Harrison-Broninski wrote: > > >>In fact, when I was trying to get RADRunner to do dynamic invocation >>of Web services with complex parameters, the only way I could find was >>to use a piece of technology from IBM's "Alphaworks" - their testbed >>for potential new technologies, that are open for anyone to try out. >>This technology, known as "JROM", claimed to be able to make the >>necessary programmatic objects from arbitrary XML documents. Used in >>conjunction with another piece of technology from IBM that they gave >>to Apache (WSIF), it seemed as though JROM provided the missing piece >>of the picture: >> >>http://ws.apache.org/wsif/faq.html#faq-N100E5 (Sample DynamicInvoker >>and Complex Type handling in WSIF) >> >>So, I started badgering people in IBM about a commercial license to >>JROM. I even met with a key player in the development team. Several >>years later, JROM has not moved on since the last release in 2002 (I >>looked again yesterday) - and IBM have neither offered me a commercial >>license, built JROM into a commercial product of their own nor donated >>it to Apache (the latter approach being the natural outcome that the >>people I spoke to seemed to expect). >> >> > >Paul Fremantle and I originally created WSIF and I'm the one who started >JROM stuff with Rania Khalaf. > >The reason JROM never made it past alphaWorks is because of >techno-politics. The techno part is that JROM is for XML only and what >IBM wanted was a unified data model for *any* kind of data, not just >XML. That's what SDOs are (http://www.jcp.org/en/jsr/detail?id=235) .. >but the reality is that trying to unify the world results in much >complexity and one loses the simplicity of JROM rapidly. > > > >>Why? I think IBM are aware that JROM does not work. Further, I think >>there are technical reasons why it cannot work. There is just not >>enough information in an XML document to tell you how to convert it >>into an object. >> >> > >Ah therein lies the fallacy. 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. > if you just need to invoke WS with compelxTypes inside WSDL you can send XML message directly (really not much work!) - the only difficulty is if you do want to have some kind of UI such as, say, creating dynamic XHTML Form to represent input parameters - if you desire to do so then take a look on Xydra which is doing exactly this and is under BSD-like license (research prototype!): http://www.extreme.indiana.edu/xgws/xydra Xydra has internal XML infoset model, simple XML Schema parsing library and way to generate XML instance documents based on XML schema and round-trip XHTML form name-value pairs to XML and back.
>>What this means, is that a key vision underpinning the whole WS effort >>- of a world of freewheeling enterprise applications that dynamically >>pick up and use Web services discovered in a registry - may never be >>achievable. The only way to do it is to use a specific technology as >>your client (e.g., a Java framework such as WSIF) and prime it at >>development time (not runtime) with the information necessary to call >>specific services (the mappings from their complex type parameters >>into programmatic objects). >> >> > >I don't agree! 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. > >There's nothing wrong with the WS vision IMO. The problem is with the >middleware that's been developed for it so far - its all been band-aid >over some current stuff. To make WS real you need a new kind of >middleware ... which is what is being built in Apache now! > >Indigo is also native WS middleware. That's the only thing that comes >close to Axis2's approach now (IMO :)). > > XSUL2 <www.extreme.indiana.edu/xgws/xsul> [1] has all of this stuff (including improved WSIF APIs, more dynamic AXIOM-like API, handlers for security) and more - but it is also research OSS code (under BSD-like license) so it has no industry heavyweight to support it but just few graduate students ... so yes i agree - the part to blame is middleware - nothing wrong with basic WS-* (XML, HTTP, SOAP, WSDL) - they work great as long as not too much is hidden in name of "XML is ugly" and when code generators/tooling do not go wild with complexity generation/hiding ... best, alek [1] http://www.extreme.indiana.edu/xgws/xsul/guide -- The best way to predict the future is to invent it - Alan Kay ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
