Menu
▾
▴
Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Ronald v. K. <rv...@ab...> - 2003-11-01 22:54:41
|
Frankie Lam wrote: >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. > > The JMS api is a fairly technical one. Creating factories, session, working with acknowledgements is not what you want an 'end-user' to have to do. It could (should?) be simpeler. Especially things the way acknowledgements work in a JMS session is not realy nice in the way that you cannot process multiple messages and just acknowledge the ones you want to. I you acknowledge one, all previous ones are achknowledged. JAXM as an api is to me not much more that "SOAP+". I'm curious to what the API's will look like for WS-Reliability (WS-ReliableMessaging?) etc... >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. > I didn't say it would be easy ;-) but I think we could get BEA, someone from JBoss and maybe even oracle to join in and within a year it could be done (don't call it JMS 2.0 then but rather 1.x since otherwise there is the risk for a full redesign that is not nessecary now) >Moreover, when JMS 2.0 is available, the messaging service >specification may reach 3.0 / 4.0 already =) > Naaahhh... 3.0 will not be that different i think. Not in functionality it won't. If there are some ws-* standards then for security (hmm how would that fit in??) and reliability probably those will be used then. (kind of like a WS-I ebXML-MS profile) >So there will always be a >mismatch between the functionality provided by JMS and ebXML MS. > > > I agree, I therefor see more in using JMS to implement some things for ebXML (queueing (with persistency), retries etc) instead of using the API in the front. JAXM doesn't fit either. It's to general. I do not fully agree with IBM et.al that there should be only one api for messaging. JMS itself has its purpose, just like ebXML has. btw, there are several api's for DOM manipulation (dom, dom4j, jdom etc...) If done right, giving ebxml MS it's own (simple!!) API would not be bad at all. >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? > > Using the same API but implementing a new JMS provider? Don't know. I think that on that level there are to many incompatibilities. Beginning with the queues (are they the paryID's?) MsgID's beeing generated by the provider etc... I see more in a simple bug good ebxml-ms specific api and for those who want it implement it on top of JMS. >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... >>>> >>>> >>>> |
