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 Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/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/
