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 Minutes for December 2003 F2F

Martin Chapman                                 
Consulting Member of Technical Staff           
P: +353 87 687 6654                           
e: martin.chapman@oracle.com                   
Title: WS-CAF F2F

OASIS WS-CAF Face to Face Meeting Minutes

Waltham, MA, USA

3 and 4th December 2003

Hosted by IONA Technologies


Agenda Review:



No changes to proposed agenda


Roll Call:





































Thakur (Observer)


Chapman (Co-Chair)


Newcomer (Co-Chair)




Face to face meeting will be considered one meeting with one roll call, and not a meeting per day each with a roll call.



Jean-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









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.






Various: Should demo be sample app, conformance, test suite, or what?

Oasis not in conformance business, so should be more of a demo.








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?




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.
Doug: let us think about giving the editor enough info. I could send out the files that we use in WS-Reliability. We don’t have a process but just a set of tools.


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.
Doug: cut and paste a lot. But there are about 5 different ways to get to any email on OASIS, which complicates things.


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.

Mark: but other systems exist that work like BPEL does.

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



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.



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?




Eric: who is on BTP?



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.



Mark: I can do that.




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.


               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]