Title: Role of MOM in a Web Services based SOA

 

Todd,

 

IMHO the relevant question should be “Role of web services in a existing MOM environment”.

 

WS infrastructure can provide a bridge among multiple MOMs and extend a MOM over WAN, Gateway MOM to other VANs or provide gatewaying services for native Web Services to access functionality that is using MOM.

 

All of these products are on the roadmap of several startups today.

 

Vikas

 

 


From: [email protected] [mailto:[email protected]] On Behalf Of Biske, Todd
Sent: Monday, October 31, 2005 9:54 AM
To: [email protected]
Subject: [service-orientated-architecture] Role of MOM in a Web Services based SOA

 

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.

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



YAHOO! GROUPS LINKS




Reply via email to