Menu
▾
▴
Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Frankie L. <fr...@mi...> - 2003-11-01 18:07:03
|
Sounds like an interesting thread =) I believe that using JMS API as the standard API is a great idea; it allows developers that have JMS experience to use ebXML messaging facility immediately. It should be a lot better than designing another set of standard API for ebXML messaging. As Patrick said, currently the biggest problem is mapping the ebxmlms-specific functions to JMS API. Creating a new JSR for JMS 2.0 to cater for the features that are supported by ebXML MS is hard and time-consuming. Moreover, when JMS 2.0 is available, the messaging service specification may reach 3.0 / 4.0 already =) So there will always be a mismatch between the functionality provided by JMS and ebXML MS. I am no JMS expert (or even a beginner). But would it be better if we implement JMS API using ebxml MS, while allowing the users to take advantage of ebxmlms-specific functionalities by setting some provider-specific properties? Frankie ----- Original Message ----- From: "Ronald van Kuijk" <rv...@ab...> To: <ebx...@li...> Sent: Sunday, November 02, 2003 1:39 AM Subject: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS > > Hi all, > > After some real busy weeks I finally got back to working with/on Hermes > again. > > I love this new discussion for several reasons and totally agree with > Patrick. Nice to see some new people with good ideas on this mailinglist. > > Using JMS with some extentions as the basis for an api for ebMS could > prove interesting since at least three (afaik) JMS servers, the ones > that come with Websphere, Bea and JBoss support some extentions on JMS > that make it even easier to implement a ebMS backend based on JMS. They > support time-to-live, retry-interval and maximum number of retries. And > last, but certainly not least, for HA/Failover one could use the > functionality provided by the JMS servers to achieve this. > > I'd therefor love to see the JMS specs get to version 2.0 (or 1.3 or > whatever) and have the ttl, retry-interval and number of retries in that > new spec. Hmmm....I almost start thinking of creating a new JSR within > the JCP for JMS2.0 specs. The similarityies go even further. JMS has an > defined property called JMSXGroupID en JMSXGroupSeq. There is however no > defined functionality for these properties and why not specify in the > JMS specs that they should be used for orderd delivery when present. > > I'm currently looking into the possibility of using the packaging etc > from Hermes and use JMS with MDB's or MessageListeners (not sure which > one to use yet) as the processing layer. All of this on JBoss, > unfortunately currently without failover. > > Ronald > > > > Patrick Yee wrote: > > > Chris & Ajit, > > > > Thanks. I mean we long for this kind of discussions so as to make > > ebXML messaging more usable. > > > > Personally, I like JMS too. The good thing is that it decouples the > > application logic with the choice of MOM provider. If I am a hard core > > open source supporter, I can use JBoss. Or if I become rich later, I > > can buy a MQ. This concept is proven to be useful, so we all can see > > the success of JDBC and JNDI. > > > > Obviously we need the same in ebXML messaging. Theorectically by > > conforming to the spec, MSHs are interoperable. But still, > > applications are not permitted to switch the vendor of MSH if the > > interface between MSH and application is proprietary to the MSH. This > > is a sad thing especially when we compare this with the successful > > JDBC and JNDI. > > > > JAXM seems to be the one we need. But it's not that easy to map to the > > function of ebXML MS. So you mentioned JMS, which is a widely accepted > > API standard. However, I would say that it's not easy to map to ebXML > > MS too. Implementing a JMS provider is not an easy task, especially > > because the mapping between JMS functions and ebXML MS functions is > > not intuitive. > > > > So Chris's idea is cool. However, afterall it's still proprietary. > > What we need is a commonly accepted API, endorsed by most MSH vendors. > > We agreed very much with Ajit's point as well. Java is all we need. > > Many MSHs are written in Java, that's perfectly fine. But that doesn't > > mean that the backend application that "uses" MSH should be in Java too. > > > > To sum up, we need a common ebMS API. And we need an API which is > > endorsed by MSH vendors. At the end, it's not purely technical. It's > > not going to be easy, but we see no choice. > > > > Lastly, we are forming a group which gathers people with the same > > vision to work that out. If you are interested, please send us an email. > > > > Sorry for the long mail. Happy Halloween! > > > > Regards, -Patrick > > > > > > > > ----- Original Message ----- > > *From:* Tripathi, Ajit (GXS) <mailto:Aji...@gx...> > > *To:* 'ebx...@li...' > > <mailto:%27e...@li...%27> > > *Sent:* Friday, October 31, 2003 6:41 PM > > *Subject:* RE: [ebxmlms-general] idea : use ebXML to bridge the > > gap, through JMS > > > > Chris, > > > > I see what you are saying ... you are not alone ... BEA and > > IBM don't want to see two different messaging models in J2EE > > either, one for MDBs and another for JAXM. Hence, JAXM was voted > > out of J2EE. However, XML/SOAP over HTTP can't be replaced by > > XML/SOAP over JMS. > > > > However, ebXML is in no way restricted by the choice of > > messaging. You may want to use ebXML over a synchronous > > messaging protocol, as much as you can use it with HTTP, SMTP, > > JAXM and JMS. Hence common JMS features need to be reinvented by > > MSHs. ebXML cares about what _services _an MSH provides. How it > > does that is in a large degree, left to MSHs. > > > > Implementation independence is a goal for a very good reason > > - ebXML without interoperability would be useless. Never forget > > Microsoft - Java isn't the only thing in the integration world. > > > > regards, > > Ajit > > > > -----Original Message----- > > *From:* Christophe Hartwig-Peillon > > [mailto:chr...@re...] > > *Sent:* Friday, October 31, 2003 3:50 PM > > *To:* ebx...@li... > > *Subject:* Re: [ebxmlms-general] idea : use ebXML to bridge > > the gap, through JMS > > > > 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 > >--------------------------------------------------------------------- > > > > > > > > > ------------------------------------------------------- > 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 > |
