ebCore-CPPA SC call tomorrow

Title: Re: [ebcore-cppa] Reminder:  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