[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 1/25 wsrm TC teleconf
The prelim minutes are attached,. ] Please post requried corrections before the end of this week. Tom Rutt WSRM TC Chair. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Preliminary Minutes of WSRM TC
Conference Call – The meeting of the WSRM TC took place by teleconference 1
Draft
Agenda:
1 Draft Agenda to WSRM TC Conference Call 2 Roll Call 3 Minutes Discussion 3.1 Appointment of Minute Taker 3.2 Approval of previous meeting minutes – 4 Action Item Status Review 5 Status of WS-Reliability Specification 6 Status of Interop SC activities 7 Next Step Documentation 7.1 Editorial Clarifications and Errata 7.2 Implementation Guidelines 7.2 Future Enhancement Requests 7.3 Composability with other WS-Specs 8 Discussion of Future Meetings 2
Roll
Call
Attendance:
Meeting is quorate. 3
Minutes
Discussion
Tom Rutt will take minutes. 3.1 Approval of previous meeting minutesThe minutes of the 12/14 meeting are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/10919/MinutesWSRMTC121404.htm The minutes of the 01/11 meeting are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/11169/MinutesWSRMTC011105.htm Abbie Moved to approve the 12/14 minutes, Jacques seconded. No opposition minutes approved Alan moved to approve the 01/11 minutes, Jacques seconded. No opposition, minutes approvesd 4 Status of Action Items4.1 Action 090704-1 (Tom) PendingAction: Tom will try to find, from previous minutes, a list of features we have put off for future versions and will post it to the list for discussion. 4.2 Action 113004-2 (Bob F and Interop SC) CompletedAction: Bob will work with the Interop SC to have them recast a next version of their feedback document using the following three categories (and taking into account the discussion at the F2F). 4.3 Action 121404-2 (Jeff M and Interop SC) PendingAction: Jeff M will provide examples of soap header dumps with both ws-reliability and ws-addressing headers in use, as in the interop demo. 4.4 Action 011105-1 (Tom Rutt) CompletedAction: Tom will send an email soliciting comments on ws/reliability/ws-security composition document to the group.. 4.5 Action 011105-2 (Tom Rutt) CompletedAction: Tom to post a pdf version of the ws-reliability/WS-Security composition document after the meeting 5 Status of WS-Reliability SpecificationOASIS staff asked Tom Rutt to edit the wsrm TC group notes to remove the links from the OASIS TC Summary Page. Tom updated the public and member web site pages for the TC to have a single announcement, which refers by URL to spec and schema at the proper location on the OASIS web site. http://docs.oasis-open.org/wsrm/2004/06/WS-Reliability-CD1.086.pdf http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd http://docs.oasis-open.org/wsrm/2004/06/reference-1.1.xsd http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd The spec itself still shows status a CD. Action: Tom will investigate how to change the status of printed document. 6 Status of Interop SC activitiesQuestions have been asked about public sites for testing spec. There was discussion on the email list pertaining to the public domain implementation: 79811 donation to Apache ??
Mark Hansen 80120 Re: [wsrm] donation to
Apache ?? Kazunori Iwasa Iwasa stated he has no new information. He has given this idea to the development team of the open source implementation. He will relay any feedback to this TC. 7 Next Step DocumentationTom Rutt obtained the text presented at the Face to Face, and edited the document to reflect discussions at that meeting. The result was posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/11078/InteropSCFeedback.pdf There is a need for clarification on some of the implementation concerns expressed in the posted document. The following excerpt is from the paper: Req/Resp MEP Failure. Consider the case of a request/response MEP. A
client application makes a Web Service call in a synchronous way, and expects
to get the results back (the business response data) on the same connection.
This initial call goes through the sender RMP which would persist
the message in its own database. The call for some reason does not succeed
(e.g., the message is lost in the network). Without special mechanisms, the
client application could be notified of the failure because a runtime exception
(such as Time Out) is propagated up to the initial caller (which is the client
application). At a later time, the sender RMP initiates the resend operation
because the message it persisted in its database was not acknowledged. Let’s
say the resending call succeeds this time, and the call is received by the Web
Service endpoint, and a business response is propagated back to the sender RMP.
With the above scenario, the sender RMP needs to know what to do with the
business response. Mechanisms are needed to let the client
application know about ultimate failure (not initial failure), while enabling
the sender RMP to give the business response to the client application when the
operation invocation eventually succeeds? Another fact to take into consideration is that
the sender RMP may not be aware that a req/resp MEP
is being used, because the sender RMP is deployed simply as a handler (an
interceptor), and is not the initial caller (which is the client application). Tom: the last paragraph might be the crux. Can you implement the request response RMP without the sending MEP knowing that it is a request response rmp. Jacques: the concern might be regarding the current soap stacks which implementers use. The fault recovery models of these stacks might cause such problems. Doug: I do not understand the background issue here. In our spec we have not stated you taking an existing soap node, adding handlers to get a working rmp. All this description is saying is that you do not want the application to call the pre existing soap node infrastructure, instead it has to invoke an intermediate layer. Jacques: it is worth discussing this further to aid implementers. Bob F: Doug had a good point there. The origin was from people working quickly to reach an interop demo. Some of their comments are colored by the tools which were at their disposal. We should not emphasize problems which would not exist in a clean implementation. Tom suggested taking out the section and posting a revision on the web site. Jacques: we should clarify this concern that it is a problem with one implementation approach. We will try to extract what is the real concern and will post this as text for discussion in a more general way. Tom: I hear no objection to taking out the section in a revision to be posted soon. People should send comments on the posted document for discussion at the next meeting. After these clarifications, the document needs to be separated into three separate documents corresponding to the following categories. 7.1 Editorial Clarifications and ErrataClarifications, editorial nits, interpretations of the actual specification, which should be posted for others to see 7.2 Implementation Guidelines / Application NotesThings to help implementers, which, would typically be specific to application environments. 7.3 Future Enhancement RequestsProposed changes for future versions which would ease implementation or enhance protocol capabilities. 8 Composability with other WS-SpecsJacques posted a contribution for discussion at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/10281/WS-R_Composability_status.txt From 1/11 minutes: Jacques will act as editor, but will await input from others. Solicit comments on the original paper for discussion at next meeting Jan 11. After the 1/11 meeting, Jacques posted the following update to the composibility paper: Jacques clarified that this was only an editorial update. Alan W posted the translation of a Japanese document regarding composition of WS-reliability with WS-Security at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/10926/WS-R%20WS-Security-20050107.doc After the 1/11 meeting, Tom Rutt posted a pdf version of the ws-security composition document at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/10944/WS-R%20WS-Security-Draft.pdf
Tom Rutt send an email soliciting comments on both of the above documents: Soliciation for Member
Comments Tom Rutt The following response was posted: Kicking off the discussion of the WS-R and WS-S Composability document Alan Weissberger 14 Jan 2005 Alan stated that this mail was posted to spur further discussion. Just before the meeting, Alan posted the following email: Progression Plan
for WS-R Composability document(s) Alan Weissberger 25 Jan
2005 All Jacques and I
propose a 2 phase approach to Composability of WS-R
with other WS stds/specs: Part I: High level "Compsability
Concepts" document, which describes: composability
model(s), baseline assumptions for SOAP HDR processing entities, composability requirements/ functionality, implications,
etc. Some examples and illustrations of
ways to compose will be provided.
Implementation details will be contained in part II. This document is
targeted at a wide audience, which includes WS Architects, WS implementors that are using modular WS-R middleware (open
source or otherwise), and technical decision makers (that probably have not
participated in the WS-RM TC and are not intimately familiar with the WS-R
standard). Part II. Composability Case
Studies for WS-R and WS-Security Detailed model
and implementation guide for selected methods to compose WS-R and WS-Security,
based on high level principles enumerated in Part This document is
aimed at WS implementors that are working with WS-R
and WS-Security middleware (open source or otherwise). Sections of the translated "WS-R and
WS-Security Composability" document will be
included in this Case Studies document, as appropriate. Note that the
latter document assumes that the WS-R entity has intimate knowledge of the
WS-Security entity such that they are implemented in the same SOAP HDR
processing node. Other models, such as a
pipelined SOAP HDR processing in different nodes may also be considered as a
separate case of composability. --------------------------------------------------------------------------------------------------------------------- Here are a few
points to consider for the Part I Composability
Concepts document: -SOAP HDR
processing entities are independent of each other and might be implemented in
different nodes (or optionally, in the same node). That is, both integrated WS-R and WS-S
processing as well as pipelining of the SOAP HDR processing entities are
permitted. However, the modularity of
SOAP HDR processing entities should always be assumed, even if extra HDR
processing is the result. -Routing of WS-R
messages should not effect composability
and the routing should be independent of the SOAP message contents. That is, composability
should not be constrained by any routing scheme. -There are
various ways to order the WS-R and WS-S entities. For example, there may be cases where we
have: WS-R then WS-S, WS-S then WS-R, WS-S then WS-R then another WS-S (say for
encryption or authentication purposes).
In cases where there is no WS-S header, the WS-R entity will bypass the
WS-S entity and pass on the received SOAP message body to the WS application
entity. -Encryption of
only the SOAP message body, or the SOAP headers + message body should be
considered as separate cases. -Redundant
processing of duplicate SOAP messages is permitted. In some cases, redundant processing is a
function of how the entities are ordered and that they are independent of each
other. --------------------------------------------------------------------------------------- Hopefully, we can
get some email discussion going on this before the next WSRM TC call in early
Feb 05. Best... alan Alan Weissberger Alan gave a review of the email contribution:
Jacques added some points. The current ws-security/ws-reliability contribution from the Japanese companies, is addressing some requirements, however it is a assuming some restrictions in the architecture. When new implementations have freedom to combine these two standards in a tighter manner, they may have a higher level of efficiency (e.g., do not repeat things unnecessarily for duplicates). There are multiple ways to compose ws security and ws reliability. The first part of the document will talk about these different implementation levels of composability. Alan: we can look at two types of model: Integrated model (entities are designed to work together) Modular model (entities have no knowledge of other’s existence) Tom: So Jacques contribution should be directed at part 1 document. Abbie expressed an interest. <abbieb@nortelnetworks.com> Task force Jacques, Alan, Abbie,. and Bob F. Alan: we propose the preceeding contributions be directed at these two documents. The task force will determine what goes into the second document. Bob F: are we facing a fundamental issue with composability? Alan:the translated document describes one particular way to compose ws-security and ws-reliability. Bob F: Do you see any composability issues, or are you just discussing implementation guidelines. Alan: we do not see any problems with the spec in the area of composability Tom: do we need a document on defects in the specifications with regard to composability. Alan: we may need such a document in the future, but have not found such problems yet. Bob F asked to be added to the composability task force. He stated he as interested in aligning it with the basic security profile. Jacques: we would like to ensure that different processing models do not result in any difficulties. Doug B: We are talking about an implementation guide, but now we are talking about delving deeply into that part. We had discussed in the past the need for general implementation guidelines. Here we are talking about specific guidelines about ws security and ws –reliability aspects. We need to also work on the general implementation guidlelines, using feedback from interop SC. Alan: I think that we need consensus in the group on what is needed for ws- security and ws-reliability composability. This is a high priority. Tom: we also have to pursue and progress the other documentation. Doug B: I was just concerned about the earlier discussion on the need for multiple methods of composition. Jacques: Some of the work we are doing might go into an implementation guidelines document. I would like an abstract processing model with multiple soap headers. Going beyond this might also be put into a specific implementation guidelines. Tom: there is an existing call to have members look at the translated document and add scenarious they would like to see in the guide. 1 Discussion of Future Meetingswhen is the next Face to face? Third or fourth weeks March are both candidates. Get a better idea at the next meeting. Tom: do we want to add a short meeting at the OASIS symposium, wed 27, thur 28. Alan we could spend a ˝ day on composability work. Tom: we could get a day in. Jacques will check if we can get a free room; Pete : I do not believe there will be a charge. Talking about a Two day meeting in either case. Bob: I suggest you just ask for two days and see what we get. Action: Tom and Jacques will see if they can get two days for our TC at the Symposium. At Jan 11 meeting, we agreed to continue schedule of 90 minute teleconferences every two weeks, from Jan 11. Jan 11, Jan 25, Feb 8, Feb 22, Tom: I will extend the existing two week sequence until the end of March.. 2 New business:Bob: I would like to introduce the concept of progressing this specification to ISO for their purposes. It is potentially feasible for us. Tom: OASIS has been granted PAS (Publically Available Spec) Submitter status by ISO/IEC JTC1, and can now.submit specifications to be voted on as a fast track ISO standards. Bob: people should discuss whether we should do this for ws-reliability on the list, and it should be put on the agenda for next meeting. Tom: action – put out a summary of what PAS process is. Bob F moved to adjourn, Mark Peel seconded. Meeting
adjourned at |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]