Preliminary Minutes of WSRM TC
Conference Call – Mar 30, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday, March 30 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
0
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call
1 Roll Call
2 Minutes Discussion
2.1 Appointment of Minute Taker
2.2 Approval of previous meeting minutes –
3 Discussions of Issues and editorial comments
4 Discussion of FAQ for
WS-Reliability
5 Discussion of New Orleans F2F
Agenda approved
1
Roll
Call
Attendance:
|
First Name
|
Last Name
|
Email
|
Role
|
Company
|
Voting Level
|
|
Jacques
|
Durand
|
jdurand@us.fujitsu.com
|
Member
|
Fujitsu
|
1
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
1
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC Chair
|
Fujitsu
|
1
|
|
Jishnu
|
Mukerji
|
jishnu@hp.com
|
Member
|
Hewlett-Packard
|
1
|
|
Robert
|
Freund
|
bob.freund@hitachisoftware.com
|
Member
|
Hitachi
|
1
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Member
|
Hitachi
|
1
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
1
|
|
John
|
Fuller
|
jfuller@wernervas.com
|
Observer
|
Individual
|
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
Member
|
NEC Corporation
|
1
|
|
Mark
|
Peel
|
mpeel@novell.com
|
Member
|
Novell
|
1
|
|
Anish
|
Karmarkar
|
Anish.Karmarkar@oracle.com
|
Member
|
Oracle
|
1
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
1
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
Secretary
|
SAP
|
1
|
|
Pete
|
Wenzel
|
pete@seebeyond.com
|
Member
|
SeeBeyond
|
1
|
|
Doug
|
Bunting
|
doug.bunting@Sun.com
|
Secretary
|
Sun Microsystems
|
1
|
|
Tony
|
Graham
|
Tony.Graham@Sun.com
|
Member
|
Sun Microsystems
|
1
|
|
Chi-Yuen
|
Ng
|
cyng@csis.hku.hk
|
Member
|
University of Hong Kong
|
1
|
Meeting
is quorate.
2
Minutes
Discussion
2.1 Appointment of Minute Taker
Tom Rutt will take
minutes.
Minutes will serve to record issue resolutions.
2.2 Approval of previous meeting minutes
Jisnu moved to accept the Mar 23 minutes posted on the server by Tom. Iwasa seconded.
It was pointed out that the minutes posted by Tom, included a proposed change by Alan.
Bob moved to amend to approve the original posted preliminary minutes. Doug B seconded.
No opposition to amendment.,
No opposition, 3/23 posted minutes approved.
The approved minutes were posted by Tom at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6167/MinutesWSRMTC032304-Approved.htm
The erroneously posted minutes were deleted by
Tom.
0
Discussion
of Issues and editorial Comments
Jacques and Sunil task force is still open.
0.1 Sunil Homework
· Chapter 5 review comments based on WD 0.992
From Sunil Kunisetty <sunil.kunisetty@oracle.com>
on 30 Mar 2004 19:51:00 -0000
From Email above:
Technical (need discussion on the call):
The only
technical issue I see here is wrt to Group Closing.
On lines 1096 & 1098,
we say that if a
message is received after the closing of a group, with the same
group ID as the closed group, it MAY be considered by the
Receiver as belonging
to a new group. Infact on line
1096 it says "would be handled as a new group ..".
I see one
issue with this. What if the old group is closed but not removed (i.e.
the state is still in the persistence store because the maxGroupExpiryTime
didn't expire or so) and new message arrives with the same
group Id. In
that cases there will be 2 groups with the same groupId which breaks the
groupId uniqueness rule.
So we
have to say that the new message is considered as a new group only
if the old group is removed from both Sender and Receiver
RMP persistence
stores.
Jacques: The group is closed, but the state is
still there. There is no obligation to
treat as part of this group. The rmp can do other things.
Tom: This is a reaction to an error condition
from the sender RMP. We should not have
to send a fault in the case of the sender sending data on a terminated group.
Tom : limit the
statement to the Receiver RMP.
Jacques: I agree it should be allowed for the
receiver to drop these messages.
Jacques: I would not make it mandatory to send
back an error.
Tom: why do we need to make statements about
this case.
Tom: we could have a case where the user sends a
later message in the group long after its last message, and they did not use
max expiry time nor max idle duration. The group could be prematurely
terminated. This is the case where it
could be treated as a new group.
This is a general problem about lack of synch of
the knowledge of group state between sender and receiver.
Talk more on email about how to fix this.
Jacques, and Sunil, and Tom will work on the
proper wording as a task force. Due by next meeting.
Editorial:
1) While
mostly we use the words Sender or Receiver RMP, there are occurrences of Sending and
Receiving RMP terms. We need to be consistent.
Agreed to change sending to sender and receiving
to receiver as a qualification of RMP.
Jacques: the root of the terminology sender and
receiver go with that everywhere.
2) The lines 1122-1125 needs
rewording.
Suggested wordings are:
"These two items can be considered as Group Termination parameters
that
control the persistence of the group data. The corresponding
message
header attributes are groupExpiryTime
and groupMaxIdleDuration respectively".
Agreement with this rewording.
3) Line
1135: We don't have InvalidGroupParameter fault. It
should be replaced with
InvalidMessageParameters fault.
No disagreement.
Agreed to this change.
4) Line
1136: Uppercase MUST
Agreed
5) Line
1148: Lowercase 'c' in criteria
Agreed
6) Line
1181: Add the following at the end of the sentence.
The group had either groupExpiryTime or GroupMaxIdleDuration specified, but not both.
Agreed
7) Line
1270: Reword as following:
Guaranteed Delivery will be most commonly used for One-way messages as the Sender does not
know the status of the message delivery otherwise.
Jacques: should say “request message for wsdl one-way operation”
Agreed with Jacques proposed change..
8) Line
1277: Uppercase P in Poll
Agreed
9) Line
1278: Replace is with has as in "for a message it has to inquire".
Agreed
10) Line 1279: Replace acknowledgement with RM
Reply
Agreed
11) Line 1280: Replace acknowledgements with RM
Replies
Agreed
-Sunil
0.2 Other Issues
Sunil
sent out the following comments on Section 6 of CD .992
All the comments are editorial:
1) Line 1329: Response pattern MUST not have replyTo attribute.
Agreed to remove from example
2) Line 1371, 1375, 1447 should be reworded as:
"The HTTP response to the (1) should have only HTTP Headers and no HTTP body contents....".
Leave open for proper wording from HTTP standard. Anish will work on the proper wording, HTTP calls it an entity body.
Anish: HTTP uses message body or entity body.
Anish: agreed to replace “no contents” with “no HTTP message body” in lines 1371, 1375 and 1447.
3) Line 1375: "no content" should be replaced with "should have only HTTP Header and no body contents." Also for 1447
4) Line 1439: We need to have 2 sub-sections: one for the sync. Poll response case and other for async. Poll response call. Figure 9 can be used for the former. For the latter, line (4) should be shown as HTTP request. The example for Async. Poll request will take a replyTo attribute.
Two subsections for 6.3. Sunil took action to do this proposal.
-Sunil
1
Frequently Asked Questions:
· Initial
list of WSRM FAQs
From Tom Rutt <tom@coastin.com> on 24 Mar 2004 00:18:43 -0000
From
email above:
What
is the need for this specification?
As Web Services (WS) start to be deployed across
enterprise boundaries and for collaborative e-business and e-transaction
scenarios, message reliability becomes a critical issue. This is because communications over the
Internet (and Intranets) is inherently unreliable, as usage of the “transport
protocols” (HTTP, SMTP, and JMS) admit conditions which do not offer guaranteed
or ordered delivery. Yet WS messages
need be delivered to the ultimate receiver, even in the presence of component,
system, or network failures. If a message
can’t be reliably delivered, then the user must be so informed.
What are the reliability features supported by the
WS-Reliability specification?
A] Guaranteed delivery to the user or
Application entity (the message MUST be persisted (i.e. stored in non volatile
memory) in the sender Reliable Messaging Processor (RMP), until delivery to the
ultimate receiver has been acknowledged.
B] Duplicate elimination - Delivery at most
once -with duplicates detected and eliminated by the RMP receiver,
C] Guaranteed message ordering - when delivered
by the RMP receiver to the user, the messages are properly sequenced. The problem arises when messages are received
out of sequence or acknowledgements are lost.
The solution is for the RMP transmitter to retransmit unacknowledged
messages (after a time-out), and for the RMP receiver to re-order received out
of sequence messages so that they are properly delivered to the user (e.g.
Application entity)
Jacques took action item to propose new text for this
question above..
How
does the WS-Reliability protocol relate to WSDL operation types?
The
WS-Reliability protocol defines a reliable messaging request header, and a
reliable messaging response header.
There are three reliable messaging reply patterns which may be used with
WS-Reliability:
·
Response RM-Reply Pattern: the
outbound Reliable Message is sent in a request of the underlying protocol and
the RM-Reply is sent in the response message of the underlying protocol that
corresponds to the request.
·
Callback RM-Reply Pattern: the
RM-Reply of a previous message is contained in an underlying protocol request
of a second request/response exchange (or a second one-way message).
·
Polling RM-Reply Pattern: a second
underlying protocol request is issued to the receiver of a previous message, in
order to obtain a RM-Reply. The RM-Reply can be either contained in the
underlying protocol response to this request or in a separate underlying
request from the receiver to the sender. This polling pattern is generally
expected to be used in situations where it is inappropriate for the sender of
reliable messages to receive underlying protocol requests (behind the firewall
cases) or to avoid resending bulk messages often.
What
is the difference between the WSRM TC’s
WS-Reliability specification and the ws-reliable
Messaging specification.
WS-Reliability is being developed within the OASIS open process, and our working draft, related documents and TC archives are all accessible to the public. We invite public review and comment on this work.
WS-Reliable Messaging is a proprietary specification being developed privately at this time by a group of vendors. As the status of the current version of WS-Reliable Messaging is not publicly known, we advise those with specific questions on WS-Reliable Messaging to contact its developers.
Jacques stated the word “difference” is too vague.
Tom: it is unclear why the name of the TC and the spec are different.
Jacques: WS- reliability seems to suggest we go beyond the messaging part.
Bob: I recommend we be silent about the other spec.
Change question to why does the spec have a different name than the TC.
Marc G agreed to propose a new question with new answer to clarify the matter.
Who is participating in the OASIS
WSRM TC and how often do they meet?
A variety of companies
participated in the WSRM TC and contributed to the specificaton.
Including::
Booz Allen Hamilton, Cyclone
Commerce, Fujitsu (3), Hewlett-Packard,
Hitachi(3), NEC Corporation(2),
Nokia (2), Novell, Oracle (3), SAP, See Beyond, SUN
Micro (2),
University of Hong
Kong. There are also many
observers.
Membership in OASIS is
required to participate in the WSRM TC. Telecon
meetings are held weekly and
face-to-face meetings are held about every
two or three months.
Nobody opposed to deleting
this question. Agreed
to remove the participation question.
When will the WS Reliability
spec be completed and what is it based on?
Agreement was reached in Nov
2003 on a committee draft spec (v0.52),
which was implemented in a demo
at the Philadelphia XML Conference, in
Deceber 2003. The TC has recently voted on a committee
draft spec
(v.0.992)
which is out for public review, to complete on April 19, 2004.
Note that the spec is based
on Requirements issues that have been
compiled for the committee’s
internal use (over 100 requirements have
been identified).
- An OASIS standard could be
approved in the 2nd Quarter of 2004, after
the public review.
Who participated in the demo
of WS Reliability?
Fujitsu, Hitachi, NEC,
Oracle, and SUN Micro. The demo was based on
v0.52 of the spec.
Who will benefit from the
completed WS Reliability spec?
• WS middleware companies
that implement the spec will benefit because
it will be universally
interoperable. Initial testing can be done with
any company that implements it.
The license to implement the spec is
royalty free.
• Application program
developers will also benefit, as their web based
applications will be reliable and
robust, operating over WS Reliability
middleware. Using the implemented
middleware will also be royalty free.
• WS End users will benefit
in accordance with their application
requirements. For example, “at most once
delivery” implies duplicate
elimination. This is important for placing
orders, banking transactions,
and insurance claims
processing. If an end user is sending a Purchase
Order, for example, he wants
to know it actually arrived at the
destination and it arrived exactly once
(not multiple times). This is
particularly vital for financial
applications.
Any
comment to send out on the list.
· RE:
[wsrm] Candidate Frequently Asked Questions for the OASIS website
From <chris.hipson@bt.com> on 30 Mar 2004 15:31:33
-0000
· Re:
[wsrm] Candidate Frequently Asked Questions for the OASIS website
From "Alan Weissberger"
<ajwdct@technologist.com> on 24
Mar 2004 21:49:39 -0000
· Re:
[wsrm] Candidate Frequently Asked Questions for the OASIS website
From "Chiusano Joseph"
<chiusano_joseph@bah.com> on 24
Mar 2004 13:48:47 -0000
From
above emails:
ebMS 2.0/2.1 has it’s own
reliability mechanisms.
ebMS 3 has been requested to align
itself with the growing web services stack, so I guess they’ll be looking at
WSS and WS-R
Chris
Hipson
Web
Service Technology Consultant
From:
Alan Weissberger [mailto:ajwdct@technologist.com]
Sent:
24 March 2004 21:01
To:
Chiusano Joseph; Anish Karmarkar
Cc:
Tom Rutt; wsrm
Subject:
Re: [wsrm] Candidate Frequently Asked Questions for
the OASIS website
1. We did get a question at the Dec 03 XML COnference on relationship of WS Reliability to ebXML. I do not
think they are related or that our spec will work in an ebXML
environment.
2. I am not familiar with ebMS
2.0 and have never heard anyone ask about it
3. It would be a very bad idea to include a
comparison of our spec to WSRM spec.
That would open a can of worms and a lot of rock throwing. This is something that the industry/ market
will have to decide on its own.
Obviously all the vendors in a given camp will be biased in favor of
their spec.
alan
-----
Original Message -----
From:
"Chiusano Joseph"
Date:
Wed, 24 Mar 2004 09:02:35 -0500
To:
Anish Karmarkar
Subject:
Re: [wsrm] Candidate Frequently Asked Questions for
the OASIS website
>
Perhaps ebMS 2.0 as well...
>
>
Joe
>
>
Anish Karmarkar wrote:
>
>
>
> The first question that is asked by people looking at ws-reliability
is --
>
> what is the difference between this spec and ws-reliablemessaging?
>
>
>
> Are we going to put that in the FAQ?
>
>
>
> -Anish
>
> --
Jacques:
The answer to this question could be formulated in a proper way. It is a legitimate question to ask and we
should have an answer to it.
Jacques
took action to clearly state what the case is.
He agreed to draft a question with an answer.
Tom:
Need a general question on how can ws
reliability be used with other ws reliability
protocols. Answer :
we design it as orthogonal, to work with any other ws-
reliability protocol. An example on why
we have a reply to element of our own would help.
Tom
Rutt agreed to send a suggested question and proposal
out.
Any
other questions for the FAQ suggested by people should send to the list.
2
New Orleans
Face To Face preparation
Email
from OASIS Staff:
Hello Tom,
I am writing this email to confirm
the WSRM TCs participation at the upcoming New
Orleans OASIS Symposium. Please take a moment to review the information
below. Since space is very limited at the hotel - it is critical
that we confirm the specifics as soon as possible. If any of the
information below is incorrect, please respond to this email with the
appropriate change. I thank you in advance for the help and look forward
to working with you on this upcoming event.
Regards,
Jane Harnad
Manager of Events
OASIS
Phone: 978-667-5115 ext. 214
jane.harnad@oasis-open.org
Meeting
Name: WSRM TC
Day: Wednesday, 28
April and Thursday, 29 April
Time: 8:00 am -
5:00 pm
(Wed) and 8:00 am - 12:00 pm (Thurs)
Number of
Participants: 15 people
Audio Visual
Request: Projection screen ($25 per day)
Phone/Internet
Request: None
Room
Set: Boardroom for 20 people
Bob
F will bring a projector.
Pete:
There will be wireless access throughout the meeting rooms. I will try to confirm this.
Jacqeus moved to adjourn Bob seconded.