----- Original Message -----
From:
Guy Pardon
To: Mark Little
Cc:
Sent: Tuesday, January 20, 2004 3:01
PM
Subject: Minutes Confcall January
19
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 ()
-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.
My recollection was that the statement by the TC
was a little stronger than this: the TC will attempt to make the work RF, but
because of the realities, it is possible that someone may not have disclosed IP;
the TC can't force this without getting members to sign something, which we
can't do (and it isn't covered by an OASIS rule).
I think it's important to get this right because
the BPEL analogy isn't the right one (I don't remember this coming up yesterday
at all, but may have missed it): from the outset BPEL has not tried to be RF;
WS-CAF has.
Mark.
-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 (
)
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.
