Sander:
From: Sander Fieten
[mailto:]
Sent: Tuesday, March 18, 2008 4:34
PM
To:
Subject: Re:
[ebxml-msg] Some ebms-level routing use cases?
Jacques,
I agree we should use one term for this. In the requirements document I
mentioned a function called MEP bridging. I think this could describe what
we want from the intermediary, namely converting the one-way push to a one-way
pull.
This will however not restrict the possibility of identifying the endpoint
where the message should be delivered.
- MEP bridging is fine for describing the ability for an
intermediary to forward a message using a different kind of
MEP.
But so far, that is not a substitute for describing an
endpoint that is not reachable by a request of the underlying protocol, e.g.
simply because it does not have an IP address.
I also agree with you that the RM configuration should be configured in
such a way that it doesn't unnecessarily resend messages. But I would always
configure RM to have resends minimized, i.e. allow the maximum time possible to
stay within business requirement before resending. That way a pull on the last
segment of the path may not lead to RM configuration changes further down the
path.
- but are we saying that just because there is
an endpoint MSH connected to the I-Cloud, that is occasionally up and doing
Message pulling every 24h, the resending parameters of all the I-Cloud nodes
will be set to wait 24h before resending a non-acked message? That means all
other endpoint MSHs including those that are always connected for push, must
wait 24h for the first resending of a lost message.
And if you decide to use an "average" e.g. set
the standard resending period for the I-Cloud to 1h, then that might cause a lot
of useless resending overhead if you have many such intermittent endpoints. And
some other endpoints still will not be happy because they need a faster resend !
In essence, one size does not fit all.
Regards
Sander
On 18 mrt 2008, at 23:35, Durand, Jacques R. wrote:
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:]
Sent: Tuesday, March 18, 2008 3:05 PM
To:
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:]
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
