RE: [ebcore-cppa] ebCore-CPPA SC call tomorrow

Title: Re: [ebcore-cppa] Reminder:  ebCore-CPPA SC call tomorrow.

 

OK to defer then, with no input sent to the list, we may have 
better uses for our time.

 

Note that we had raised the issue of how to handle ebBP 
signals in the "related channels" model, we can take that up next 
time.

Also, I believe that the semantic alignment was moved to in 
the main ebCore TC as a topic.  

 

I am working on a note to handle CPA handling for 
multi-hop for next meeting.

 

Since there may not be an ebCore TC meeting next week (unless 
new topics are raised), we can have an SC meeting using that 
slot.

 

Pim

From: Moberg Dale [mailto:] 

Sent: 23 April 2010 19:14
To: Pim van der Eijk; 

Subject: RE: [ebcore-cppa] 
ebCore-CPPA SC call tomorrow

I think with both Pete 
and Sander missing it is better to defer. Maybe we can use an ebcore slot next 
week, at least in part? Because the semantic agreement support was the main (or 
only) ebcore issue.

 

Dale

 

From: Pim van 
der Eijk [mailto:] 
Sent: Thursday, April 22, 2010 6:16 
AM
To: 

Subject: [ebcore-cppa] ebCore-CPPA SC call 
tomorrow

 

 

Reminder that we have a 
call scheduled for tomorrow.   Please let me know if you can attend 
and will be able to review the materials out there.

 

Notes from our previous 
meeting:  

 

We reviewed the 
document comparing "old" and "proposed new" ways of specifying related 
channels.

One discussion item was 
the use of ebBP signals.   In ebMS 2.0 and 3.0, these signals map to 
UserMessages, so they are defined messages with action bindings in the 
CPA.  We could add special links to link the business messages and the 
related ebBP signals.    A BSI library could use this information 
since for a message it should be able to process multiple response messages 
(having RefToMessageId set to the MessageId of the sent message), one business 
response and ReceiptAcknowdlegment, AcceptanceAcknowledgement etc. 
messages.   I believe Dale agreed to look into this 
!?

 

Pim

 

 

 

From: Pim van 
der Eijk [mailto:] 
Sent: 08 April 2010 19:36
To: 'Pim van der Eijk'; 

Subject: [ebcore-cppa] ebCore-CPPA SC call 
tomorrow

 

Usual 
reminder.   I hope to produce some notes outlining and comparing "old" 
and "proposed new" ways of doing synchronous replies, pull mode, setting 
channels for various types of signals.  In the mean time, the examples and 
notes I posted before give some background.

 

Pim

 

 

 

From: Pim van 
der Eijk [mailto:] 
Sent: 26 March 2010 09:24
To: 
''
Subject: ebCore-CPPA SC call 
today

Hello,

 

A reminder about 
the call today.  Same agenda as for the proposed earlier, cancelled 
meeting. 

 

Note that the time for 
the call is 20:00 CET.  CET, unlike other timezone, is not yet in DST so 
the meeting time may be an hour different from previous meetings if you are in 
other timezones.

 

Pim

 

From: Pim van 
der Eijk [mailto:] 
Sent: 12 March 2010 15:32
To: 'Sander Fieten'; 'Moberg Dale'; 
''
Subject: RE: [ebcore-cppa] Reminder: 
ebCore-CPPA SC call tomorrow.

OK, then I see little 
reason to have a call and suggest we postpone.  

 

In the proposal, a 
delivery channel can include a specification of its related channels, where the 
type attribute identifies what kind of message is sent over that channel.  
E.g. the following associates the ebMS 3.0 Receipt with a channel called 
dc.Default.Sync.   

<RelatedChannels>
   
<ChannelId 
type=http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/Receipt>dc.Default.Sync</ChannelId>
</RelatedChannels>

That channel can 
have an  @addresId attribute that points 
to an addres group elsewhere in the CPA that can include WS Addressing reference 
parameter information.   

 

Pim

 

 

 

 

From: Sander 
Fieten [mailto:] 
Sent: 12 March 2010 14:58
To: Moberg 
Dale; Pim Eijk, van der; 

Subject: Re: [ebcore-cppa] Reminder: 
ebCore-CPPA SC call tomorrow.

I won’t be able to join todays 
call. Our cat probably broke his tail, so will have to go to the vet with him. 

I think we have to decide and discuss whether we want CPA’s for endpoint 
to intermediary traffic or only for end-2-end exchanges. On the structure of the 
CPA I was thinking that we can also define specific ActionBinding for signals. 
They can then be bound to their own channel (with the required WS-A config). 

Regards,
Sander

On 11/03/2010 21:49, "Moberg Dale" <> 
wrote:

I am on vacation this week but 
could dial in to receive a status report.

Reviewing pending materials 
will be difficult because I have only worked
with Kathryn on how to obtain 
requirement input related to Christiano
N's general issue.

I have 
tried to organize obtaining some sample of what would be needed
to support 
"semantic alignment agreements" on data.

Beyond that I have not looked at 
the scope of rework needed using your
RelatedChannels this 
week.

-----Original Message-----
From: Pim van der Eijk [mailto:]
Sent: 
Thursday, March 11, 2010 3:04 AM
To: 
Subject: 
[ebcore-cppa] Reminder: ebCore-CPPA SC call tomorrow.

Hello,

A 
reminder that we will have a call tomorrow.   If you can't
make it, 
please let me know.
If you can, please review the materials that have 
been
posted so far.

Thanks,

Pim

-----Original 
Message-----
From: Pim van der Eijk [mailto:]
Sent: 22 
February 2010 22:06
To: ''
Subject: 
No call on 2010-02-26

Hello,

Since I wrote the minutes for the 
CPP/CPA call I learned
that I will be travelling on Friday, so I am 
cancelling the
call.
In the mean time, your review of the proposed changes 
and
any comments to the list are 
welcome.

Thanks,

Pim

-----Original 
Message-----
From: Pim van der Eijk [mailto:]
Sent: 15 
February 2010 15:11
To: 
Subject: 
[ebcore-cppa] Notes from CPP/CPA call 2010-02-12

1)  Discussion 
of schema enhancements and examples for pull
and sync

TC member 
discussed the proposals (a.o. use of
<RelatedChannels/>), but need more 
time to review time.  By
next meeting, we will decide whether the 
changes are worth
pursuing.  If yes, the next steps are to work out 
the
precise specifications for all types of related channels,
for all 
protocols that CPA supports.

2)  Cristiano's request

Pete 
looked into this.  There are some extensibility points,
but they don't 
seem to provide what Cristiano requested.
With a document (or constituent 
part), we would need to
specify (i) the referenced external document, (ii) 
the
namespace or type of such a document and (iii) some
indication of the 
what the external document says about the
document or part. Like additional 
validation constraints,
profiling rules, other types of semantic alignment. 
 Dale
proposes to bring some more people to the discussion and
will 
draft some input for discussion.

Next call on 26th of this 
Month.

Next schedule ebCore TC meeting on 19th of this Month.

N.B. 
 I took the liberty to extract the PartyId type
specification from the 
CPA draft and am proposing it to the
ebCore TC as a standalone 
(mini)spec.

Pim

-----Original Message-----
From: Pim 
van der Eijk [mailto:]
Sent: 08 
February 2010 11:20
To: 
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:]
Sent: 
27 January 2010 21:02
To: 
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:]
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" <>
To: <>
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

------------------------------------------------------------
---------
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_workgroups.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_workgroups.php