Menu
▾
▴
Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Christophe Hartwig-P. <chr...@re...> - 2003-10-31 10:20:00
|
Hi, I'm not talking about using JMS as the transport... It's the opposite : I'm talking about using JMS as the API and architecture, and using ebXML over (choose your favorite transport) for the encoding and transport. ebXML wants to be independant (of transport, apis, etc...) : the net result is lack of adoption, lack of integration. ebXML is not considered a "solution", just an encoding :-( If sending an ebXML message was as easy as sending a JMS message with a toParty header, and receiving an ebXML message was as easy as writing a message bean, ebXML would be easier to adopt ! I tend to think of ebXML as an encoding for MOM semantics. JMS has no encoding protocol : JMS assumes the transport layer also takes care of the encoding. The protocol stack would be, from top to bottom : - JMS - ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME mini-stack) - HTTP, SMTP, or whatever protocol the MSH could support If you prefer : ebXML is needed, because we need an XML encoding which preserves MOM semantics, for easy interoperability, but JAXM is useless, since we already have MOM apis... Until now, interoperability was not the primary goal of JMS : JMS made the interop possible, since no assumption was made on encoding or transport. The result is that, except for JSM bridges (for Tibco or MQSeries), interop is weak ! Using ebXML as the encoding, and HTTP/SMTP the transport could make JMS interop possible. JMS-JMS interop would be great, but the fact that ebXML is API agnostic is even better : it would allow anyone with HTTP/SMTP libraries and an XML parser to send messages to your JMS server ! It would allow JAXM - JMS interop, and commercial ebXML implementations - JMS interop... I think JMS is *the* MOM API for J2EE, not JAXM... And ebXML should be *the* interoperable encoding for MOM implementations. But I don't recommend implementing a JMS provider on top of Hermes : one solution is the use of an existing JMS implementation, and the implementation of the ebXML layer as a JMS client... A servlet can wait for ebXML messages, create a temp queue for the reply, send the ebXML message to a JMS queue... Message Beans can handle messages, and post their reply to the reply-to queue. The servlet can then send the response (it was blocking on the temps queue until now)... To send an ebXML message, you'll just post the payload and some JMS headers (like the recepient of the message) to a JMS queue... A queue listener will then build the ebXML message and send it, using some of the JMS message headers for the ebXML header... The ebXML implementation could take care of signing, choosing the right transport, etc... the ebXML layer would be focused on what is does best : interop ! JMS will take care of acknoledgement, transaction support, persistence, etc... The MSH will just be a relay ! That's one possible implementation (well, deep thinking is needed here, I admit :-)... Another one would be to take an existing JMS implementation (like JBoss'es), and add an ebXML/HTTP and ebXML/SMTP transport. This implementation would work only for that JMS implementation, but might offer greater support for MOM semantics (because it would be linked with the implementation of the JMS server)... I know all of this is heretic, since JAXM exists and is an endorsed standard... but sometimes standards die, sometimes they are abandonned... I would prefer to see JAXM die instead of ebXML : we need ebXML ! Chris Tripathi, Ajit (GXS) wrote: > Chris, > > The ebXML messaging spec (ebMS2) seeks to be independent of > application transport. As per the spec, JMS can be incorporated into > msh products, alongwith http and smtp but that is an implementation > decision. > > Clearly, messaging is only one aspect of ebXML. The spec > broadly seeks to enable business processes between trading partners > using XML (vis-a-vis EDI) . However, inter-enterprise collaboration > requires much more sophisticated messaging than SOAP spec accounts for. > > While ebXML messaging is built on top of SOAP-Attach, security > and reliability are two key messaging requirements not mentioned in > the set of specs known as "web-services". ebXML also seeks to bridge > that gap through msh. > > regards, > Ajot > > -----Original Message----- > From: Christophe Hartwig-Peillon [mailto:chr...@re...] > Sent: Friday, October 31, 2003 2:19 PM > To: ebx...@li... > Subject: [ebxmlms-general] idea : use ebXML to bridge the gap, through > JMS > > > Hi all, > > At the beginning, I considered ebXML as an alternative to Web Services... > But this mistake was due to my lack of understanding. > > My understanding now is that ebXML is a MOM protocol, but this kind of > assertion is found nowhere, hence the ambiguity with Web Services. So > assertions like "Web services will take over ebXML" are just plain > nonsense : you can't compare MOM with RPC. > Then JAXM has added its load of ambiguity, since it has added one more > API in the Java world, despite the existence of a proven API for MOMs, > JMS... > > Don't you think that there would be a place in the ebXML for a JMS based > implementation of ebXML MSH for its encoding and transport ? > I can imagine implementing ebXML on top of an existing JMS > implementation would make things easier : JMS already has reliable > messaging semantics, and already offers transactional persistent > messages, etc... Many features of Hermes are already supported by JMS > implementations... And JMS supports temporary queues (and reply-to) for > request-response messages... And JMS already offers Message Beans > integration... and JMS is most often clusterable... and ... I like that > idea :-) > > I think such an implementation would make the use of ebXML simpler, > better integrated with J2EE environments, would reduce the learning > curve, would make ebXML an obvious choice for reliable messaging... > > Your thoughts ? > > Bye > Chris > > PS : I think my idea means a new implementation, not just an adaptation > of Hermes... > --------------------------------------------------------------------- Christophe HARTWIG - Interface Technologies cha...@re... 17, avenue Andre Roussin http://www.reservit.com ZAC de Saumaty-Seon Tel : + 33 4 91 03 64 90 13016 MARSEILLE - FRANCE Fax : + 33 4 91 03 64 92 --------------------------------------------------------------------- |
