[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
Minutes WS-CAF F2F 25th to 27th February, Paris, France
Hosted by Attachmate
Scribes:
Day 1 - AM -- Jeff
Day 1 - PM -- Doug
Day 2 - AM -- Simeon
Day 2 - PM -- Peter
Day 3 - AM -- Greg
Attendance:
Jean Jacques Dubray, Malik Saheb, Peter Furniss, Doug Bunting, Greg
Pavlik, Simeon Greene, Jeff Mischkinsky, Martin Chapman, Dale Moberg,
Alstair Greene
Not quorate (10 out of 28)
Agenda Review:
Push ws-rf discussion into FAQ topic, which will now start at 2:30
Since we are not quorate, we will establish positions via consensus and
then vote to ratify (or not) at the next quorate opportunity.
Previous Minutes:
Review of minutes from 16 Feb.
Process for minutes and agendas -- minutes and agendas should be sent to
the email list in an open format -- text (or pdf). Chairs will copy into
Kavi but turning member notification OFF -- so that we're not bombarded by
the update messages. End result is that you will be able to view minutes
off the event listing in Kavi and have an email record for yourself.
Issue 16 - Doug reported that the notes I believe my proposed (and
accepted) amendment for issue 16 was a follow up to an earlier question
about the follow-up to any items discovered using the testing tools.
Replace both bulletted items with: "Minor items discovered through this
testing will be handled within the editorial team. Any important concerns
will become separate issues for TC consideration".
Minutes 16th feb approved Unanimously at the meeting
Action Item Review
------------------
Eric post editorial issues for issues 12-20 ... NOT DONE
Mark - Automatic update of bugzilla -- NOT DONE
Eric to contact WS-RF folks -- NOT DONE
Editor's Report/spec logistics
------------------------------
Editor's had a discussion to iron out document and issue management. One
thing was a need to separate the "pre-TC" issues and docs with post-TC
formation. Mark has the AI to go in and tidy up the bugzilla db, so that it
only contains relevant issues.
The spec actually is made of several pieces -- text, schema, and
wsdl. Since these wind up in different files, there is an issue of
management to keep versions in synch.
After some discussion it was decided that the editors will maintain and
publish a single zip file which will contain a complete consistent set of
all the constituent parts of the spec, including source.
[chairs note - recent viruses relatedto zip files might make us revist this decision]
Resolved status meanings in Bugzilla:
ASSIGNED -- issue is in the system
LATER -- means group has voted on resolution, but has not yet been
incorporated into a working draft, although in all likelihood the editors
will have folded the resolution into the latest editing draft
FIXED - means group has adopted a working draft -- blessing an editor's
draft as correctly reflecting decisions of the group
Mark has updated bugzilla to reflect the above scheme. Mark still needs to
sanitize the bugzilla list to remove pre-TC issues.
An editors subgroup will be set up (anyone can sign up, but it is for
editors's use). Editors' call will occur at 4PM GMT (8 AM Pacific) on
alternate Thursdays. dates tbd
Issues as they are resolved need to have the resolution in its full final
form need to be pasted into bugzilla after the minutes are
approved. Currently they are only in the minutes.
Action: chairs, Person responsible for updating resolutions in bugzilla to be identified.
Issue 15 - consensus is - issue is valid (it is in the last official
adopted WD), and the resolution is to fix as suggested in bugzilla --
*** Unanimous ***
Action: chairs to determine if bugzilla db backed up and if access to account creation
restricted to WS-CAF members.
Issue 41 - mis-labeled = re-categorized to WS-CF
Issue 12 -- no change, it's ok
Issue 52, 53, 54 -- defer discussion until later in meeting
Issue 59 - AI Greg to produce sequence diagrams to vote on.
Motion: TC adopts policy that sequence shall be used to depict
interactions. Consensus to do so.
*** Unanimous ***
Issue 60 -- discuss later today
Issue 62 -- issue needs clarification -- AI Simeon to ask proposer to
elucidate and explain, otherwise we will close the issue
Issue 68 -- close fixed resolved by previous discussion about zip files,
etc.
Issue 14 -- AI Greg/Mark to restructure the status type
Issue 20 -- AI editor's need to make the spec consistent
Issue 43 -- In all the schemas, the any element should be moved to be the
first element to allow for "true" extensibility. (##other extension points
should be put at the beginning).
*** Unanimous ***
Issue 46 -- defer discussion to later
Issue 47 -- Need clarification/risk analysis/scoping work - volunteer tbd
Issue 48 -- defer discussion to later
Issue 49 -- AI Simeon to put a proposal on the table -- general agreement
to not use substitution groups if possible
Issue 50 -- mismatch between text and wsdl -- resolution needs to be
proposed. Note the answer to this question is intimately bound with issue
103 -- what is indentity?
FAQ
** Question 1
Jeff proposes some wording: "to define a generic" -> "to provide an open
industry forum", add "As the work of the TC progresses, it will refine
and develop this framework. This FAQ will be updated as appropriate."
** Question 2
When looking at questions 2 and 3, it is hard to answer question "what
is WS-CAF?" until the TC has completed its work. Must say the input
documents are not completed but early working drafts for TC use. Need
some term to describe the input documents (not "WS-CAF Framework").
For this question: Just ask what the input was? Make sure people know
the WS-CAF documents out there are not competitive in any way but are
the input for this TC.
Resolved, change question to "What was the original input for the TC's
work?" Change answer to begin "The TC bases its work upon the WS-CAF
specifications published by ..."
** Question 3
Really, asking more about the input documents. Change second sentence
of answer to read "WS-CAF currently includes three specifications:"
Note: We are assuming this FAQ will be living document and will be
updated as we progress. Ensure our FAQ is dated and updated as changes
occur.
Specifically, we are having a current discussion around the structure of
the document set.
Resolved: Change last sentence to "WS-TXM is designed so that other
transaction models could be added if the need arose."
** Question 4
Allastair notes that BTP at least used open processes to discuss some of
these issues. While it did not reach the status of an OASIS Standard,
this answer should avoid the implication nothing had been done in the
past.
Change "of the last remaining items to be standardized" to "key items
not yet standardized".
Change "menas" to "provides" and "into a single transaction" to "into a
coordinated set" in the third paragraph. Delete comma after "various".
Delete everything after "known state".
Last sentence does not clearly make the point about distinction between
business process management and business transactions. Change to "
"compensations and asynchronous business process flows" to
"compensations and the transactional apsects of business process flows"
Add "WS-CAF directly includes support of three transaction protocols:
ACID, long running action (LRA) and business process".
** Question 5
Questions on meaning of "You’ll want to make sure that the work they do
is associated with your work somehow." Who is "you"? Replace this
sentence with "The work of the travel providers must be associated with
your overall travel plans." Change "flight shops, hotels and car rental
organizations" to "flight, hotel and car rental organizations".
Next sentence begins with a definition not true in our current
specifications and "shared resource" is not truely as constrained as the
examples indicate. Travel example does not fit either (no single
distributed context or shared resource), in that case you have unshared
resources that are used within a larger business context. Context in
our framework can both be directly accessed (updated) and identify
non-shared information of interest to just one service. Trying to get
to the common thread through the many examples we have of context.
Allastair proposes changing definition to read "for the purpose of
carrying out multiple related operations. The most basic means of
establishing the relationship between operations is through a shared
context." Also, remove "defined as" from first sentence.
New issue: As previously defined (mentioning a "specified sequence"),
context management may be useful outside of a composite application.
Ended up rephrasing first sentence of second paragraph to "A composite
is a collection of related Web service operations."
** Question 7
What does reciprocal royalty free terms mean? Jeff is not a lawyer but
current OASIS rules prohibit chartering a TC on purely RF terms. Went
through some of the history in setting up the TC. Referred to the
charter for clear description of the TC intents and directions in the
area of licensing. May answer this question using words copied from the
charter or link to that document.
Change answer to "The goal of this TC is to define a set of royalty-free
related, interoperable and modular specifications. See the charter
(http://www.oasis-open.org/committees/ws-caf/charter.php) for further
details."
** Question 6
Change first sentence to start with "The TC will work..." Delete second
paragraph of answer. Delete "also" in third paragraph and change
"definitions" to "mechanisms". Last sentence is more an answer to "What
is the benefit of this framework for all web services specifications?"
but will remain.
Action: Eric to updtae FAQ based on f2f comments
* WSRF discussion
On our list, a number of issues touching on WSRF have been discussed.
Questions include:
. Should future versions of WSRF make use of WS-Context?
. What is the current state of our attempts to influence WSRF "community"?
. Is WSRF useful and are people of a mind to use it?
. Does WSRF represent a distribute OO model where we lean toward SOA?
Questions of identifying true termination of a reference (addressing
issues) have also emerged in this TC.
Do you build object reference into the addressing mechanism or place key
separately; say, in the context?
Analogy: Service endpoint for each individual bank account or one
(multiplexing) service location for all of Bank of America with account
as an explicit parameter to the interface? Both are extreme points on a
continuum.
General agreement on likelihood of coarse grained services that are
parameterized to distinguish the bits. Level the service actually
breaks apart the URI is immaterial to the client.
Some comments about recognizing what clearly lies in the client space
and how to consolidate protocol for (say) various application servers.
Should higher level application protocols govern the protocol? How much
of the key must be standardized and understood by every application
server?
Is it a problem that URI alone is defined to be opaque to the client?
This was a complaint against one of the Corba mechanisms.
Manner of doing reference creation invites same complaint? Wish
disciplines on how these references are created to avoid falling into
that pit. Do not leave everything to be implementation driven rather
than protocol driven. Make it explicit on platform creators that these
references are not created under their control.
WS-Addressing somewhat overspecified in implementation terms: Required
to dispatch based on the content of the reference properties.
WS-Context allows such a choice but also allows many other choices.
WS-Context also identifies the specific type of context in the headers
that arrive.
Choices: include account number in application parameter (SOAP Body),
include it (somehow) in the URL (opaque address) or place it somewhere
in the header (WS-Addressing or WS-Context). Design pattern is
different in each of these cases. How much about use of this parameter
must the client and client application layer know in each case?
Deft avoidance of "why web services are a poor choice to do RPC"
question...
WSRF encourages people to use opaque identification in circumstances
where semantic (broadly understood) identification may be more
appropriate; that is, it discourages distributed or shared understanding
of the identifiers or algorithmic generation of the identifiers. WSRF
hinders automatic generation of the resource keys. This may be a
philisophical issue that is difficult to fix.
Still have not had the conversation about distinguishing WS-Context from
generic header(s) containing similar information.
Generic question of requirement for demultiplexing headers also not
completely answered. Have not discussed overall model, just addressing
keys.
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.
Discussion of Peter Furnis' Email and Value of WS-Context:
presentation at http://www.oasis-open.org/apps/org/workgroup/ws-caf/download.php/5669/WS-CAF%20radical%20treatment.ppt
- Chair (Martin): This discussion should only occur once and tease out individual issues
- 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.
Alastair: Would be good to get clarity on Activity lifecycle; and on tree-building – different
ways of building a tree.
Greg: there are 2 trees associated with an activity
participant/registration tree
activities in hierarchy, nesting
there is a 1:1 relationship between activity and context
or not (Eric) – hasn’t been finalized
Greg draws some diagrams
begin -> begin+ctx ->
ActSvc/CtxSve <- begun +augmented ctx ALS
Ctxsvc makes the context, passes to ALS, which augments context
Later, user may pass begin + existing context to CtxSvc which creates a new child ctx
(unclear exactly what is passed to the ALS in this case)
Then, using addParticipant (from ws-cf), or equivalent, Participants register within a
particular activity
Question: does /should a context involve more than one ALS ?
Spec not entirely clear (or assumes NO).
Simplifying assumption would be to say no: one context only involves a single ALS (and
thus one using protocol)
Can there be more than one ALS for a single protocol ?
Question revived: is there/should there be a mechanism for more than one ALS
augmenting a pcol.
What is an activity (or Activity). Is it a first-class citizen of ws-caf/ws-context ?
Is it created by the begin (to ctx service)
Concepts to be sorted out:
Activity
Context
Activity Service
Context Service
Activity Lifecycle Service
Eric (in reply to question “what’s the Activity Service”): an extension of context service
that could be merged back into it, including lifecycle mgt, context mgmt.
Martin starts a UML diagram
Webservice operation invocation -- is associated with 0..N Activities
Rethink
Webservice operation invocation is associated with 0..1 WS-Context contexts.
(simplifying – in fact there can be multiple in hierarchic, related [or unrelated ?]
relationship, but will be presented as one for now.
WS-Context context : Activity is 1:1
(do we want to have multiple contexts for the same Activity)
An Activity can be related to other Activities ( this is reflected in the corresponding
Context’s, but we don’t show that)
Context is for a single activity, but is it 1 context : 1 activity ? or can there be synonyms
(shadows, multiple representations)
Martin: If 1:1, then should drop one (and just have context)
Further discussion on whether an Activity is a concept that needs to defined and/or
included in the ws-ctx spec.
Eric: activity references the execution environments
Martin draws another diagram – four web-service invocations in an activity, each labelled
with context X. Can there be another invocation labeled with context FOO, which is part
of the same activity.
Martin: would like to see a diagram showing the concepts
In the primer or the spec
Ask the authors to produce such ?
ACTION: editors to draft a model diagram from which the normative specification is
derived.
(See also issue 65)
For future consideration, after sorting out the concepts –
Diagram of different trees
List of subjects/issues from this morning (repeated here)
1. Absolute necessity of an “application protocol” governing the meaning of a
context ?
2. Switching/compound usage hierarchy and relationship
3. Tree building
4. Must propagate
5. Facilitate interception
6. Mutation
7. Context service and HTTP utilization
8. ALS
Implementation group:
Sub-agenda
Charter
Malik showed the plan as in
http://www.oasis-open.org/archives/ws-caf/200402/msg00028.html
Q: are we on schedule – deferred for tomorrow’s discussion
Group charter (included in some msg)
Purpose is to show that WS-CAF implementations (will) exist
Intent is to have running code before our very eyes – this is not explicitly stated in
group charter
What exactly is the target in terms of demonstration ? Possibilities:
Workshop = we got it working in the lab last week
Stage demo = look it works, on a particular day
Continuing interoperation = standing access over the net between implems
Main charter says we will have a testing/interop program but doesn’t detail which of the
above.
Subgroup charter improved by adding “showing sample application implementations
interacting”.
Charter document should NOT include the sample application description – will be
moved to separate document as design document.
Deliverables list will continue to be in the charter.
(Note implementation group is a separate subgroup in OASIS, but kavi may not show it’s
existence to non-members)
Action: Peter whinge at OASIS staff to get subgroups shown to members of parent
TC even if not member of subgroup.
Deliverables timetable follows the schedule of the specification documents (ctx first etc).
Document names should follow current pattern: WS-CTX, WS-CF, WS-TXM. For each
there will first be a description of the application, later the demonstrated
implementations. Associated artifacts (e.g. WSDL) may be made publically available but
there is no requirement to make source code available.
The subgroup charter will be put up for ballot by main group (strictly, a subgroup doesn’t
need a charter, but it is helpful to them)
Action: Malik to update Impl team charter to reflect f2f discussion
Demo application
Martin resiles authorship of the draft
Greg: purpose of demo is to show interoperability and basic validation of spec, not to
necessarily show best practice or range of functionality. Is this correct ?
Doug: there is marketing value in showing that it works
Martin: this plan is modeled on WS-RelMsg; occasional events. Not expecting the scale
of WS-I.
Alastair: if this is ornamenting the existing WS-I app, could the involved companies
make a beauteous version using WS-CAF
Martin: it is a question for us now as to how fancy to make this. (Oracle & Sun have WS-
I apps running, but Arjuna don’t, so they would have uneven starting points)
We are basing on the WS-I application, but this is not the same. It’s the WS-CAF demo
application. IPR is ok if we don’t call it the WS-I application.
Simeon summarises:
Our demo take just the retailer from the ws-I sample app.
Each implementation will use the context service of another.
Propagated context is the shopping cart, being moved around between the stores – one of
the issues is whether to propagate by value or by reference.
Alastair: if the updates to the shopping cart are not using the ctx mgmt service, then the
demo will test the interoperation of the application implementations, not the ws-context
implem. If each client calls its own context svc, passes the ctx by value, then the service
adds to the ctx and (in the final case) fires its own checkout svc, there is isn’t any (or very
much) ws-context demonstrated.,
Martin: yes, starting very basic.
Pass-by-reference will show more.
Involvement of which service
Current draft does not expect to show ALS:CTX interoperation
Will show application:ctx service (to get ctx)
If checkout svc is ctx mgr using pass-by-reference the ctx mgr interfaces are
shown
Alastair: problem is that with checkout just being the printing of a collected list of things,
it rather undercuts the claim of independent utility of ws-context – a genuine case of
multi-merchant shopping cart is a coordination and transactional use-case.
Eric: this is a ref. implem to show that it works, rather than showing the utility of ws-
context as such.
Malik (& general) : it would be good to show the utility
Alastair: this is but a step on the way to the full demo of all layers which would show.
Greg: Newcastle GAF work might show the pure use of ws-context. Would be worth
checking with them to see if that is a possible source.
Simeon took us through the scenarios:
UC-1: 1 stores (doesn’t actually show any ws-ctx interop)
UC-2: 2 stores (and thus does have ws-ctx)
UC-3: 3 stores, and one of the items is the same from two stores
…
Doug: not clear if there is any more complex of ws-context use, just more complex
application use between the cases. Doesn’t necessarily add to things for our purposes.
Are items identified by “manufacturer” or opaquely by the store ?
Alastair: if the additions made to the context are opaque (specific to the store), then ..
Does the shopping cart contain lists of globally-understood items, subdivided by supply
store; or lineitems each of which is store-and-item.
Greg: cf. amazon current bookselling – allows purchases from other sellers.
Alastair: in doing a demo, as it goes through the stages, only change one thing at a time,
or people will focus on the non-significant.
Alastair: main importance is to show ws-context interoperability – should work out which
interfaces, and which operations of ws-context are exercised (rather than worrying too
much about business model reality)
Liasons:
Prelude
Martin: what's happened? Eric: not much; Add to agenda: WS-Transactions
(and dependent specs) Workshop is March 10.
JJ: new ebXML architecture
group; CAF may be new way to think about
architecture for ebXML.
Dale: ebXML messaging may be relevant
OASIS Plenary
Doug: ebXML 2.0: eq. to reliability, manifest, security profile.
EMEA/AsiaPac adoption. Canada, some US gov. White paper from TC about
possible directions for ebms 3.0 (white paper available). ebms has some
context like things, so interest exists in TC particularly in royalty
free standards. Time frame: early requirements phase.
Dale: BPSS potential interest in coordination.
Action for chairs: request time with ebXML ebms in New Orleans.
WS-Transaction hosted by Microsoft, March 10.
Open discussion: Do we as a group want to send a rep? Individual
companies are concerned with legal issues associated with participation.
Action: chairs to draft statement on behalf of TC calling for industry
to work together.
Scheduling:
Meeting schedule:
March 8 (F2Freview/votes)
March 15 (model discussion)
March 29 (impact assessment of model on specs)
April 12 (continue on issues)
Editor action item on model description: March 8.
Editor call 11am EST: March 4.
Impact assessment of model for consideration in draft: March 25.
WS Context Draft by April 22.
Summary of actions:
Action: Eric post editorial issues for issues 12-20
Action: Mark - Automatic update of bugzilla
Action: Eric to contact WS-RF folks
Action: chairs, Person responsible for updating resolutions in bugzilla to be identified
Action: chairs to determine if bugzilla db backed up and if access to account creation
restricted to WS-CAF members.
Action: Eric to updtae FAQ based on f2f comments
ACTION: editors to draft a model diagram from which the normative specification is
derived. by March 8
Action: Malik to update Impl team charter to reflect f2f discussion
Action: chairs to draft statement on behalf of TC calling for industry
to work together.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]