[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: draft minutes 1 August 05
_________________________________________________________________ Martin Chapman Consulting Member of Technical Staff Oracle P: +353 87 687 6654 e: martin.chapman@oracle.com
Minutes for CAF meeting, 1st August 2005
Comments on Agenda:
http://www.oasis-open.org/apps/org/workgroup/ws-caf/event.php?event_id=7365&day=1122890400
- [Alistair] Deal with items in email discussion early. Check transactions, optimizations, etc.
- [Martin] skip to agenda item 7b, then go back to AIs
Agenda Item 7b:
1) Enlistment optimizations
[Mark Little] Second draft of text that went around on 26th. There were a couple of comments mostly from Alistair.
http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200507/msg00093.html
[Alistair] See email: Re: Checked transactions (by Alistair to Greg) on 7/25/2005
http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200507/msg00081.html
** Mark made a motion, Greg seconded the motion. Adopt proposed text in:
http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200507/msg00093.html
Discussion on the motion:
[Greg] A question on Mark's proposal especially last paragraph. Is it necessary or simply an artifact of the existing structuring.
[Mark] It doesn't have to be a participant added message that flows across the message. A participant message can be added directly added by the registering service.
[Greg] Is this just an implementation detail.
[Mark] Yes.
[Mark] This paragraph can be removed.
** Greg motioned to strike the last paragraph, Simeon seconded the motion.
Amendment approved
[Alistair] Enlistment, Vectorization, optimization is worthwhile. There may be other message bundling that need to take place. Another thing that was raised... I don't see the point of locality. My other point is: I don't see why you would fail to deal with this optimization, I don't see the need for the fault code "Cannot Deal With Optimization".
[Martin] Any proposal?
[Alistair] Making a proposal to remove the penultimate paragraph. ("If a receiver of a response obtains the soap header..."
[Eric] Are we amending the spec or Mark's proposal
[Alistair] The proposal
[Eric] We would have to re-vote on the proposal after this amendment is done.
[Martin] Yes.
*** Peter seconds Alistair's proposal.
[Martin] We will come back to this after Alistair continues.
[Alistair] Next point (working backwards). I don't see any reason why addParticipant header has to be propagated back with the response. This is a choice of use in application context. Anything with response should not be normative. Fourth point... Locality issue. We should vectorize the response instead of having multiple response messages.
[Martin] Let's go back to the amendment.
[Alistair] Withdrawing amendment.
[Greg] Wanted to ask about amendment. Should I table?
[Martin] No go ahead.
[Greg] Concern with withdrawing the fault. The sender may not be capable of registering with anything. Has anyone done analysis on this and come to an opposite conclusion.
[Mark] There is a need for the receiver of the context to tell the registering service that "I can't register", "I don't have the capability to register"
[Peter] I don't think this is necessary (the fault). Bundled messages are being sent back to the app client. Then that only makes sense if we're taking advantage of an application message. If the message is not able to piggy back on a client message there is no reason for the app client anyway and we should take advantage of the registration service.
[Doug] Mark or someone else please remind me of the parties involved. The question that peter is raising about bundle with application messages or within CAF confuses me.
[Mark] The scenario is that: A coordination service, service A, service B. Service A receives a context, because it receives an invocation from another service. A makes a call to B passing the context. B has several participants to register. This optimization allows B to package up the participants and sends them back to service A in the response. Basically allowing B not to have to send them individually in separate calls.
[Doug] It's useful to divide optimizations in message flows between two parties.
[Mark] (disagrees with Peter). We cannot make the assumption that service A can do registrations.
[Alistair] I don't get it. (disagrees with Mark). Why do we make the assumption of non-communication between A and the coordination service? We're in danger of drawing one optimization scenario and ignoring others that might likely occur.
[Mark] motion to adopt the amended text (Text that Greg amended). New motion will be raised to adopt Alistair's objections.
[Alistair] I do think that the fault could do with a different name. (rename the Fault)
[Martin] Do you wish to make an amendment?
[Alistair] motion to rename fault to CannotProcessEnlistments.
*** Mark seconded Alistair's motion.
[Peter] 2nd para typo: drop 's' on last AddParticpants. (note to editors: watch pluralization)
[Martin] Any objection to the amended motion. (None)
[Martin] Motion carried.
Agenda Item 4:
Approve minutes from 18th July. (http://www.oasis-open.org/apps/org/workgroup/ws-caf/email/archives/200507/msg00058.html)
*** Mark made motion to adopt, Eric seconds. No objections. Minutes approved.
Agenda Item 5
a. Kevin to come up with a proposal for a stand-alone WS-CF
interoperability demonstrator.
[Martin] Kevin should have that done
[Mark] He will have it done tomorrow.
b. greg to propose on some text to address this Issue 273 (policies for isolation level)
[Martin] Leave this open.
c. Greg to write up a proposal for how to address the issue of asynchrony in the ACID spec.
[Greg] Not done yet
d. Greg to write up proposal for how to address policy also - to stimulate discussion.
[Martin] done
e. All members to check preferred new RF mode, to be discussed at an upcoming conference call.
[Martin] ongoing till we agree when/if to transition.
f. MC to check with Jamie and report back on the delta, so that the TC can consider further.
[Martin] I have done this. Spoke with Jamie last week. What will be the diff. of how we are operating now and how we will be under the new RF terms. The only diff. is that under the old system the licensing terms don't really have to be disclosed. Whereas in the new they would have to be disclosed in 60 days. One has to evaluate whether there are any licensing issues and whether we should note them.
Agenda Item 6: WS-CF status.
[Martin] Kevin sent out an email with WSDLs and schemas
[Mark] Sent it out with an updated document.
[Martin] We just updated the document.
[Mark] Motion to adopt this as the next revision of the WS-CF TC
[Martin] You mean a committee draft.
[Mark] Yes.
[Martin] Anyone second.
** Eric seconded. No objections.
AOB:
Policy and Checked Transactions will be first on the next meeting.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]