Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

[Ganga S. <gan...@ya...>]

I would agree with Patrick that it would not be easy
to replace JAXM(as used in Hermes) with JMS API but it
should be possible to add JMS as a tranport in
addition to currently existing transports of HTTP and
MAIL, although ebXML MSH may not be specifc about usng
JMS as alternative transport. Apache
Axis(JAX-RPC/SOAP) has added support to use JMS
transport in addition to HTTP,MAIL etc.
thanks,
ganga
--- Patrick Yee <kc...@ce...> 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) 
>   To: 'ebx...@li...' 
>   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. 
> 
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/