JMS in a B2B scenario
We have a scenario where external partners will transmit requests to our application, which will reply back with some results. Some of the other requirements for _our_ application are: support for concurrency, scalability, high avail, etc.
We feel that using EJBs to model our application will help us because the EJB container/appl server will handle security, transactions, etc. That's good - but, our problem is how would the external client applications communicate with us ?
One solution would be: we expose the remote interfaces of our EJBs and the external applications code to that interface. But, this may mean that any time we change our interfaces, the external applications also need to be changed. This may be a pain ;-)
But, what if the external applications send requests encapsulated in a mutually-agreed message format and receive responses via messages ? Yes, I am thinking about JMS. Our external applications can send messages to queues in our JMS provider. Our application picks up requests from a "request" queue and inserts results into a "results" queue. The external applications will obtain these results from this queue.
I was going to spend more time researching on this, when I came across the JMS FAQ, which says that JMS is to be used only within an enterprise, while ebXML messaging is recommended for a B2B scenario.
Before I discard my current line of thinking, I would like to get some input/advice/suggestions as to whether JMS will work in our scenario. If not, what kind of an architecture would help us ?
Thanks a lot !
[1617 byte] By [
debapriya] at [2007-9-26 1:36:04]
> We have a scenario where external partners will
> transmit requests to our application, which will reply
> back with some results. Some of the other requirements
> for _our_ application are: support for concurrency,
> scalability, high avail, etc.
>
> We feel that using EJBs to model our application will
> help us because the EJB container/appl server will
> handle security, transactions, etc. That's good - but,
> our problem is how would the external client
> applications communicate with us ?
>
> One solution would be: we expose the remote interfaces
> of our EJBs and the external applications code to that
> interface. But, this may mean that any time we change
> our interfaces, the external applications also need to
> be changed. This may be a pain ;-)
>
> But, what if the external applications send requests
> encapsulated in a mutually-agreed message format and
> receive responses via messages ? Yes, I am thinking
> about JMS. Our external applications can send messages
> to queues in our JMS provider. Our application picks
> up requests from a "request" queue and inserts results
> into a "results" queue. The external applications will
> obtain these results from this queue.
>
> I was going to spend more time researching on this,
> when I came across the JMS FAQ, which says that JMS is
> to be used only within an enterprise, while ebXML
> messaging is recommended for a B2B scenario.
>
> Before I discard my current line of thinking, I would
> like to get some input/advice/suggestions as to
> whether JMS will work in our scenario. If not, what
> kind of an architecture would help us ?
>
> Thanks a lot !
>
Hi,
I don't think you need discard your current thinking. Yes some JMS implementations are best placed in the enterprise however some are designed specifically for external connectivity and building business partner networks. Our own product ( Nirvana ) is one that has been designed for externally facing middleware connectivity. Our messaging functionality resides above a pluggable transport layer and supports sockets, SSL enabled sockets, HTTP and HTTPS transports. The whole proxy and firewall traversal problem is handled correctly. There is no requirement for a web server ( although we have produced an Apache module for reverse proxying ) running a suite of servlets.
We are currently packaging a new release that provides a new JMS implementation as well as a P2P framework. All of which runs over our pluggable transport drivers. The P2P framework supports the concept of BOP's ( Business Object Proxies ) , this functionality allows you to create services that are directly accessible from pretty much anywhere.
We would be more than happy to provide you with an early access distribution prior to us updating our web site. Please feel free to contact us.
Paul Brant
http://www.my-channels.com/
Email: paul.brant@my-channels.com
