http://lists.w3.org/Archives/Member/member-ws-chor/2003Jun/att-0041/jun_f2f_Agenda.htm
|
Martin Chapman (MC) |
Oracle | |
|
Steve Ross-Talbot (SRT) |
Enigmatec | |
|
|
| |
|
W3C Staff Contacts |
| |
|
| |
|
|
|
Members:
|
David Burdett (DB) |
Commerce One |
|
Paul Lipton (PL) |
Computer Associates |
|
Alistair Barros (AlB) |
DSTC Pty Ltd (CITEC) |
|
Jean-Jacques Dubray (JJD) |
Eigner |
|
Francis McCabe (FM) |
Fujitsu Ltd |
|
Assaf Arkin (AA) |
Intalio Inc. |
|
Abbie Barbir (AB) |
Nortel Networks |
|
Greg Ritzinger (GR) |
Novell |
|
Jeff Mischkinsky (JM) |
Oracle Corporation |
|
Nickolas Kavantzas (NK) |
Oracle Corporation |
|
Ugo Corda (UC) |
SeeBeyond Technology Corporation |
|
Michael Champion (MCham) |
Software AG |
|
Monica Martin (MM) |
Sun Microsystems, Inc. |
|
Jon Dart (JD) |
TIBCO Software |
|
Daniel Austin (DA) |
W. W. Grainger, Inc. |
|
Leonard Greski (LG) |
W. W. Grainger, Inc. |
|
Ed Peters (EP) |
webMethods, Inc. |
Substitutes:
Bob Haugen (BH) |
Choreology |
|
Gary Brown (GB) |
Enigmatec |
Guests:
|
Tom Carrol (TC) |
UBS |
|
Steve White (SW) |
IBM/BPEL Liaison |
|
Rajesh Pradhan (RP) |
iopsys/BPEL Liaison |
|
John Evdemon (JE) |
Microsoft/BPEL Liaison |
|
Diane Jordon (DJ) |
IBM/BPEL Liaison |
Raw IRC logs at: http://www.w3.org/2003/06/18-ws-chor-irc
http://www.w3.org/2003/06/19-ws-chor-irc
http://www.w3.org/2003/06/20-ws-chor-irc
Meeting scribes were: Francis McCabe, Monica Martin, Greg Ritzinger, Ed Peters, David Burdett
email etiquette: get your subject lines right!
liaison with OASIS BPEL
chairs of WS Business Process TC were invited,
Yves: http://lists.w3.org/Archives/Member/member-ws-chor/2003Jun/0024.html
try to sort out relationship between WS-CHOR and WS-BEPL
JD: Should this group build an executable language ?
JD: Requirements not in yet
We need to clarify the scope of WS-CHOR
Yves: http://lists.w3.org/Archives/Member/member-ws-chor/2003Jun/0028.html
We had a discussion on the liaison with WS-BPEL. We will revisit this together with the mission statement later
We discuss requirements document
Document is level 0.5 currently has use cases but no requirements
submitters should ensure that no products are mentioned in use cases offered for the requirements document
submitters should document salient features of the use case. E.g. parallel processing
Use case scenarios' template needs a section on salient features: i.e., what is important or technically interesting about the use case
Haugen: What about negotiating on an agreement?
Examples include negotiation of an agreement, of a quote, of a delivery.
Use a negotiation pattern
Austin: The contractual negotiation is key for web services across organizational units.
What happens on composed web services?
Asserts occur at various steps in the process.
Correction: Assertions occur at various steps in the process.
How do you ensure continuity in agreements? The vendor feedback on this is identify a set of assertions at every point of the node to resolve.
Business will not feel comfortable about cross-boundary web services unless this can be resolved.
What implicit set of assertions exist to apply the context of these web services.
Dart: Is this out of scope? What about SAML, single sign on and validation?
Austin: Distinguish between business contract and the specific business rules (For example, 24x7 capabilities).
Chapman: What are the requirements on the choreography language? Can we establish patterns?
SRT: Metadata information may be provided with the choreography that relates to a contract.
Different services have different SLAs.
McCabe: There are consequences of including this in the choreography - what happens if something occurs dynamically?
Chapman: Differentiate static and dynamic.
Dart: Negotiation of terms - are there actually flows related to negotiation?
Peters: Does this provide a requirement for a choreography to be extended to include an agreement or contract?
Burdett: Describe attributes of a choreography to apply to what we do.
This is a more general requirement for capability to describe a choreography to express an agreement.
Martin: Do we provide a reference capability?
Chapman: Differentiate between contract and agreement.
Haugen: There is offer, counter offer...keep it simple.
Brown: Different interaction between different processes.
Chapman: Negotiation is a use case subset of a use case.
Haugen: Break this into a separate negotiation use case.
Austin: We carry this metadata.
Chapman: Maybe or maybe not.
Let's only talk about the technical contract. Is it a part of our scope?
McCabe: Contracts are boundary areas.
Chapman: WSDL or choreographies can be considered agreements.
McCabe: Three aspects exist: negotiation involved in coming to agreement, have an agreement, and the document that tells the constraints involved.
Haugen: What about fulfilling the commitment4?
Chapman: Typically we start with the WSDL document.
Martin: Doesn't this relate to CPP and CPA?
Dart: Different.
Austin: Compare assertions.
What are common assertions?
Negotiation is a verb, according to McCabe. What are the combined set of assertions?
We have two verbs and one subject: Negotiate set of assertions and then we have an agreement.
Chapman: Look at Goland use cases. When we write the choreography, we need to start with the businesses that have existing processes.
The agreement is the message flows.
Nickolas: Common agreement
Chapman: How does this relate to choreography?
Austin: Need this to enable web services across boundaries.
Chapman: Is this manual?
Austin: Need to automate.
Chapman: We look at operations and apply a new process?
Austin: We are negotating the constraints.
Chapman: Am I trying to put in choreography?
Dart: Negotiation phase
Chapman: Is there a construct I need to define the queries and the MEP?
McCabe: DAML and OWL, DAML-S - If you can put DAML-S in WSDL 1.2 to include specific data - you may not need to add some of this into the choreography.
Burdett: Shows interoperations between services?
Austin: Yes.
Burdett: What is the sequencing, how (busines protocol, secure, etc). We are only addressing choreographies.
We may not be able to solve but it needs to be.
We are trying to solve the interoperability problem.
Brown: Support interoperability and the global model.
Burdett: Annotate or extend a WSDL definition to show what choreography it supports.
Bind together.
SRT: Is annotation extending WSDL with choreography? And, if you have multiple choreographies with specific goals, is multiple chor against a specific web service related to tasks?
What if you have a task that can be done in multiple ways? What happens if you compose services? Do you need to then negotiate?
Burdett: Extend WSDL to define choreographies.
McCabe: MEP express choreography within a service.
This is within WSDL.
Chapman: WSDL doesn't expreess ordering, duration, quality, etc.
Burdett: M-M WSDL-Choreography
McCabe: WSDL sees services as atomic.
Austin: Requirements to ask WSDL to provide these extensions.
SRT: Externally observable behavior sits outside of WSDL definition - does that dictate that those actions all go through the choreography? If they don't do you lose something?
McCabe: Interaction with web service where a choreography is hardwired should exist.
Explicit choreography exists between agents - one is hardwired and the other looks at the choreography specification and they could interoperate.
Dart: What are the requirements?
Chapman: Requirement generally related to contracts
Nickolas: What about abstract process in BPEL?
Chapman: Stick to our requirements. What about quality, for example? In BPEL, this is implicit.
Negotiation - what in the language helps negotiation?
SRT: Task can have multiple choreographies.
What choreography do you choose?
REQUIREMENTS: EXPAND WSDL. LANGUAGE SUPPORT FOR NEGOTIATION. DYNAMIC NEGOTATION WITH TASKS WITH MULTIPLE CHOREOGRAPHIES.
Haugen: Negotiation presents challenges to choreography.
For example, what about nested negotiation?
Peters: This communication may not only apply to negotiation. If we can take this idea, and define a pattern.
Chapman: REQUIREMENT - Need to express nesting, recursion, in a simple manner.
SRT: REQUIREMENT Simple attributes or complex one with context (Same choreography definition with different attributes)
Dart: This is in Privacy use case.
Table for now.
Chapman: Is there a standard interface?
Burdett: There are many questions.
McCabe: Meta-negotiation and then negotiation - differentiate these.
Chapman: Get to essentials first.
Dart: REQUIREMENT Extensible choreographies
Example is a bidding process for several networks - travel services without an integrator.
SRT: What system does bi-simulations dynamically? Is this a requirement?
Chapman: Callback use case needed.
WS-I cases - try to get WSDL and SOAP working.
Place order. Manufacturer gets a callback message when the product ships.
Break time......
Austin: Define primitives.
Use to develop choreographies.
SRT: Explicit list of simple use cases
Barros: What about broadcast?
What do you expect in response?
Peters: MPC that is not dynamic - Buyer-Seller-Shipper case is an intermediate level of complexity.
Austin: Need to develop user scenarios.
BORRAS VOLUNTEERED FOR THIS USE CASE.
ACTION: Borras will develop a use case / scenario for this broadcast use case.
Burdett: If you want to involve multi-parties in a single choreography, all parties need to have visibility to the others.
Haugen: In MPC, if the supplier delivers to the end customer - the whole supplier has to be involved in entire choreography??? Is this feasible?
Differentiate visibility vs. involvement.
Burdett: Combine choreographies within a choreography set.
Martin: What are the requirements here?
REQUIREMENTS: Differentiate multi-party collaboration visibility from involvement.
Dart: There needs to be synchronization point between choreography subsets within a set.
REQUIREMENT: Determine if MPC is limited to visibility, are the MPC actually defined within the scope of binary collaborations.
Austin: Hierachy of choreographies
Martin noted that BPEL can't handle the scenario Jon just outlined
REQUIREMENT: Synchronization point between choreography subsets within a set.
Lafon: Multi-cast - you may not have visibility to parties that are involved.
Requirement: counting constructs needed - e.g after 4 replies
Dart: Can't base decision on the parties (fixed M number of parties).
Borras: Bounded and unbounded are important.
Dart: All participants may not be known in advance.
REQUIREMENT: Support a number of rules, such as number of parties, timing, etc. that can trigger an event for a service.
SRT: Classify choreographies with, for example a fixed or dynamic set of participants.
Chapman: Who has visibility to see when a new member is added?
REQUIREMENT: When a member is added, changed or deleted, what roles have visibility?
Dart: What visibility exists other than message exchange?
Lipton: Need to handle composite responses - 15 minutes or three parties respond.
SRT: More complex than a join condition
Issue: how are state changes (e.g. new participant join) communicated? part of the choreography infrastructure or built into a choreography?
Austin: Business rules are not simple assertions but compounded with several variables.
SRT: Complex join condition
What is the public observable behavior or not?
ACTION: Burdett - Need design collaboration use case.
Dart: Complex business logic in an observable way - does this bring this down to execution language?
SRT: Next steps with requirements document? Go public in two weeks.
Austin: Differentiate use case and user scenarios.
ACTION: SRT harvest requirements from the email list.
This is now subsumed by the addition on SRT to the requirement editing team.
ACTION: Laron determine what format is required for the documents we produce.
SRT: Falls on 4 July.
Get a vote on first release 8 July 2003.
ACTION: All team members who submit a use case must provide in the template format by 1 July 2003 if they wish it to be in this release.
SRT: Why would we wish to liaison with WS-BPEL? Why is it important to us?
Discussion on the why liaison is important.
Group agreed to minimize overlap, but realized some overlap is probably unavoidable.
Worked on mission statement to present to BPEL Liaison group on Thursday.
We agree to the following, with the caveat that wordsmithing is required:
A language to define/describe a Peer to Peer global model for cross-enterprises through the composition of web services that are independent of any specific programming language based on the foundation of WSDL 1.2 and the incorporation of the semantics of their interactions
Review of Issues
MC: discussed use of BugZilla to manage issues list. Restrict editing access to subset of members. Editing access can be requested.
ACTION: Give GR and DA editing access to Bugzilla
MC: Issue can be anything you want logged.
DA: Issues are things that need group level resolution.
MC: Open issues could mean work of group is incomplete.
ACTION: Chairs (MC/SRT)to sum issues process.
BPEL Liaison
DJ: discussed general BPEL liaison activities (management)
DJ: expressed agreement with objective to reduce duplication of effort.
SRT: demonstrated overlap of membership w/in both groups
MM: suggested using this group's task as a point of discussion. The current task definition was presented.
DJ: Pointed to BPEL charter. Charter motivation is BPEL spec. but recoginizes that it may be incomplete.
SRT: Asked DJ for her views on what technical overlap there may be between the groups.
DJ: preferred to remain neutral on this issue.
SRT: asked how DJ would like to proceed in working together.
DJ: hoped work would be through the liaisons. Asked other present BPEL members for suggestions.
JD: mentioned IP concerns w/ BPEL.
SRT: expressed concern about patent disclosures.
DJ: said that 2 of the submitters posted those disclosures (on OASIS BPEL group web page?)
DJ: said that 3 of 5 authors have gone beyond OASIS requirements regarding licensing disclosure, which is RAND terms.
RP: asked SRT about his thoughts on starting the liaison process.
SRT: thought discussing requirements would be a start. Liked idea of doing papers together.
Comment: More IP concerns, no lawyer present...
LG: expressed concern about inheriting IP problems from another group from the point of view of the end user
MC: answered that you really need to be aware of all the patents involved.
DJ: suggested discussing our IP concerns with our IP specialists.
MC: suggested we not become paranoid by the IP issues.
AA: suggested that talking to IP specialist == crash course in paranoia
LG: Expressed concerned about user's responsibilities regarding IP
JD: concerned about vendor's IP rights.
MC: We need to be careful, let's move on from IPR theme.
MM: abstract process vs. choreography, what is potential overlap? Could groups concentrate on their core competencies?
SRT: it is not our intent to specify a language that could be considered a business process execution language.
MC: agreed that we are not in that space
SW: has current mission statement been accepted by the group?
MC: so far there has been no desent from the group.
SRT: it is not a question of if there will be overlap but a question of how overlap will be handled bewteen the groups.
RJ: what is the overlap?
MC: e.g. abstract processes (possibly)
??: could groups share use cases?
LG: how would 2 groups interact (in a perfect world)?
SW: are ws-chor use cases available publicly?
SRT: they are on the public mailing list.
LG: what steps need to be taken to get happy days liaison scenario to happen?
LG: group overlap does not include "user" organizations, a concern.
MC: users could join other group(s).
JE: felt that there would be interest w/in the BPEL group.
SRT: overlap needs to be complimentary.
SRT: we don't know the BPEL-TC view of what the overlap would be.
DB: 2 problems to be solved, one is the shared definition of the choreography (missed 1st).
JD: shared state issue as possible overlap
MCham: asked for clarification about relationship between BPEL executable/abstract processes.
SRT: asked DJ if choreography was in the BPEL-TC scope.
DJ: no it is not in scope.
MCham: There seems to be interest in defining our (BPEL, ws-chor) scopes re: coordination. Group discussed advantages of focal point (person or group) in liaison activity.
LG: read W3C Coordination Groups definition
DJ: OASIS has no formal liaison process, currently.
DJ: as TC we can do what makes sense. For each group we liaison with we will have a focal point.
RJ: number of focal points will depend on size of target group.
DJ: asked MC if he wanted to begin thinking about appointing a focal point for liaison?
MC: not yet, needs further research re: W3C procedure.
SW: asked if this group had a list of questions for BPEL group?
MC: we will formulate
MC: Suggested to DJ that liaison activity should be through chairs until focal point is determined.
Formal Models
Event Calculus (Frank McCabe)
Reference: EventCalculus.pdf
DA: so an event's an operator
FM: I'd like to table that discussion
EP: can you give an example?
FM: in russian roulette, when you spin the barrel you don't know anymore whether the gun's ready to fire).
JD: you do know a probability
FM: probability doesn't enter into it at this level
MCham: so it's something simple, like guilty or not?
JM: what do you mean by an extent in time?
MC: I'm 38; I won't be in three weeks
JM: what's the state of the fluent outside that period of time?
FM: it's release
JM: so it's three-valued logic?
FM: it's not true three-valued logic
JD: I assume you can't use the fluent value at that point
FM: correct, you can't use it at
JM: but it's a logical formula, so can't I do f1 & f2?
FM: we'll get back to that
BH: what's the difference b/w terminated, clipped, released?
FM:
MM: you reason that something is true, and when it's not true, it's terminated. what happens with a non-substantive failure? example: if I'm required to give an acceptance and a procedural acknowledgement -- if I don't get the acceptance, the process doesn't terminate, meaning it's not substantive.
FM: this isn't a process language, it's a way to reason about things that you might believe about the process. you can set up logic that tells you whether the process should be stopped or not, but there's no way to then go on and direct the process to stop.
FM: <presents a partial ordering of points in a choreography that involves an order. states are fluents like "Order Placed", that get initiated with events like "Send Order">
BH: in a distributed multiparty process, how do all the parties agree that the ordering is acceptable
FM: how do you map a set of messages to an event? identify an event and the fluents associated with it (e.g. a cancel event terminates the order). in a two- phase commit, there's more involved.
BH: but getting two parties to agree is the problem
EP: aren't we talking about the mapping between the simple calculus model and the real-world implementation?
BH: I want to take this nice simple formulation and get to a point where we can both agree that a particular fluent is true.
FM: if you're trying to understand any kind of calculus, you have to map the symbols into the real world. that mapping is a form of interpretation. an event mapping may well involve multiple "real-world" events like sending documents.
FM: in response to srt: the preconditions to a fluent can definitely involve multiple events (e.g. "the order is sent when we receive events E1 and E2")
Initiates(f) and
not Clipped(0,f,t)
(something holds if it was initiated and not clipped)
Happens(a,t1)
Initiates(a,f)
t after t1,
not Clipped(t1,f,t)
(basically, this says that something holds at a particular
time if it was initiated and has not since been clipped)
BH: does "holds at" mean "true"? couldn't it mean "we know it's false"?
FM: no, "holds at" means true, but it could be a negative fluent. dealing with negative fluents involves richer axioms.
MM: you mentioned policy. how does EC know that something is true without having a reference to something that determines what is true?
FM: it doesn't, you have to make an ontological commitment (make an agreement) that certain things mean certain things. it's useful as an analysis tool, but you can also do simulations. in terms of its connection to real life, you can express policy rules in this framework, and it gives you predictive capability; e.g. you can't have an invoice if the order wasn't accepted.
MM: so the semantics of the process are outside the calculus?
FM: always
JD: to what extent can you have alternate flows -- for instance, how can you model an order being accepted or rejected?
FM: EC is neutral to the nature of the fluents being modeled. if you have negated fluents, things become much more complex, but this is a function of logic involving negation.
JD: another common condition would be -- this fluent becomes true based on time, but also based on completion of some other part of the process.
FM: this is what events are all about. you need to identify events that are relevant to the fluent.
SRT: it would be interesting to take some of the use cases and express or analyze them using this framework. it would be a very concise way to express them -- like pre- and post-conditions.
JD: this is very much like state machines
FM: you can map state machines onto EC, but it's not the most natural way of thinking about this
EP: seems like a one-way mapping -- because of parallelism, you can map EC onto state machines
FM: it does seem asymmetrical
DA: aren't there different kinds of events?
FM: when you describe the association of a fluents and some events, you're saying that no other events will touch them.
DA: so there are at least two different kinds of events: one that change the state of the fluent, and one that doesn't
BH: how does the partial ordering of time points happen? The only time points that we know about are associated with time points. how do we establish the ordering?
FM: you declare the ordering as part of the definition.
SRT: what other formal models (if any) should we be looking at, and what relationship should this have to the work we've been doing.
DA: the two we've looked at (PC and EC) are dynamic calculi used to describe sequences of events. we lack a formalism to describe the static configuration of the different parts taking place in those exchanges.
MC: pi can do that.
DA: something like UML -- captures statics, but not dynamics. but we're can't use that.
MC: if we're talking about one process connected to another, pi calculus can do that.
DA: if I want to talk about the properties of service A and how it's connected to B.
MC: OCL is a formalism you might want to leverage, but it's pretty similar to EC.
DA: UML isn't formal enough.
JD: I'm disturbed that it's difficult to move back and forth between EC and a state machine model. One problem is how to determine that implementations are correct?
FM: the verification industry hasn't gotten off to the start everyone thought they would.
JD: this may be a special problem.
FM: the EC is neutral with respect to that issue
MC: there are many formalisms out there, with one (pi) gaining a lot of mindshare. do we have a compelling reason to be different?
DA: we might
SRT: we may not have to be -- I'd like a higher declarative form in which to specify things, and event calculus looks good, but it may be useful in conjunction with pi.
MC: we're not engineering a one-to-one mapping with the concepts of these formalisms, so we're not going to be handing people pi.
NK: you can't use pi (as it is) to do global models
AlB: there are formalisms modeled on petri nets (operational semantics), which might be interesting, but is it the job of this group to assign a formalism to our output? that's a huge task
MC: we intend to base our work on a formal model, but it's not entirely clear which one
AlB: what is OASIS doing?
MC: probably nothing, because the original authors of BPEL used pi, and that's good enough for them
FM: the merit for having a formal underpinning is that is helps you determine when you've completed your job; i.e. when you have enough features to accomplish the task, with a minimum of surprises later on
AlB: there's a necessary tension between establishing the formal model of a language, and fleshing it out with features and functionality
FM: yes, and you can get a PhD student to do that. We want to learn lessons from pi-calculus to help us answer that question of when we're done. I don't think anyone's talking about doing a denotational semantics of ws-chor
MC: we've had a lot of discussions about this, perhaps we should record this decisions
SRT: and others: we should record that it's not one of the deliverables of this group to define the formal semantics derived from a formal model
MC: so why are we talking about formal models at all?
NK: to provide us guidance
DA: what bad thing will happen if we don't do this?
NK: you may not be able to prove things like conformance
JM: this is similar to relational databases, where every vendor "sorta" implemented the formal model, plus a bunch of ad hoc features. you can still prove useful things.
SRT: they implemented enough, though -- you couldn't have query optimization without a formal model. because we're loosely deriving from a formal model, we'll still have an idea of what we can and can't do.
DA: will bad things still happen if we don’t directly derive from a formal model?
MC: if we don't have a formal model, you might not have a language that works at all
JD: if we have an interesting language where useful stuff is possible, we still might not be able to prove anything at all.
MC: how much time as a group should we spend on this?
EP: it seems like a big coin to flip -- what's the right stuff to stick with?
PL: the harder this is, the longer it will take us, which is a Bad Thing, so can we figure out how long this will take us?
AlB: just basic extensions to workflow parallelism took me twelve months. it's a lot of time.
DB: it would be very useful to have one or more people to be our "conscience" to advise us when we're making huge mistakes
FM: the conscience role is a very good one. there are black holes we can fall into, and maybe we can avoid them if we can use formal models to decide whether a proposed feature (e.g.) will cause trouble
GB: rather than an ad hoc thing, maybe the folks with the relevant experience could have a parallel track to include Bugzilla issues related to formalisms.
FM: going off in an ad hoc way hoping that the PC or EC police will tell us when we're wrong is likely to be inefficient. different formalisms will have very different predictive capabilities. I think we should pick a course.
LG: maybe we could finish the requirements spec and then evaluate the various calculi against them. we could use Greg Meredith's evaluation matrix of calculi along with our requirements for this.
EP: can we breakdown a use case based on formalisms?
MC: action -- form a formalism task force to dig into this deeper, and maybe evaluate a use case.
Language features
WS-Choreography Submission (known as BurdettML) (David Burdett)
Reference: WS_Choreography_v.0-1_Overview.ppt
NK: are you talking about static or dynamical verification?
DB: at runtime
NK: are interactions one-way or bi-directional
DB: basically one-way
- Why Reusability?
* supply chain example: must be able to reuse chor up and down supply chain to realize benefits
NK: what are you really reusing?
DB: the choreography -- roles, states, etc.
- State Driven
* <example slide w/ order example>
NK: which states are public and which private?
DB: all are potentially public, and I'm not sure we really need to define processes.
DB: the example process is artifically simple
MM: isn't the goal to synchronize states?
DB: no -- you can never be absolutely certain of the other guy's state, because messages can fail.
- Interactions, RM, Signals
* some messages are fundamental (reliable acks, etc.)
MM: you have to differentiate business signals from (e.g.) transport signals. which of those should be in the choreography?
DB: some signal-type information should be in the choreography; for instance, an "out of stock" message is definitely key
DA: does the choreography def define the ordering of the messages?
DB: yes
SRT: if I use the telephone, and the line drops, I don't phone back and talk about a low-level telco message, I ask about a business message. you're talking about business messages, right?
DB: yes. and alot of this stuff has already been discussed on the list.
JJD: the benefit of signals is to take lower-level messages out of the choreography
- Checking Chor Progress
* question: what do you do with a "state error", where you're
in the wrong state to receive a message?
- Random
* composing choreographies might be better than extending them
* choreography dependencies: there's a relationship b/w the choreography for sending an order, and the one for checking order status
PL: what's a state change query? an actual query? or a callback?
DB: imagine a callback, where you never get called back. You should be able to go get the choreography.
PL: a callback would be better for management
MM: we need to understand the state; the mechanism for doing that is an implementation decision.
PL: wondering about how to make choreographies manageable. Two ways to do this -- a query, or a callback. callbacks scale much better.
EP: how can you get distributed state? do you have to query everybody?
DB: yes
- XML Structures
* definition provides an anchor point for natural language
description, OR potentially RDF
* import works the same way as WSDL import
MCham: couldn't include be just an xinclude
DB: this is a work in progress
* a role contains states and some other stuff
MM: you're attaching roles to a choreography -- how do you know how you're allowed to do that? a particular business partner might not be allowed to execute a particular choreography. I'm not talking about security, but rather about the capabilities of the role and the instance of the choreography it's in.
DB: a role is more like a partner type
GB: how do you represent concurrency?
DB: I'll get back to you
PL: end states aren't global?
DB: correct, they're specific to a role
MC: conditional end states seem dangerous, because they invite bad design.
GB: when we design the XML for this, are we looking to have something which is potentially human-readable, or only something for machines?
MC: is XML human-readable?
GB: if you look at BPEL (e.g.) you can understand the flow; if you look at this it's hard to understand all the relationships involved
SRT: it's not readability, it's the ease with which it can be understood
- What's missing
NK: what about correlation?
DB: I see that as part of the binding to WSDL & SOAP
SRT: what do you mean?
DB: in sending a message from one role to the other, the sender needs to know the choreography and instance, and that information should be stored in a SOAP header
YL: correlation is at the contract level, and depends on the features and properties introduced in SOAP 1.2 and WSDL 1.2
JD: can I do iteration or concurrency?
DB: you could do concurrency with multiple potential output states
LG: are we really talking about roles, or services?
DB: services are taking roles
LG: state changes are really on the message objects -- an order is the thing that's being changed
MC: yes, but in a distributed implementation you couldn't track the state
BPSS Lessons Learned (Jean-Jacques Dubray)
Reference: BPSS_f2f_june03.ppt
- BPSS MEPs
* BPSS only recognizes a single MEP
* Once an exchange is done, we can recognize a state: business
success/failure, protocol success/failure
- Business Transactions
* introduced non-repudiations etc., should have been a new layer
* business exceptions should be called service exceptions
NK: business exceptions can be long-term; do these really map to web services exceptions?
JJD: the idea is to define a standard kind of signal that can be passed back as a result
MC: the issue is that WSDL has no standard notion of signal
JJD: a very important aspect is to make sure that each participant has an unambiguous view of the state of the interaction. We must be able to look at that space. how do we layer the messaging to give choreographies the ability to do that, without cluttering them with simple signal documents.
- BPSS Control Flow
* Based on UML activity diagram (big mistake)
* UML doesn't support concurrency/iteration very well
MM: Is that UML 1.4 or 2.0?
JJD: not sure.
- WS-Chor Control Flow
* event-based
* MEP completion enables/disables certain MEPs
* supports parallelism very easily
- WS-Chor Control Flow (example)
<slide with sample XML>
NK: this looks like join calculus
JD: when you say enable, do you mean "enable" or "will occur"
JJD: ?????
MC: what is a "choreography protocol"?
JJD: in a choreography, you do state synchronization, and usually in a protocol you do state synchronization,
MC: is this related to WS-Coordination
JJD: not sure
DA: talking about multiple MEPs in WS-Chor, the idea of a MEP language came up in another working group. is this something that this group should do?
MC: responding from WS-D perspective, they're probably going to fix the number of MEPs in WSDL, saying "that's what choreography for?"
NK: this is use case 0
EP: a choreography should be reusable, then a two-party chor becomes a MEP
MC: should we define a language for MEPs, or a library of MEPs?
JD: the question of whether we expand WSDL has been raised, it's time to put this on the issues list.
DB: if you could use the language we come up with to describe the MEPs in WSDL, that would be good, but then you want to standardize some of the most common message exchange patterns.
FM: a language for defining MEPs may be structurally similar to a choreography language, but will include a whole bunch of details that aren't relevant in a chor.
AlB: these patterns should embrace multiple messages
LG: you could look at a MEP as an interaction b/w one or more services where it's a synchronous interaction, whereas multiple interactions b/w multiple services could be synch or asynch
SRT: MEPs as I see it are one application that a chor language could be put to -- it's not a language feature, it's a use (with possible requirements on the language). Also, we haven't talked about the potential feature of scoping, or restricting choreographies.
JD: MEPs (currently) are synchronous, but asynchronous exchange patterns are definitely useful, and not having them at the WSDL level is complex. For example, WS-Callback had to define all operations as one-way.
MCham: it would probably be useful to "pour beer down" various schema people and users
DA: what is WS-Coordination? what is WS-CallBack? can we come up with a way to organize this stuff?
MC: this would be for the architecture group. part of the problem is that these aren't all really standards -- it's just stuff companies have written and posted.
MC: regarding MEPs in the language -- if you say you want the language to be able to define MEPs, it definitely affects the language. For instance, most of our proposals, we talk about strongly typed stuff, but an exchange pattern really wouldn't fit that bill.
MM: when we talk about looking @ other patterns, we've already got 6 (possibly 7) interactions have been defined in the UMM. how does that relate to MEPs?
MC: MEPs are more structural -- how you exchange, rather than what you exchange
MM: I'm more interested in interaction
BH: those 6 interactions really correspond to more like 3 MEPs
MC: several interesting presentations, do we have any other suggestions for potential starting points?
JD: what about WSCI?
DA: it is in our charter
MC: the global model part of WSCI is very thin, and everything else very much overlaps the BPEL model.
JD: it has a global model, but not in a way that's particularly central or easy to use.
YL: the charter doesn't say we should *start with* WSCI, it says we should consider it
GB: maybe we don't want to build on it, but maybe we can get some useful building blocks
MCham: seems like the conclusion of the first draft of the requirements doc would be a good point to look at things like WSCI in light of our requirements
PL: can we come up with a "short list" of tech underpinnings?
MC: the list itself may be premature, but we should be able to eliminate possibilities.
DA: let's not wait to finalize requirements before we start, and let's not throw out the WSCI spec. let's take that along with BurdettML and JJML and start looking.
SRT: summary -- we have a bunch of inputs listed in our charter, including WSCI. none have been ruled out. we can use the time around the publication of the first strawman requirements doc to evaluate these inputs and ask ourselves "why is this not enough?" and "what can we use from this?". AT THE SAME TIME we can also take frank's event calculus input, BurdettML, JJML, possibly some pi-related input from NK, and investigate those.
LG: I'd like to cull out some of the behavioral and non-behavioral requirements that we've talked about today.
MC: For example, JJ's presentation was a requirements list. Where requirements stop and architecture starts is a very fuzzy line.
DA: we should assign some tasks to task forces and get movin'.
daniel: define issues, missing features, etc., form task forces, get to work
Daniel. Do we have to assume that something like BPEL exists?
LenGreski: does a web service have to know whether it is participating in a choreography?
MChapman: it shouldn’t be a requirement
Daniel. We need a mechanism to maintain state - proposed requirements.
Jeff: Existing WSDL systems have no mechanism of maintaining state. Therefore existing WSDLs are essentially stateless as far as the WSDL is concerned.
Jeff: If you then need to include them in a choreography then they will remain stateless unless you change them.
LenGreski: When Daniel stated a requirement to maintain state across transactions, this raises the question of
whether a choreography handles one or more transactions.
Jon. Having a mechanism of sending state information at the message level may be necessary. If you want to enforce that you are following a state machine then WSDL and SOAP by itself does not provide a mechanism or a method detecting if the choreography is being violated.
Gary. Shouldn't the service police it's own state.
ISSUE: do we/should we assume enforcement of a choreography i.e. should a participant be policed/monitored to ensure it doesn’t violate message sequences
ed. This discussion seems quite low level. We need a high level spec, but how do you share state across web services.
Monica. Should also look at WS Coordination and WS Transaction. As well as WSIA and WSRP in OASIS
Monica. Also work done on state machines in UN/CEFACT.
Martin. You could argue that in WSDL 1.1. is stateless. But we could generate requirements that WSDl 1.2 had some specific features. So legacy doesn't exist yet.
Martin. We do have to make a decision about "design by contract" is it active or passive monitoring. You could do it either way but we need to decide.
Martin. If you do want to enforce it then you have to put a proxy in front to check.
Martin. Ws Coordination ... how do you communicate that a new party has come on board - you need a protocol.
ISSUE: how much state needs to be exposed
Tom. Why would we want to be agreeing on the states I am going through. It seems contrary to the idea of a service hiding what it is doing.
MChapman: there is a difference between the state of an endpoint (the impl) and the state of the choreography
Tom. Sounds like there needs to be someone in the middle to control what's going on.
Bob. It is confusing unless you specify the state of "what". Is it the state of an endpoint, an interaction, a transaction, global view of state, business state, state of a business deal,
ISSUE: what states do we need to distinguish, and what ones do choreography have to describe
Bob. If we don't distinguish between them then it is hard to know what we do . Need to define what states we are defining.
LenGreski: key issue regarding state is: the state of "what" do we need to track?
LenGreski: I'm not sure there needs to be a central state controller (isn't this an orchestration?). Shouldn't each service need to know
only the caller, and the next service to be called? Does the originator of the choreography know all the services to be called at the
time of specification? How do you handle non-repudiation if new participants can be added to the choreography after it is specified?
MChapman: +1 to len; about central controller
Tom. Agrees there are different types of state but needs clarification. Doesn't see why he needs to expose his states.
Len. If we incorporate services into a choreography then we need to assume that they are stateless and that the choreography is a token that is passed from service to service.
Len. There are also issues around design time vs run time. What do you do if the participant is chosen at run time?
Jeff. We really need to agree what we mean by state before we can usefully progress.
Jeff. We are really thinking about existing services that are stateless and how to handle them.
Jeff. Re-iterates point that if you want to use a web service in a stateful way then it has to be changed.
Jeff. However changing might just involve wrapping it with a state machine.
Jon. We're moving into implementation which is good as we need to be sure we can implement it.
Jon. There are two ways to solve it: 1. State passing at the message level as well as an identity conveyance, 2. Is to have a wrapper or a monitor.
Jon. Doesn't think this can be a SOAP intermediary.
ISSUE: how does one party identify itself to another in an interaction
LenGreski: regarding identification of participants, if you look a the pair-wise interactions between the services,
then the pair can guarantee identity, as opposed to having a central identity manager.
Jon. Another complication, might be a requirement. There is a need for concurrent execution of choreographies. You don't want to have to lock out someone who is placing an order because you are processing another order.
Requirement: concurrency is needed – don’t block a choreography if you are expecting multiple inputs
Nick. Classifies types of state: Observable state - visible by other parties, non-observable state kept private. Interactions manipulate just the observable state. Thinks we should just model observable state.
Nick. Do we do an endpoint approach (as in BPEL) or a global state approach.
Nick. One approach is each endpoint monitors its own state as it follows a common global definition, compared with each endpoint defining its own state machine with its own rules which somehow get aligned so that they can work together.
Nick. These design approaches are different. It is not wiring of abstract processes but more the definition of global state.
Martin. This is a clarification of our mission statement
MChapman:
mission statement implies a choreography is an agreed common/shared state machine
Gary. Not comfortable with mechanisms for sharing state. WS-Transaction has a service that is managing a number of participants that are joining at different points at the application level
LenGreski: we're starting to use the term transaction again. Is the result of a choreography a single transaction?
MChapman: depends on the choreography!
LenGreski: ergo, we can't assume a one to one relationship between choreography and transaction.
A choreography consists of one or more transactions. I agree with this, since individual services can be considered transactions.
Mike. Thought we were converging on simple concepts of a shared global state machine. This is coming together. We can talk about state in a constrained way and we can do powerful things with it.
Mike. We could come to a consensus quickly about what mean about state.
Len. What does it mean to look at JJ's vs David's approach - this is a useful process
LenGreski: another way to look at the state question: is the sum of the states (individual MEPs)
equal to the state of the sum (the choreography)?
Alistair. Under a new composition you have independent privately operating workflows. BPEL does not help if the start of one workflow is dependent on the completion of another independent workflow.
Steve. We need to get some structure about what we need to do.
Steve. There are two tracks: requirements, and technical.
Steve. The technical track needs to kick off.
Technical track deliveries (see issues below):
LenGreski: regarding the state question, consensus during the break indicated that the state of the sum is
different than the sum of the states. Therefore, we need to account for this difference in the choreography specification.
Monica. Question, what about Copyright on David's spec.
Martin. Precedent, of PASWA spec. David's approach is OK as he has made it clear that the IP will be made RF. This is the same as PASWA and the W3C is OK with David's approach.
on the technical track, need to work on the four areas we discussed yesterday (BurdettML, BPSS++, Event Calculus, and Pi calculus)
Input summaries: (WSCI, BPSS, JJ)
pluses and minuses...
Requirements Track: use case reformatting, requirements reformatting (DA, AB, SRT)
SRT: all use cases need to be resubmitted according to the accepted format (see the mailing list for template).
SRT: work for the next 2 weeks we will clean up the document and deliver a new draft.
SRT: need to assign leaders to two task forces (input summaries, language / formalizations review).
Frank: willing to volunteer for #3, if timeperiod is more than 2 months
SRT: need intermediate delivery before then.
SRT: need checkpoint @ next face to face.
ACTION: David to check with Commerce One legal, issues around IP and report back
IMPORTANT: Responsibilities. for Requirements track, use case and requirement re-formatting ... DA, AB & SRT)
IMPORTANT: Responsibilities. For Technical track Define +ves and -ves wrt to mission statement for imput summaries (WSCI - CM, BPSS - JJ, DAML/S - JH??
for each track, need to review characteristics, pluses / minuses, and relate them to our charter.
IMPORTANT: Responsibilities. For other specs, BurdettML - DB, BPSS++ - JJ, Eventcalc - FM, Picalc - NK.
IMPORTANT: Frank to take on co-ordination of last four specs.
MC & MM are coordinating the Input summaries.
Steve is coordinating the Use case reformatting.
Discussing next September meeting location
Discussed options and agreed to try and co-locate in Seattle to align with the BPEL conference
ACTION: MC/SRT to find venue in Seattle
December meeting – Alastair Barros offering Australia as a location
Task force mailing list - include name of task force in the subject.
All task force meetings are made public to the whole WS Choreography group.
Thanks to Grainger for hosting and Daniel Austin (DA) in particular for hosting the meeting.
Meeting closed.
ACTION: AlB will develop a use case / scenario for this broadcast use case.
ACTION: DB - Need design collaboration use case.
ACTION: SRT harvest requirements from the email list.
This is now subsumed by the addition on SRT to the requirement editing team.
ACTION: Laron determine what format is required for the documents we produce.
<SRT NOTE: Who is Laron?>
ACTION: All team members who submit a use case must provide in the template format by 1 July 2003 if they wish it to be in this release.
ACTION: DB to check with Commerce One legal, issues around IP and report back
ACTION: SRT/MC to find venue in Seattle
ACTION: YL to give GR and DA editing access to Bugzilla
ACTION: MC/SRT to sum issues process.
ISSUE: Do we need a specific language for describing MEPs? Is this what WS-Chor should be, or is this something that should be added to WSDL?
ISSUE: We should form a "formalism task force" that will investigate various formal models (including pi-calculus and event calculus) that we could use to "advise" us in our work. The task force could analyze submitted use cases/requirements in terms of the formal models to provide examples.
Resolved through formation of task force
ISSUE: We have a bunch of inputs listed in our charter, including WSCI and "BurdettML", none of which have been ruled out. We should evaluate these inputs and ask ourselves "is this enough and, if not, why not, and what can we use from it?" We could also use use cases/requirements to evaluate these.
Resolved through formation of task force
ISSUE: How does one party identify itself to another in an interaction
ISSUE: What states do we need to distinguish, and what ones do choreography have to describe
ISSUE: How much state needs to be exposed
ISSUE: Do we/should we assume enforcement of a choreography i.e. should a participant be policed/monitored to ensure it doesn’t violate message sequences
ISSUE: How are state changes (e.g. new participant join) communicated? part of the choreography infrastructure or built into a choreography?
IMPORTANT: Responsibilities. for Requirements track, use case and requirement re-formatting ... DA, AB & SRT)
IMPORTANT: Responsibilities. For Technical track Define +ves and -ves wrt to mission statement for imput summaries (WSCI - CM, BPSS - JJ, DAML/S - JH??
For each track, need to review characteristics, pluses / minuses, and relate them to our charter.
IMPORTANT: Responsibilities. For other specs, BurdettML - DB, BPSS++ - JJ, Eventcalc - FM, Picalc - NK.
IMPORTANT: Frank to take on co-ordination of last four specs.
MC & MM are coordinating the Input summaries.
Steve is coordinating the Use case reformatting.