> most of BPEL engines work similarly when using WSA (WS-Addressing)
> to send messages from outgoing queue (with optional sender EPR that
> point to workflow incoming queue for request-reply pattern) - it
> shows that in that sense WSA enables very Linda-like computing
> environment.
That may be so, but it seems like an implementation detail rather than
an architectural constraint. When the architecture is constrained to
all service interaction to asynchronous inbound (push) and outbound
(pull) queues then the infrastructure developers can make some
simplifying assumptions, and the service developers can as well.
A BPEL engine may be implemented using queues but the overall
architecture is still wide-open to all kinds of interactions. No
assumptions can be generally made. Even if the queue approach was made
visible, yet optional, again no assumptions can be generally
made. Most bets are off.
I am not arguing that this queue architecture is the best one or
anything. I think it has some advantages, certainly over "no
architecture". But at least it *is* an architecture, it is simple, and
that does afford certain assumptions with potential benefits.
> i think SOA in this way is orthogonal to actual what are
> architectural "patterns" used to combine Web Services into something
> that actually does work: one can be Linda, BPEL, pubsub, or others.
Another way of saying this may be that SOA is so general as to be
nearly meaningless. Very few assumptions can be based on the typical
definition of SOA. Better to make assumptions even if they are bad
assumptions, because then they can be tested, analyzed, and improved.
-Patrick
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/
