Web Services Architecture telcon
26 Jun 2003

See also: IRC log


Present: Dave Orchard, Daniel Austin, Dave_Hollander, David Booth, Doug Bunting, Frank_McCabe, Geoff Arnold, Hao He, Heather Kreger, Hugo Haas, Jin Yu, Mike Champion, Paul Denning, Sandeep Kumar, Tom Carroll, Ugo Corda, Yinleng Husband, Zulah Eckert


Chair: Mike Champion

Scribe: Paul Denning


Minutes approval?  no objections.

AI Review

ACTION: Chairs to bring up the Web arch document on later telcon. 
ACTION: Editors when we put the UML in the diagram we must explain why we
are doing this. 
ACTION: MikeC to ping Heather about taking correlation. 
ACTION: To everybody please review the current Web Arch document and
formulate comments. 
ACTION: To the group to follow up on their issues.
  no change.
  5 unassigned
  Hugo, Daniel have closed a few
  New AI.  WG should examine their issues
  New AI to chairs to put on next week agenda

ACTION: (from editors telcon) Frank will propose a revised outline based on
discussions in Rennes and Chicago

Heads up TAG draft working toward last call.
Now is a good time to review TAG doc for WSA impact and/or feedback to TAG

AI: Hugo to work with DBooth to work on reslution to i26

4. [16:00] Harvesting / Text suggestion tasks assigned last week

The idea here is to check on the status of the assignments last week to
assign concepts to "champions" who will review the text in the draft, check
for useful discussions on the mailing list that can be harvested to improve
the text, and help lead us to resolution on actual document wording for each
concept in Section 2.
I'll link to any messages that I know of completing the task, and update
this with pointers to any that have been completed by the telcon time.  

MEP - MJ and Hao exchange.  Take to public list.  Get concensus in WG, 
then editors will add to doc.
Editors should note which text comes through this concensus process.

FM: adopt approach used in reqt doc.  section numbering, prefix "D" for draft. 
 works well for Choreography

AI editors to use "D" for draft convention.  Remove D after vetting on mailing 
list initiated by issue "champion"

Section 1.5.3 text from DBooth.
No objections.

(Note, to re-open after 'D' removed, we should have really good reason, not 
necessarily 2/3 majority. Needs to be something new and not previousl;y 

MEP text MJ/Hao worked offline.  See January breakout session,  2.2.22.  
Patterns at several levels.  MJ wants more


MC: Choreography.
FM:  "Orchestration" is a no-no topic.  "Orchestration is Choreogrpahy from 
perspective of one of the participants", but FM would rather stay away from the 
term altogether.
DO questions.  WSAWG different mandate:  identify gaps.  Okay if WSChor declares
 Orchestration out of scope, but WSAWG needs to figure out if this creates a gap.

How to handle in our document?

WSChor could not agree on "Orchestration" like WSAWG sync/async discussion.  

FM: need way to show that services are part of a Chor. Not an issue of precision.
idea 1: enforcement that WS is following a choreography
idea 2: participant view of the choreography.

DA: Harmony with DH.  Not comfortable WSAWG ignoring.  However, WSAWG could go 
back to WSChor to request further.  Enough WSChor people

Chapter 1 backgrounder, Chapter 2 deals more with ...

What does BPEL TC think they are doing?

DO: WSAWG should sort it out, BP execution, orchestration, choreography.  Not a
 high priority.  Make visible in WSA WD, then get review from WSChor and BPEL TC.
MC:  Talked with TimBL.

DO comfortable saying "within W3C it means X, but in OASIS is means Y" if
 consensus across industry cannot be achieved.

 BPEL doing both executable and abstract processes.  Need to partition so
 BPEL TC focus on single participant (execution) and WS Chor focus on bigger 

Hugo: agree with DO.  People will wonder about relationship to BPEL and 
execution vs abstract.  WSAWG needs to address it in some detail.

Shared State Machine (SSM) idea.  Resonated in WSChor.  DBurdett sounds like 
implementation.  FM would push back on DBurdett comments.  DA: can we accomplish
 interop goals without going into this space?  Need to go there.

Choreography addresses global model, which gets into shared state concepts.

Don't get too geeky.

DH: audience is spec developers and people who assign resources to spec 
Not for the press.

SSM not meant to address implementation.

WSChor unresolved about difference between Chor and MEP.  Chor should be able to
 model all MEPs.  MJ and Hao?

MJ  composition of patterns at various levels.  SOAP has specific notion.  
Message and responses played out at binding level.
Chor addresses messaging framework above binding.

DA:  Chor higher level than MEP, but keep hierarchy in focus to help organize
 out thinking.

FM:  recursive composition required in Chor, not in MEP.
FM:  messages vs signals needs to be clarified, lost at MEP level.  Signals 
lower than MEP?

Msg A to B, signal B to A as 'ack', but later message from B to A as response.

DA: WSA opportunity to add value.  Start with SOAP MEP, build up.  Get agreement.

BPEL bound to WSDL???

Reliable Message.
Started with messaging.  Found relationships ...?
Req/Resp as separate message.  Unclear about response as part of same message.
Headers and message structure.

MC: Message Description Language?  same as WSDL?

FM:  agree to be clearer about messages vs interactions, but ...
interaction with pub mgr
initial subscription is a request
arbitrary time and processing between

Is everything based on Req/Resp model?

FM:  Does not address P2P.  Don't bake in MEP when defineing message.  
Just address data that is transferred.

Hugo: msg may be part of MEP, vs MUST.  Def of Msg should be basic, structure, 
header, not much more.  Sender and Receiver?  Identifier?  Messages MAY have 

MC:  Definition of Messages does not have to talk about MEP not Interactions.

Hao:  if anything can be a message, does not help in WS context.  What is 
Message in WS context?

Which is more foundational?

MJ:  Goes back to def of WS as something related to SOAP and WSDL, vs 
something broader.

Simplest possible MEP is just a Message,  fire and forget.

Add concept of interaction to message, or 

FM:  interaction is overused.  not definable.

Hao did a good job to identify a fuzzy area.

Need to remove interaction stuff.

Message is a one way zero or more recipient.

Black force - unknown receivers.  NNTP intended destination - net news group.

MJ: problem with zero receipients.

Change to one or more?

Ugo:  HTTP headers.  confusing.  Cannot use HTTP GET if ... HTTP headers.


MJ:  covered in earler discussion.

Doc re-org (FM):
Diagram sent proposing to break into 5 sections.
Large bubbles labeled.  Relationship among bubbles?

Distinct subsystems.  Separately explainable

Core concepts bin, other.
Frank's proposal captures the spirit.

Core concepts are partitioned into the 5 bubbles.

1. SOA
2.  Resource Oriented Architecture - REST
3.  Security
4.  Management Architecture
5.  Message Oriented Architecture

People overwhelmed by spaghetti diagram.

5 bubbles provide a gentler introduction.

Lost some of Rennes discussion?

Greyed out concepts - necessary, but not part of the architecture.  
Legal entity.  Not foundational, but need to reach out to it.

DA: Chapter 2.5 roadmap?

FM:  don't need a whole chapter for foundational concepts.

DA:  At least a dozen discussed at Rennes.

Terms not WS-specific or defined elsewhere.  E.g., resource (IETF).
"Agent" discussion.  DO proposed normative pointer to external definitions.
Get these pinned earlier in document before using them.

DBooth: propose editors discuss.

DA:  Alphabetical only makes sense.  Pushback on Frank's 5 bubbles as 

Discuss next week.

<yinleng> I think we need to distinguish between or define choreography and orchestration within WSA for the sake of providing guidance to the general industry

<mchampion> [scribing Mark's comment for my own benefit] MEP's are primitive units of interaction between consumer and provider; Choreographis are compositions of MEPs
... Daniel: Chor more abstract than MEP, keep levels
... frank: Choreographies are recursive, MEPs definitely not
... daveh: it is a Good Thing to layer Chor on MEP and help world understand this
... Hugo: more WSDL MEPs not SOAP MEPs ... that's what BPEL is based on
... http://lists.w3.org/Archives/Public/www-ws-arch/2003Jun/0218.html

<ugo> The previous comment on WSDL MEPs was from Ugo, not Hugo

Summary of Action Items

ACTION: dbooth and Hugo to work on resolving Issue 26

Minutes formatted by David Booth's perl script: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
$Date: 2003/07/09 20:03:54 $