OASIS Specification Template s3

2Proposal: Multi-hop for ebMS V3

3(V0.18)

4November 6, 2008 5 6Editor(s): 7 Jacques D. / Sander F. 8Abstract: 9 Proposal draft for Multi-hop section.. 10Status: 11 Draft for discussion. 12 13

161.1 Background 17The core specification of ebMS version 3.0 defines how the message exchange between two parties 18takes place when they do communicate directly point-to-point. A much found situation when several 19organizations exchange messages with each other however is the use of intermediaries which are 20responsible for the message delivery and which may provide additional services. The intermediaries are 21in charge of routing functions that make it possible for communicating parties to ignore the destination 22details of their messages (e.g. the URL of the ultimate MSH). 23

241.2 Terminology 25In the messaging model extended to multi-hop, ebMS V3 MSHs are acting in a new role called 26“intermediary”. (The ebMS V3 Core specification previously defined two roles: “Sending” and “Receiving”). 27The following definitions are used throughout this section: 28Intermediary MSH (or ebMS Intermediary): An MSH able to act in the Forwarding role (see detailed 29definition in related subsection). In short, an Intermediary is able to forward a received ebMS message to 30another MSH without modification (i.e. without altering any header attribute). ebMS Intermediaries support 31routing functions based on the meta data provided by the ebMS message header. 32ebMS Multi-hop path: a multi-hop path is a string of MSHs involving at least one Intermediary MSH, and 33that are configured as to allow the end-to-end transfer of some ebMS messages from one end of the 34string (called path origin MSH) to the other end (called path destination MSH). The following figure 35illustrates a topology allowing for two multi-hop paths between MSHs A and B: one from A to B, the 36other from B to A (the term I-Cloud is defined later). The arrows show possible directions of message 37transfer. Components between MSHs A and B are ebMS Intermediaries.

38 39The hops that relate the path origin MSH and destination MSH to the I-Cloud (i.e. hop: MSH A - 40Intermediary 0, and hop Intermediary N – MSH B) are called Edge hops, while the hops over the I-Cloud 41are called I-Cloud hops. 42Endpoint MSH: An MSH that is only able to act either as the path origin MSH (i.e. in the Sending role) or 43as the path destination MSH (i.e. in the Receiving role) of a multi-hop path. An Endpoint MSH can not act 44as an Intermediary MSH: it is in general only compliant with the Core ebMS V3 specification. 45ebMS multi-hop topology: An ebMS multi-hop topology is a network of ebMS nodes connected so that 46they define one or more multi-hop paths. Note that not every pair of ebMS nodes in a multi-hop topology 47has to be part of a multi-hop path, i.e. the topology is not always configured to allow message transfer 48from any ebMS node to any ebMS node. A multi-hop topology usually comprises Endpoint MSHs on its 49periphery, although it does not have to: for example, in a ring topology all MSHs are Intermediaries.

4[Document Identifier] [DD Month YYYY] 5Copyright © OASIS Open 2005. All Rights Reserved. Page 2 of 39 50I-cloud (or Intermediary-cloud): The I-cloud is the network of ebMS Intermediaries that is at the core of a 51multi-hop topology. The I-cloud does not comprise the Endpoint MSHs. 52 53

541.3 Multi-hop Topologies

551.3.1 Assumptions 56The following assumptions are made about ebMS Intermediaries, that restrict the multi-hop model 57described here in a way that is considered acceptable for the large majority of situations: 58 The topologies considered here all involve ebMS intermediaries, not exclusive of other non-ebMS 59 nodes. Other nodes (SOAP nodes, HTTP proxies, etc.) may be involved in transferring ebMS 60 messages over multi-hop paths, but they are not considered as ebMS intermediaries in the sense that 61 they are not required to understand any of the ebMS headers. Their presence is orthogonal to the 62 definition of ebMS topologies. 63 In all topologies considered here, every Intermediary is “addressable” in the sense that either (a) at 64 least some other MSH of the I-cloud can push messages to it, or (b) some Endpoint MSH can push 65 messages to it, or both. This implies it has an IP address that is resolvable and usable by at least 66 another MSH. 67 When an ebMS Intermediary is connected to an Endpoint MSH acting as path destination for some 68 type of message, it may support message pulling from this Endpoint MSH. 69 In any multi-hop path, the message may be pushed or pulled over each I-Cloud hop. When not 70 specified, it is assumed to be pushed on each segment of the path. 71 The same MSH may find itself at any place in a multi-hop path depending on the type of message 72 transferred: it can be an Intermediary for some messages, a path destination MSH for others, and a 73 path origin MSH for others. The multi-hop model described here must support this, although in 74 practice many topologies will restrict the roles that an MSH can play. 75

761.3.2 Hub-and-Spoke 77 In the Hub-and-Spoke topology, a single Intermediary MSH (called Hub) is used, to which all endpoint 78 MSHs are connecting. In this configuration, every multi-hop path is actually a 2-hop path. Every 79 Endpoint MSH connected to the Hub is either a destination or an origin to at least one multi-hop path.

7[Document Identifier] [DD Month YYYY] 8Copyright © OASIS Open 2005. All Rights Reserved. Page 3 of 39 80 811.3.3 Interconnected Hubs 82This topology is a generalization of the Hub-and-Spoke model. It applies when each Hub is only serving 83“regional” Endpoint MSHs, e.g. for security, manageability or scalability reasons. The group of endpoints 84directly served by the same Hub is called here an Endpoint cluster. Each Hub can be configured for 85routing messages intended to an Endpoint MSH of another cluster.

86 87Some Intermediaries may not serve any cluster of endpoint MSHs, but act as relays between 88Intermediaries.

891.3.4 Bridged Domains 90In this topology several private ebMS sub-networks are related by Intermediaries called Gateways. 91Indeed, the internal addresses within an I-Cloud can have private IP addresses and DNS names that are 92not publicly reachable or resolvable in the Internet.

10[Document Identifier] [DD Month YYYY] 11Copyright © OASIS Open 2005. All Rights Reserved. Page 4 of 39 93Each private ebMS domain is only reachable from outside via its Gateway. The assumption is that every 94Gateway is reachable from any Gateway and knows how to route messages intended to other domains. 95This topology mostly departs from the Interconnected Hub topology in its addressing constraints and 96partitioning into domains bridged by these Gateways. 97

981.4 Usage Requirements 99

1001.4.1 Operation Principles 101 The following principles are overarching to the design and operation of ebMS multihop messaging: 102 Principle 1: The I-Cloud does not modify messages. It does not add or remove SOAP headers. Its 103 intermediaries have to parse and understand some (ebMS) headers for routing purpose. 104 Principle 2: The message transfer over a multihop path, is controlled by two disjoint entities in 105 multihop messaging: (a) PMode for communication over edge hops (path origin to ICloud, or I-Cloud 106 to path destination) (b) routing function for transfer over ICloud hops. Origin MSH and destination 107 MSH never have to be aware of the way messages are transferred in the I-Cloud, nor can they 108 control it besides setting header content used as input by the routing functions. 109

1101.4.2 Connectivity and Addressability constraints 111 An Endpoint MSH may or may not be addressable. If not addressable, it will pull messages from the 112 Intermediary it is connected to in the multi-hop topology (i.e. must be able to act as the initiator of a 113 One-way / Pull MEP, and the Intermediary to act as the responding MSH of such an MEP). 114 There may be other reasons from message pulling than non-addressability, e.g. intermittent 115 connectivity of endpoints, security aspects, and risk mitigation in reducing the time between message 116 reception and message processing. 117

1181.4.3 QoS of Exchanges 119It must be possible to configure a multi-hop topology so that end-to-end message transfer is possible 120without breaking signatures. This implies that Intermediaries do not modify ebMS messages.. 121It must be possible to configure a multi-hop topology so that end-to-end reliable transfer of a message is 122possible, i.e. over a single reliable messaging sequence. 123When message forwarding does not involve pulling, and when there is no other connectivity impediment, 124an Intermediary must be able to use streaming to forward a message without having to persist any part of 125it. 126(Also: WSI Conformance where feasible - especially with respect to WSI RSP policy that WS-RX 127Reliable Messaging headers be signed, including WS-Addressing elements where used within 128ReliableMessaging) 129

1301.4.4 Intermediary Configurability and Change management 131 As in point-to-point communication, PModes governing message exchanges should only be known 132 from Endpoint MSHs, and some subset of PModes may need be configured on. The I-Cloud should 133 not have to be aware of PModes, with an exception: when an Intermediary has to support message 134 pulling, it must know which ones of the messages it receives must be pushed and which ones must 135 be pulled. This requires partial knowledge of PModes associated with message pulling.

13[Document Identifier] [DD Month YYYY] 14Copyright © OASIS Open 2005. All Rights Reserved. Page 5 of 39 136 Multi-hop exchanges between two Endpoint MSHs may be re-routed without knowledge from the 137 Endpoints. In particular, messages from a single end-to-end reliable sequences may be routed on 138 different paths, provided they reach the same destination. This may happen when an Intermediary is 139 out of order, requiring routing via an alternate path. 140 141(Spoke configuration to services within an I-Cloud should have simplicity of configuration 142change management. 143Specifically, rerouting to services (within the I-Cloud ) can be accomplished without spoke 144configuration changes”) 145

1461.4.5 Contingent requirements 147 (possibility of user message bundling,…) 148

1491.4.6 Error handling 150ebMS Errors (eb:Error) generated by endpoints are subject to the same reporting options as errors in 151peer-to-peer communication. AT least a couple of routing patterns for eb:Error must be supported: (a) the 152error destination URL is known (e.g. obtained from the PMode) and does not require any multihop routing, 153or (b) the eb:Error signal is routed using the same routing functions as those used for User messages. 154ebMS Errors may be generated by Intermediaries. A new type of error must be supported by 155intermediaries: 156  error ID: EBMS:0020, 157  short description: RoutingFailure 158  severity: failure 159  description: whenever an Intermediary is unable to route an ebMS message, it must generate 160 such an error and stop processing the message. 161The reporting of the error must follow one of these three patterns: (a) the error is logged locally to the 162Intermediary, for later analysis, (b) the error is sent to a fixed destination provided to the Intermediary at 163configuration time, (c) the error is reported to an explicit URL present in a wsa header (wsa:ReplyTo or 164wsa:FaultTo) of the message in error. 165

1661.5 Message Exchange Patterns 167

1681.5.1 MEPs and Channel Bindings 169 170 Section 2.2 of the Core V3 Specification defines the notion of ebMS message exchange patterns. 171 These MEPs represent how messages are exchanged between partners. The Core Specification 172 defines two MEPs, 173  One-Way for the exchange of one message and 174  Two-Way for the exchange of a request message followed by a reply in response. 175 Also the concept of MEP Bindings is introduced in section 2.2 of the Core Specification. Such an 176 MEP binding defines how the abstract MEP is bound to the underlying transport. 177

16[Document Identifier] [DD Month YYYY] 17Copyright © OASIS Open 2005. All Rights Reserved. Page 6 of 39 178 The above MEPs between two partners are independent from the network topology, i.e. two partners 179 evolving from a point-to-point topology toward a multihop topology, would still describe use the same 180 message exchanges using the same MEPspatterns (One-Way, Two-Way) as defined in the Core 181 specification (V3). The MEP represents the exchange pattern between the (application-level) 182 Producer and Consumer of the message. 183 The way these MEPs bind to the underlying transport protocol does change however, as the transfer 184 is now divided into multiple hops. This implies that the binding of MEPs to the underlying transport 185 ( “channel binding”, see 2.2.3 in Core V3) may vary in a way that is not covered by the Core 186 specification. 187 Message transfer over a multihop path (including the way the underlying transport protocol is used) is 188 controlled by two different means: 189  Edge hops: controlled by PMode deployed on the path origin MSH and path destination MSH 190 (and also partially deployed on the Intermediaries participating in these hops) 191  I-Cloud hops: controlled by the routing function. 192 The following figure illustrates the control of multihop transfers and the related partitioning of multihop 193 paths,

194 195 Throughout this specification, the notion of “MEP multihop channel binding” will only be defined in 196 terms of the binding of edge hops, and will make abstraction of the binding of I-Cloud hops. 197 The channel binding of the first and last hops (the edge hops) is controlled by the PMode. In a 198 multihop context, when a PMode governs the message transfer to and from an endpoint MSH, its 199 MEPbinding parameter only defines the binding of hops (e.g. push or pull) between this endpoint and 200 the first (or last) Intermediary of the I-Cloud. 201 The routing function in the I-Cloud will control whether a message is pushed or pulled over an I-Cloud 202 hop, as explained in section 1.6. 203 204 The following subsections describe multihop MEP bindings while making abstraction of the channel 205 binding inside the I-Cloud. Because only the binding of the edge hops (first and last hops) – i.e. the 206 bindings controlled by P-Mode – is defined, these multihop MEP bindings are called “edge-binding”.

19[Document Identifier] [DD Month YYYY] 20Copyright © OASIS Open 2005. All Rights Reserved. Page 7 of 39 207 208 These multihop edge-bindings will not result inbe defined by new names or URI values for the 209 PMode.MEPbinding parameter. Instead as explained in Section 1.8, they will result from the 210 combination of point-to-point MEP bindings for each edge (i.e. controlling the first and last hops). In 211 other words, while the same PMode was deployed by each endpoint to control a point-to-point 212 exchange, slightly different PModes on each endpoint need be deployed for controlling the same 213 exchange over a multihop path. Section 1.8 will describe these changes, one of them being the 214 PMode.MEPbinding parameter value which may now differ on both ends, as the first and last hops 215 (edge hops) may be channel-bound quite differently over a multihop path. 216

2171.5.2 Edge-bindings Options for Multi-hop PathsOne-Way 218NOTE: in the following, the path origin MSH is also called the Sender, and the path destination 219MSH, the Receiver. 220

2211.5.2.1 Pushing Messages from the Sender 222 223Both of theThe following shows how multihop MEP edge-binding combinationss assume a 224Sender pushing the message to the I-Cloud. These edge bindings are configured via the 225PMode.MEP and PMode.MEPbinding parameters deployed on each endpoint, using 226conventional values defined in Core V3:are configured in the PMode parameters MEP and 227MEPbinding deployed on each endpoint, using conventional values defined in Core V3: 228 229 230NOTE: in the following, the path origin MSH is also called the Sender, and the path destination 231MSH, the Receiver.

22[Document Identifier] [DD Month YYYY] 23Copyright © OASIS Open 2005. All Rights Reserved. Page 8 of 39 233 234Case 1: Both endpoint MSHs interact with the I-Cloud using the same MEP bindings they would 235use with their partner in a direct point-to-point mode. 236P-Mode MEP configuration: 237 238 1. Push on the multihop edges for One-way MEP 239 o Edge hop Sender side: 240 . Sender as PMode.Initiator 241 . MEP and binding = One-way / Push 242 o Edge hop Receiver side 243 . Receiver as PMode.Responder 244 . MEP and binding = One-way / Push 245 246Case 2: This edge-binding applies when both Sender and Receiver endpoints are not addressable. 247P-Mode MEP configuration: 248 249 o Edge hop Sender side: 250 . Sender as PMode.Initiator (Intermediary as PMode.Responder) 251 . MEP and binding = One-way / Push 252 o Edge hop Receiver side 253 . Receiver as PMode.Initiator (Intermediary as PMode.Responder) 254 . MEP and binding = One-way / Pull 255 256 257

2581.5.2.2 Pulling Messages from the Sender 259 260Both of the following edge-binding combinations assume that the I-Cloud pulls messages from 261the Sender. These edge bindings are configured via the PMode.MEP and PMode.MEPbinding 262parameters deployed on each endpoint, using conventional values defined in Core V3:

25[Document Identifier] [DD Month YYYY] 26Copyright © OASIS Open 2005. All Rights Reserved. Page 9 of 39 263 264 265In both Case 3 and Case 4 above, the edge bindings are quite similar: all of them are One-way / 266Pull. However, the difference lies in the way the pulling is propagated across the I-Cloud. 267 268Case 3: In this MEP binding, the PullRequest signal is generated by the Receiver endpoint MSH, and 269routed all the way by the I-Cloud as any other message, to the Sender MSH. In other words, the same 270PullRequest message is used in both edge-hops. The implication of such multi-hop pulling, is that each 271Intermediary on the path must keep its transport connections open. The main advantage is that there is a 272single authorization point for the pulling: the Sender MSH. The I-Cloud has no responsibility in authorizing 273the pulling and has no authorization information (passords or certificates) to maintain. 274 275P-Mode MEP configuration: 276 277 o Edge hop Sender side: 278 . Sender as PMode.Responder (Intermediary as PMode.Initiator) 279 . MEP and binding = One-way / Pull 280 o Edge hop Receiver side 281 . Receiver as PMode.Initiator (Intermediary as PMode.Responder) 282 . MEP and binding = One-way / Pull 283 284 285Case 4: In this MEP binding, the PullRequest signal is not routed, and only goes over a single hop. 286The PullRequest signals over each edge-hop are different messages, which could have different 287authorization credentials (the Pull signal is authorized for the next node only). These edge pulls are 288relayed by the I-Cloud in unspecified ways – the pulled message could be pushed and/or pulled across 289the I-Cloud. The MPC that is pulled from is the only common point between these decoupled pulls, called 290chained pulls. The Intermediary configuration for pulling some MPCs while pushing to other MPCs is

28[Document Identifier] [DD Month YYYY] 29Copyright © OASIS Open 2005. All Rights Reserved. Page 10 of 39 291part of the routing function, so the difference between Case 4 and Case 3 is not much in the P-Mode 292configuration, but rather in the I-Cloud routing function. 293 294P-Mode MEP configuration: 295 296 o Edge hop Sender side: 297 . Sender as PMode.Responder (Intermediary as PMode.Initiator) 298 . MEP and binding = One-way / Pull 299 o Edge hop Receiver side 300 . Receiver as PMode.Initiator (Intermediary as PMode.Responder) 301 . MEP and binding = One-way / Pull 302 303Other combinations of edge-bindings are expected to be used and supported by Intermediaries 304that are not described here (such as One-way / Pull on first hop and One-way / Push on last hop), 305although they will automatically be supported by Intermediaries that already support the edge- 306binding combinations specified here. 307

3081.5.3 Edge-bindings for Multi-hop Two-Way 309 310NOTE: in the following, two multi-hop paths are involved: one for the “request” message, one 311for the “reply” message. The origin MSH for a path is also called the Sender, and the destination 312MSH, the Receiver. 313

3141.5.3.1 Asynchronous Edge-bindings 315 316Both of the following edge-binding combinations assume a reply message that is sent back 317asynchronously by the request Receiver endpoint MSH. The routing through the I-Cloud is 318independent from these edge-bindings. These edge bindings are configured via the PMode.MEP 319and PMode.MEPbinding parameters deployed on each endpoint, using conventional values 320defined in Core V3:

31[Document Identifier] [DD Month YYYY] 32Copyright © OASIS Open 2005. All Rights Reserved. Page 11 of 39 321 322 323Case 1: Both endpoint MSHs interact with the I-Cloud using the same MEP bindings they would 324use with their partner in a direct point-to-point mode. Both are addressable. 325 326P-Mode MEP configuration: 327 328 o Edge hops on Request Sender side: 329 . Request Sender as PMode.Initiator (Intermediary as PMode.Responder) 330 . MEP and binding = Two-way / Push-and-Push. 331 o Edge hops on Request Receiver side: 332 . Request Receiver as PMode.Responder (Intermediary as PMode.Initiator) 333 . MEP and binding = Two-way / Push-and-Push 334 335Case 2: This case applies when both endpoint MSHs are not addressable: both are pulling 336messages from the I-Cloud. 337 338P-Mode MEP configuration: 339 340 o Edge hops on Request Sender side: 341 . Request Sender as PMode.Initiator (Intermediary as PMode.Responder) 342 . MEP and binding = Two-way / Push-and-Pull 343 o Edge hops on Request Receiver side: 344 . Request Receiver as PMode.Responder (Intermediary as PMode.Initiator) 345 . MEP and binding = Two-way / Pull-and-Push 346 347

34[Document Identifier] [DD Month YYYY] 35Copyright © OASIS Open 2005. All Rights Reserved. Page 12 of 39 3481.5.3.2 Synchronous Edge-bindings 349 350Both of the following edge-binding combinations assume a reply message that is sent back 351synchronously by the request Receiver endpoint MSH. The routing through the I-Cloud is 352independent from these edge-bindings. These edge bindings are configured via the PMode.MEP 353and PMode.MEPbinding parameters deployed on each endpoint, using conventional values 354defined in Core V3:

355 2. P 356 ush on the multihop edges for Two-way MEP 357 o Edge hops Sender side: 358 . Request Sender as PMode.Initiator 359 . MEP and binding = Two-way / Push-and-Push. 360 o Edge hops Receiver side: 361 . Request Receiver as PMode.Responder 362 . MEP and binding = Two-way / Push-and-Push 363 364 365Case 3: The request Receiver endpoint MSH interacts with the I-Cloud using the same MEP 366binding it would use with its partner in a direct point-to-point mode. The request Sender MSH 367may be non-addressable, and will pull the reply message. No connection has to be kept open on 368the first edge-hop. 369 370P-Mode MEP configuration: 371 372 o Edge hops on Request Sender side: 373 . Request Sender as PMode.Initiator (Intermediary as PMode.Responder) 374 . MEP and binding = Two-way / Push-and-Pull

37[Document Identifier] [DD Month YYYY] 38Copyright © OASIS Open 2005. All Rights Reserved. Page 13 of 39 375 o Edge hops on Request Receiver side: 376 . Request Receiver as PMode.Responder (Intermediary as PMode.Initiator) 377 . MEP and binding = Two-way / Sync 378 379 380Case 4: Both endpoint MSHs interact with the I-Cloud using the same MEP binding they would 381use between themselves in a direct point-to-point mode. The request Sender MSH may be non- 382addressable, and will pull the reply message over the same transport connection as the request 383message – so this connection has to be kept open on the first edge-hop. 384 385P-Mode MEP configuration: 386 387 o Edge hops on Request Sender side: 388 . Request Sender as PMode.Initiator (Intermediary as PMode.Responder) 389 . MEP and binding = Two-way / Sync 390 o Edge hops on Request Receiver side: 391 . Request Receiver as PMode.Responder (Intermediary as PMode.Initiator) 392 . MEP and binding = Two-way / Sync 393 394These two MEPs are illustrated in the following figure: 395

396 397 398 399 3. Push and Pull on the multihop edges for One-way MEP 400 o Edge hop Sender side: 401 . Sender as PMode.Initiator

40[Document Identifier] [DD Month YYYY] 41Copyright © OASIS Open 2005. All Rights Reserved. Page 14 of 39 402 . MEP and binding = One-way / Push 403 o Edge hop Receiver side 404 . Receiver as PMode.Initiator 405 . MEP and binding = One-way / Pull 406 407 408 4. Push and Pull on the multihop edges for Two-way MEP 409 o Edge hops Request Sender side: 410 . Request Sender as PMode.Initiator 411 . MEP and binding = Two-way / Push-and-Pull 412 o Edge hops Request Receiver side: 413 . Request Receiver as PMode.Responder 414 . MEP and binding = Two-way / Pull-and-Push 415 416 417 5. Push, Pull and Sync on the multihop edges for Two-way MEP 418 o Edge hops Request Sender side: 419 . Request Sender as PMode.Initiator 420 . MEP and binding = Two-way / Push-and-Pull 421 o Edge hops Request Receiver side: 422 . Request Receiver as PMode.Responder 423 . MEP and binding = Two-way / Sync 424 425 426These three MEPs with “mixed” bindings are illustrated in the following figure: 427

428 429

43[Document Identifier] [DD Month YYYY] 44Copyright © OASIS Open 2005. All Rights Reserved. Page 15 of 39 430Other optiona are: 431 432 6. Sync on the multihop edges for Two-way MEP 433 o Edge hops Request Sender side: 434 . Request Sender as PMode.Initiator 435 . MEP and binding = Two-way / Sync 436 o Edge hops Request Receiver side: 437 . Request Receiver as PMode.Responder 438 . MEP and binding = Two-way / Sync 439 440 441 Two endpoints previously configured (PMode) for One-way / Push can participate in a One-way / 442 Push-then-push exchange without any change in their PMode.MEP, 443 This transport-channel-bound MEP is essentially the same as the One-Way/Push MEP presented in 444 section 2.2.5 of the Core Specification. In the Hub-and-spoke case the ebMS User Message is 445 pushed twice, first from the Sending Endpoint to the Intemediary and then from Intermediary to 446 Receiving Endpoint. 447 448

449 450 NOTE: The diagram only shows one intermediary for simplicity, but there could be multiple. 451 452 453 454 455

4601.5.4 Multi-hop with Pulling on both Edges 461IMPORTANT: There are two options: 462(a) Pull signal routing: In this option the PullRequest signal is generated by one endpoint MSH, and 463routed all the way by the I-Cloud as any other message. The semantics of such multi-hop pulling, is that 464each Intermediary on the path must keep its connections open. The main advantage is that Pull 465authorization is controlled at the ultimate destination – the endpoint being pulled from. 466(b) Chained Pulling: In this option the Pulling only goes over a single hop, and is “relayed” by other Pull 467signals initiated by intermediaries to the next node of the I-Cloud. The Pull signal is authorized for the next 468node only. The Intermediary configuration for pulling some MPCs while pushing to other MPCs is part of 469the routing function. The PulRequest signal is generated by the Intermediary itself as a way to implement 470an “inbound pull” routing mode. The first Intermediary (on the multihop path) may then Pull from the 471Sending endpoint, and would need to be authorized for this pulling. The Receiving endpoint needs to be 472authorized for pulling from the (last) Intermediary only. 473 474 In this MEP, a One-way message is pulled over each hop of its path, including the first hop. The 475 ebMS User Message is carried over the second leg of an underlying 2-way transport protocol as a 476 result of a [series of ] ebMS Pull Signal. (TO DECIDE: At each node of the path, the Intermediary 477 keeps the connection open so that the pulled message is carried over the same connection as the 478 PullRequest signal.) The channel-bound MEP is called: 479 (a) One-way / Pull-then-Pull 480 481 This binding is indentified by the URI http://docs.oasis-open.org/ebxml- 482 msg/ebms/v3.0/ns/multihop/200810/pull 483 NOTE: as it is assumed in this specification that all Intermediaries are addressable, this channel 484 binding should never be necessary. In particular, when two Intermediaries are adjacent on the 485 same multi-hop path, it is always assumed that messages on this multi-hop path can be pushed 486 between these Intermediaries.

49[Document Identifier] [DD Month YYYY] 50Copyright © OASIS Open 2005. All Rights Reserved. Page 17 of 39 487 488 All synchronous variant: 489 This channel binding applies only to Two-way MEPs. The response (“reply”) message is sent back 490 over the back-channel (leg 2) of the underlying protocol at each hop, where the fore-channel (leg 1) of 491 the same connection was used for the “request” User message. This binding requires that all 492 connections remain open by each Intermediary over the path, until they get the response message. 493 The latency of a Two-way roundtrip may not allow this channel binding, especially when several 494 Intermediaries are involved, with regard to the number of connections that can be kept open at the 495 same time. The channel-bound MEPs are called: 496 a. Two-way / All-Sync 497

4981.6 The Intermediary MSH Role 499A new messaging Role (besides Sending and Receiving) is defined here as “Forwarding”. The 500Forwarding role implies support for the following Intermediary functions. 501

5021.6.1 The Intermediary Functions 503 504An ebMS intermediary is expected to support the following functions: 505 506 Message forwarding. Besides the Send and Receive operations defined in the model of V3 Core 507 specification, a new operation: Forward is added to the messaging model. It is defined as: sending 508 (operation Send) a message that has been received (operation Receive) without altering it. Doing so 509 requires no additional processing other than that needed by the routing function. 510 511 The following figures illustrate a Hub MSH (Hub-and-Spoke topology) forwarding a message either for 512 pushing to or for pulling by the Receiver endpoint. 513 514

515 516 NOTE: The diagram could easily be generalized for the Interconnected Hubs topology, where every 517 Intermediary onb the multi-hop path would have to act in the Forwarding role. 518 52[Document Identifier] [DD Month YYYY] 53Copyright © OASIS Open 2005. All Rights Reserved. Page 18 of 39 519 520 MEP bridging. Forwarding also implies the ability to bridge different MEP channel bindings, although 521 in a limited way (see Section …). For example, a message bound to a One-way / Push MEP when 522 received, may be bound to a One-way / Pull after forwarding, as illustrated in the following Figure.. 523

524 525 Message Routing. As an intermediary is not an endpoint of the communication multi-hop path, every 526 message received must be forwarded to another MSH. The routing function of an intermediary 527 defines to which MSH a message must be forwarded based on meta data taken fromcarried by the 528 received message. 529 530 Message pulling support. This implies some partial knowledge of PModes that determine a push vs. 531 a pull channel. In the case of pulling, some scalability feature (sub-channels) will also be supported 532 and configured with authorization info. In addition to assigning (a) eb:UserMessages to Pull channels, 533 an Intermediary MUST also be able to assign (b) eb:SignalMessages and (c) non-ebMS, RM signals 534 such as wsrm:CreateSequence or Sequence Acknowledgments, so that these signals become 535 available for pulling by an endpoint MSH. In case (c), the pulled signal MUST be combined with an 536 eb:Error element with code: EBMS:0006 (EmptyMessagePartitionChannel). Consequently, the 537 response to a Pull request is always an ebMS message. 538

5391.6.2 Message forwarding options 540 541 For the new abstract operation Forward two implementation models exist. First is the store- 542 and-forward model in which the Send operation only starts after the Receive operation has 543 successfully been completed. So the Send and Receive are executed sequentially and the 544 successful execution of the Receive operation is not dependent on the successful execution of 545 the Send operation. The sequence diagram for this model is shown in the next figure.

55[Document Identifier] [DD Month YYYY] 56Copyright © OASIS Open 2005. All Rights Reserved. Page 19 of 39 546 547 Opposite to this model is the streaming model in which both operations are executed in 548 parallel, i.e. data is directly transferred to the next hop. In this model the Send operation 549 starts as soon as possible after the Receive operation does. Because the next hop will only be 550 known after the message header has been received the Send operation can only start some 551 time after the start of the Receive operation. Based on whether the Receive operation ends 552 before or at the same time as the Send operation two sub cases of the streaming model exist. 553 In the first sub case, called asynchronous streaming, the Receive operation completes 554 successfully after receiving all message data, i.e. a transport channel acknowledgment is sent 555 to the previous hop and the channel is closed. The figure below shows the sequence diagram 556 for this streaming model sub case.

557 558 In the other case, called synchronous streaming, the Receive operation only ends when the 559 Send operation is complete successfully, i.e. the transport acknowledgement is only sent back 560 to the previous hop when a transport acknowledgement is received from the next hop. The 561 sequence diagram for this sub case of the streaming model is shown in the next figure. Note 562 that synchronous refers to the transport acknowledgements and not the ebMS message 563 transfer, Even when using synchronous streaming intermediaries the ebMS MEP could be 564 asynchronous.

58[Document Identifier] [DD Month YYYY] 59Copyright © OASIS Open 2005. All Rights Reserved. Page 20 of 39 565 566 For synchronous ebMS message transfers the only option is to use the synchronous streaming 567 model because this will wait with responding to the previous hop until a response is received 568 from the next hop. 569 Advantage of both streaming models over the store-and-forward model is that is requires less 570 storage space because there’s no need to store complete messages. Also the end-to-end 571 latency is shorter. 572 The main disadvantage of this model is that it requires more bandwidth as the Receive 573 operation only ends after the corresponding Send finishes, so incoming connections stay 574 open until the outgoing one is closed. If the outgoing connection doesn’t have at least the 575 same bandwidth as the incoming connection the streaming model will lead to congestion on 576 the intermediary. Therefore the streaming model should only be used when bandwidth is 577 known to be available. 578

5791.6.3 Details of the Routing Function 580 A function every intermediary MUST implement is the routing function that defines to which MSH a 581 received message is forwarded. The input to this routing function, called the routing input, is a set of 582 meta data elements taken from the received message. 583 The output of the routing function is the next destination of the message. This is not just the URL of 584 the next MSH, but also includes information on how the forwarding should be done - i.e. by pushing 585 or pulling. When for example the destination is the ultimate receiver which uses pulling to get its 586 messages there is no URL where message must be sent to. The routing function must then specify 587 which MPC is intended for a pull and not a push, over the next hop. Part of this pull information are 588 the credentials for pulling authorization. (see section…). 589 The routing function can be modeled as: 590 591 f( RoutingInput )  either a URL or a pull channel assignment 592 593 <> 594 595The RoutingInput data is a subset of the header content of ebMS User Messages, more precisely 596the eb:UserMessage element. The routing function of an Intermediary MUST be able to parse 597and use the following meta data as its routing input:

61[Document Identifier] [DD Month YYYY] 62Copyright © OASIS Open 2005. All Rights Reserved. Page 21 of 39 598 - The mpc attribute, when present. 599 - The eb:PartyInfo element and its subelements. 600 - The eb:CollaborationInfo element and its subelements 601The routing function SHOULD be able to parse and use: 602 - The eb:MessageProperties element and its subelements, 603 - The eb:PayloadInfo element and its subelements 604An Intermediary MAY parse and use the eb:MessageInfo element. 605 606NOTE: an Intermediary MUST NOT fault a message with an eb:UserMessage element that does 607not contain and eb:MessageInfo element, and MUST consider such eb:UserMessage as a valid 608input for the routing function. 609 610The routing function must be able to route all messages that need to be forwarded by the 611intermediary, including: 612 (a) ebMS signal messages which are not also ebMS user messages; 613 (b) non-ebMS messages that are involved in facilitating the transfer and quality of service of 614 ebMS User Messages. 615 616Such messages however do not contain an eb:UserMessage element with the input needed for the 617routing function. In order to provide the routing function with the routing input these messages 618MUST contain a WS-Addressing endpoint reference parameter that includes the routing input. 619This reference parameter is defined as an element named RoutingInput and which contains 620exactly one child UserMessage element. So for non ebMS user messages like (a) and (b) above 621the SOAP header must contain the following WS-A reference parameter: 622 623 624 ... 625 626 627An ebMS Intermediary MUST be able to obtain the routing input from a message in two ways: 628 (1) By parsing the eb:Messaging header in an ebMS user message, and by extracting its 629 eb:UserMessage child element. 630 (2) By parsing the wsa reference parameter header ebint:RoutingInput and by extracting its 631 ebint:UserMessage child element. 632 633It is possible that an ebMS user message also contains a WS-A reference parameter in the SOAP 634header. In such case where both the ebint:RoutingInput and the eb:Messaging/eb:UserMessage 635elements are present in the same message, the intermediary MUST use the WS-A reference 636parameter as input for the routing function. 637 638A routing function must be able to map the ebint:RoutingInput header into either a URL (for 639pushing the forwarded message) or a pull channel. 640 641In addition to the routing function, and when message pulling must be supported, an 642Intermediary configuration MUST indicate (a) which MPCs are outbound pull channels, in case 643outbound pulling must be supported, (b) which MPCs are inbound pull channels, in case inbound 644pulling must be supported, along with the authorization credentials.

6471.7 Endpoints requirements 648 649Intermediaries are responsible for the routing of messages through the I-Cloud based on the 650routing available in the routed message. The MSH sending a message to the I-Cloud is 651responsible for providing the correctappropriate meta dataheader data in the message to allowso 652that the routing functions of the intermediaries to can perform their function and deliver the 653message to its destination. 654 655For normal ebMS user messages this poses no additional requirements on endpoints: the routing 656input is included in the eb:Messaging SOAP header block. For non ebMS user messages 657however the endpoint MUST insert one or more WS-Addressing headers and use these to carry 658routing input. The following cases are to be distinguished. 659 6601.7.1 Routing Support for Request Messages 661(i.e. messages bound to the “request” leg of an ebMS Two-way or “oneway” of an ebMS One- 662way, in case of ebMS User Messages – and messages bound to the first leg of an underlying two- 663way transport protocol, for other messages.) 664 6651. Case of ebMS User Messages: the eb:UserMessage header element contains all routing input. 666The content of these headers is determined jointly by the PMode configuration of the Sending 667endpoint and/or by the submitting message Producer. 668 6692. Case of ebMS Signal Messages: the only case of “request” ebMS signal, is the eb:PullRequest 670message (see Case 4 of On-way edge-bindings in section …). The ebms header of such messages 671does not contain an eb:UserMessage element. However, 672the PMode associated with the messages to be pulled (i.e. defining a One-way / Pull MEP) is shared 673between partners, along with the EPR of the sender of the pulled message. From this EPR is extracted 674the eb:routinginput reference parameter, added as. WS-Addressing header to the PullRequest signal. 675 6763. Case of non-ebMS messages: Such messages do not contain any eb:Messaging header (unless they 677are piggybacked on ebms Messages in which case the routing rules for these messages apply). The 678WS-Addressing headers for reference parameters contain all routing input. The content of these 679headers is determined by the PMode configuration of the Sending endpoint as in (2). 680 681a WS-A reference parameter in the SOAP header containing the meta data representing the 682destination endpoint. 683 684 685

6861.7.2 Routing Support for Response Messages 687

67[Document Identifier] [DD Month YYYY] 68Copyright © OASIS Open 2005. All Rights Reserved. Page 23 of 39 688A response message is defined as a message that is sent by the Receiver of a previous (request) 689message, in general back to the Sender of this request. For example, a “reply” message in an 690ebMS Two-way MEP. More precisely: a message that relates to a previous message in any of the 691three following ways: 692 (a) The response message is an ebMS user message that is the second leg of an ebMS two-way 693 MEP, and relates to the first message using eb:RefToMessageId 694 (b) The response message is an ebMS signal message that is referring to a previous ebMS message 695 also using eb:RefToMessageId, regardless of the type of MEP the previous message is involved 696 in and its role in the MEP. This concerns eb:Error messages and eb:Receipt messages. 697 (c) The response message is NOT an ebMS message, but an accessory message such as an RM 698 signal that is responding to a previous RM message (e.g. wsrm:CreateSequenceResponse) or to 699 a group of such messages (e.g SequenceAcknowledgment message). 700 7011. Case of ebMS User Messages: the eb:UserMessage header element contains all routing input. 702The content of these headers is determined as for request User messages. In case the wsa:ReplyTo 703header was present in the request message, and if its EPR value contains the eb:routinginput element, 704then the corresponding wsa reference parameter header block MUST be present in the response 705message – and will therefore take precedence as the routing input for the response message. In case the 706wsa:To element is present in the response message (from the wsa:Address element present in the 707wsa:ReplyTo EPR) it MAY be used as routing input by an intermediary. 708 709 7102. Case of ebMS Signal Messages: These are either eb:Errors or eb:Receipts sent in response of a 711previously received ebMS message. The ebms header of such messages does not contain an 712eb:UserMessage element. However, either one of these conditions MUST be met and decided per 713agreement between communicating parties: 714 (b1) the wsa:ReplyTo header was present in the request message, and if its EPR value contains the 715 eb:routinginput element. In that case (and unless the EPR also contains a reachable URI – see 716 Section 1.7.3) this element is used to generate a corresponding wsa header that will be used by 717 the I-Cloud routing function. 718 (b2) the PMode associated with the request message is shared between partners, and the sender of 719 the response message extracts the EPR of the initial sender from this PMode (even if it has an 720 anonymous URI). It inserts the eb:routinginput reference parameter obtained from this EPR in the 721 header of the response message. This header will be used by the I-Cloud routing function. 722 7233. Case of non-ebMS messages: Such messages do not contain any eb:Messaging header (unless they 724are piggybacked on ebms Messages in which case the routing rules for these messages apply). The same 725rules as for above case (2) apply: the routing is based on WS-Addressign reference parameter header 726eb:routinginput (unless the EPR also contains a reachable URI – see Section 1.7.3) An exception is 727made for RM protocol messages (such as Acknowledgements, or sequence management messages): In 728that case – and assuming that end-to-end reliable messaging is used - the EPR of the request sender 729MUST be specified in the wsrm:AcksTo element provided when requesting or accepting an RM sequence 730creation. Either one of the following conditions MUST be met: 731 (c1) This EPR contains the eb:routinginput element suitable for routing across the I-Cloud back to the 732 initial message sender. 733 (c2) The wsa:Address element in this EPR contains a URI identifying the request message sender so 734 that it can be used as routing input by Intermediaries or used to directly reach the Internet 735 destination, bypassing the I-Cloud and not relying on any ebMS-related routing function. 736 (c3) This EPR has an wsa:Address element that contains a URI identifying the Intermediary used by 737 the request message sender, as well as some MPC parameter, so that the message can be 738 pulled by the request sender on this MPC, piggybacked on a EmptyMessagePartitionChannel 739 warning (EBMS:0006).

7411.7.3 Interpretation of WS-Addressing header ReplyTo 742 743Case of anonymous wsa:ReplyTo: The absence of wsa:ReplyTo, or the presence of wsa:ReplyTo 744with an anonymous URI, is of no significance for the Intermediary MSH. Because the actual destination of 745the message is beyond the Intermediary, the Intermediary SHOULD NOT interpret this header as 746requiring to send the response message over the same HTTP connection (when using HTTP). This 747header is however of significance for the last hop of the multi-hop path, meaning that the first hop of the 748response message MUST be sent back over the underlying protocol back-channel (HTTP response) by 749the ultimate receiver. Once the last Intermediary received the response message over the back-channel 750of the underlying protocol, it will route the message further based on its routing function 751 752Case of non-anonymous wsa:ReplyTo: The presence of wsa:ReplyTo with a non-anonymous URI 753that can be resolved as a reachable Internet address, will indicate that the response message is not 754subject to I-Cloud routing. It should instead be directly addressed to the specified URL. It is also possible 755that the URI identifies the Intermediary used by the request message sender (i.e. Intermediary involved in 756the first hop of the request message, and assumed to also be the last Intermediary of the response). In 757that case, and if the message is not an eb:UserMessage, the EPR MUST also contain the eb:RoutingInput 758Reference parameter, so that the message can be routed to its final destination, e.g. pulled by the request 759sender on the MPC specified in the reference parameter (piggybacked on a 760EmptyMessagePartitionChannel warning - EBMS:0006). 761 762 763Case of the “I-Cloud” wsa:ReplyTo: The presence of wsa:ReplyTo with an EPR containing a 764predefined address URI set to: 765 http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/icloud 766will indicate the need to rely exclusively on the reference parameter eb:RoutingInput to route the message. 767 768In all three above cases, it is expected that the response message has a wsas:To header set to the 769address element of the wsa:ReplyTo header that was in the request message.Reverse Routing of 770Response Messages 771A response message is defined as a message that relates to a previous message in any of the three 772following ways: 773 (d) The response message is an ebMS user message that is the second leg of an ebMS two-way 774 MEP, and relates to the first message using eb:RefToMessageId 775 (e) The response message is an ebMS signal message that is referring to a previous ebMS message 776 also using eb:RefToMessageId, regardless of the type of MEP the previous message is involved 777 in and its role in the MEP. This concerns eb:Error messages and eb:Receipt messages. 778 (f) The response message is NOT an ebMS message, but an accessory message such as an RM 779 signal that is responding to a previous RM message (e.g. wsrm:CreateSequenceResponse) or to 780 a group of such messages (e.g SequenceAcknowledgment message). 781 782In all these cases, it is assumed that the original sender (of the message triggering the response, also 783called the “initial” message) is also the destination of the response message. [Jacques] Other options are 784not prohibited but not part of this specification. 785 786The routing of these response messages complies with the following rules: 787 788Case (a): The response message is an ebMS user message. Intermediaries are expected to implement a 789reverse routing function that operates similarly as for the initial message, based on routing input present 790in eb:UserMessage. In case the wsa:ReplyTo header was present in the initial message, and if its EPR 791value contains the eb:routinginput element, then the corresponding wsa reference parameter header 792block MUST be present in the response message – and will therefore become the routing input for the

73[Document Identifier] [DD Month YYYY] 74Copyright © OASIS Open 2005. All Rights Reserved. Page 25 of 39 793response message. In case the wsa:To element is present in the response message (from the 794wsa:Address element present in the wsa:ReplyTo EPR) it MAY be used as routing input by an 795intermediary. 796 797Case (b): The ebms header of such messages does not contain an eb:UserMessage element. 798However, either one of these conditions MUST be met and decided per agreement between 799communicating parties: 800 (b3) the PMode associated with the initial message is shared between partners, and the sender 801 of the response message extracts the EPR of the initial sender from this PMode (even if it 802 has an anonymous URI). It inserts the eb:routinginput reference parameter obtained from 803 this EPR in the header of the response message. 804 (b4) the EPR value that provides the eb:routinginput parameter is obtained from the 805 wsa:ReplyTo element in the initial message. 806 807Case (c): Regarding RM messages: Such messages do not contain any eb:Messaging header (unless 808they are piggybacked on ebms Messages in which case the routing rules for these messages apply). In 809that case the EPR of the initial sender MUST be specified in the wsrm:AcksTo element provided when 810requesting or accepting an RM sequence creation. Either one of the following conditions MUST be met: 811 (c4) This EPR contains the eb:routinginput element suitable for routing across the I-Cloud back to the 812 initial message sender. 813 (c5) The wsa:Address element in this EPR contains a URI identifying the initial message sender so 814 that it can be used as routing input by Intermediaries.[Jacques] or used to directly reach the 815 Internet destination, bypassing the I-Cloud? 816 (c6) [Jacques] This EPR has an wsa:Address element that contains a URI identifying the Intermediary 817 used by the initial message sender, as well as some MPC parameter, so that the message can 818 be pulled by the initial sender on this MPC, piggybacked on a EmptyMessagePartitionChannel 819 warning (EBMS:0006). 820 821 822 823For ebMS signal messages and for WS clerical messages (such as CreateSequence, 824CreateSequenceResponse, etc.) several approaches are under consideration 825 1. Define a ebMS Reference Parameter that allows the wsa attribute “isReferenceParameter” 826applied and that contains the metadata needed for routing. 827 2. Allow use of WS-Addressing headers such as From or ReplyTo or FaultTo that have an 828EndpointReference model (and include ReferenceParameter within the EPR). 829 3. For return path, if WS-Addressing Messaging-Id was present in incoming message, require 830use of RelatesTo in response message. 831 4. For using the request connection for a response, some read-only access to ReplyTo is needed 832to check for the “anonymous” URL value. 833 In this case, all intermediaries would be expected to hold the connection open (?) to allow 834the final service to use the HTTP backchannel for its response. 835 836For Pull MEP-binding, allow first intermediary to handle MPC requests and let internal I-Cloud 837arrangements for this option be implementation specific. 838 839 Error handling 840

8431.8.1 PMode Extension for Routing Input 844 845 846When it is necessary to insert reference parameters in a message, a Sending endpoint needs to get 847this information from the PMode. The PMode governing the sending messages SHOULD 848specify whether a reference parameter must be added and what should be included in the 849parameter. This requires an extension of data model for PModes as presented in the core 850specification. A new PMode feature RoutingInput is introduced to define the values to be used in 851the reference parameter. 852 853PMode.Multihop.RoutingInput.Sender.Party 854PMode. Multihop.RoutingInput.Sender.Role 855PMode. Multihop.RoutingInput.Receiver.Party 856PMode. Multihop.RoutingInput.Receiver.Role 857PMode. Multihop.RoutingInput.BusinessInfo.Service 858PMode. Multihop.RoutingInput.BusinessInfo.Action 859PMode. Multihop.RoutingInput.BusinessInfo.Properties[] 860PMode. Multihop.RoutingInput.BusinessInfo.MPC 861 862The use of its extension will generally be required for non-ebMS messages (e.g. RM protocol 863messages) and may be require for eb signals (eb:Receipt, eb:Error) although the reverse routing 864of these messages may rely on information provided in the WSA header of the related request 865message (wsa:ReplyTo). 866 867

8681.8.2 Migrating From a peer-to-peerpoint-to-point semantics to a Multihop semantics 869 870An endpoint involved inmigrating to a multihop exchange may have to modify its behavior 871compared with a point-to-point exchange. 872For example, depending on the multihop channel binding (see section 1.5) it may have to pull 873eb:Receipt messages related to pushed User messages, whereas in a point-to-point exchange the 874eb:Receipt message cwould be received over the same connection as the User message (e.g. on 875the HTTP response). 876Another example is, when using reliable messaging (WS-RM) the routing of RM signal 877messages such as CreateSequence, requires the addition of reference parameters (conforming to 878WS-Addressing) in the SOAP header. 879 880Often, when two partners who were communicating point-to-point need to migrate to a multi-hop 881configuration, it is expected they want to preserve most of the PModes that govern their point-to- 882point exchanges (security, QoS, Error reporting…). 883In order to minimize the impact over an already deployed endpoint MSH when upgrading a 884point-to-point exchange into a multihop exchange, the existing PMode model as defined in ebMS 79[Document Identifier] [DD Month YYYY] 80Copyright © OASIS Open 2005. All Rights Reserved. Page 27 of 39 885core V3, does not need to extend to new MEP binding values in order to implement the new 886multihop bindings (edge bindings) defined in 1.5. (such as “One-way / multi-push”, etc.). 887 888The following rules will apply to automatically extend to a multi-hop semantics the PMode 889parameters values specified in Core V3 for PMode.MEP and PMode.MEPbinding: 890 891  (Rule 1) Whereas these parameters were meant to define the exchange between an 892 Initiator and a Responder endpoints in a peer-to-peerpoint-to-point context, they are 893 meant to define the exchange between the Initiator MSH and the first Intermediary 894 MSH in a multi-hop path, when interpreted by the Initiator (i.e. when the PMode is 895 deployed on the Initiator). 896 897  (Rule 2) Whereas these parameters were meant to define the exchange between an 898 Initiator and a Responder endpoints in a point-to-point peer-to-peer context, they are 899 meant to define the exchange between the last Intermediary MSH and the Responder 900 MSH in a multi-hop path, when interpreted by the Responder (i.e. when the PMode is 901 deployed on the Responder). 902 903  (Rule 3) These PMode parameters have no effect on the mode of transfer (either pulling 904 or pushing) over each segment hop of the portion of the multi-hop path across inside the 905 I-Cloud, as this is governed by the routing function which also dictates the mode of 906 transfer associated with an MPC, separately for inbound and outbound traffic over this 907 MPC. 908 909The above rules ensure that a pair of point-to-point peer-to-peer partners can migrate to a multi- 910hop context with minimal changes or no changes in their PMode configuration. 911 912(will need an update or removal: ) 913

82[Document Identifier] [DD Month YYYY] 83Copyright © OASIS Open 2005. All Rights Reserved. Page 28 of 39 9141.8.3 When migrating from a peer-to-peer context to a multi-hop context, the actual MEP 915 binding (as determined by thePMode parameters: PMode.MEP and 916 PMode.MEPbinding) will be determined as follows: 9171.8.4 9181.8.5

9191.8.6 A One-way / Push MEP in the PMode is interpreted as a One-way / Push-then-Push 920 in a multihop context (regardless of what transfer mode the ICloud is doing 921 between its nodes). 9221.8.7 A One-way / Pull MEP in the PMode is interpreted as a One-way / Pull-then-Pull in a 923 multihop context. 9241.8.8 9251.8.9 A Two-way / Sync MEP in the PMode is interpreted as a Two-way / All-Sync in a 926 multihop context. (NOTE: this MEP requires the first intermediary to keep its 927 connections open) 9281.8.10 9291.8.11 9301.8.12 However, these above cases only represent a subset of multihop channel 931 bindings, where the same PMode parameters apply to both endpoints. 9321.8.13 9331.8.14 In case a different binding is needed, each endpoint or one of them must change 934 its PMode, for the same type of message. 9351.8.15 9361.8.16 For example: 9371.8.17 9381.8.18 Assume a Two-way / Push-then-Sync-then-Pull multihop channel binding. As 939 opposed to previous cases, different PMode MEP parameters must be used on 940 Initiator and Responder sides. 9411.8.19 On the Initiator side, the PMode should specify: Two-way / Push-and-Pull 9421.8.20 On the Responder side, the PMode should specify: Two-way / Sync 9431.8.21 9441.8.22 In case the two endpoints were already communicating in a peer-to-peer mode 945 before migrating to a multi-hop context, they would likely use a Two-way / Sync 946 MEP. This means that only the Initiator must modify its behavior (and PMode) 947 when migrating to multihop. 9481.8.23 9491.8.24 The following table shows how MEP multihop channel bindings are configured in 950 the PMode parameters MEP and MEPbinding deloyed on each endpoint, using 951 conventional values defined in Core V3: 9521.8.25 9531.8.26 (TO REMOVE) 9541.8.27 9551.8.28 One-way / Push-then-Push : 9561.8.29 Sender: as PMode.Initiator – MEP and binding = One-way / Push 9571.8.30 Receiver: as PMode.Responder - MEP and binding = One-way / Push 9581.8.31 One-way / Push-then-Pull : 9591.8.32 Sender: as PMode.Initiator - MEP and binding = One-way / Push 9601.8.33 Receiver: as PMode.Initiator - MEP and binding = One-way / Pull 9611.8.34 One-way / Pull-then-Push:

85[Document Identifier] [DD Month YYYY] 86Copyright © OASIS Open 2005. All Rights Reserved. Page 29 of 39 9621.8.35 Sender: as PMode.Responder - MEP and binding = One-way / Pull 9631.8.36 Receiver: as PMode.Responder: MEP and binding = One-way / Push 9641.8.37 One-way / Pull-then-Pull: 9651.8.38 Sender: as PMode.Responder - MEP and binding = One-way / Pull 9661.8.39 Receiver: as PMode.Initiator - MEP and binding = One-way / Pull 9671.8.40 9681.8.41 Two-way / Push-then-Push-Twice: 9691.8.42 Request Sender: as PMode.Initiator - MEP and binding = Two-way / Push-and- 970 Push. 9711.8.43 Request Receiver: as PMode.Responder - MEP and binding = Two-way / Push-and- 972 Push

9731.8.44 Two-way / Push-then-Pull-Twice 9741.8.45 Request Sender: as PMode.Initiator - MEP and binding = Two-way / Push-and-Pull 9751.8.46 Request Receiver: as PMode.Responder - MEP and binding = Two-way / Pull-and- 976 Push

9771.8.47 Two-way / Push-then-Sync-then-Pull: 9781.8.48 Request Sender: as PMode.Initiator - MEP and binding = Two-way / Push-and-Pull 9791.8.49 Request Receiver: as PMode.Responder - MEP and binding = Two-way / Sync

9801.8.50 Two-way / All-Sync: 9811.8.51 Request Sender: as PMode.Initiator - MEP and binding = Two-way / Sync 9821.8.52 Request Receiver: as PMode.Responder - MEP and binding = Two-way / Sync

9831.8.53 9841.8.54

9851.8.55 The case of signals (eb:Receipt, eb:Error, RM Acks)Controlling All Aspects of 986 Edge-bindings with P-Modes 987 988As previously explained, the P-Mode only controls the message transfer over the edge-hops of a multi- 989hop path. Since there are two edge-hops in such a path (the “first” hop and the “last” hop), it is expected 990that different deployment conditions and restrictions on each end of this path will lead to different P- 991Modes. Consequently, two different P-Modes may have to be deployed to control the same multi-hop 992exchange. For example, different MEP channel bindings may need be defined for each edge-hop of the 993same multi-hop exchange, as described in Section 1.5. 994Although several parameters of a P-Mode that has been defined for point-to-point exchanges will not 995change when migrating to multi-hop, others must be adjusted. (here we need to expand on what are the 996possible combinations for the related PMode parameters, that are compatible with the above multihop 997channel bindings.) 998Depending on the selected edge-binding combinations (see section 1.5) the following PMode parameters 999must be adjusted when migrating from point-to-point to multi-hop: 1000 10011. General PMode parameters: 1002PMode.MEPbinding : as explained in Section 1.5,, the value of this parameter may vary from one side of 1003a multi-hop path (say, first edge-hop) to the other side (say, last edge-hop).

1005 7. Protocol PMode parameters:

1006PMode[1].Protocol.Address: The PMode deployed on the Initiator side will update this to the URL of 1007the immediate Intermediary MSH. (In case of a Pull MEP binding where the endpoint MSH acts as 1008Initiator, this address indicates the URL of the Intermediary to be pulled from.)

1009 8. Error handling PMode parameters:

1010PMode[1].ErrorHandling.Report.AsResponse: This parameter only concerns the receiving side of an 1011ebMS message. It may need be modified as it may no longer be the same for each edge-hop of the same 1012path. This will be more often the case for the Sender endpoint (first hop) than for the Receiver destination 1013endpoint. For example, the first edge-binding may not be able to keep the transport connection open to 1014wait for the error generated by the ultimate destination endpoint. In that case, the value will be “false” on 1015the Sender side, while it may still be “true” on the Receiver side

1016 9. Reliability PMode parameters:

1017PMode[1].Reliability.AtLeastOnce.Contract.AckResponse:

1018PMode[1].Reliability.AtLeastOnce.ReplyPattern:

1019 10. Security PMode parameters:

1020PMode[1].Security.SendReceipt.ReplyPattern:

1024 1025

10261.8.56 PMode extension for Routing Info 1027 1028 1029When it is necessary to insert reference parameters in a message, a Sending endpoint needs to get 1030this information from the PMode. The PMode governing the sending messages SHOULD 1031specify whether a reference parameter must be added and what should be included in the 1032parameter. This requires an extension of data model for PModes as presented in the core 1033specification. A new PMode feature RoutingInput is introduced to define the values to be used in 1034the reference parameter. 1035 1036PMode.Multihop.RoutingInput.Sender.Party 1037PMode. Multihop.RoutingInput.Sender.Role 1038PMode. Multihop.RoutingInput.Receiver.Party 1039PMode. Multihop.RoutingInput.Receiver.Role 1040PMode. Multihop.RoutingInput.BusinessInfo.Service 1041PMode. Multihop.RoutingInput.BusinessInfo.Action 1042PMode. Multihop.RoutingInput.BusinessInfo.Properties[] 1043PMode. Multihop.RoutingInput.BusinessInfo.MPC 1044 1045The use of its extension will generally be required for non-ebMS messages (e.g. RM protocol 1046messages) and may be require for eb signals (eb:Receipt, eb:Error) although the reverse routing 1047of these messages may rely on information provided in the WSA header of the related request 1048message (wsa:ReplyTo). 1049

10501.9 WS-A Reference Parameter Definition 1051 1052 1053The embedded UserMessage element is conforming to the XML schema defined for the similar 1054element in the packaging section of Core V3, except for the eb:MessageInfo element which can 1055be absent here. 1056 1057NOTE: The UserMessage element in the reference parameter is in a different namespace than the 1058UserMessage element from the Core spec because it allows for the MessageInfo element to be 1059absent and therefore must be redefined for use in the reference parameter. The namesp 1060 94[Document Identifier] [DD Month YYYY] 95Copyright © OASIS Open 2005. All Rights Reserved. Page 32 of 39 10611.10 Reliable Multihop 1062 Establishing a Reliable Sequence with WS-ReliableMessaging (requirements on Endpoint MSHs…) 1063 An endpoint MSH MUST be able to control which reliable (RM) sequence is used by the User 1064 Message it sends. This includes the ability to initiate RM sequences as required by the PModes of 1065 messages to be sent. The main difference between a multi-hop environment and a peer-to-peer 1066 environment, is the need to add routing input to RM Lifecycle Messages (CreateSequence, 1067 CloseSequence, TerminateSequence) in a multi-hop environment. This routing input is obtained from 1068 References Parameters associated with the destination EPR (of which the Address element is either 1069 unknown or unreachable directly, justifying the use of routing). Such Reference Parameter value 1070 SHOULD be specified in the PMode.RoutingInput parameter associated with the sender. 1071 The response to CreateSequence may be obtained in one of three ways, described in Case(c) of 1.6. 1072 (describe what happens on the destination side. Is the endpoint always supposed to send 1073 CreateSequenceResponse as a callback, or do we assume that an wsa:ReplyTo of “anonymous” 1074 value is only meaningful for the ultimate destination (the one actually replying) and should be ignored 1075 by Intermediaries? Is ReplyTo anonymous prohibited or which semantics does it have for 1076 intermediaries?) 1077 The process to establish an RM sequence is illustrated in the flow diagram of Section 1.9.1. 1078 1079 Routing of response RM signals (use of WS-a headers, ref parameters…) 1080 As described in section 1.6. Should describe routing of Acks, RM Errors, RM Lifecycle responses. 1081 Case of non-addressable endpoints 1082 (no need for it: handled in previous sections) 1083 The case of WS-Reliability conformance profiles 1084

10851.11 Flow Diagrams for Multi-hop 1086

10871.11.1 Reliable Sequence Establishment 1088 1089 1090 1091

97[Document Identifier] [DD Month YYYY] 98Copyright © OASIS Open 2005. All Rights Reserved. Page 33 of 39 1092 1093  Step 1: The Sending party submits a User message to its endpoint MSH A. The MSH resolves 1094 which PMode / CPA is associated with this message so that it knows its processing mode (which 1095 level of security, reliability, MEP…). In this case, the PMode requires that its related messages 1096 need be sent reliably, i.e. that an RM sequence needs be initiated for these. 1097  Step 2: The Sending endpoint MSH A determines where to send this message – here to an 1098 ebMS Intermediary – by getting the Intermediary URL from its PMode / CPA configuration 1099  Step 3: MSH A is initiating a wsrm:CreateSequence message to the Intermediary (unless an RM 1100 sequence already exists for this PMode / CPA). Because the PMode also contains a wsa EPR for 1101 the destination, including the Reference Parameter eb:routinginput that replicates a significant 1102 subset of the ebMS header data associated with this PMode (data that will be common to all User 1103 Messages sent for this PMode), the MSH piggybacks this Reference Parameter on the 1104 wsrm:CreateSequence message for routing purpose. 1105 o NOTE: because the destination URL is unknown (dynamically resolved by I-Cloud 1106 routing), the destination EPR is containing a filler value instead: 1107 http://www.w3.org/2005/08/addressing/anonymous, which has no special meaning in 1108 case of a SOAP Request. The header wsa:To is absent from the wsrm:CS message. 1109  Step 4: The First Intermediary receives the wsrm:CreateSequence message, and forwards it 1110 using a routing function that uses ebMS header data (regardless whether this data is wrapped 1111 into an ebMS header or into the eb:routinginput wsa Ref Parameters headers). In this case the 1112 routing data is in wsa Reference Parameters. 1113  Step 5: At the end of the routing path, the Last Intermediary gets the wsrm:CreateSequence 1114 message. Two options must be supported depending on the MEP required by the destination 1115 endpoint (MSH B):

100[Document Identifier] [DD Month YYYY] 101Copyright © OASIS Open 2005. All Rights Reserved. Page 34 of 39 1116 o Push MEP: The Last Intermediary keeps routing the wsrm:CS in a push mode to the 1117 destination endpoint (MSH B). The content of wsrm:AcksTo will determine how the 1118 wsrm:CSR is sent back. 1119 o Pull MEP: The Last Intermediary is aware that the reference parameter associated with 1120 the wsrm:CS calls for a Pull mode. Among these parameters, is a mention of the MPC 1121 where messages for this sequence will be pulled from. The Intermediary MAY piggyback 1122 on the wsrm:CS a dummy eb:Header with a non-effective Service value ( 1123 http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service). 1124 The intermediary MUST assign the wsrm:CS message to the related MPC so 1125 that the message becomes subject to pulling using eb:PullRequest 1126 targeted to this MPC. 1127 . EDITOR NOTE: an alternative could have used wsmc:MakeConnection to pull 1128 such signals. However, the use of MC would not be able to use the most 1129 standard cases (pulling based on sequence ID, and pulling based on 1130 wsa:Address) due to the multihop context. Consequently MC extensibility points 1131 would have to be used, to pull based on MPC. Because of this level of 1132 customization there is little advantage in using the wsmc standard, and it 1133 becomes simpler and more reliable to rely on a unique pulling mechanism – 1134 eb:PullRequest – for all messages related to a sequence. 1135 1136  Step 6: The RM module in MSH B takes knowledge of the wsrm:AcksTo element contained in the 1137 wsrm:CS message. The wsrm:AcksTo element value indicates the EPR where the wsrm:CSR 1138 must be sent back. Indeed, in the ebMS multihop model, RM lifecycle response messages such 1139 as CSR must be sent to the same destination as RM acknowledgment. The wsrm:AcksTo 1140 element is itself an EPR that sufficiently identifies the initial Sending MSH so that the I-Cloud can 1141 route the wsrm:CSR back to MSH A. The following cases need to be supported, depending on 1142 how the wsrm:CS was transmitted: 1143 o Pushed wsrm:CS: The wsrm:CSR is sent back based on the wsrm:AcksTo content. If it 1144 were an anonymous URI, the CSR is sent over the backchannel of the wsrm:CS, from 1145 the RM module of MSH B to the Last Intermediary. In all cases, the eb:routinginput 1146 Reference Parameter, if present in the AcksTo EPR, is added to the wsrm:CSR 1147 message. The routing of wsrm:CSR is based on this reference parameter. In a special 1148 case where the AcksTo gives the URL of the destination (MSH A) and this destination 1149 can directly be resolved without ebMS-level routing, the RM module can directly send it 1150 back to MSH A. 1151 o Pulled wsrm:CS: The wsrm:CSR is sent over a new HTTP connection to the I-Cloud. 1152 The eb:routinginput Reference Parameter in the AcksTo EPR is added to the wsrm:CSR 1153 for routing. 1154 o NOTE: In both cases the wsrm:CSR MAY be sent to a node of the I-Cloud other than the 1155 last Intermediary involved in routing the wsrm:CS message. This depends on how the 1156 AcksTo EPR is to be resolved by the I-Cloud. 1157  Step 7: In case the routing of wsrm:CSR involves the initial First Intermediary, the latter gets the 1158 wsrm:CSR with sequence ID. Here, the same procedure as for Step 5 takes place for transmitting 1159 the wsrm:CSR to MSH A, allowing for both Push and Pull options. 1160 1161 In the above process, it must be noted that: 1162 - the endpoint MSHs have the ability to insert and parse WS-addressing EPRs. 1163 - The ebMS intermediary in contact with the destination endpoint MSH, must know part of the 1164 PModes especially in case of message pulling from the endpoint. 1165 .

1168 1169 1170  Step 1: The Sending party submits a User message to its endpoint MSH A. The MSH resolves 1171 which PMode / CPA is associated with this message so that it knows its processing mode (P- 1172 Mode) In this case, the P-Mode is already associated with a Reliable Messaging (RM) sequence. 1173  Step 2: The Sending endpoint MSH A determines where to send this message – here to an 1174 ebMS Intermediary 1175  Step 3: The First Intermediary receives the User message, and forwards it using a routing 1176 function that uses ebMS header data. 1177  Step 4: At the end of the routing path, the Last Intermediary gets the User message. Two options 1178 must be supported depending on the MEP required by the destination endpoint (MSH B): 1179 o Push MEP: The Last Intermediary keeps routing the User message in a push mode to 1180 the destination endpoint (MSH B). 1181 o Pull MEP: The Last Intermediary is aware that the P-Mode associated with the User 1182 message calls for a Pull mode. The message is assigned to a Pull channel (MPC). 1183  Step 5: The RM module in MSH B sends back a wsrm:SequenceAcknowledgment based on the 1184 content of wsrm:AcksTo. It will be routed in the same way as the wsrm:CSR during the sequence 1185 establishment. In case where the User message was pulled from the last Intermediary, and if the 1186 resolution of wsrm:AcksTo is compatible with using this last Intermediary for routing

106[Document Identifier] [DD Month YYYY] 107Copyright © OASIS Open 2005. All Rights Reserved. Page 36 of 39 1187 acknowledgments, then the wsrm:SequenceAcknowledgment header may be piggybacked on the 1188 eb:PullRequest message. 1189  Step 6: In case the routing of wsrm:SequenceAcknowledgment involves the initial First 1190 Intermediary, the wsrm:SequenceAcknowledgment message is subject to the same Push / Pull 1191 alternative as in Step 4. In case of a Pull configuration, the Intermediary will assign the 1192 wsrm:SequenceAcknowledgment to a Pull channel. The acknowledgment will be associated with 1193 an eb:Error of type warning (EBMS:0006) unless it is piggybacked with another eb message for 1194 this channel. 1195 1196

11971.11.3 Routing User Messages 1198

1199 12001.11.4 Routing ebMS Response User Messages (2-way MEPs) 1201

112[Document Identifier] [DD Month YYYY] 113Copyright © OASIS Open 2005. All Rights Reserved. Page 38 of 39 1205 1206 1207 NOTE: eb:Error signals may be sent back by Intermediaries. Need to define the types of error 1208 that an Intermediary may generate (need a new error for Routing failure?). For an Intermediary to 1209 be able to send back an Error, the request message must have wsa:ReplyTo that either specifies: 1210 – Explicitly the URL of the originating MSH (in the EPR) 1211 – The EPR Ref parameters for the originating MSH (RoutingInput) 1212 1213