[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebcore] CPP/CPA enhancement suggestions
A reminder that our bi-weekly CPPA SC is today.
Here are some additional comments, following up from my
email of September 3rd.
http://www.oasis-open.org/apps/group_public/email/ebcore/200
909/msg00005.html
I continue the numbering from that email.
6) WS-A EPR and synchronous business responses
(Follow up on (5) in earlier email, replacing the
@usesTransportBackChannel attribute by anonymous EPR).
In CPA 2.0 and the draft 3.0, synchronous business responses
are modelled using nesting. In the CollaborationInfo
structure of the initiator, there is a CanSend element (or
ActionBinding equivalent) that can have an CanSend.
Similarly, the responder has a CanReceive with a nested
CanSend.
In a CPP, multiple DeliveryChannels can be used to express
alternatives. However, if a partner supports synchronous
and asynchronous responses, this can not be expressed as
separate DeliveryChannel options, that can be selected by
CPP intersection. You have to have multiple CanSends (resp.
CanReceive etc.), one with an embedded CanReceive, and
another without one.
An simple alternative way to express synchronous responses
is to adopt WS-Addressing and the anonymous EPR. Then we
can describe the "response" message in the CPP as having two
alternative channels: one with a proper URL (that can be
HTTP posted to asynchronously) and another with an
http://www.w3.org/2005/08/addressing/anonymous EPR.
To accomodate this, we should change DeliveryChannelType to
have either a transportId reference or reference to an EPR,
as a transport reference is not needed. (In the approach
with synchronous replies as nesting, there still is a
required reference from the embedded action binding, though
it is not used).
We need the EPR change and optional transport anyway for
multihop:
7) Multiple channels
With multihop, some agreement parameters are end-to-end
(sender and ultimate recipient), and others are between
endpoints and edge intermediary (see section 2.8.2 and 2.8.3
in the Part 2 draft). The partner agreement is only about
the end-to-end agreement. We could extend the CPP to extend
each delivery channel option from a single channel reference
to multiple
<tp:ChannelId>channelEndToEnd
localchannel</tp:ChannelId>
Where each channel is tagged with a role:
<tp:DeliveryChannel tp:channelId="channelEndToEnd"
tp:eprId="icloudepr"
tp:docExchangeId="docExchangeA1"
role="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part
2/200811/nextmsh">
<tp:DeliveryChannel tp:channelId="localchannel"
tp:transportId="firstintermediary"
tp:docExchangeId="docExchangeA1"
role="http://www.w3.org/2003/05/soap-envelope/role/next";>
For CPA formation, only the delivery channel with the role
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/2008
11/nextmsh is relevant.
The icloudepr would reference the ebMS 3.0 part 2 icloud EPR
and reference parameter.
<wsa:EndpointReference xml:id="icloudepr">
<wsa:Address>http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/
ns/part2/200811/icloud</wsa:Address>
<wsa:ReferenceParameters>
<ebint:RoutingInput>
<ebint:UserMessage>...</ebint:UserMessage>
</ebint:RoutingInput>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
The "localchannel" can be considered "private" information,
not published to partners, but shared with the intermediary
so it can validate that there are routing rules, pull
channels can be set up for the MPCs etc. It would reference
the actual endpoint URL of the intermediary for outgoing
messages
<Endpoint
uri="https://intermediary.example.com/ebxml3handler"; />
And the private endpoint of the partner.
<Endpoint
uri="https://partnerA.example.com/ebxml3handler"; />
Questions / comments:
- Is having the EPR at the same level as transport enough,
or should the EPR be part of a WSA section in DocExchange
(see (2) in previous email below).
- Having separate channels for different roles nicely
supports addressing special types of intermediaries (other
than ebMS intermediaries) that need to be targeted, setting
up header blocks for those intermediaries to process.
- Is using
"http://www.w3.org/2003/05/soap-envelope/role/next"; to
reference the edge intermediary ok ?
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 03 September 2009 22:56
To: ebcore@lists.oasis-open.org
Subject: [ebcore] CPP/CPA enhancement suggestions
Here are some brief descriptions of potential enhancement
requests for ebXML CPP/CPA, for tomorrow's meeting.
Depending on interest from the TC, these could be developed
further.
Warning: these are rough ideas, hopefully the description
conveys the general ideas.
1) Supporting end-to-end agreements in multihop: abstracting
from hop-specific parameters
In the current CPP/CPA schema, a <DeliveryChannel> defines
both quality of service (security, reliability) that applies
"end-to-end" and settings that are different from hop to
hop. The transport <Endpoint>, SSL settings and MEP binding
(pull or push) are between the initiator and the first hop,
and between the responder and the last hop. They are not
end-to-end agreement features.
Requirement: allow partner agreements that abstract from the
per-hop settings and express only the end-to-end settings.
This hides the local parameters and allows both partners to
use the exact same agreement.
A simple option is to make @transportId in <DeliveryChannel>
optional. The CPA is then the same for sender and recipient
and can be digitally signed. The transport configuration is
declared out of scope for the agreement.
Analogy to email: our ebMS header and WS-A routing parameter
are structures for end-to-end routing, like the RFC 2822
email address "user@domain". The sender has its private
settings for SMTP and recipient for IMAP/POP3 servers, and
both can reconfigure them independently and without the
other party knowing, as long as the edge hops can establish
a message forwarding path.
In this case a CPA no longer is sufficient to fully
configure an ebMS MSH, like CPA 2.0 XML documents are today.
The missing information needs to be added to each
deliveryChannel so that the MSH can function properly. We
could leave how this is done to products or define a
standard XML format for it. The missing information plus the
end-to-end agreements can be merged to generate a classic,
complete CPA. But that "CPA" could be different for sender
and recipient, especially if there is more than one
intermediary.
Note that this is already the case with ebMS 2.0 if e.g. one
party uses an SSL terminator and the other does not: the
<Transport> elements in the CPA are already different.
(Note: this mapping from channels or messages to "local"
transport configurations is like the unspecified "routing
function" that intermediaries must implement. See an earlier
proposal in
http://lists.oasis-open.org/archives/ebxml-cppa/200811/msg00
000.html. )
2) Extending <DocExchange> and using WS-Addressing
In Part 2 we are using WS-Addressing. The
<ebXMLSenderBinding> and <ebXMLReceiverBinding> elements now
have sections for (end-to-end) security and reliability. The
<DocExchange> element should contain information that
expresses whether the exhange is point-to-point
(default) or multihop. If multihop, we could use some
defined attribute value to express that the forward EPR
reference parameter is constructed using the default
algorithm (which constructs an EPR that mirros an ebMS
UserMessage). The DocExchange group would then be reusable
for many different service/action combinations.
We could also allow explicitly setting other WSA fields like
Reply-To.
3) Delivery channels for "response" signals
With some delivery channels there are associated signals:
pull requests, errors, acknowledgements, receipts. These
can all use EPRs in a multihop context. If one of these EPRs
does not use the default values mentioned in the spec, the
DeliveryChannel should specify this EPR explicitly and
therefore becomes less reusable.
The CPA 3.0 draft XSD has an Endpoint type that can express
whether an endpoint is used for various uses (e.g. errors).
It may be more flexible to have separate explicit delivery
channels for these signals and have a reference from the
<DeliveryChannel> that is used for the business message to
e.g. an @errorChannel, @initiatingChannel (for Pull or
Sync), @receiptChannel, @errorChannel. That way, for each
signal associated with a channel you can set security,
addressing and other parameters explicitly. (Using
@defaultMshChannelId and OverrideMshActionBinding, you can
set global defaults for all signal channels, or channels of
some type, but there is a need to be able to set this per
delivery channel).
4) Configuring PullRequest
We now support the ebMS 3.0 "pull" feature in CPA 3.0 draft
by having an <Endpoint> element on the <TransportSender>
element. (Section
4.3.8 of the latest CPA 3.0 draft). This expresses that the
sender acts as the HTTP server, unlike in CPPA 2.0 where the
HTTP server endpoint is always associated with the receiver.
This is not enough to fully configure the ebMS 3.0
PullRequest. The pull request may be secured using
WS-Security, it may or may not be sent reliably, and may or
may not have WS-Addressing configuration (routing
parameters). I think the PullRequest should have its own
DeliveryChannel (even in regular point-to-point ebMS) and
there could be a reference @initiatingSignalChannel from the
business message <DeliveryChannel> element to the channel
that the pull request uses.
In multihop, we have distinguished two cases:
- Local pulling: only an edge intermediary needs to be aware
of, and configured for, the pulling. Pull requests are not
reliable:
end-to-end retransmission; authorisation with intermediary
locally.
- End-to-end pulling: here we have subcases based on routing
based on the @mpc (no reference parameter needed) or routing
using a reference parameters. Global authorisation:
receiver has authorisation agreement with sender.
So the proposed @pullRequest parameter (that links a
delivery channel for a business message to the delivery
channel for the pull request
signal) is either an end-to-end configuration, agreed
between sender and recipient, or a local configuration.
5) Synchronous responses
The CPA 2.0 used nesting of CanReceive in CanSend (or vice
versa) to indicate synchronous responses. The new
ActionBinding elements can also be nested. I would like to
have a way of expressing that a message on some channel is
using the transport backchannel, other than nesting but by
just using a different DeliveryChannel. This way, whether
or not a CanReceive is a synchronous response to a CanSend,
is expressed in the channel, not by nesting.
Motivation: in a CPP, you could have say 3 CanSends and 5
CanReceives.
These are associated with one or more DeliveryChannels. In
CPP intersection those channels are matched against another
CPP that should have 3 CanReceives and 5 CanSends. If
synchronous response is expressed as nesting, a partner that
supports synchronous and asynchronous will have a duplicate
ActionBinding, one with a nested ActionBinding and the other
without one. It is simpler if there is just a single
mechanism (multiple alternative <DeliveryChannel>
elements) to express this. CPP intersection is must simpler.
There already is a @syncReplyMode parameter in the CPP/CPA,
but it is in MessagingCharacteristics which is optional. We
could have an attribute @usesTransportBackChannel with
default value false. If true, there could be an
@initiatingDeliveryChannelId parameter that identifies the
other delivery channel that a particular channel uses the
backchannel from.
These two parameters could also be used for PullRequest as
in (4) to reference the pull request delivery channel that
the message uses the backchannel of.
------------------------------------------------------------
---------
To unsubscribe from this mail list, you must leave the OASIS
TC that generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]