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] Some ebms-level routing use cases?


Sander:
 
We just need a word to describe endpoints that can't receive incoming [HTTP] requests, which we all know was a major requirement for V3, motivating a feature like Pull messaging.
 
Please suggest a word for this...
 
Regardless of how the routing is made to such endpoints, the key point is, the Intermediary needs be configured for message pulling (authorization metadata, MPC...). Therefore it must be able to do more when communicating with an endpoint than just pushing.The original sender also must be aware of this, because the RM resending parameters on one side and the pulling frequency on the other side need be adjusted in order to avoid generating a clutter of resends at each message (and in the case of relayed Acks, ALL the intermediaries on the way need to have their RM parameters adjusted).
 
Jacques
 


From: Sander Fieten [mailto:sander@fieten-it.com]
Sent: Tuesday, March 18, 2008 3:05 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Some ebms-level routing use cases?

I'm not sure if this definition of addressibility is not too narrow by focusing only on the transport level of the message exchange. I think every endpoint involved in an ebMS message exchange must in some way be uniquely identifiable / addressable by ebMS header data as defined in the core spec for user messages. If this assumption is true routing could be done based on this address.

Regards,
Sander




On 13 mrt 2008, at 19:29, Durand, Jacques R. wrote:

I suggest we use the network-level definition of "addressable", which is used in other WS-*:
Addressable = having an IP address AND able to receive incoming requests from remote partners (e.g. through firewall)
 
- When HTTP is used, that means running an HTTP server able to receive HTTP requests.
- for ebMS, that means ability to be the destination of One-way / Push MEPs.
- a non-addressable ebMS endpoint means then it can receive messages only by pulling them (or when bound to HTTP responses)
 
Jacques

 

From: Sander Fieten [mailto:sander@fieten-it.com]
Sent: Wednesday, March 12, 2008 1:52 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Some ebms-level routing use cases?

Pim,

I'm wondering about the communication constraint you mention. As you write under topology the intermediaries can identify endpoints based on PartyId, so the endpoints are addressable. 
Furthermore I think they also support the two-way push MEP beside two-way push/pull MEP.

Regards
Sander

On 12 mrt 2008, at 09:59, Pim van der Eijk wrote:

 
General business-level description:
A particular set of government services and processez is provided by agencies in different sectors reporting to different ministries, that have their own (very large) private networks.  Dozens of MSHs in various sectors, with some MSHs serving dozens or hundreds of parties.  In total a few thousand parties.
 
Topology:
Within a sector, agencies communicate via an intermediary. There is never any Endpoint to Endpoint communication. The intermediary is also the connection to agencies in other sectors (via their sector intermediary).  Each intermediary knows whether the addressed To/PartyId is connected to itself (two hops) or is connected to some other sector hub (more than two hops).
 
Routing function:
- some intermediaries are also Endpoints (sector hubs, hosting sector services).  They inspect the eb:Service to determine if they provide this service themselves (possibly on behalf of many different organizations), or need to forward the message to a separate MSH. 
when (not delivering locally but) forwarding, forwarding is based on ebMS header content: eb:To/eb:PartyId.   
 
Communication constraints:
- Branches are not addressable. Can only push, or pull. The branches only use One-way / Push MEPs for invoking the servers. Need to pull the "Signals".
 
Evolution profile:
Sometimes a business partner is first connected as an Endpoint to an intermediary, then later a Intermediary is inserted. This should not require any changes at the Endpoints other than changing the URL and TLS details. An intermediary should not have to know if the MSH it is connecting to is the Endpoint for the message, or an Intermediary that forwards it.
- PartyIds may move from one Endpoint MSH to another. Only the closest intermediary should have to take action to account for that change. No other intermediary or Endpoint should need to know (as they will still receive messages from, and send to, the same intermediary).
- Some intermediaries are also






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