Linda/tuple spaces as a paradigm has certain inherent advantages including underlying decoupling (i.e. going beyond loose coupling) whilst allowing the implementation of coupling at a higher level to whatever degree of tightness or synchroncity is required. It is also both inherently scalable and failover in nature. Have any of you architects in middleware companies considered implementing it as the underlying connectivity mechanism for an ESB?
Gervas ----- Original Message ----- From: "Gregg Wonderly" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, November 01, 2005 3:40 AM Subject: Re: [service-orientated-architecture] Role of MOM in a Web Services based SOA > Biske, Todd 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. > > > 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. > > This is a scarry statement. Are there really people going around talking about > SOA who have not deployed systems using Linda spaces such as the Javaspaces > implementation in the Jini platform? There is some things to learn by at least > reading about Jini technology. There are no new books on the jini2.0 and later > security changes. But the basic of Jini and javaspaces are clearly explained in > the old books and on the web. > > For those who have no spaces experience: > > A space provides an excellent mechanism for exactly what you describe. The > basic scenario is > > 1. N Workers are performing reads from the space, blocking when not > data is available. > 2. Applications put work items in the space. > 3. A worker's read returns the item, the worker does the job and > puts back a response. > 4. The application performs a read on the space for its results > 5. The application gets its results and proceeds. > > Identifying the response for a specific work item is part of the detail that you > decide on. One way is: > > 1. write an object with a transaction in it, along with the work > into the space first. > 2. perform a read under the same transaction, waiting for your result > 3. worker writes result to space using your transaction. > > This lets you see the transaction lease expiration as an indication that your > work will not be performed for you so that you can re-request your work. > > You can put a magic cookie in your work item that the result is also written > with so that you can identify the specific response you want. > > Queues are interesting, but only for more single focused data transfers. > Multi-in/Multi-out scenarios work much better with a space, instead. > > Gregg Wonderly > > > > > > > Yahoo! Groups Links > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
