[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] a bi-partisan proposal
Pim, I not clear that what you are saying is more involved than what Jacques was originally proposing. What I think I'm hearing as the simplest way forward is to support WS-RM as a delivery mechanism that would be transparent to the sender and receiver. In other words - our ebMS headers are all that the participants need to complete - and then intermediaries may deliver on one or more hops via WS-RM - but that would be handled by those middle processes that would use the information in the ebMS packaging to enable WS-RM aware steps. This means we just need to ensure ebMS packaging supports WS-RM - and keeps our specification clear and simple. DW > -------- Original Message -------- > Subject: RE: [ebxml-msg] a bi-partisan proposal > From: "Pim van der Eijk" <pvde@sonnenglanz.net> > Date: Wed, February 13, 2008 10:04 am > To: "'Durand, Jacques R.'" <JDurand@us.fujitsu.com>, > <ebxml-msg@lists.oasis-open.org> > > Hello Jacques, > > If WS-Reliability is considered as an option, could it provide end-to-end > reliable messaging in situation 2 (b) too? Assuming a constraint that the > reliable messaging headers must be piggy-backed with ebMS headers (assuming > routing is based on these ebMS headers). When the sender knows which > messages will end up at the same MSH (even if it does not know which > particular MSH), it could send these messages as a group. If it does not > even know this, it could use groups of cardinality one, functionality that > ebMS 2.0 reliable messaging provides today. Security would be preserved too. > > > When end-to-end reliable messaging is not used, perhaps we need to consider > two separate wsse:Security blocks to secure the exchange: > 1: One that signs the complete SOAP with attachments message, including any > WS-A and WS-RM headers, targeted at the next MSH. > 2: A second header that signs (and encrypts) only the ebMS 3.0 header and > all payloads, targeted at the ultimate receiver MSH. > An intermediary would remove the first wsse:Security header block and > re-sign the message. The second wsse header, the ebMS 3.0 header and all > payloads would be copied. In this scenario, the intermediary can forward > messages in different sequences, not necessarily to the same ultimate > receiving MSH, and it can even deliver some messages locally. An > intermediary needs sequences to deliver to its associated endpoints and for > any other intermediaries. Each intermediary is an end-point for WS-A and > WS-RM processing, except for the special ACK "relaying" functionality. > > I know proposing a second header violates the requirement that endpoints > should not have to behave differently to support intermediaries, but we need > to balance that against the requirement of end-to-end security. > > Pim > > > > > _____ > > From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] > Sent: 13 February 2008 05:07 > To: ebxml-msg@lists.oasis-open.org > Subject: [ebxml-msg] a bi-partisan proposal > > > Here is a bi-partisan proposal for a change ;-) > > 1. The core of an "Intermediary role" specification should primarily focus > on such functions as store-and-forward, bridging MPCs, rules for bridging > MEPs e.g. allowing a received pushed message to be pulled, etc. > - The routing function has to be assumed, but can remain unspecified, as it > may depend on various header data anyway. > - the RM function can be largely ignored when specifying the above. > > 2. Reliability function: a couple of options should be specified. > > (a) Because there will be multi-hop configurations where the Sender knows > enough about the ultimate receiver endpoint so that routing is not an issue > even for RM signals, the end-to-end RM sequence should be an option. Note > that this option is straightforward for conformance profiles that make use > of WS-Reliability (no RM signals besides Acks). When using > WS-ReliableMessaging, it will require routing support for RM signals (e.g. > use of WSA, or other means TBD). > This option is the only "fully transparent" end-to-end RM (e.g. for > security) and this alone justifies to support it although not possible in > all multi-hop configurations dues to routing constraints. It is also very > straightforward in terms of itnermediary conformance - once the routing is > resolved. > > (b) Because there will be multi-hop configurations where the routing of RM > signals cannot be done e.g. to establish a stable RM sequence between two > endpoint MSHs (e.g. because of too much dynamics on resolving MSHs even if > partners are known, or because security issues require to "hide" a portion > of the cloud) then end-to-end RM sequences cannot be established. In that > case, an advanced intermediary profile will support RM sequences "bridging", > so that end-to-end delivery assurance is still possible at least for > "At-Least-Once", "At-Most-Once" and "Exactly-Once" delivery. This bridging > can involve some Ack relaying techniques that need to be specified so as to > depart as little as possible from standard RM module behavior. > > Clearly, some multi-hop topologies might combine both (a) and (b). E.g. the > I-cloud includes a "hidden" portion that has a well-known "gatekeeper" > intermediary. Regardless of how many intermediaries are involved between a > Sender endpoint MSH and a "hidden" ultimate Receiver MSH, it is possible to > use a single RM sequence from Sender to Gatekeeper, and a single RM sequence > from Gatekeeper to ultimate Receiver, while reducing the RM sequence > bridging to the Gatekeeper only (all other intermediaries of the I-cloud > being "transparent"). A non-transparent Gatekeeper would make sense anyway > as it is possible that the QoS on the hidden I-cloud is different (e.g. a > VPN), so some Security processing may need to take place on the Gatekeeper, > e.g. validating a sig on the RM headers that are removed, or removing > encryption. > > Hope that may relieve the deadlock... or provide enough wiggle room to move > one step further. > > Jacques
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]