wsrm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Oracle's Requirements/Issues list
- From: Sunil Kunisetty <Sunil.Kunisetty@oracle.com>
- To: wsrm@lists.oasis-open.org
- Date: Thu, 01 May 2003 17:58:47 -0700
Hi,
Here is the Oracle's list of requirements/issues based on the
latest requirements/issues list document.
-
'Poll-Model' Async. Acknowledgments: The current spec. mandates having
a (HTTP) listener for the Sender to receive asynchronous acks. The listener
should be able to understand basic HTTP commands such as GET, POST et.
al. Though we can have a light weight listener, there could be cases even
that could be considered heavy weight and un-warranted. In such cases,
instead of Sender receiving async. acks., Sender can poll the Receiver
for the msg. ack. until Receiver sends one. This can be done in "when-in-doubt"
cases only as an optimization. This will be more useful in the request-response
reliability case that's being discussed recently. Note that sync. acknowledgments
may not be possible in pure one-way messaging systems. [[ this may be related
to REL-9 [1] that Iwasa raised. But reading the description it is
not clear and hence prefer to have it as a separate requirement ]]
-
WSDL declarations for RM operations: The WSDL extensible mechanisms (annotations)
should be employed to declare/define (statically) RM operations
such as MO, DE, GD either at <wsdl:operation> or at <wsdl:portType>
level or at both. When using WSDL 1.2, we could use the WSDL 1.2 properties
& features.
-
Handling message delivery failure cases: While it could be argued as an
implementation optimization, we feel it is better if we standardize it.
It means trying to recover in an optimized manner from when-in-doubt, mismatch,
negative cases etc.. and not necessarily at post-failure cases.
Few examples are:
-
If you have to retry for msg 'i' in a group (message ordering case), then
Sender should retry for (0 to 'i'-1) msgs. whose ack. was not received.
[[ Assumption here is retry count/interval is set at a message level ]]
-
If the Sender receives an ack. for msg 'i' in a group and it has a prior
msg(s) in the same group for which it didn't receive acks., the Sender
can retry those msgs.
-
Upon time-out (TTL expiration) simply log the error and not process it
any further. Example could be Sender should check whether the TTL expired
or not before it has to do any retries. Similar things apply for
Receiver too for acks. etc.
-
Sending Faults in Header rather than Body because of <soap:detail> usage:
As per SOAP 1.1 spec. for Faults (section 4.4), "<soap:detail> MUST
NOT be used to carry information about error information belonging to header
entries. Detailed error information belonging to header entries MUST be
carried within header entries". Unfortunately, this is not the case with
the initial WS-Reliability spec. as all WS-Reliability specific faults
are sent in /Body/detail. [[ Actually, this is more an outstanding issue.
It was in the Issues list at one point, but it was removed when Issues
list was converted to Futures list as this is too low-level (technically)
to fit into the former. ]]
-
Global Unique IDs (GUIDs): Generating GUIDs is a nasty problem. One easy
way to solve would be that Sender asking the Receiver to generate
one for it before it initiates any reliable message.
-
Amend REL-12 to say "Usage/Capabilities of Transport/Underlying Protocol"
to capture cases such as SOAP over JMS wherein there is no standard wire
protocol, but the underlying protocol must support features such DE, GD,
MO. If REL-12 was meant strictly for transport protocols such TCP, UDP
etc. then may be REL-3 (Non HTTP Bindings) should capture such requirement.
If not, a new requirement should be added.
Thanks,
-Sunil
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]