Menu
▾
▴
Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Patrick Y. <kc...@ce...> - 2003-10-31 15:34:56
|
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.=20
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 -----=20
From: Tripathi, Ajit (GXS)=20
To: 'ebx...@li...'=20
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.=20
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 :-)...=20
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,=20
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.=20
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.=20
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,=20
Ajot=20
-----Original Message-----=20
From: Christophe Hartwig-Peillon [mailto:chr...@re...]=20
Sent: Friday, October 31, 2003 2:19 PM=20
To: ebx...@li...=20
Subject: [ebxmlms-general] idea : use ebXML to bridge the gap, =
through=20
JMS=20
Hi all,=20
At the beginning, I considered ebXML as an alternative to Web =
Services...=20
But this mistake was due to my lack of understanding.=20
My understanding now is that ebXML is a MOM protocol, but this =
kind of=20
assertion is found nowhere, hence the ambiguity with Web Services. =
So=20
assertions like "Web services will take over ebXML" are just plain =
nonsense : you can't compare MOM with RPC.=20
Then JAXM has added its load of ambiguity, since it has added one =
more=20
API in the Java world, despite the existence of a proven API for =
MOMs,=20
JMS...=20
Don't you think that there would be a place in the ebXML for a JMS =
based=20
implementation of ebXML MSH for its encoding and transport ?=20
I can imagine implementing ebXML on top of an existing JMS=20
implementation would make things easier : JMS already has reliable =
messaging semantics, and already offers transactional persistent=20
messages, etc... Many features of Hermes are already supported by =
JMS=20
implementations... And JMS supports temporary queues (and =
reply-to) for=20
request-response messages... And JMS already offers Message Beans=20
integration... and JMS is most often clusterable... and ... I like =
that=20
idea :-)=20
I think such an implementation would make the use of ebXML =
simpler,=20
better integrated with J2EE environments, would reduce the =
learning=20
curve, would make ebXML an obvious choice for reliable =
messaging...=20
Your thoughts ?=20
Bye=20
Chris=20
PS : I think my idea means a new implementation, not just an =
adaptation=20
of Hermes...=20
=
---------------------------------------------------------------------
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
---------------------------------------------------------------------=20
|
