Minutes WS Choreography WG conference call 25 August 2005
IRC: http://www.w3.org/2005/08/25-ws-chor-irc
Agenda: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/att-0033/agenda_20050825-0.txt
1. Role Call
------------
Martin, Gary, Greg, Nick
2. Confirm Scribe
-----------------
Scribe is Nick
3. Agenda Changes
-----------------
Add exception handling issue
4. Issues
---------
Martin's proposed rewording on participants/roles/etc
Updated proposal at: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0036.html
Text:
participantType, roleType, and relationshipType - Within a
Choreography, information is always exchanged between participants
within or across trust boundaries. All interactions occur between roles
being exhibited by participants, and are constrained by a relationship.
Within WS-CDL, a participant is abstractly modelled by a
participantType, a role by a roleType, and a relationship by a
relationshipType. A participantType groups together those parts of the
observable behavior that must be implemented by the same logical entity
or abstract organization. A logical entity or organization may be
represented by more than one participantType within a Choreography. A
RoleType enumerates potential observable behavior a participantType can
exhibit in order to interact. A RelationshipType identifies the mutual
commitments that must be made for interactions to be successful.
PROPOSAL ACCEPTED
ACTION: To editors use this to make it consistent in the defs of roleType, participantType, relationshipType
ACTION: for the group to review on the latest CDL editors draft (that is going to be sent by Greg to the member's list)
<nick> , section 4.4
Steve's comments:
http://lists.w3.org/Archives/Public/public-ws-chor/2005Aug/0021.html
*** ITEM 1 ***
6 Activities
Activities are the lowest level components of the Choreography, used to
describe the actual work performed. The Activity-Notation is used to
define activities as either:
An Ordering Structure - which combines Activities with other Ordering
Structures in a nested way to specify theordering rules of activities
within the Choreography
A WorkUnit-Notation
REPLACE WITH:
6 Activities
Activities are the lowest level components of the Choreography, used to
describe the actual work performed. The Activity-Notation is used to
define activities as either:
An Ordering Structure - which combines Activities with other Ordering
Structures in a nested way to specify theordering rules of activities
within the Choreography
A WorkUnit-Notation - which is used to guard and/or provide a means of
repetition of those activities enclosed within the WorkUnit.
ITEM 1 ACCEPTED. EDITORIAL FIX
*** ITEM 2 ***
6.2.1 Interaction Based Information Alignment
In some Choreographies there may be a requirement that, when the
Interaction is performed, the Roles in the Choreography have agreement
on the outcome. More specifically within an Interaction, a Role MAY
need to have a common understanding of the observable information
creations or changes of one or more State Capturing Variables thatare
complementary to one or more State Capturing Variables of its partner
Role. Additionally, within an Interaction a Role MAY need to have a
common understanding of the values of the Information Exchange
Capturing Variables at the partner Role..
QUESTION:
Not sure that the "MAY"s should be capitalised in this paragraph.
ITEM 2: ACCEPTED: MAYs SHOULD BE LOWER CASE in 6.2.1
ACTION: Editors to change "MAY" to lower case "may"
*** ITEM 3 ***
6.3 Composing Choreographies
......
The variable attribute within this element specifies that a Variable in
the performing Choreography is bound with theVariable identified by the
variable attribute within the free element in the performed
Choreography.
REPLACE WITH:
The variable attribute within the this element specifies that a
Variable in the performing Choreography is bound with theVariable
identified by the variable attribute within the free element in the
performed Choreography.
ITEM 3: ACCEPTED, in 6.3
ACTION: Editors to apply change above.
ACTION: Note to editors, when putting text in (new, or from the proposals) always make it consistent with the text in the spec (like lower v in variable, roleType with no spacing, etc.)
*** ITEM 4 ***
The WS-Reliability specification supports messageexchange patterns,
over various transport protocols (examples are HTTP/S, FTP, SMTP,
etc.). The WS-Reliability specification supports sequencing of messages
and guaranteed, exactly once delivery.
QUESTION:
Should we say anything about WS-ReliableMessaging too?
MartinC: Reliability sepcifications, such as WS-Reliability and WS-ReliableMessaging supports message exchange patterns,
MartinC: over various transport protocols (examples are HTTP/S, FTP, SMTP,
MartinC: etc.). These specifications support sequencing of messages
MartinC: and guaranteed, exactly once delivery.
Latest draft (yesterday 8/29)
"7.2 Interoperability with Reliable Messaging frameworks
Reliability specifications such as WS-Reliability [WSRM] and WS-ReliableMessaging [31] provide a reliable mechanism to exchange information among collaborating participants. These specifications prescribe the formats for all information exchanged without placing any restrictions on the content of the encapsulated business documents. These specifications support message exchange patterns over various transport protocols (examples are HTTP/S, FTP, SMTP, etc.). . These specifications support sequencing of messages and guaranteed, exactly once delivery.
A violation of any of these consistency guarantees results in an "error", which MAY be reflected in the choreography with an exception."
Note the extra full-stop!
ACTION: Chairs to check next call to see if this was accepted
*** ITEM 5 ***
7.4 Interoperability with Addressing frameworks
Web Services Addressing [WSAD] provides transport-neutral mechanisms to
address Web services and messages. WebServices Addressing 1.0 - Core
defines a set of abstract properties and an XML Infoset [XML], [XMLNS]
representation thereof to identify Web service endpoints and to
facilitate end-to-end identification of endpoints in messages.
The specification enables messaging systems to support message
transmission through networks that include processing nodes such as
endpoint managers, firewalls, and gateways in a transport-neutral
manner.
WS-Addressing can be used to convey the reference and correlation
information for normalizing expanded ChannelVariable information into
an uniform format that can be processed independently of transport or
application.
The WS-Addressing specification is in progress and the WS-Choreography
Working Group will review and comment on developments in this effort on
an ongoing basis.
REPLACE WITH:
7.4 Interoperability with Addressing frameworks
Web Services Addressing [WSAD] provides transport-neutral mechanisms to
address Web services and messages. WebServices Addressing 1.0 - Core
defines a set of abstract properties and an XML Infoset [XML], [XMLNS]
representation thereof to identify Web service endpoints and to
facilitate end-to-end identification of endpoints in messages.
The specification enables messaging systems to support message
transmission through networks that include processing nodes such as
endpoint managers, firewalls, and gateways in a transport-neutral
manner.
WS-Addressing can be used to convey the reference and correlation
information for normalizing expanded ChannelVariable information into a
uniform format that can be processed independently of transport or
application.
The WS-Addressing specification is in progress and the WS-Choreography
Working Group will review and comment on developments of this effort on
an ongoing basis.
AGREED ON ITEM 5
ACTION: Editors to make necessary changes as above.
Charlton/Monica RFC 2119 mods:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0031.html
<grizinger> http://lists.w3.org/Archives/Member/member-ws-chor-editors/2005Aug/0045.html
<gritzinger> http://www.w3.org/2002/ws/chor/edcopies/cdl/cdl.html
#3. Section 5.7: 1st * agreed
#2 * agreed
Monica: A Choreography in an Enabled State MUST complete unsuccessfully
Monica: when an Exception is caused in the Choreography and its
Monica: Exception Block, if present, is enabled. This causes the
Monica: Choreography to enter the /Unsuccessfully Completed State/.
Monica: A Choreography in an Enabled State completes unsuccessfully when an Exception is caused in the Choreography and its Exception Block, if present, is enabled. This MUST cause the
Monica: Choreography to enter the /Unsuccessfully Completed State/.
Monica: c/Choreography and its/Choreography. Its
A Choreography in an Enabled State completes unsuccessfully when an Exception is caused in the Choreography.
This MUST cause the
Monica: Choreography to enter the /Unsuccessfully Completed State/.
In this case, its Exception Block, if present, is enabled.
In this case, its Exception Block, if present, MUST be enabled.
agreed
The unsuccessfully completed Choreography MUST enter the
completed. If the Exception Block is not present, the
Choreography implicitly enters the Closed State and the
Exception occurred MAY be propagated to the enclosing
Choreography."
MartinC: change:
MartinC: If the Exception Block is not present, the
MartinC: Choreography implicitly enters the Closed State and the
MartinC: Exception occurred MAY be propagated to the enclosing
MartinC: Choreography."
MartinC: to:
MartinC: If the Exception Block is not present, the
MartinC: Choreography implicitly enters the Closed State and the
MartinC: Exception occurred MUST be propagated to the enclosing
MartinC: Choreography, if it exists
nick: the MAY -> MUST
nick: A Choreography in an Enabled State MUST complete successfully
nick: when there are no more enabled activities within its body.
nick: This causes its Exception Block, where present, to be
nick: deinstalled,
nick: Finalizer Blocks to be installed if specified, and the
nick: Choreography
nick: enters the /Successfully Completed State/.
nick: agreed
nick: Alternatively, a Choreography MUST complete successfully if
nick: its
nick: complete condition, is matched by evaluating to "true". A
nick: complete condition is considered for matching while the
nick: Choreography is in Enabled State. The complete condition
nick: MUST be possible to be matched in all Roles that participate
<When the complete condition of a
nick: Choreography is matched then all activities in the
nick: Choreography MUST be disabled, except for any Finalizer
nick> Block(s), and the Choreography completes as if there were no
nick: more enabled activities within it.>> When a Choreography
nick: completes, all uncompleted enclosed Choreographies MUST
nick: automatically become successfully completed."
nick: agreed
nick: 4. Section 5.8:
nick: #1 * agreed
MartinC: This MUST cause the Choreography to enter the Exception
MartinC: state, and its Exception Block MUST be enabled, if specified."
nick: #2 * agreed
MartinC: This MUST cause the Choreography to enter the Exception state, and its Exception Block, if specified, MUST be enabled.
nick: #3 * agreed
nick: #4 * agreed
Greg: all finalizer blocks?
MartinC: When its Choreography body completes successfully and
MartinC: associated
MartinC: Finalizer Blocks are specified, those Finalizer Blocks MUST be installed.
nick: %5 * agreed with the text change above
nick: 10. Section 6.2.2
nick: #1 was done on Tuesday 23 Aug conf-call
nick: #2 ok
nick: #3 ok
nick: #4 ok
Additional notes for further clarification:
Reference: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/att-0041/minutes_20050825-1.txt
========
Section 5.7:
A Choreography in an Enabled State completes unsuccessfully when an
Exception is caused in the Choreography. In this case, its Exception
Block, if present, MUST be enabled. This MUST cause the Choreography to
enter the /Unsuccessfully Completed State/.
The unsuccessfully completed Choreography MUST enter the Closed State
once the exceptionBlock is completed.
If the Exception Block is not present, the Choreography implicitly
enters the Closed State and the Exception occurred MUST be propagated to
the enclosing
Choreography, if it exists.
A Choreography in an Enabled State MUST complete successfully when there
are no more enabled activities within its body. This causes its
Exception Block, where present, to be deinstalled, Finalizer Blocks to
be installed if specified, and the Choreography enters the
/Successfully Completed State/.
Alternatively, a Choreography MUST complete successfully if its
complete condition, is matched by evaluating to "true". A complete
condition is considered for matching while the Choreography is in
Enabled State. The complete condition MUST be possible to be matched in
all Roles that participate. When the complete condition of a
Choreography is matched then all activities in the Choreography MUST be
disabled, except for any Finalizer Block(s), and the Choreography
completes as if there were no more enabled activities within it. When a
Choreography completes, all uncompleted enclosed Choreographies MUST
automatically become successfully completed."
Section 5.9:
This MUST cause the Choreography to enter the Exception state, and its
Exception Block, if specified, MUST be enabled. When its Choreography
body completes successfully and associated Finalizer Blocks are
specified, those Finalizer Blocks MUST be installed.
==============
All other items were agreed as posted.
6. AOB
------
NONE
SUMMARY OF ACTIONS:
1. ACTION: To editors use this to make it consistent in the defs of roleType, participantType, relationshipType
2. ACTION: for the group to review on the latest CDL editors draft (that is going to be sent by Greg to the member's list)
3. ACTION: Editors to change "MAY" to lower case "may"
4. ACTION: Editors to apply change above.
5. ACTION: Note to editors, when putting text in (new, or from the proposals) always make it consistent with the text in the spec (like lower v in variable, roleType with no spacing, etc.)
6. ACTION: Chairs to check next call to see if this was accepted
7. ACTION: Editors to make necessary changes as above.