My comments are inline.
Durand, Jacques R. wrote:
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 see what you mean about this MEP bridging function not describing the
situation of the endpoint. Maybe we should define addressability on the
three levels described by Pim. So we get ebMS addressability, SOAP
addressability and transport addressability. Then we can require every
endpoint to be identifiable by information in the ebMS header as
defined in the core spec for user messages. SOAP addressability could
be about the possibility to identify an endpoint by ws-a headers. And
transport addressability as the existence of an URL where messages can
I'm not sure about the need for SOAP addressability, but in some use
cases this might be usefull.
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.
No, I certainly don't want to have the weakest link have such an impact
on the whole system. But in my proposal for relayed RM I never meant to
have the intermediaries do real RM. They should just pass on the RM
signals to the next hop and not get involved in acknowledging or
resending. That functionality should be left at the endpoints. That way
the relaying could stay simpler with just a sequence relation table.
When we want to allow for "sequence splitting" like Pim described the
RM handling will be a bit more complex but I would still prefer to have
the endpoints do the resending.
On 18 mrt 2008, at 23:35, Durand, Jacques R. wrote:
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).
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.
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.
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
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.
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.
- 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
- 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.
- 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".
- 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