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: Minutes for Thursday Evening


These are the minutes for the meeting on Thursday, Feb 25th in Paris.
Meeting Notes:

Attendance:
	Martin Chapman
	Doug Bunting
	Greg Pavlik
	Jean-Jacques Dubris
	Simeon Greene
	Eric Newcomber
	Malik Saheb
	Peter Furnis
	Alistair Green
	Dale Moleberg
Today's Agenda:
	9:00 - 10:15 XDI -Presentation from Jean Jaques on the XDI TC

	10:15 - 10:45 Break

	10:45 - 12:30 Discussion of Peter Furnis' WS-Context Issue

	12:30 - 13:30 Lunch

	13:30 - 15:00 Implemnation group
	- Review of Demo scenario

	15:00 - 15:30 Break

	15:30 - 17:30 Implementation group (cont)

1) Jean-Jacques gives presentation on XRI and XDI.
- Slide presentation will be made available on Oasis site as a URL.
- XRI is basically an extension of URIs.  XRI is a URI scheme.
- Discussed the differences between XRIs and URIs.
- Martin asked how XRI is relevant to context
- Jean Jacques explained that when passing Context by reference, an XRI instead of a URI can be used.  XDI on the other hand can be used for updating the Context.
- Alistair asked whether XRI is currently being used.
- Concerns were raised as to what is the cost of using XRI.
- Both XRI and XDI have Oasis TCs.
- These specs have been around for about 10 years.
- The specs were found to be interested but their usefulness with regards to WS-Context or the WS-CAF spec in general was not fully determined.



2) Discussion of Peter Furnis' Email and Value of WS-Context
- Chair (Martin): This discussion should only occur once.
- Peter Furnis delivered a presentation entitled “WS-Context radical treatment?”
- A discussion ensued 
- Question: Are generic contexts (application specific contexts) included in the assumptions of this presentation?  i.e. Context services aren't required to only accept a list of predefined context types.
- Answer:  Yes.
- Suggestion: drop the switching between pass-by-value and pass-by-reference.
- Passing by value can be useful for stuff like transactions, while pass-by-reference is useful for state storage.
- Currently the spec does not specify whether you can switch these two.
- Eric/Greg: Perhaps the spec needs to clearer on this.  Currently the spec is merely silent on this issue.
- Suggestion: drop pass-by-value from WS-CTX.  Passing by value is just repeating what is already in soap header.
- This slide sparked a lot of discussion.  Only some text from these discussions have been recorded.
- Eric: the option is available to facilitate ease of access to the entire context.
- Martin: passing the context by value keeps things standardized.
- Dale: the issue is that that notion is already provided by SOAP header.
- Eric: Does it break the spec to have the pass-by-value mode?  No.  So making the case for dropping it is moot in my opinion.
- Greg (to Dale/: pass-by-value may be useful for tree building as used by WS-Coordination.
- Dale: agrees.
- A suggestion was made that rather than having the TC convince Peter/Dale that WS-Context is useful, Peter/Dale should focus on showing how WS-Context is not.
- A lively debate ensued over this point (details have been omitted).
- Headers which are context headers are a benefit because they can be easily identifiable.  Similar to a base class.
- Dale: Context is useful in TBP (Tree Building Protocol).  Dale feels in the case of TBP ws-context is useful.
- Suggestion: Re-examine pass-by-reference.  It should work as a central-state-repository. The dereferencing mechanism should be specified preciely.  Creation and update mechanism should be outlined but protocol constructs should not be provided.
- Greg: What is the meaning of dereferencing a context refernce?  i.e. Does the uri represent a web service that can be used to get the context data or does it represent the location of the context data itself (ex. a url to context data).
- This is not clear in the specs.
- Discussion of mechanisms for updating the context...
- Updating the Context is out of band in the spec.
- Discussion of ALS registration.
- ALSs are registered with Context service (Activity Service) for augmenting contexts.
- Doug: What is the semantic difference between performing an ALS registration and adding a child, by-reference context that is maintained in another service.
- Eric: ALS tries to track the lifecycle of a context... i.e. which services are using this context over its lifetime.
- Martin: There is also augmenting of the context.
- Peter: no point in having ALS:CTX registration and interfaces.
- Peter: when the context service creates a context it knows what the ctx is being used for... it doesn't create a generic thingy that needs to be filled in.  Thus no need for an ALS.
- Greg: but the spec suggests that multiple ALSs can be registered to augment a context.
- Malik explained protocol registration in WS-CTX.
- Peter: How will the Activity merge the information/functionality provided by ALSs?  For example: A security ALS and a Transaction ALS have registered with a Context Service to provide secure transactions.  How for example will the activity service make sure that the security ALS gets called first or that the augmented context makes sense after both ALSs are called?
- This is not properly defined in the spec.
- Peter: If it is not fully defined in the spec, should it be defined at all?  Is there any point in completing it?
- Eric: Just because it's not fully defined doesn't mean it should be thrown away.
- Dale: agrees.
- The specs may need to address this.
Discussion points arising from this discussion session:
i. Absolute necessity of an “application” protocol governing the use/meaning of a context.
ii. Switching/Compoint usage hierarchy + relationships.
iii.  Tree building
iv. Must propagate flag.
v.  Facilitate interception.
vi. Mutation
vii. Context Service + HTTP utilization.
viii. ALS.









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