Minutes Confcall January 19

[Guy Pardon <guy@atomikos.com>]

Below are the meetings I recorded. Due to the interference on the line I am not sure if I got everything right.
Please send your comments to me if you have any.

Guy


OASIS confcall minutes 19/1/04
Recorded by Guy Pardon (guy@atomikos.com)

-Approval of previous minutes
Update: Jamie should be contacted about update
->there is general consensus on handling this in subgroup
Motion to approve minutes, seconded by Mark
Any objections? No, so approved.

-Action items
Martin posted FAQ. 
Martin: Every workgroups has an FAQ. This one was developed by the original authors of the CAF spec and is a live document. 
Comment: there is still the mentioning whether of not to submit to a standards body, seems unnecessary?
Martin: we may just omit this piece of text
Guy: nobody has signed any royalty free agreements except maybe the original authors. Just want to point that out.
Martin: this is running ahead of things, but it is supposed to be independent of WS-CAF.
-Someone (?): the agreement is RAND terms.
-Someone: we should get the FAQ updated to the current TC. The TC pages are still outdated.
(Discussion on RF issue here)
-The only way we can enforce IPR issues is to ask people to respect RF upon submitting a contribution.
-Nobody can ever make that promise because you don't know of any undisclosed IPR.
-Conclusion of this: the original RF authors have made this statement in the FAQ, but not the other members.
-The CAF spec should be RF as much as possible, but it may not be possible entirely. BPEL is also not RF.
-Are we going to change the FAQ to reflect the fact that only the original authors? OK, action item.
The FAQ is to be adopted as a document of the TC. So now would be the time to get it changed if required.

Martin: any other questions on the FAQ? No.

Next item: Eric: Context examples presentation:
In the F2F in December, there was some discussion about deferring long issues to later.
One such things was whether the CTX service is really generic outside TM functions.
We talked at the F2F mainly about the characteristics of CTX and about thinking of some examples of use case scenarios.
Some things included security, database files, clusters membership,...
None of these examples are normative but rather to be included as appendix in the specs.
Going over them in (reverse) order of the emails mentioning them:

-Example1: Session state from Greg: shared session across WS interactions to support conversations.
It appears that Gregs example would fit.

-HP pointed out that they did not define the creation of session but rather the need for them

-Example2: Cluster membership: Mark wrote scenario on how to use CTX for replicas in fail-over and load balancing. Conclusion: CTX seems good match for weak or even strong consistency protocols (dixit Mark). Weak consistency seems more appropriate for WS applications

-Example3: Database files and devices: CTX could be used to share resource information. A set of WSs could access common resources over multiple interactions. The CTX could contain and share the different handles to these resources.

-Example4: Security example: never received.

-Example5: Context for sharing state in business processes: Jan Alexander proposes an intermediare and define the state of an activity as the set of messages exchanged. The intermediary would make share state between apps in a transparant way. CTX would nicely fit.

Are any of the examples' authors present to point out any mistakes in the presentation? Silence.

Eric: OK, let's open for discussion

-Alistair: Choreology went over them and comments: Erics example is like a config service (cf property files): a service which sits on top of a file repository. The same seems to apply to Jan's example. Remark: it would be useful to have a webservices edition of that, since it seems basic functionality that can be isolated from the more complex examples. It seems like registration and outcome notification are on a different level.
Another comment: there is an update facility here. We don't have any access control to the information in the CTX. One can dynamically modify the information from different locations.
Answer: a signalling protocol to allow participants to detect conversation ending would be useful.
Also, singalling is already out of the basic CTX and put into the coordination framework.
CTX only provides the basics and begin/end in some way.

-What is the thing that enlists in CTX? The ALS? There seems some confusion about this.
As it reads: enlistment is in the CTX specification, but Greg suggests it is one level up.
So where does coordination start and CTX stop?
(Some discussion about whether we should limit ourselves to the examples or discuss the specs).

-Choreology's point: completion in Mark's facility is confusing: is the completion signal going through CTX or not? Is there any enlistment in the specs, or is this the wrong version of the specs?
Answer: there is no necessary dependency between the ALS and any coordinated event.

-Mark's answer: the coordination aspects in the example are back-end and not meant for the CTX service to do. The CTX service only has to signal a termination event. The replica coordination is not part of CTX but can be something else.

-Follow-up question by Alistair: does the signal depend on some registration or not? 
Mark (with some reservations): CTX has very low-level type of co-ordination among the different ALS-es. Activity.start would add something to the basic context. We can continue this discussion by email.

-If there is nothing using the termination in the CTX then why should it be there? Maybe it is worth raising an issue about it. (there seems to be agreement on this)

Martin: let's continue the discussion via email
Next item: implementation scheme update
-Malik: WS-I proposition has had no objections. A charter was posted for the implementation group.
Any questions? No

Next item: issues resolution
Martin: The only way to make progress is by going over issues and resolve them before moving on.
Did everyone get a chance to read the issues? Silence. Any motions?
Remark: In most cases they appear typos or editorial fixes.

Motion to adopt them (issues 1-11) by Greg. Anybody seconding? Yes: Simeon.
Any discussions? No. Objections? No. Motion approved.

Simeon still has to do an update.

Issues 44-45: 
Issue 44: was informally resolved at F2F? Are we going to use WSDL version 1.1 or 2.0?
1.1 seems more reasonable, since 2.0 is too far out?
Motion to use WSDL1.1, seconded by Mark. Any discussions? Yes, we could later map to WSDL2 if it is stable? There is nothing in the resolution now that precludes that, but maybe we should formalize the willingness to be forward-compatible.
Martin: we can still reverse this decision if appropriate.
Any objections? No. Motion approved.

Issue 45: do we want to be compliant with WS-I BP?
Any motions? 
Question: what is the impact of a decision? Martin: BP was recommending not to do stupid things with WSDL by adhering to best practices.
Question: is there any need to reference BP from the specs? Yes, we should mention it. 
Simeon: BP is well-established and we should not come up with our own. If we all agree to comply with BP then things will be easier.
Motion: Adopt BP, seconded by Simeon. 
Any objections? No. Accepted, issue 45 closed with resolution that intent is to be BP-compliant.

Next agenda item:
End of April there are possibilities to meet in a F2F. Are we going to do this? Currently we have Feb and then May-June. Any comments? No. Anybody opposed to meeting? No. Eric: we should consider meeting since it will be a chance to get interaction with other TCs. This opinion seems to be shared by others.
No objections, so this is approved.

Next meeting: Feb 2nd.

Last Question: how do we raise a new issue? Answer: send an email, it will go the the bug tracking system.



Dr. Guy Pardon ( guy@atomikos.com )
Atomikos: Your Partner for Reliable eBusiness Coordination
http://www.atomikos.com/

The information in this email is confidential and only meant for the addressee(s). The content of this email is informal and will not be legally binding for Atomikos.