[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes for December 2003 F2F
_________________________________________________________________ Martin Chapman Consulting Member of Technical Staff Oracle P: +353 87 687 6654 e: martin.chapman@oracle.comTitle: WS-CAF F2F
OASIS WS-CAF Face to Face Meeting MinutesWaltham, MA, USA 3 and 4th December 2003 Hosted by IONA Technologies
Agenda Review:http://www.oasis-open.org/apps/org/workgroup/ws-caf/event.php?event_id=3086&
No changes to proposed agenda
Roll Call:
Face to face meeting will be considered one meeting with one roll call, and not a meeting per day each with a roll call.
ScribesJean-Jacques Dubray, Morning 3-Dec-03 Dale Moberg, Afternoon 3-Dec-03 Guy Pardon, Morning 4-Dec-03 Ramesh Nagappan, Afternoon 4-Dec-03
In future meetings, if there are no volunteers for scribe duties, the chairs will progress through the role call in reverse alphabetical order asking people to scribe.
Approval of Con call minutes:
Martin had an action point to set up a poll regarding con call times. Minutes did not record that this will be discussed at the f2f and poll will be made after this discussion (unless the f2f meeting decides otherwise)
Motion to approve the minutes with the changes above made by Mark Little, Seconded by Jeff Mischkinsky. No objections were raised so motion carries.
Mark Little Presentation on WS-CAF
The purpose of the presentation is to get us on the same page
WS-Transaction Management: There has been some discussion where one protocol is sufficient, this specification was intended as a live document such that more than the 3 protocols currently in the spec can be supported.
Default binding for the spec: one ways and call backs rather than request/response, since the response might be sent to some other node.
Ws-addressing: using a home grown mechanism. There is not an open standard yet in this area.
ISSUE: are we basing this work on WSDL 1 or WSDL 2? ISSUE: what should we use for ws-addressing? There is a sub-issue relative to multiplexing. ISSUE: which version of the basic profile (WS-I)?
Coordination was originally factored out of Transaction The authors then realized that Context needed to be factored out of Coordination
People can see immediate requirement for Context.
Context leads to the concept of a Context Service. Activity is a fairly abstract notion (no strong requirement on what an activity is). Activity is a unit of work, context is a way is correlating work within this unit of work.
There is no notion of time limit defined in an activity (session, long running…)
A context service should be really easy to implement. For coordination and transaction it should be enhanced. A context service maintains context on behalf of activities.
Context should be differentiated from correlation mechanisms of message exchange patterns because they are not the same. Question: should more types be defined in context (security, replication…). The problem becomes how these types are managed. We should come up with other examples (than transaction) to illustrate how context can be used. Is it general enough? Or transaction specific?
For the basic spec, activity work correlation was targeted at a minimum.
Context can be hierarchical when activities are composed.
The intention is to support all the concepts of context out there.
Context URI: the URI is dereference-able to a web service (? – martin something is missing here)
Context be augmented dynamically.
Context is propagated in a SOAP header.
Faults are not managed by the basic context service. It is for instance coordination and transaction that introduce the notion of fault in the context.
ISSUE: discuss context sharing
Discussion topic: one service or two for “activities” Discussion topic: terminology clarifications, e.g. “correlation” + “domain”
A transaction service is an ALS (Activity lifecycle Service).
Question: how to demarcate context from coordination (since a context is a simple form of coordination –with no guarantees).
Discussion topic: uses cases and requirements (later migration) to align with other specs relying on context (e.g. SAML)
Discussion topic: relationship to reliable messaging
Issue: security for context manager (ALS)
The context service is an optional part. The minimum context is a data structure. Context can then be passed by value or reference. By value is just a header schema.
The basic use case is an immutable rather than dynamic context.
ISSUE: more clearly describe the basic context sharing case and add data reference to the schema.
A child context can only have one parent. UBAC (Anders Tell) has some requirement with merging multiple contexts for some legal purposes.
Discussion topic: how ws-caf and BPEL relate (e.g. correlation sets). There are also important applications of context to B2B.
Break for Lunch
Mark Little Presentation on WS-CAF (Cont)
The afternoon session began by introducing the concept of the Coordinator The approach to coordinator so far taken has involved,
Protocol neutrality
Schema for context extensions
One ISSUE noted was whether in future work the approach to optional parts should be retained (coordinator to participant)?
WS-CF does not define format of AssertionTypes.
Identity in WS-CF
Coordinator operation accepts (see slides) status, identity, wrongState, generalFault, addParticipant, removeParticipant messages for protocol interactions defined.
Runtime extensibility, for example, time bounds on enlist/delist
Using Qualifiers
Interposition, where a participant in one coordination activity is a coordinator for another ' subordinate coordinator
Digression on use cases
Efficiency was original motivation for interposition, but also considerations of interoperability and multiple protocol coexistence became additional motivations.
Proxy protocol bridge makes it possible to permit interoperability in a multiple protocol environment.
Coordinator to coordinator protocol is used in this bridging. And apparently this protocol is the one found in the transaction draft.
Recovery mechanism left open because of their variety.
Recovery coordinator Currently participant driven Coordinator moves-how to proceed?
Currently considered as Out of scope and implementation specific
Should multiple bindings by addresses of coordinators? Should there then be a logical identity (logical address?) for coordinator that my have various endpoints? How would this help simplify the problems with recovery when coordinator changed?
Transactions WS-TXM
Basic goals and assumptions
One size does not fit all for aggregate of use cases.
N+1 phase for very large scale cases, 3 phase cases mentioned.
Assumption that ws-transactions will be for b2b bridging for exisitng TP systems because of costs of replacing well entrenched systems
3 transaction/activity modes
acid, long-running with compensation, business processes as single logical transaction
Report of a site with 3 in 10000 failure rates, 400 people handling manual recovery
Cannot use removeParticipant in ACID
ACID semantics needed --presumed rollback --trusted components
prepare, commit, rollback
Synchronization
beforeCompletion afterCompletion
Forward work, credit account back eg Compensatable unit of work as activity Pass compensator to parents from child, but compensator technique may vary.
Travel agent example
Book 1st class try economy else fail
Diagram may be misleading in some respects.
Lra is long running activity
Domain assumptions
Domain exposed as subordinate coordinator,
JJ Dubray: Ad hoc web services at odd with reusable patterns?
JeffM: But ad hocness is no worse than what we have always had? What is point?
JJ explains interest in templates aiding design
JeffM OK
Issues list is a submission for TC to consider
Mark comments that many issues are minor editorial or terminological inconsistency
Break occurs at 3 oclock or so.
Martin agenda item on timelines, schedule, deliverables.
Proposed serial effort, one specification at a time.
Proposal to start with Context, Coordination, then Transaction.
Draft of WS-Context in April 2004 Draft of WS-Coordination August 2004 Draft WS-TXN December 2004
Implementations needed for OASIS specification status.
CTX COOR TXM
Various: Should demo be sample app, conformance, test suite, or what? Oasis not in conformance business, so should be more of a demo.
Primer.
Glossary
FAQ
Btw, does FAQ need approval? Various: Yes
ACTION: Martin to put FAQ on agenda for approval. ACTION: MARK to post FAQ from initial collaborators to the group
ACTION: Martin and Eric to post IPR info on link on web page.
Eric and Greg and Mark Little and Simeon to review schemas.
Word, PDF, and/or docbook?
http://www.oasis-open.org/spectools/#documents
Has formats for OASIS documents.
Miscellaneous comments on primer pronunciation.
PDF line numbers are to be used when referencing specifications.
Issue discussion:
Uses for context Eric presentation
Use case families
1. Userid, address, email, phone (from requesting environment) 2. Security context of requester (request or response) 3. Transaction id (response) 4. Database sessions, device session resource being used (response) 5. Governing technical, legal economic contract agreement 6. BusinessProcessState identifier, Choreography BP 7. Replication 8. Tracking or Monitoring support 9. Faults
Question about how type attributes of context pertain to use cases Question about processing, handling and dispatch What is middleware and what application?
Context extensibility model? Illustrate.
What prevents any soap header from getting mapped into a context container header? Surely there is a difference between a context header block and the generic header block function? Otherwise, xcope can drift out of control
Design patterns.
Coordination of BPEL engines... need to trace through how they would use CTX data?
Volunteers for use cases, scenario description to be posted to list
Mark, high availability Eric, on security Others unfortunately not captured.
End of day 1.
Meeting Minutes 12/4 Morning Session
Eric opens the meeting by greeting everyone and proposes to start with the issues process list formed the day before.
Issues Process and Editors
Martin: time to make some hard decisions and formalize how to deal with the issue list so far. Who is going to be the editor(s)? And will the TC use the BPEL process?
Jeff: The ideal thing is like in BPEL: linked to emails: subject says XXX -> editors pull out the things and put it together. Do we need a lot of formality? BPEL is more tensed and therefore needs more formality? A simpler system could do like an HTML form or spreadsheet. Do we keep separate issues lists for each doc or not?
Doug: reliability considers that different lists don’t work well because issues move around.
Jeff: one editor for context and another editor for CTX?
Martin: we can have some categories but one flat numbering list. Jeff: in BP we had different lists.
Martin: let us segment the discussion: we look through the BPEL process and see what tools we need. Jeff, are there any suggestions?
Jeff (summarizing): issues have two states, open and resolved. For BPEL it was important to have all issues closed before the work was done. The editor has to maintain a list of issues and does not have any discretion about how to do it. Nobody can change the process without the TC voting. If someone submits an issue then the editor can moderate first with the submitter to rethink ‘unclear’ issues.
Doug: Does the initial revision round do anything else than suggest spelling changes? Jeff: we have to ask Peter.
Jeff: the editor has to assign a number and … Martin: you send submissions to the editor and not to the list? Yes.
Martin: what about outside people mailing-in issues? Jeff: the issues editor is supposed to send an announcement to the list.
Jeff continues the summary of the process.
Jeff: to help resolve issues it helps to have champions: somebody who agrees to facilitate discussions.
Martin: why not use Bugzilla Doug: which part? Martin: the whole system.
Jeff: this is the format of the emails (shows section in document on slide) Because there are so many in the TC for BPEL, they don’t want to vote on con-calls so the KAVI system is used. There has to be the formal process for proposing issues voting. It is difficult to figure out what the latest state is you are going to vote on.
Jeff: we wanted to make sure that there is a week’s notice for voting. This means getting things in the agenda on time etc.
Ben: it is not really followed that closely, only generally. Martin: is there anything we want to remove? Jeff: it is a bit of an overkill. Martin: let us take this as a guideline to resort to in case things get messy. Jeff: people should know when a topic is likely to be voted on. Martin: given the size of the group, we should be….
Doug: we don’t want email votes. Eric: only by confcall or KAVI.
Doug: KAVI does not really tell you if it passed or not. Do we want to write a much shorter version of the process for reference? For some parts (description of fields and editor communication) it feels a bit like the UB FAQ.
Jeff: if you have scripts
than you need to be precise.
Martin: we should borrow as much as possible from existing processes.
Ben: how does WS-RM work with the tools? Jeff: who maintains the list? Doug: me. I edit an XML file if there is a new issue.
Ben: so you take the mail and go into the XML? Doug: yes.
Ben: it sounds a lot of
work.
Eric: what is the volume? Doug: I can look it up.
Martin: how many issues in BTP? -> about 200.
Doug: experiments with other Tcs to send in XML issues were not a success. Alexander: we do things like Doug in WS-RM.
Martin: if new people join then we should have a formal description to show. We can probably get rid of some fluff to simplify.
Ben: but how do we anticipate the issues to be generated? Solo or in group? Martin: one of the reasons for the process in BPEL was to have some administration support.
Ben: the ability to mail to somewhere is a good thing. Dale: I could see the (BPEL) process as a superset.
Martin: we have to cut some things; we just want rules without all the background.
Martin: is there someone who wants to review this? The most efficient way is to have the candidate editors go through it.
Eric: we already have a list from before. It has numbering schemes which could serve as a test of the process. Do we need someone separate or is this for the editors?
Martin: it is nice having a separate role if it ends up being the same people. Eric: we could say the chairs are to follow-up the process and the editors are responsible for implementing it.
Martin: it is a group or one person? Mark: it depends on what tools to use. We could maintain Bugzilla at our site and refer to it from OASIS site if nothing else works.
Martin: yes, but it does not integrate with email very well.
Alexander: can they generate overall lists?
Mark: yes. Ben: who has the software? Bugzilla is open source. Doug: the only issue is that we are supposed to be open to the public. If we link to another site it feels proprietary. Ben: the process is just: email to something; a number is generated and later the collection is posted back to OASIS.
It is valid to keep working documents.
Ben: will Bugzilla generate numbers and send back to list? Mark: yes.
Martin: Decisions? Mark, do you volunteer for editor responsibilities? If so, could you come with a recommendation?
Mark: yes.
Mark Little is appointed as issues editor, and will supported by the other issues editors.
Mark: bugzilla allows you to mark issues against components. Ben: is a category-editor supported based on email content?
Mark: no. Everyone has to submit their issues through Bugzilla. You would have to go to the system’s URL and submit your stuff.
At every moment you could generate a list of issues through a query. On the CAF site you publish the URL to the site. The current issue list is whatever report you get from the bugzilla site.
Eric: should we input the existing list of issues in the system? Martin: yes.
Ben: what about exit criteria? Martin: in BPEL we needed all issues closed. Jeff: Theoretically you can also close an issue by deferring to a next version.
Martin: anything else in issues process?
Agenda item closed. Summary: Mark is candidate editor, and will review the BPEL document and propose tools to put forward.
ACTION: Mark Little to review the BPEL issues process and look at potential tolls and bring back a proposal to the group Liaisons
Martin: we should go into the candidate list of liason-specs.
Jeff: what is liaison? Martin: we have to see. Are we trying to sell them our solution? If not then there is no point? Cites definitions of liaisons in dictionary.
Eric: just an example: for WS-architecture, the point would be to position the CAF in that spec. I will take that responsibility. Maybe the highest priority is BPEL though.
Martin: what will we do with BPEL? I think it is a selling job. If we convince the members then that is it. We have lobbying to do.
Eric: who is on BPEL here? 4 people raise hands.
Martin: we should go through the list and see what we want to come back on next week.
Jeff: in BPEL, one reason is PR to let them know what happens. The other is to try and get some of CAF in their spec.
Mark/Jeff: the last teleconf was about putting explicitly transaction demarcation into the language. There is also a need for propagation of context.
Eric: so let’s start with CTX first.
What about BTP?
Dale: for BPEL there are at least two models: -the cookie model: I get something back to know what to do with the transaction. -the context thing: a global view to relate a shared perspective what the conversation ID is. There is a global view of the context along with the cookie model. Most likely the cookie model is what is more appropriate for them. Or correlations? Some discussion between Martin/Dale about this topic.
Eric: at least we should clarify the difference between CTX and correlations.
Martin: BPEL does not correlate things a protocol level. It is up to the application programmers to determine what comes in.
Dale: could we show that there is an advantage to use CTX to fill the gap they leave? Eric: yes, would be an idea.
Martin: BPEL is not about shared context, just about each process’ individual correlations.
Eric: maybe we introduce the thing? Ben: just present it. OK
Jeff: I thought we were discussing the nature of liaisons? Dale: I wanted to be sure that here is some list of contacts and common interests.
Jeff: view it as a marketing exercise. We want them to notice something. Martin: I can do the PR for BPEL in their meeting next week.
Eric: maybe we should send in an issue for the meeting.
Jeff: no, the agenda is set already. The way to do it is to raise issues in the lists. Jean-Jacques: let us introduce things with a value proposition. Jeff: you can only effectively do this by raising an issue. That way they have to deal with it.
Martin: just for the timing: we should think about what issues we need to raise.
Martin: I will stand up and talk about the PR. I can take Mark’s slides as a pitch.
Jean-Jacques: isn’t coordination a kind of execution? Overlaps etc? We need to differentiate coordination and orchestration more clearly?
Any TODOs?
Martin: an overall PR pitch about the CAF efforts. Second, a more lower-level discussion about tactics and how to raise issues.
Dale: write up a BPEL-flavored use case?
Eric: who will do ebXML?
Dale; for ebXML, let us contact the ebXML Joint Committee first.
Eric: what about WS-RM?
Doug: I can raise the topic, but I am not sure if CTX should be used there. Eric: WS-CAF could more use the WS-RM messaging instead.
Jeff: suggestion: we should pick some volunteers who will track and make recommendations to use if we need to worry about something going on. It does not mean that they have to make presentations to other groups. For WS-I I can do that. But it is premature to propose anything for them to use.
Martin will take WS-Choreo.
Alexander could do security, but is there a CTX relevance? It is limited to one message? And how should you do it for securing the CTX itself?
Eric: maybe we should use Security rather than the other way around. Alexander could look into that.
Jeff: someone have issues for WSDL? We should identify any holes in the spec for things that we need. If anyone has suggestions I am willing to propose these.
Dale: are we going to sign the context? Eric: that would be a way: sign and encrypt etc.
What about SAML? Doug: the session in SAML is probably relevant. Their authentication token can be used for extra info. Kind of a security specific CTX. So they could use our generic protocol instead.
Eric: anyone for SAML follow up? Who is on SAML?
Nobody…
Eric: who is on BTP? Bill.
Martin: what is our goal? Bill: let us start with CTX.
Eric: it would be nice to validate our openness to other protocols; to validate our statements about BTP compatibility.
Eric: anyone for WSDM? Martin: context in there would be nice…
Who is on WSDM? Ben.
Eric: could you introduce the topic there? Ben: Sure.
Eric: GRID? Anyone in there? Ben: Yes. what part? Eric: CTX might be useful, maybe coordination. Ben: there is a transaction issue going around there. Some companies (amberpoint) have some interest in transactional state. I will look into it.
OGSI? Mark: I can do that.
Conclusion:
List: WSA (Eric), BPEL (Martin), WSRM (Doug), WSI (Jeff), WS-CHOREO (Martin), ebXML (Jean-Jacques and Dale), WS-Security (Jan), WSDL (nobody yet) , SAML (Krishna), BTP (Bill), WSDM (Ben), GRID (Mark – OGSI in particular)
Eric: item closed; we can discuss some of the issues then.
Issue: relationship to WS-addressing?
Mark: at the moment there is a home-brew addressing scheme (URI). We should reuse a standard one. Maybe WSDL 2.0 too.
Eric: could we just wait for WSDL 2.0 to solve this? -> no.
Gregg: Let me write an email to see what can be done between WSDL and CAF and post it to their discussions. ACTION: Greg to write a proposal on a web service addressing/referencing scheme.
Mark: multiplexing investigation wrt addressing.
Ben: should pub/sub schemes be supported for the transactions? Like: who is interested in this transaction? Eric/Mark: why not. (Adds it to the list)
Break for Lunch
Since some people wanted to leave a bit early the two afternoon topics were swapped around from the agenda.
Logistics and Meetings– Conf call times – Suggestions (Monday / Friday) – 4 People from Europe opted Monday – Friday is preferred by US Timezone Members · Choice of Time · Monday 9:00 PST, 12 EST, 5 PM GMT · Friday 8.00 PST – 6 people opted Monday 9:00 PST – 4 People opted Friday 8:00 PST – Members discussed on their time conflicting issues! – Members agreed on all Conf-calls will be scheduled at Monday 9:00 PST. – Monday 15th will be the next conf-call before the Winter break – January 5 will be the first conf-call (After New year) – Oracle will be hosting the conf-calls till February '04. – We should schedule weekly con calls in our calendars, although with plenty of notice, the chairs may cancel alternate weeks if there is not much on the agenda.
– Face to Face Meetings – When and Where – 2nd Face to Face Meeting (2004) – Suggested options around March or April or February – Members suggested March 1st week after W3C Planery meeting Mandelo, S. France (Declined due to WS-I meeting schedules) – Atomikos – Brussels – J-J suggested Paris, France (Feb 25, 26, 27) or Week before. – JJ offer tentatively accepted – ACTION: Jean Jacques to confirm F2F hosting in Paris Feb 25-27 2004
– 3rd Face to Face Meeting (2004) – Suggested options Around May or June – Preferred Week of May 10 (Will be hosted by Jeff/Martin – Oracle (California) – Finally planned for May 11, 12, 13 are preferred dates – ACTION: Jeff to confirm F2F hosting in Redwood Shores May 11-13 2004
– 4th Face to Face Meeting (2004) – Around July or August – Hosts and location TBD
Implementation Subgroup
–Responsibilities include analysing the specs, implementing a Demo and supporting test suite tools. –Questions arised on tools about its role in the spec and capabilities. –Resolution – Build a demo to illustrate the use cases and test scenarios – Discuss on the implementation – Technology choices – Java and C++ – Malik will be lead for the Implementation team. – Some demo during the next face-to-face will be useful – Initial participants include Malik, Eric, Guy, Simeon, Ramesh – ACTION: Chairs to setup Implementation subgroup and invite participants – ACTION: Malik to propose a charter and set of deliverables for the implementations sub-group.
– Martin and Eric concluded the F2F meeting.
Meeting is officially adjourned.
Summary Of Action Points.
ACTION: Martin to put FAQ on agenda for approval. ACTION: Mark to post FAQ from initial collaborators to the group ACTION: Martin and Eric to post IPR info on link on web page. ACTION: Mark to review the BPEL issues process and look at potential tolls and bring back a proposal to the group ACTION: Greg to write a proposal on a web service addressing/referencing scheme. ACTION: Jean Jacques to confirm F2F hosting in Paris Feb 25-27 2004 ACTION: Jeff to confirm F2F hosting in Redwood Shores May 11-13 2004 ACTION: Chairs to setup Implementation subgroup and invite participants ACTION: Malik to propose a charter and set of deliverables for the implementations sub-group.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]