Menu
▾
▴
RE: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Tripathi, A. (GXS) <Aji...@gx...> - 2003-10-31 08:58:43
|
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 --------------------------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ ebxmlms-general mailing list ebx...@li... https://lists.sourceforge.net/lists/listinfo/ebxmlms-general |
