Prelim Minutes WSRM TC
Conference Call – September 30, 2003
The meeting of the WSRM TC took place by teleconference
Tuesday August 30, 2003, from 5:30 to 7:30 PM Eastern Daylight Time
(UTC - 4)
The call in details were as follows :
Dial-in numbers:
----------------
Toll Free - : 1-800-605-5167
International - : 1-719-457-0339
Passcode: 732072
0
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call – Sept 30, 2003
1 Roll Call
2 Minutes Discussion
2.1 Appointment of Minute Taker
2.2 Approval of previous meeting minutes
3 Discussion of Issues:
4 Discussion of Interop Demo at XML show, and status of Subgroup
Discussed interop demo before issues.
1
Roll
Call
|
First Name
|
Last Name
|
Email
|
Role
|
Company
|
|
Joseph
|
Chiusano
|
chiusano_joseph@bah.com
|
Member
|
Booz Allen Hamilton
|
|
Pramila
|
Mullan
|
pramila.mullan@rd.francetelecom.com
|
Member
|
France Telecom
|
|
J
|
Durand
|
jdurand@fsw.fujitsu.com
|
Member
|
Fujitsu
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC Chair
|
Fujitsu
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Member
|
Hitachi
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Member
|
Hitachi
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
|
John
|
Fuller
|
jfuller@wernervas.com
|
Observer
|
Individual
|
|
Dock
|
Allen
|
Dock@mitre.org
|
Member
|
Mitre Corporation
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
Member
|
NEC Corporation
|
|
Alan
|
Weissberger
|
ajwdct@technologist.com
|
Member
|
NEC Corporation
|
|
Magdolna
|
Gerendai
|
magdolna.gerendai@nokia.com
|
Member
|
Nokia
|
|
Szabolcs
|
Payrits
|
Szabolcs.Payrits@nokia.com
|
Secretary
|
Nokia
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
|
Sumit
|
Kupta
|
|
Observer
|
Oracle
|
|
jeff
|
mischkinsky
|
jeff.mischkinsky@oracle.com
|
Member
|
Oracle
|
|
Pete
|
Peterson
|
|
Observer
|
Oracle
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
Secretary
|
SAP
|
|
Pete
|
Wenzel
|
pete@seebeyond.com
|
Member
|
SeeBeyond
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Secretary
|
Sun Microsystems
|
|
Chi-Yuen
|
Ng
|
cyng@csis.hku.hk
|
Member
|
University of Hong Kong
|
|
Scott
|
Werden
|
scottw@wrq.com
|
Secretary
|
WRQ, Inc.
|
Meeting was quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt
will take minutes.
Mark Goodner agreed to take issue resolutions.
2.2 Approval
of previous meeting minutes
Boston f2f minutes:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3640/MinutesWSRMTC-916.htm
Sunil moved to accept the minutes. Iwasa seconded.
No opposition, minutes approved.
3
Discussion
of Feasibility Demo Activities
3.1 Proposed
charter
Mail from Bob Freund:
Draft
Charter, WS-RM Interoperability Demonstration Sub-Group
Purpose
The
WS-RM Interoperability Demonstration Sub-Group is designed to:
1.
Provide a forum for implementers of the WS-RM
specification, to meet and demonstrate interoperability across implementations.
2.
Provide test tool standards, specifications, and test
case definitions for participants engaged in interoperability demonstrations of
WS-RM implementations.
3.
Provide specific feedback to the TC regarding WS-RM
implementation experience and specification issues as may be discovered.
4.
Provide proof of concept and demonstration capability
for the promotion of this specification.
Deliverables
The
following are expected to represent deliverables associated with this
sub-group:
Demonstration
Scenario Collection
This is a collection of demonstration scenarios and specifications
designed to exercise one or a combination of protocol features. The collection will be revised and refined
from time to time
Demonstration
Post-Mortem
This report documents the collective experience of the implementers
engaged in a interoperability demonstration. Topics that will be covered include any
specification inconsistencies or misleading wording that presented difficulties
to the implementers. Issues will be
related to the reference specification utilized in the interoperability
demonstration and commentary will note issues that although present in the
reference specification appear to be corrected in some subsequent committee
draft specification superceding the reference specification.
Demonstration
Tools
Although the mechanism to be used for the distribution of
contributed tools has yet to be established, it is the intent of the sub-group
to generate, revise, and refine a set of such Demonstration Tools from time to
time and to distribute those tools to participant of Interoperability
Demonstrations
Alan moved to approve
the charter of the new group. Jeff M
seconded.
Jacques stated Sub
committees need a statement of purpose.
They do not really need charters, and it does not need Oasis approval.
Doug B asked that he
would like time to read this email. He
asked what the deliverables are.
The tools delivered
would be things like the trouble maker.
They would be made
available to other participants by those that make them available. The way to do the distribution would have to
be resolved by this group.
Jacques stated the
subcommittee deliverables are only to the TC.
Any other deliverables would have to be done by the TC.
These SC deliverables
are to the TC members, not to the outside world.
Jacques stated he liked
this as a statement of purpose for the TC.
Change the title to
Statement of purpose.
Nobody opposed to title
change.
No opposition,
subcommittee has been formed.
Check how mailing list
is set up.
Bob F will check to set
up what is needed in Kavi.
Bob F and Jacques were
nominated as co-chairs.
Nobody opposed, Jacques
and Bob are co chairs.
3.2 Demo
at XML show
Demo has to be a
committee draft.
Jamie Clark stated there
are three criteria for the XML 2003 conference:
- List of participants, three or more
- Agree to scenarios well in advance of demo
- Normally a 1.0 CD is what they expect to
see at these demos.
Bob Freund talked to
Jamie on this, who stated a dot level of CD is all that is required.
Jeff M: demo is W3c and
Oasis. Will the other group be allowed
to demo their stuff?
Jamie stated Oasis has
been subcontracted to organize this demo.
That is why they want CD status to level playing field.
Tom stated we could
have a 0.8 draft out of the face to face meeting. This is on our roadmap already.
Doug B stated they are
not really rules.
Bob Freund stated there
could be moving parts in the spec, however the demo should be based on stable agreements. Part of the reason for the demo is promotion
of standards activities. They want a
committee jure specification.
By the time the demo
happens, we would need at least a 0.8 committee draft. They would like to get to 1.0.
The
main open things polling/status and request/response.
Bob F stated that they
should stay clear of poll/status and request/response in the core spec.
Jacques stated that
there are some features which need to be cleared up, with the agreed
features. However we could have an early
CD for ballot, which is not complete.
Tom Rutt
stated that this puts pressure on us to take a vote, before the demonstration.
Alan stated we should
focus at the f2f on getting the current features stabilized.
We need volunteers to
work on improving the text in the documents.
4
Discussion
of Issues:
Latest issues list at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/3529/wsrm-reqm-issues.html
4.1 Rel yy – Use of Sequence Number
outside of Ordered Delivery
Mail from Jacques:
I
would like to summarize what I believe the "amended RelYY"
proposal is
currently, so as to make progress on submitting it, as it is
one of these features
that is on the critical path of implementors...
-
There will be three ways to "sequence" (or not) messages within a
group:
(1)
when ordering is required:
GroupId + SequenceNumber(with
status) + MessageOrder
(empty subelement of requestheader
as all the others are)
(2)
when ordering is not required, but for other benefits
(here the possibility of fast/space efficient duplicate
check)
GroupId + SequenceNumber(?
optionally with status)
(3)
when ordering is not required, but no other use of
sequences is desired,
there will be only one message per group, identified by
group Id:
GroupId (and
no SequenceNumber element)
Invariant:
-
each GroupId is globally
unique.
-
in both cases (1) and (2) SequenceNumber
values must be unique within a group,
and generated as a contiguous sequence (modulo...)
-
in both cases (1) and (2), the status attribute on SequenceNumber is allowed values
"Start"
"Continue" "End" according to similar rules. (does Doug agree here?)
NOTE1:
Sunil did not reintroduce MessageOrder in his latest schema
yet.
I
personally favor this over a lower level way to signal the Ordering feature:
it is more consistent with what we do with AckRequested and DuplicateElimination.
NOTE2:
Along the line of what are the rules in using combinations of header elements:
Since
the Ordering feature applies to an entire group, and that it is no longer
signaled by the presence of SequenceNumber
under this proposal,
should we consider
significant the "MessageOrder" (or whatever
signal)
in the first message only of the group?
(or few first ones in case we need to handle the special case
of the first one missing / delayed)
otherwise, if we keep a per-message semantics, having a mix
of messages with/without such signal
should NOT be allowed in a group. And the question extends
to AckRequested and DuplicateElimination,
since these two features are required with Ordering.
Jacques
Doug B stated that
ordering and providing a sequence number are not completely orthogonal. When you do ordering ,
the sequence number is required..
This requirement is
just text.
Doug B stated he would
prefer the requirement is enforced in the schema.
Group ID is required,
sequence number is optional.
Reply to must only
exist when pattern in callback. Sunil
stated we have already have these kind of cross requirements.
Sunil stated he prefers
to put reliability features requested in RequestHeader.
It is a clear abstraction.
Tom asked why the sequenceNumber could not be mandatory.
Sunil stated how we
would distinguish sequence numbers which are independent from ordered
messages.
There is an overhead
cost in maintaining groups. In such
cases you could just use group ID.
The other alternative
is adding start and end as a status.
This is a single identity scheme, identity plus group number.
Sunil: Why do we need
to send it if it is not needed. Sending
a value that is ignored is not good. The
only advantage is to help the schema.
Sunil does not want the
value to signal any special features.
Remove after in group
ID. Group ID is mandatory. This is an orthogonal issue.
New Spec issue on
semantics RemoveAfter attribute of Group ID.
Payrits
had question about the text for grouping of acknowledgement. Jacques clarified that this is not part of
this motion.
There are open Spec Issue
on multiple acknowledgements mechanisms, Rel 74 and
75.
Sunil moved to accept
the proposal of Jacques, Jacques seconded.
No opposition motion
passed.
Instruct editors to updated the text and the schema as well.
Sunil agreed to get a
proposal for the semantics of RemoveAfter attribute, Jacques will
participate.
4.2 Multpiple acks proposal.
Payrits
stated that ack should be legally binding proof that
message is sent. Optimizations can be
used.
Bob F asked if he was
talking about non-repudiation.
Parits
stated we should keep it in mind.
Bob F also asked about
message mining.
Jeff M stated we should
stay away from legally binding areas.
Iwasa
had a proposal to change the syntax of the ack
response.
Iwasa
volunteered, Payrits agreed to participate in the
proposal.
The will send a
proposal to the group before the next meeting.
4.3 Schema
comments
Payrits
asked why the Any is there.
Scott stated this is
for extensibility.
Payrits
stated there are problems with Any, but he can accept
if the group is happy.
Name
of the response vs acknowledgments.
Finalizing names will
be delayed to the face to face meeting.
Sunil stated to send
him mail on any problems.
Sunil had some
editorial concerns.
4.4 Poll
Mechanisms
The main issue is
whether the Poll should be a wsdl operation bound to
the body of the message.
Doug B stated the wsdl allows a definition to be pointed at by multiple
endpoints.
Tom Rutt
asked about whether the wsdl operatio
for poll would be in the same port type with the data. It could be in a separate wsdl
port type, bound to a different url.
There are problems with
binding two services to same URL.
Given a WSDL approach
for poll, Should we allow both scenario:
1)
the Poll operation is combined in a port type with the
application operations:
2)
The poll operation is in a separate port type which is
bound to a separate url from
the application port type.
Sunil stated that the
combination of operations is difficult since there is no port type inheritance.
The second scenario
requires exposure of the RMP as a separate service.
Sunil stated that WSDL
1.2 has an interface attribute, all ports on url have the same value.
Sunil stated
reliability is not a service by itself, once it has a wsdl
it is exposed as a service. It is a
quality of service.
John Fuller stated that
there may be other headers to use outside of reliability. We could use these existing services instead
of polling if feasible. This is status
of an individual message.
The wsdl
approach seems to make one have to describe the poll in the wsdl.
Doug B stated that we
could define the wsdl once, which is referred to by
other wsdl documents.
Doug is not certain why
we are not talking about the protocol being described. When you are doing the status check can you
reuse MEP from soap or do we have to reinvent them.
Doug stated that the
protocol should remain silent on whether the poll is sent as its own reliable
message.
To put in the body, we
would have to deal with the binding issues (which might be
Covered
by wsdl annotations).
John Fuller asked if
the RMP is directly addressed as URL.
The service endpoint
has both the RMP processing and the Body processing.
Option 1 ( combined in port type) might be useful to turn on or off,
for specific endpoints. If it is global
option 2 might be better.
Sunil stated option 1
is a combinatorial nightmare.
Mark G stated he liked
option 2.
Sunil stated he prefers
the poll be in the header.
WSDL annotation issue
is orthogonal.issue, since it is optional.
Sunil stated that the
fault issues from Doug regarding a header can be dealt with.
Sunil stated there is a
piggybacking issue which is made easier using a header. The body is meant for application
payload. Once we open this up, the RMP
has to open the body, and is swept into dealing with all the issues we have
brought up on the WSDL.
Sunil stated he does
not see the poll as a different body.
For the callback we are sending headers, and sending a poll as a header
in the reverse direction is symmetric.
Sunil stated that
dealing with headers is that the endpoint can do this in the wsdl (bind the header elements to the soap header) but they
do not have to do that.
Doug B stated that
other soap extension specs have defined both headers to add annotations or
metadata, and also specify protocol elements as soap body elements, to find
info about tokens in the headers.
Example it to add SAML
token to message, receiver has option to use SAML protocol to validate that
token.
Doug B stated that the
headers would require additional faults.
They have centralized
WSDL document to describe the protocol.
Payrits
stated the problem is not header vs body, the question is to reuse soap MEP or define our own.
Payrits
stated that if we do headers, we have to redo all the work that was done by
Soap and WSDL.
Payrits
stated that if it an operation, we can either use soap or do our own. If the poll is an operation this can use the
soap MEP.
Peter from Oracle: If
it involves the wsdl it affects deploying the web
services.
Even if you import a
central wsdl document, you would still have to
include it in a deployment scenario.
Peter stated the time
to live scenarios may make it hard to implement as a separate service endpoint.
The reliable handler is
not easy to implement as going with the wsdl for the
poll.
Peter stated there are
already rules in soap for header faults processing.
Payrits
stated the only rules for header faults is that they
must occur back in the return message header.
Practical question how
do you do deal with the deployment of an orthogonal WSDL for the polling
operation
Peter: How is the URL
from orthogonal RMP service communicated to the Client of the original request.
Jacques: Scenario 1
seems unthinkable as a requirement for a business app
If we are going to use wsdl, we are most likely in scenario 2 world.
Jacques stated we are
opening a can of worms using the wsdl level solution.
Jacques stated the
conservative approach is to use the header based approach.
Jacques would like to
see the use case for polling.
Continue on email. Sunil will clarify the use case to justify
the polling.
4.5 Rel – Reliable Request/Response Proposals
Mail from Jacques:
Here
is a tentative summary of the reliable request-response proposal I have sent
a couple of weeks ago ( co-signed Marc G., Sunil K., Payrits S., Jacques D.)
Because
it is a big chunk, we 'd like to get feedback first on
the overall direction of the proposal
(summarized below).
Then
there are still some details left to be discussed.
Jacques
------------------------------------------------------------------------------------------------------------------------------------------------
General
recommendation on what WS-R should cover regarding Guaranteed
delivery (GD)
of messages involved in a WSDL request-response :
1-
Only the following GD cases should be supported by this version of WS-R:
-
GD of request + GD of response (Variant 1)
-
GD of request + no GD of response (Variant 2)
The
following case should be excluded (not covered by this specification) (see
Option 3.1.1):
-
no GD of request + GD of response (Variant 3)
2-
The recommendation for GD of request-response, is that its use of Ack and resend procedures
will differ from one-way ops in the following way:
-
request-response is treated as a single transaction
(will be entirely replayed, if either leg failed)
-
in case of Variant 1, in case the response is not
acknowledged, the request-response should not be replayed.
Instead,
the Ack should be resent (see Proposal 1.2)
(depending on firewall restrictions on either side,
either using RMP-level polling to get the Ack, or a resending mechanism for Acks.)(to resolve!)
3-
Given the impact of supporting GD request-response on SOAP implementations (seee Appendix A),
recommendation is that it should belong to a higher
conformance profile for WS-R.
i.e. some implementations that cover only the reliability of
one-way operations
should still be considered as conforming at some level to
WS-R.
There was no time to discuss this,
it will be discussed on the next call.
People are requested to discuss this proposal on the email.
5
Future meetings
France Telecom Research will host the next FGF
October
28-30, 2003, in South San Francisco.
Agreed to start start at 9 on
Tuesday and go to 5 every day.
Have all three days for meetings.
Meeting in South San Francisco 801 gateway blvd.
Pramilla agreed to send out the
notice, with all the details.