Comments on: Does SOA Need A Reliable Messaging Protocol? http://www.goland.org/soareliablemessaging/ Technology, Politics, Food, Finance, etc. Mon, 23 Jan 2012 17:37:17 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Administrator http://www.goland.org/soareliablemessaging/comment-page-1/#comment-5570 Administrator Fri, 14 Oct 2005 19:57:46 +0000 #comment-5570 Yeah but using an XA interface would actually be bad because reliable messaging will never be able to get even close to the kind of guarantees that XA provides. Nor, btw, do I think we should try to get to that level of guarantee across a network. I'm hoping at some point to get to put together some code for my reliable messaging solution as an open source project. I'll start out probably with an Apache Plug-Ins (since my protocol will be HTTP based) and then see about exposing it across JMS and maybe JBI. Yeah but using an XA interface would actually be bad because reliable messaging will never be able to get even close to the kind of guarantees that XA provides. Nor, btw, do I think we should try to get to that level of guarantee across a network.

I’m hoping at some point to get to put together some code for my reliable messaging solution as an open source project. I’ll start out probably with an Apache Plug-Ins (since my protocol will be HTTP based) and then see about exposing it across JMS and maybe JBI.

]]> By: Bernd Eckenfels http://www.goland.org/soareliablemessaging/comment-page-1/#comment-5569 Bernd Eckenfels Fri, 14 Oct 2005 19:26:10 +0000 #comment-5569 Yes, but I as a service consumer/provider dont care about the protocol. If i have an ESB (JMS) or App Server (Remote Session Bean) I do have perfectly safe XA transactions without inventing any new protocol. And I dont want to use another API. If there is an API which can be expected to work I can start to implement SOA today and dont have to wait on the third WS-R spec... Gruss Bernd Yes, but I as a service consumer/provider dont care about the protocol. If i have an ESB (JMS) or App Server (Remote Session Bean) I do have perfectly safe XA transactions without inventing any new protocol. And I dont want to use another API. If there is an API which can be expected to work I can start to implement SOA today and dont have to wait on the third WS-R spec…

Gruss
Bernd

]]> By: Administrator http://www.goland.org/soareliablemessaging/comment-page-1/#comment-5568 Administrator Fri, 14 Oct 2005 15:50:28 +0000 #comment-5568 I'm not too worried about the language bindings actually. I think the key is to come up with a protocol that calls for an architecture that is brain dead easy to implement. In that case there will be tons of implementations in multiple languages and people can choose whatever solution they prefer. So long as the protocol enables interoperability the cacophony of languages won't be a big deal. I think that is certainly a lesson we can take away from HTTP and to a less extent XML. I’m not too worried about the language bindings actually. I think the key is to come up with a protocol that calls for an architecture that is brain dead easy to implement. In that case there will be tons of implementations in multiple languages and people can choose whatever solution they prefer. So long as the protocol enables interoperability the cacophony of languages won’t be a big deal. I think that is certainly a lesson we can take away from HTTP and to a less extent XML.

]]> By: Bernd Eckenfels http://www.goland.org/soareliablemessaging/comment-page-1/#comment-5564 Bernd Eckenfels Fri, 14 Oct 2005 07:26:56 +0000 #comment-5564 From my point of view Java needs a SOA API. There are currently only two APIs which allow the kind of QOS you need in business applications: JAXM and JMS. The first is somewhat dead and only very general specified, and both are not WebService oriented, since you cant really easyly transport a RPC call. So the question is, if we will see RM Providers who will work as JMS (including transaction propagation?) or as JAX-RPC providers. Gruss Bernd From my point of view Java needs a SOA API. There are currently only two APIs which allow the kind of QOS you need in business applications: JAXM and JMS. The first is somewhat dead and only very general specified, and both are not WebService oriented, since you cant really easyly transport a RPC call.

So the question is, if we will see RM Providers who will work as JMS (including transaction propagation?) or as JAX-RPC providers.

Gruss
Bernd

]]>