Menu
▾
▴
RE: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS
|
From: Tripathi, A. (GXS) <Aji...@gx...> - 2003-10-31 10:45:43
|
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...
<mailto:chr...@re...> ]
Sent: Friday, October 31, 2003 2:19 PM
To: ebx...@li...
<mailto: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...
<mailto:cha...@re...>
17, avenue Andre Roussin http://www.reservit.com
<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
---------------------------------------------------------------------
|
