OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Prelim minutes of 10/19 teleconf


Prelim minutes are attached.

Please provide corrrections to entire list before Monday morning.

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Minutes of OASIS WS-RX Teleconference

Prelim Minutes of OASIS WS-RX Teleconference

Oct 10, 2006

 

Start Time:4:00 PM Eastern Daylight Time

 

Paul F acted as chair.

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi:

 

meeting is quorate

 

Tom Rutt agreed to take minutes.

2         Agenda Approval

Agenda

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the Oct 5, 2006 meeting minutes

http://www.oasis-open.org/committees/download.php/20751/MinutesWSRX-100506.html

 

4) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

5) Report from the Implementation SC

 

6) Discussion of PR Issues

a> PR003 WS-Addressing comment/question related to WS-RM MakeConnection

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i003

 

b> PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001

 

7) Any other business

 

3         Approval of the 10/5 Minutes;

http://www.oasis-open.org/committees/download.php/20751/MinutesWSRX-100506.html

 

Tom moved to approved 10/5  minutes, Paul C seconded.

 

§    No objections, minutes of 10/5 approved.

 

4         AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php  

 

#0111: Paul and Bob to work out joint WS-RX/WS-Addressing forum for further discussion of pr001 issue.

Owner: Paul Fremantle

Status: Open

Assigned: 2006-10-05

Due: ---

 

Bob: noting the various proposals, it might be better to wait a week or two before pursuit of a joint forum.

5         Report from the Implementation SC

Dug: link to status page http://www.soaphub.org/interop/status/WSRXInteropStatus   Less than ½ are green (passed).  I do not see these as interop issues.

 

Marc G: I would concur, there is green on earlier interop scenarios, and the security scenarios have been recently added.  We have three companies up with secure endpoints.

 

Sanjay: It would be good if the Interop SC could give us an updated on the schedule for the next call.

 

Paul: there are situations where the rm agent is holding onto anonymous connection.  Without timeout there could be deadlock in single threaded client.

 

Sanjay: is this a spec issue?

 

Paul: it only happens when you turn RM on, even though it is an issue with a timeout on the underlying HTTP channel.  It might be something implementers need to know about.

 

Sanjay: It would be good to get all feedback in by the end of the PR period.

6         Discussion of PR Issues

Marc G: where will we discuss new PR issues which have come in.

 

Sanjay: Scheduling PR issues are for their resolution.  I do not think that is applicable for PRs.

 

Marc G: what about volunteers for owning them.

 

PR0004 - Two misspellings and some obsolete text

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00068.html

 

Gil took ownership.

 

PR0005 Sequence ack ranges overlap

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00070.html

Dug took ownership of PR0005

 

PR0006  Destination sequence faults

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00071.html

Dug took ownership of PR0006

 

PR0007 RM Destination to terminate inbound sequences.

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00069.html

Gil took ownership of PR0007

 

Marc G: Issues 8 – 15 will be split out from one common PR comment.  We can then assign owners.

6.1PR003 WS-Addressing comment/question related to WS-RM MakeConnection

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i003

 

Proposal from Dug Davis:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00066.html

Attached is a new version of the changes for pr003 (note this still doesn't include pr002 changes).  The text is pretty much what Paul suggested with two changes:
1 - s/unusal/untraditional/
2 - remove the last bullet about not having the MakeConnection operation in the WSDL

I've also updated the comment in the WSDL related to the MakeConnect operation, and kept the operation there.

I wanted to get people's opinion on the WSDL change.  There's still this overall question of whether or not the RM operations would appear in a service's WSDL - if they do appear then I don't see why MakeConnection would be any different.  Any one-way operation could result in a soap envelope being return - e.g. a Ack can flow back.  So from that perspective MakeConnection is no different.  I did update the WSDL with a new comment that I think gives us the "pay attention" flag we were looking for.  Take a look and let's discuss it on Thursday.

thanks
-Doug

wsrm-1.1-spec-cd-04-pr003-v2.pdf

Doug reviewed the detailed proposed changes.

 

Jonathan: Could you not sent a create sequence response as an input message?  It may be impossible to define a wsdl port type with all the appropriate messages in the correct directionality.

 

Jonathan: I am not sure wsdl can be made complete and accurate for make connection operation.  Would anyone actually use this wsdl in tooling to validate the messages?  If not, so what.

 

Anish: what does this wsdl describe, the RMS or RMD side.  Now it desribes the RMD view of Create Sequence.  A wsdl for the RMS would have to have an out-in operation definition.

 

Jonathan: the wsdl descirbes the service from the point of view of an endpoint.  If and endpoint if both RMS and RMD, should not the wsdl be the union of both views?

 

Anish: that depends on whether we have make connection in there or not.

 

Jonathan: What is this wsdl to be used for. 

 

Jonathan: a firewall would use this wsdl in both directions.

 

Jonathan: the original problem was on the make connection being a one-way operation.  I would like to see some warning on the wsdl.

 

Jonathan: the annex is non normative, but it states the reference wsdl file is normative.  I would like to have no claim that this wsdl is normative.

 

Gil: should the normative nature of the annex be its own issue?

 

Jonathan: we could add a statement “there may be additional message present, especially when an endpoint acts as both an RMS and RMD.

 

Paul C: “not all possible messages are reflected in the WSDL”.

 

Jonathan will raise a new issue on the wsdl annex.

 

Matt Lovett moved, Dug D seconded to clos pr003 with Dug D proposal.

 

§    No objection, Issue Pr003 closed with Dug D proposed resolution.

 

Jonathan: My real question is “who are the protocol level users of a wsdl description”.  The language of which direction things flow is in the spec.

 

Anish: in many cases there is an existing wsdl, and later RM is enabled on top of it.  A policy assertion would be better for these purposes.

 

 

6.2      PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001

 

Dug: WS addressing WG is in the midst of heated discussion.  I would prefer to have us defer the discussion.

 

Bob: we are discussing several possibilities, some of which are breaking changes to the ws-addressing core.  These are fundamental issues in WS-addressing, which are still in the midst of discussion 8 possible solutions.

 

Sanjay: can we estimate when we would have resolution in ws-addressing.

 

Bob: I cannot promise when consenus will be reached in W3C.

 

Tom: perhaps we can discuss Marc G recent contribution, which has an alternative which does not step on WS-addressing toes.  We could begin to discuss today.

 

Paul: F:  I am in favor of discussing our own options which do not confilict with WS-addressing anonymous.  I am concerned about WSRM defining its own anonymous URI.  I am concerned about implementations to have to deal with a growing list of special URIs. If we did not need the extensions, perhaps WS-addressing would not have to change their semantics around wsa:anonymous.

 

Bob:  This is consuming a lot of bandwidth in ws-addressing.

 

Dug D: I would not like us to finalize a conclusion until WS-addressing has completed their discussion.

 

Bob: there is a large portion of the ws-addressing group which has straw polled that they want to restrict the number of special URIs.

 

Marc G opened discussion of his new proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00065.html

Microsoft was opposed to the MakeConnection functionality when it was added to the specification. We continue to be concerned about the impact of the current form of MakeConnection in terms of the problems it has composing with WS-Addressing and unspecified but allowed polling capabilities independent of WS-RM. We do now see that there are RM cases that MakeConnection addresses that are important.

 

We have been looking at how MakeConnection could be modified to compose properly with WS-Addressing, retain scope to RM, and still solve the RM scenarios it supports today. Retaining a generic polling model was not one of our goals.

 

We arrived at the attached proposal that supports the following scenarios. We do believe that this is the set of RM scenarios MakeConnection currently attempts to address. We are unaware of any others.

 

1.       Allow an unreachable RMD of an established sequence to use the back channel to receive Sequence Traffic and Lifecycle messages.

 

2.       Allow a RMS to establish a new sequence to an unreachable RMD.

 

3.       Composability with mechanisms that facilitate identifying an unreachable RMD.

 

Details on how this proposal can solve each of these scenarios are covered below.

 

What we are proposing is to remove both the RM anon URI and the identifier from MakeConnection.  Instead we propose targeting the MakeConnection message at the AcksTo EPR of the RMS. We think this satisfies all of the RM scenarios that the current form of MakeConnection satisfies as listed above.

 

The principal impact of this change is that the RMS needs to add some unique information, e.g. in the form of ref params to that EPR, to distinguish MakeConnection requests from otherwise anonymous clients. When it cannot identify the requestor of the MakeConnection message it sends a CreateSequence to start a  new sequence and establishes the unique AcksTo EPR. The recipient of a MakeConnection request is also permitted to refuse it if the recipient cannot satisfy the requirement to transmit messages on the underlying transport back channel.

 

 Summary of changes:

 

·         MakeConnection is now a header, modeled similarly to AckRequested.

 

o   MakeConnection has been tightly scoped to RM uses, there is no generic polling capability.

 

o   MakeConnection messages are sent to the AcksTo EPR

 

§  RM anon URI and Identifier are both gone

 

§  AcksTo EPR should use unique info, e.g. ref params, to distinguish clients for MakeConnection requests.

 

§  If an RM service cannot distinguish the requestor it should send a CS (with a unique AcksTo EPR if needed) or fault.

 

·         Secure use of MakeConnection is defined

 

·         We have added flow diagrams illustrating the model and expanded on the description of the feature.

 

·         Added a new fault, MakeConnectionRefused.

 

·         The state table has been updated. Only new rows are needed for the existing RMS/RMD state tables. The separate state tables for MakeConnection are no longer needed.

 

Details on supported scenarios:

 

1.       Allow an unreachable RMD of an established sequence to use the back channel to receive Sequence Traffic and Lifecycle messages.

 

This is covered in the attached document in detail. The common scenario here will be an inbound sequence to an anonymous client that was established via Offer (there is no requirement that offer be used however). In this scenario at sequence creation time the server side RMS simply sets up its AcksTo with unique information it can use to identify MakeConnection requests from this client, e.g. by using ref params in the EPR.

 

2.       Allow a RMS to establish a new sequence to an unreachable RMD.

 

This is also described in the attached document. The primary scenario here is for reliable out only sequences. In this case as the AcksTo EPR has not been established the client sends the MakeConnection message to the RM endpoint. When an RM endpoint receives a MakeConenction message it cannot correlate to an existing sequence it should return either a CreateSequence to establish a new inbound sequence or raise a MakeConnectionRefused fault.

 

3.       Composability with mechanisms that facilitate identifying an unreachable RMD.

 

This is not explicitly described in the attached document but is enabled by what is present. Other mechanisms could be composed independently to enable or enhance a scenario where an unreachable RMD needs to be identified. This scenario would arise in cases where there is an unreachable client with an established outbound sequence that the server side RM service wishes to initiate an inbound sequence to. In this case it can place a MessagePending header in a response to the client to trigger it to send a MakeConnection request. This MessagePending header should include the optional AcksTo EPR so that the subsequent MakeConnection request to flow a CreateSequence can be correlated to the correct unreachable client. The server side RMS can then use the unique information in the AcksTo EPR it provided to relate the sequence to the Sequence Traffic and Lifecycle messages it needs to send to the specific unreachable RMD.

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/pdf00000.pdf

 

Marc G: by emplying ref parms in the acks to EPR, we get around some of the the opaqueness issues.

 

Dug D: this proposal is doing more than we need to.  It is re-opening a resolved issue.

 

Tom: perhaps our original solution was more general than it had to be.  I am not opposed to resolving this new pr issue from addressing by backing away from the more general make connection mechanism to one which is tailored just to WSRM Sequences.

 

Anish: the make connection has no syntax, how does RMS which gets the make connection figure out who it is.

 

Marc G: in the description of the Acks to epr it is discussed.

 

Anish: what is it in the make connection to identify the initiator, if it is behind a firewall.

 

Marc G: this is no different than the existing mechanism to flow back a create Sequence on a back channel.

 

Anish: Make connection have an ID which means something to the service.  This uniquely identifies something.

 

Marc G: you can identify uniquely once you have the sequence established.

 

Discussion ensued

 

Marc G: how does receiver know it has a create sequence message queued for that anonymous destination, since it has not seen that UUID before.

 

Anish: This proposal moves away from using UUID, and uses refP, which I am not severely concerned with.  However, it takes away the ability to implement a simple destination to receive acks centrally.  This is an overload of the meaning of ACKS To.  It might be better to introduce a new EPR element.

 

Paul F: RE reopening a new issue.  Give this is a potentially valid solution, which takes away a PR issue, it is within scope of the TC resolutions.

 

Paul F: re Anish concern, there is text in 4.8 (message pending ACKs to) .

 

Dug D: the guy receiving the messages might not have been the original guy who sent the ACK to EPR.

 

Dug D: I understand this proposal addresses rm scenarios, however it does not handle all the scenarios which we discussed in WSRX.  I do not know how this would work with a sequence spanning multiple endpoints.

 

Marc G: The use cases you used can be met by this new mechanism.

 

Dug D: If all you have is a sequence ID, you have no way to know which client is doing the polling.  RM information is different than application level messages.

 

Stephan: The core issue is to identify an unreachable client.  Marc G proposal meets these scenarios, either directly or with composition with other mechanism.  It would help to understand Marc G proposal, by showing how it meets various scenarios.

 

Tom: however some of these discussions were at a Task Force level, and were not surfaced to the entire TC.

 

Dug: this proposal is trying to change existing agreed solutions.

 

Jonathan: your multiple clients on sequence need to share the UUID that identifies this as a client.

 

Dug: No, each client has to know their own ID.  The RM sequence ID may be shared.

 

Marc G: There is no model in the spec which identifies these scenarios from Dug.  I do not know from the spec which problems must be solved.  I am supposed to address undocumented scenarios.

 

Tom: I would like Dug to bring up the scenarios that he states will not work with the simplified proposal.  This would help the TC members who were not part of the Task Force decide the proper way to resolve this solution.

 

Anish: the scenario which requires the ID was discussed in the TC.

 

7         Any other business

 

Next call Nov 2.

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]