MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC
Title: RE: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC
I have not heard of any call scheduled today.
> It would be interesting to discuss what would be required in ebms to
>enable pluggability of rm processors.
Reliability has been designed from the start as a modular feature in V3 (meaning rather independent from the processing of ebMS headers), so that should not be too hard to realize. So far, the definition of QoS reliability features, and the abstract operations involved are rather similar between the two reliability specs. I see two things that can be done and an issue to resolve:
- the core body of V3 specification should only address the common reliability model, and related abstract operations (which/how they are used to make various MEPs reliable), but not mention any specific to WS-Reliability. The parts of the RM agreement that are common (top level QoS features) can also be profiled here.
- WS-Reliability specifics (e.g. lower level RM agreement parameters) can be moved to a binding section in appendix. The other module based on WS-ReliableMessaging would be treated the same when it is ready (could take a year, maybe two...)
- issues: reliability of synchronous responses is not addressed by either spec... although it is on the WS-Reliability roadmap and has been anticipated in current V3 draft, we don't know about WS-ReliableMessaging. Also, WS-ReliableMessaging is a bit fuzzy regarding the notification of delivery failure. It may need to be profiled further so we can have a clear contract at MSH level.
For now I'd rather concentrate on the other features beside reliability: still a lot to do there...
Jacques