OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: draft f2f minutes






_________________________________________________________________
Martin Chapman                                 
Consulting Member of Technical Staff           
Oracle                                        
P: +353 87 687 6654                           
e: martin.chapman@oracle.com                   
23 members, quorum is 12

Roll call: 
Eric Newcomer 
Doug Bounting 
Jan Alexander 
Martin Chapman 
Mark Little 
Bob Haugen 
Greg Pavlik 
Bryan Murray 
Jeff Mischkinsky 
Joseph Chiusano
Malik Saheb (phone)
Dale Moberg 
Peter Furniss (phone)

Meeting scribes were Jan Alexander, Mark Little and Greg Pavlik



Agenda review: Basically going through the issue list

Bob: Can one WS-Context interoperate with multiple ALS - how that works? Bob: 
Can existing WS-Context implementation work with new ALS it didn't about 
previously?

Martin: we are not officially quorum, so let's proceed and write the issues down 
and vote about them when other will join us to have a quorum.

Martin: Have to join BPEL call, propose to have a break and to continue at 10:30 
with the current editor's versions of the documents, hopefully we will have 
quorum at that time.

Eric: Should we go through the complete editor's versions, or just walk through 
the existing editorial issues and discuss those only?

Eric: Documents were updated about 61 issues, either editorial or voted on 
during the TC concalls. Propose that these would be approved. 

Motion: To adopt editor draft 01 dated on 21.April as a working draft for the 
purpose for discussing other issues. The motion is seconded by Mark Little.

Eric: The dafts of the model diagrams were posted at least twice to the mailing 
list, so we assume they are discussed and understood, so we would like to make 
this an editorial issue. [Add a URL to the Eric's mail summarizing the issues, 
that were fixed (mail subject: Issues fixed in editor's spec) from the April 
18.)]

Mark: Only difference between 01 and 02 drafts is restructuring of the documents 
and incorporating the new model from the mailing list.

Martin: Let's discuss the open issues now.

Issue 40: Remove restriction from the schema and establish convention for the 
hierarchical names of the status. Issue 46: This should be left to the 
implementation, because there is multiple ways how to do that and we don't want 
to restrict to the implementation of this. Mark: Motion: Add an implementation 
note in the text to setContent: Concurrency control of a context passed by a 
reference is an implementation issue. Motion seconded by Eric.

Issue 50: actually two issues. The missing piece can be either added to the WSDL 
or removed from the spec. Mark: Motion: Remove addIdentity and removeIdentity 
from the spec of the ALS portType. Seconded by Greg

Issue 59: let's wait for the rest of issues to be resolved (we need model 
resolved for it). Leave open, it is editorial.

Issue 60: Mark: Motion: Activity is an abstract thing, context allows you to 
capture activity, the maintainer of the context should be called Context 
Service, not Activity Service. Seconded by Greg.

Martin: we should change the name Context for the marketing reasons to Cookie. 
There is large overlap between Context and Cookie in HTTP. Eric: Let's postpone 
this after the issues discussion.

Jan: Shouldn't we rename ALS to CLS (Context Lifecycle Service) if the activity 
sevice is renamed to context service. Erik: Yes, ALS should be CLS

Greg: Is it possible to introduce CLS/ALS into the context by application of the 
context - coordination framework? Is the CLS/ALS in the WS-Context essential? If 
it is optional for the context and required for the coordination, shouldn't it 
be introduced by WS-CF? Mark: We need it for the interoperable context 
augmentation. Martin: Let's make it a new issue.

Issue 61: Greg: originally there were two ways how ALS/CLS said I'm associated 
with specific protocol, but that is another issue 106. So close this issue, 
because it was obsolete by issue 106.

Issue 91: Leave it open for now, Greg will provide a text.

Issue 94: Mark: Suggestion is to keep setContext simple now and when enough 
implementation experience will be gathered, we can return to this. Motion: close 
it as a non-issue. Seconded by Greg.

Issue 109: Mark: clarification text will be added, editorial issue.

Issue 123: Martin: Dough sent an email proposing that the implementation should 
decide, if to pass context by reference or by value, we should make it out of 
the scope of the WS-Context specification. Mark: we leave the signature of the 
begin() method as it is and maybe add some text explaining the possible return 
values of the method. Jan: should we add something like: "Implementation of the 
context service decides, whether it will return reference or value of the 
context as the response of the begin() method". Martin: Add to it, that it is 
always possible to convert value to the reference and vice versa.

Bob: Returning the questions from the beginning: Can a context implementation 
interoperate with ad-hoc ALS/CLS or have it know from the beginning the 
referencing specifications of those CLS/ALS? Mark: I think this was resolved in 
the new restructured editorial documents.

Lunch break.

Restart after lunch looked at Bob's issues:

(i) can one WS-CTX implementation interoperate with ad hoc ALS
implementations or does it require knowledge of the referencing specs?

(ii) can multiple ALSs be involved in the same context, or can they be
associated with the same context service?

Mark's answer is that a context implementation should be able to use
any ALS as long as it conforms to the WSDL.

Also one ALS per activity is now required.

Greg: where does it state that one activity per ALS?

Mark: enlistALS

Greg: there is an inconsistency between the start of the spec. and
that section.

Martin: editorial issue to tidy up.

Bob: one context to one activity. But there may be different snapshots
of that context.

An activity can have one or more contexts representing it, but each
instance shares the same context identifier.

Bob: one activity not one context? Is the intent that the main
identity is the activity.

Greg: yes, the context is just the wire-level representation of the
activity.

Eric: the activity is the "execution environment".

Martin: we'll revise the UML diagram and put it into the text. Must
make sure that the text syncs up with the diagram.

This only occurs when passing by value.

Model should capture the fact that multiple protocol implementations
can be wrapped by the single ALS.

Context is a view of an activity. Can have multiple views during time.

Issue 11: not resolved. Simeon to send correct WSDL. May have to
re-assign (Greg to check).

Issue 47: not sure about the issue. Choices could be boiler plate
saying our specs are composable with WS-Security, enumerate potential
threats for using WS-Context without appropriate security. Is security
of the context service implicitly securing the activity? Likewise, if
we don't secure the context service and a security ALS is added, does
that secure the context service?

Action point: do we need to change out schema in context inorder to
sign these within headers? Martin to check.

We need a dedicated teleconference to discuss this.

Issue 48: text clarification required. Editorial.

Issue 52: define the completion type for context spec. but remove all values
from the specification. State that the referencing specifications can
define their own values for this type. Remove completeWithStatus and
make complete take an optional completion status value (min=0,
max=1). Each ALS is allowed to interpret the receipt of a complete
message with no parameter in whichever way it requires. The
referencing specs. can define the default value.

Mark makes motion. Dale seconds.

Issue 53: close no change. All delegated to ALS.

Mark makes motion. Jan seconds.

Issue 54: close no change.

Mark makes motion. Greg seconds.

Issue 62: fixed; in editors copy. The change to incorporate the new model
text removed the ALS-configuration id in favour of the protocol-type and is
in the AssertionWithProtocolURIType.

Mark makes motion. Dale seconds.

Issue 72: editorial. Close issue. Should go into the Primer.

Greg makes motion. Mark seconds.

Issue 92: closed as resolved by issue 91.

Greg makes motion. Jan seconds.

Issue 93: close issue. No action.

Mark makes motion. Greg seconds.

Issue 99: leave open.

Action point: Martin to determine what best practice is.

Issue 100: closed because revised model uses a single ALS per
activity.

Greg makes motion. Mark seconds.

Issue 101: closed because of issue 52.

Jan makes motion. Greg seconds.

Issue 114: closed because of issue 52.

Mark makes motion. Greg seconds.

Discussion topics:

(i) addressing (WS-MD).

(ii) state transitions (state model).

(iii) ALS - can it be collapsed into context service.

---------------------------------------------------------------------------------------------------------------------------

April 29 2004 (Greg Pavlik, scribe)

Agenda for the day:

	general issues
	discussions
		OASIS namespace
		protocol versioning
		addressing/referencing
		state transitions
		ALS - can it be collapsed into context service
		doug to talk about model
	document planning
	implementation group

Implementation subgroup presentation by Greg
	to post ppt show to TC site
	Jan expressed interest in a general interop event
	AI for Eric: find place to do publicity demonstration

General Issues
	of which there are 3
		Issue 49 assigned to Simeon
		Should we use substitution groups? Resolution: no.
		Fix produced, to be incorporated in next draft
		Closed, resolve later

		Issue 124 should we include synchronous-style port types?
		defer until message delivery discussion

		Issue 125 Respondant needs to be changed throughout all specs
		Editorial change for CF and TXM
		Resolution, make sure ResponseHandler is used throughout.

Discussions
	OASIS namespace
		Doug: multiple answers, there is no centrally managed namespace. However, there is a long history of TCs using http://www.oasis-open.org/committees/short for of committee name/[documents|schemas]
		There is also an RFC for a URN scheme. People like resolvable namespace identifier.		
		Eric, what about webservicestransactions.org? Doug: several issues with that.
		AI: chairs to find fixed location on OASIS site

	Protocol Versioning
		Mark concerned about versioning being addressed now, under assumption that changes may occur after WS-Context is adopted but before other specs expose problems
		Martin doesn't want to have to rev up through OASIS level multiple times; and no errata process.
		Martin: every new version is in a new namespace. General agreement; Dale suggesting version attribute for "tweaks" on final spec.
		
		
	State transitions
		Do we need state machines for WS-Context? Resolved, this is not significant in light of specification changes removing failure states.

	Doug Model Issues
		Suggestion that Context be treated as a shared information space.
		We also talk about the hierarchy of contexts, but not of a linked chain of various temporal contexts.
		Not comfortable with name protocol type -- could be misconstrued, and ought to be type.
		Doug motion to change protocol-type in Context structure to "type". This has ripple effect to all use cases of protocol-type.
		Motion carried.

	ALS discussion
		Mark: delegate much to ALS, can it be removed as an independent entity? Martin asks if there exists a market for separate ALSes?
		Mark: possible to add it back at later date, but removal simplifies and removes adoption hurdle.
		Doug: question of genericity? do more use cases exist beyond coordination?
		Motion from Greg: Motion to remove ALS and validate the Context Service definition is complete.
		Mark seconds.
		Discussion ensues.
		Motion carried.

	Referencing/Addressing/Request-Response style
	
	Do we want to use w3c MessageDelivery for referencing services? Concern over status as a note. SOAP for example was adopted by Working Group
	Eric hesitant to tie spec to something in state Note.
	Discussion to provide open content model for references to web services and conformance claims around a subset.
	Motion by Jan to adopt an open content model for all uses of references to web services in the specification.
	Mark seconds.
	Motion carried.

	Discussion about addressing headers. 

	Motion by Greg: Addressing scheme will be defined by association to reference model. If reference model does not provide addressing headers, an implementation will provide in a proprietary manner.
	Second Jan.
	Discussion, Eric expresses approval.
	Motion carried.

	As a result of this motion, the AssertionType addressing elements will be removed
	AI: editors will add to text to explain content model.
	AI: Martin will explore how we identify WS-Reference compliant implementations in the CAF content model.
	
	Request-Response WSDL

	Leave as is, need to initiate investigation on MD callback pattern. Issue remains open.
	Peter would like to see Logical request-response table.


	Liason slot

		Two new use cases for CAF that are not transactional

		ebMS (Messaging)

		Ian Jones chair of the ebMS group visiting to see if there is synergy between the requirements of 
		ebMS group and WS-Context. Strong interest on both sides. ebMS looking to combine reliability, security and context from OASIS.

		Peter in now in attendance.

		Monica for BPSS/EBPP 2.0: multi-party collaboration, coordination and shared context becomes important.
		How to associate multiparty collaboration? Potential customer.

		In both cases, a draft around June to TCs for review.

	Scheduling

		Meetings
			Next F2F Oracle Redwood Shores July 13-15
			AI for Jan: check on September, October F2F in Prague
			Next telecon starts May 10, usual time/call-in

document schedule:
 from july we dont touch context unless we must (take it to cd) and we propose to oasis standard once we asses its stable.

					


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]