Re: [service-orientated-architecture] Role of MOM in a Web Services based SOA

Tue, 01 Nov 2005 01:51:36 -0800

See also WS-Eventing.
http://www-128.ibm.com/developerworks/webservices/library/specification/ws-eventing/

Consider Microsoft's Indigo (now WCF) programming model -- it provides a common programming model that support request/response and event/queuing.

>From my perspective, an application shouldn't have to work directly with a queue. It should be able to send a message to an endpoint, and the endpoint should be able to accept it syncronously or asynchronously based on its current load and its policies. The sending application should use WS-Addressing to indicate its reply-to address.

The technology obviously needs to catch up with the concepts, but I think that's where things are headed. Two years from now, I see no reason to continue to use propriatery MOM protocols except in support of legacy applications.

Anne

On 10/31/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Todd

Firstly, good post. I agree this is a highly interesting and relevant discussion. I think the whole SOAP/JMS is basically a slight red herring, because it mixes up transport with semantics.T

 As you point out, there is a need for Web Services to support pull semantics as well as push semantics. For example, the submission by IBM of WS-Polling to the W3C ( http://www.w3.org/Submission/ws-polling/) creates an option to loosely couple services in time and directionality.

The other relevant option is the Amazon Simple Queueing Service, http://www.amazon.com/gp/browse.html/104-4790757-2434363?_encoding=UTF8&node=13584001&no=13584171 , which provides  a WS mapping to a queueing paradigm.

Both these options should be composable with reliability, and composable with SOAP transports, making a more flexible approach to choosing the right model (transport, QoS and semantic) compared to a JMS solution.

Finally, I think that one thing that would be immensely useful would be a mapping from existing queueing models such as JMS into SOAP+RM+ a WSDL definition of queue transport. This would allow reliable interoperable bridging over SOAP/HTTP between JMS implementations which would be hugely valuable.

Paul



On 10/31/05, Biske, Todd < [EMAIL PROTECTED]> wrote:

In the spirit of Gervas' suggestion to turn the discussions on SOA infrastructure, I'm interested in what the group has to say about the role of MOM in a Web-Services based SOA. >From an architectural perspective ( i.e. technology indepedent), I don't think there's any argument that queuing systems are a key part of an SOA.  Once we actually try to implement the infrastructure required for an SOA, and build our services on top of it, we run into technology-specific issues.  One high up on my list is queuing systems.

In my experience, there are two primary types of service invocations. The first is a push model.  The service consumer pushes the request to a service consumer, and blocks for a response.  Infrastructure is designed to handle some peak level, and blocking may occur for some amount of time if the number of concurrent requests exceeds the number of handlers available.   The second is a pull model.  In this case, the service consumer pushes the request to a queue, and service providers pull the requests off as they have handlers available.  A debate in this scenario is whether there ever can be a service response, as certainly some vendors have allowed the possibility with proprietary JMS endpoints in WSDL.  My preference is to treat all of these as fire and forget services.  Any message produced as a result should be viewed as a business event rather than as a service response.   My definition of an event versus a service message is that the service consumer has an expectation that some processing will occur with a service message, while an event has no implied processing. 

There are several questions that arise around the pull model:

  • What's the proper way of exposing these services?
  • Do we need a standard wire protocol for talking to a queue? 
  • When will queuing systems support SOAP natively?  Right now, we have mediation technology for SOAP/HTTP where everything is migrating toward policies based upon the SOAP envelope, not the HTTP envelope.  JMS providers focus on their proprietary JMS envelope ( i.e. JMS properties) not on the SOAP envelope.
  • What if queuing providers exposed a Web Service for publishing to a queue?  What would this do to the functional model? 

I've yet to see anyone really attack these problems head on.  While the ESB solutions built on top of a MOM do address this, they're all proprietary solutions.  The only option that has some appeal is to utilize an HTTP to JMS/MQ/MSMQ bridge, provided that you accept my premise that all of these services are one-way invocations.  While this would address things from the consumer perspective (once WS-RM has broad support), it doesn't quite fix things on the provider perspective.  We still don't have a good answer for how this service should be exposed by the provider. 

Thoughts?
Todd Biske
Software Infrastructure Engineering
A.G. Edwards Technology Group, Inc.
V:(314) 955-6254 F:(314) 955-4055 E:[EMAIL PROTECTED]



-------------------------------------------------------------------------------------
A.G. Edwards & Sons' outgoing and incoming e-mails are electronically
archived and subject to review and/or disclosure to someone other
than the recipient.

-------------------------------------------------------------------------------------

SPONSORED LINKS
Service-oriented architecture Computer monitoring software Computer and internet software
Free computer monitoring software

YAHOO! GROUPS LINKS





SPONSORED LINKS
Service-oriented architecture Computer monitoring software Computer and internet software
Free computer monitoring software

YAHOO! GROUPS LINKS




YAHOO! GROUPS LINKS



Reply via email to