OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore-cppa message

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


Subject: Use of <RelatedChannels/> for synchronous and pulled messages



Hello,

Attached is an example CPP for a partner that can send
Purchase Orders and receive Purchase Order Responses either
synchronously, asynchronously or via Pull.  

There was an earlier proposal to express Pull by an Endpoint
in SenderTransportBinding.  What I am proposing is to view a
pulled message as sent to the anonymous EPR, and having a
related channel that is the pull request.  We need that
related channel anyway to specify QoS for the pull request,
and the pull request can find the endpoint from the
ReceiverTransportBinding of the business partner, from the
partner CPA.

Please review the example as it gives a good initial
impression of what the mechanisms could look like.  

There are some notes in the attached ODT document.

I think we can use a mechanism very similar to
RelatedChannels for Bundling:  the
Pmode[].bundling.compatibility.pmodelist would be a relation
between Delivery Channels.  But that is not yet in the
example.

Pim


-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] 
Sent: 08 February 2010 11:20
To: ebcore-cppa@lists.oasis-open.org
Subject: RE: [ebcore-cppa] CPP/CPA call this Friday


Hello,

Brief notes from this call:

1)  We discussed the proposed changes and discussion.   So
far, CPPA has attempted to be maximally compatible with
version 2.0.  Some of the new constructs (like
RelatedChannels) are covering and extending the
functionality of MessagingCharacteristics.  The spec needs
to indicate which features are included for compatibility
and make recommendations how new CPAs should be set up.

The concept of RelatedChannels can also be used to cover
synchronous replies and Pull mode.  Pim will send an update
some time this week with examples for the next meeting
(which is this Friday, February 12).   

We also need to talk more about the concept of multiple CPAs
(with business partners, intermediaries) at the same time
and how CPA formation would work.

2)  We looked at Cristiano's input.  Pete and Dale think
that the current schema can accomodate his need, as there is
an extensibility option to add attributes.  This could be
used for adding references to XSDs and other documents, like
Schematron definitions.  They will prepare some input for
next meeting.

Pim

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 27 January 2010 21:02
To: ebcore-cppa@lists.oasis-open.org
Subject: [ebcore-cppa] CPP/CPA call this Friday


Hello,

Reminder about are meeting next Friday.  Agenda topics:
1)  Continued discussion of support for ebMS 3.0
intermediaries in CPA 3.0.
2)  Cristiano has asked us to discuss the topic he raised
September last year, see email below. 

Pim

-----Original Message-----
From: Cristiano Novelli [mailto:cristiano.novelli@enea.it]
Sent: 04 September 2009 11:17
To: Pim van der Eijk
Subject: Re: [ebcore] CPP/CPA enhancement suggestions

Hi Pim,

could be useful a way to describe files associate to the
business document XML Schemas (specified in the SimplePart),
but that don't become part of the message;

this file (associate to the XML Schema of a business
document) could be, for example:
a report file,
or a documentation file about the collaboration, or a CAM
template file, or something that is useful retrieve in the
agreement matching task.

To describe in CPPA this reference associate file it could
be need, for example, something like
SimplePart/NamespaceAssociate/@location

Is there something or a way like this?
What do you think about it?

Best Regards

------------------------------------------------------------
-----------------
Cristiano Novelli
ENEA, SIC - UDA - PMI
info http://summer.bologna.enea.it/~cristiano/information/




----- Original Message -----
From: "Pim van der Eijk" <pvde@sonnenglanz.net>
To: <ebcore@lists.oasis-open.org>
Sent: Thursday, September 03, 2009 10:56 PM
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
> 


------------------------------------------------------------
---------
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 


------------------------------------------------------------
---------
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 

bindings.cpp.xml

cpa3_log--pvde -- continued.odt



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