Full Agenda 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)
Conference call Dial-in number : Toll number (only): 1-512-225-3050 Participant code: 89772
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
??? approved
1
Roll
Call
Attendance:
Meeting ?? quorate.
2
Minutes
Discussion
2.1 Appointment of Minute Taker
Tom Rutt will take
minutes.
??? will serve to record issue resolutions.
2.2 Approval of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6146/MinutesWSRMTC032304.htm
xx moved to accept the Mar 23 minutes. yy seconded.
?? opposition, 3/02 minutes ??approved.
3
Discussion
of Issues and editorial Comments
3.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 grup, 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.
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.
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".
3) Line
1135: We don't have InvalidGroupParameter fault. It
should be replaced with
InvalidMessageParameters fault.
4) Line
1136: Uppercase MUST
5) Line
1148: Lowercase 'c' in criteria
6) Line
1181: Add the following at the end of the sentence.
The group had either groupExpiryTime or GroupMaxIdleDuration specified, but not both.
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.
8) Line
1277: Uppercase P in Poll
9) Line
1278: Replace is with has as in "for a message it has to inquire".
10) Line 1279: Replace acknowledgement with RM
Reply
11) Line 1280: Replace acknowledgements with RM
Replies
-Sunil
3.2 Other Issues
4
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)
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.
Who is participating in the
OASIS WSRM TC and how often do they meet?
A variety of companies are
active in the WSRM TC. The members include:
Booz Allen Hamilton, BT, Cyclone
Commerce, Fujitsu (3), Hewlett-Packard,
Hitachi(3), NEC Corporation(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.
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.
· 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
>
> --
5
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