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:]
Sent: Wednesday, March 12, 2008 1:52
PM
To:
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
