OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] Groups - Transparent MEP routing proposal V0.1 (ebMS-transparent-Multihop-MEPs-Routng.doc) uploaded


 

Hello Jacques,

Here are some quick comments on this proposal (and some earlier documents):
 
1)  What does "no additional capability besides Core ebMS V3 is required from the endpoint MSHs involved at the boundaries of the I-Cloud" mean?  The proposal describes a requirement that "The PMode parameter PMode.Protocol.Address contains the Hub URL, the value of which must be extended with an HTTP Query of the form: ?pmode=<ID>".  In this proposal, any support for multihop would mean the ebMS 3.0 processor must append this query to the hub URL.  I don't know if any of the few existing ebMS 3.0 processors support this ability to update the hub URL today, and it may not be easy to add this behaviour to an existing SOAP stack. Or are we assuming this is configured statically by users, e.g. in the CPA?   In a CPA with a dozen CanSends, each would be connected with a DeliveryChannel that references a Transport element that contains a URL that include a substring naming that same DeliveryChannel. We would be missing a generalization, which users and implementers will object to.
 
2)  This proposal is based on features of HTTP as an underlying transport protocol.  Even if most ebMS implementations will use HTTP, the idea that an ebMS multihop functionality ("level 3" in my earlier terminology) has dependencies with transport protocols (two levels lower) does not seem right architecturally. If someone defined another transport protocol binding than HTTP for ebMS 3 0 (e.g. SMTP or JMS), he should be able to use our multihop solution with those other lower level transport protocols.
 
3)  Page 5 "Step 4: The Hub receives the message, and closes the HTTP connection (asynchronous case). The Hub determines where this User Message must be sent, using routing function based on ebMS header data".  It would be better if the Hub does a routability check (do I have a configuration rule that tells me where to forward this message to?) before closing the connection.  If it does not know how to forward the message, the Hub could then return an ebMS error directly.  This means that a sender in a multihop context could receive errors from both the ultimate recipient (as in the peer to peer case) and from intermediaries.
 
4)  I have been thinking of an alternative way to do what you want using this appended query.  An alternative that to me seems more in the spirit of the SOAP processing model, would be to allow messages to contain more than one eb:Messaging SOAP header element.   One eb:Messaging block would be targeted at ebMS intermediary nodes, identified using a separate "target" attribute.  The other would be targeted at the true recipient, as in v3.0 Core. The idea is analogous to having multiple WS-Security header blocks, targeted at multiple SOAP nodes. Given our goal to converge with WS-* specifications, it seems best to leverage their type of solutions to similar problems.
 
The only required (compatible) update to the ebMS v3 0 schema is to add an optional "target" attribute to eb:Messaging.
 
The eb:Message block targeted at the intermediary could be used in various situations:
-  When sending a wsrm:CreateSequence message, it would serve to provide rich business document routingheader content (To/PartyId, Service) to enable the sequence to be established with the right recipient MSH.  Like the appended "?pmode=<ID>", this second header is not explicitly mentioned in v3 0 Core.  But v3 0 Core is assumed to be composable with other WS-* specifications not discussed in v3 0 Core (say, WS-Addressing or WS-SecureConversation) like any well-designed WS spec without this having to be described in the v3 0 spec.  It may be an acceptable price to pay, even for Endpoints.  In a Web Browser you have to configure something in your client to use an HTTP proxy too, after all.
- But the Sending endpoint could use the appended "?pmode=<ID>" trick to pass information to the first intermediary that would allow to create the second ebMS header block as in your proposal, if it somehow cannot be modified to create this second block itself.
-  Intermediaries could have same default logic as ebMS 2.0 to reverse route any ebMS (user or signal) message by reversing eb:From and eb:To, copying eb:Service, eb:Action, eb:ConversationId, eb:AgreementRef and setting eb:RefToMessageId based on incoming eb:MessageId. We only need to think of a value for eb:Action. This model could be used to return a standalone wsrm:CreateSequenceResponse to the sending MSH.
-  When sending an eb:Messaging/eb:SignalMessage, adding a eb:Messaging[@target='intermediary'] structure could provide rich header data to allow the signal to be routed across hops, even though the Signal itself lacks business semantics.   This would even work for PullRequest which unlike eb:Receipt and errors is not a response message, where the trick of rerouting based on retrieving data from the preceding UserMessage using MessageId/RefToMessageId would not work.
-  When sending an eb:Messaging/eb:UserMessage, adding a eb:Messaging[@target='intermediary'] structure would not be necessary, if the ebMS header is not encrypted, so that its header elements can be used for routing.
-  When sending an eb:Messaging/eb:UserMessage, adding a eb:Messaging[@target='intermediary'] structure would allow the end-to-end ebMS header to be encrypted by the first intermediary and decrypted by the last one or by the recipient.  This has some advantages in cases where (some of the) header data is sensitive too.  The eb:Messaging structure targeted at the intermediary could be copied from the end-to-end headers, or it could have some derived generalized content (e.g. mapping many From/PartyIds to a more general PartyId, e.g. the one of the first intermediary).  This would greatly simplify the maintenance of routing tables at the intermediary, which would just have to know how to get from one intermediary to another, not from any endpoint to any other endpoint.  In realistic use cases (e.g. hubs linking geographies, or various sectors) there could be in the order of dozens of intermediaries serving thousands of endpoints.
- The last intermediary could remove this header block before forwarding the message to the Endpoint, as in your proposal.
- The second ebMS header would never be needed in peer-to-peer ebMS messaging.
 
Note: the above attempts to use routing based on ebMS header data for all ebMS traffic and WSRM lifecycle messages.  This does not preclude the use of optimized routing information, as in your proposal.  If the endpoint somehow pre-computes a way to express the HTTP URL of the ultimate recipient in a WS-Addressing header, as a custom header, as an HTTP URL or as an IP address, this could be encoded in the SOAP structure too.  But before we look at optimizations, I wanted to make sure the ebMS 2.0 style of header-based routing can be used to cover end-to-end routing of user messages, signals and reliability messages.
 
Pim
 
 
 
 
 
 
 
 
 
 
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]