RE: Typical SOA ... SOA Patterns

(See my reply to David Booth, which says this should not be added as a 
separate issue, but the agreed upon unresolved issues could say something 
about SOA.  Specifically, the issue about correlation, and the issue about 
intermediaries.)

That's the point.
We're talking about the "unresolved issues".
I guess you're not grasping what I think is the unresolved issue, and you 
cannot agree that it is unresolved.
OK.
Perhaps "relationships between and patterns for" causes confusion.
So maybe simply "More work needed on SOA" would work.

Perhaps that is obvious and will get addressed in due time by W3C or elsewhere.

I was pulled away from the F2F this week so I could not work this 
unresolved issue in earlier.

By the way, I was pulled away because I am working on an effort which has 
as one of its goals "to establish the value of a SOA approach for xxx".

The term "broker" gets used quite a bit in my environment lately, and I 
have been trying to define how a "broker" fits into SOA, and hopefully 
apply concepts from WSA.

Broker was not a term I wanted to introduce to the WSA trout pond.  In 
discussions with my colleagues, we talk about simple brokers and more 
complex brokers.  But we need to relate these "brokers" to the "SOA approach".

In WSA, we have intermediaries as an unresolved issue.  Intermediaries 
could be SOAP intermediaries, or perhaps things we could call 
brokers.  Perhaps there are different types of brokers and each can be 
identified by a role.  A broker might be a web service like any other, with 
its own WSDL and SOAP endpoint.  A broker that sits between a requester and 
some other service, in a high level view, might just look like two web 
services.  The broker may act in one role, and the actual service may be 
another role.  The broker may act as a requester for the other service.  A 
specific set of roles might be used in defining a particular SOA Pattern.

We (WSAWG) eliminated the triangle diagram from the WSA, which is OK.
We do not talk about the triangle diagram in the section on SOA, which is OK.

I guess I'm hoping for more clarity on SOA, in a standard would be 
nice.  WSA says some things about discovery, registries, indexes, and 
discovery federation, which relate to the "simple broker" stuff that I deal 
with in my day job.  I feel like I need more when it comes to relating 
complex brokers to SOA.   Given more time with WSAWG, or perhaps in another 
WG or effort, I would probably explore "SOA Patterns".  If the minimal 
essential SOA is Interface Description and Messages, then adding things 
like brokers would be a SOA Pattern; a way of using SOA.

Maybe WS-CDL (choreography) will get into things that I am calling SOA 
Patterns.  The problem I see is that WS-CDL would describe interactions 
between busineses, but brokers might be used within one of the businesses 
and would not have a place in WS-CDL.  WS-CDL might get converted to BPEL 
for one side of the interaction, which would imply a BPEL engine (or 
broker).  So neither WS-CDL nor BPEL may give me a view of the SOA Pattern 
used inside that organization.  I do not know enough of the details of 
either WS-CDL nor BPEL to say for sure whether or not they can express SOA 
Patterns.

WSA section 3.4.3 says "Note that each registry or index may provide a web 
service for discovery, so it may be appropriate to use a choreography or 
orchestration description language to describe the exchanges among these 
services needed for federation."  To the extent brokers are involved with 
discovery and provide a web service interface, I may be able to define the 
exchanges in BPEL.  Brokers that deal with things like content-based 
routing and message transformation may also have roles worth defining so we 
can use them in SOA Patterns.  Some brokers claim to do load balancing and 
failover (LB/FO).  If I have SOA, do I get LB/FO?  If minimum essential SOA 
does not provide it, what SOA Patterns do I need to get LB/FO?  If there 
are different ways of doing these things, then when a need arises to 
combine services but not lose LB/FO, it would be nice for architects to 
have a way to articulate what they have and what they need.

I'll start a thread over in ws-chor to see if/how they are addressing any 
of this.

Paul

At 11:55 AM 2004-01-30, Cutler, Roger (RogerCutler) wrote:
>In my humble opinion it is too late.  Even though I would probably
>support such a statement (if I understood it), I think that it is VERY
>clearly substantive and beyond the scope of mechanical preparation for
>publication.  I think that it would be a VERY bad precedent to sneak a
>substantive change in after the WG has disbanded.  In addition, I think
>that the fact that as a former member of the former working group I
>honestly do not understand what the statement means or the ramifications
>of it indicates that discussion would have been required had it been
>proposed during the working session of the group.
>
>Sorry.
>
>-----Original Message-----
>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
>Behalf Of Paul Denning
>Sent: Friday, January 30, 2004 10:40 AM
>To: www-ws-arch@w3.org
>Subject: RE: Typical SOA ... SOA Patterns
>
>
>
>At 10:20 AM 2004-01-30, Champion, Mike wrote:
> >I completely agree.  The problem is that it is January 30th; the WG
> >charter ends tomorrow, and we are simply out of time to make *any*
> >substantive changes to the Note.  (Typos, broken links, etc. can be
> >reported and fixed until Wednesday, I believe).
>
>I guess it is up to the editors to add verbiage (perhaps, or do
>something
>with @@) in section 4.3 [1], which now reads
>
>4.3 Significant Unresolved Issues
>
>@@What is the difference between an MEP and a Choreography?
>
>@@What should be the representation returned by an HTTP "GET" on a Web
>service URI?
>
>@@Should URIs be used to identify Web services components, rather than
>QNames?
>
>@@The relationship between privacy and Web services technology needs
>clarification.
>
>@@SOAP 1.2 and this architecture introduce the concept of
>"intermediaries",
>but this concept is not represented in WSDL 2.0.
>
>@@[wordsmith:] What happens if two WSDL documents define the same
>service?
>
>@@The relationship between conversations, correlations and transactions
>and
>choreography is unclear and needs more work.
>
>@@There is a need for consistent tracking mechanisms in Web services.
>
>------
>I am proposing
>
>@@Further work on the relationships between and patterns for using Web
>services and SOA.
>
>(Would be nice to add it if we can, but I understand if it is too late.)
>
>[1]
>http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2
>.html#id5212661
>
>Paul

Received on Friday, 30 January 2004 14:36:58 UTC