Next in thread →
Next in month →
RE: [ebcore-cppa] Next meeting
Title: Re: [ebcore-cppa] Reminder: ebCore-CPPA SC call tomorrow. I have taken my summer vacation for 2010 and I hope to be caught up from it by August J So I should be available for an Aug 13 meeting. From: Pim van der Eijk [mailto:] Sent: Tuesday, July 06, 2010 8:56 AM To: Subject: [ebcore-cppa] Next meeting Hello, We have not met for some time as participants' focus has been on getting ebMS 3.0 out for review and finishing the ebCore PartyId Type specification. I intend to take up CPP/A 3.0 again later this summer and post material to discuss after the holiday season. Friday 13th of August could be a first date for our next meeting, or two weeks after depending on progress and availability of participants. Pim From: Moberg Dale [mailto:] Sent: 20 May 2010 22:55 To: Pim van der Eijk; Subject: RE: [ebcore-cppa] ebCore-CPPA SC call tomorrow Let’s meet when you have new material to introduce. Dale From: Pim van der Eijk [mailto:] Sent: Thursday, May 20, 2010 1:34 PM To: Subject: RE: [ebcore-cppa] ebCore-CPPA SC call tomorrow Hello, Do people want to have a call tomorrow? I did not have time to get my multihop CPA input ready for tomorrow, and have not seen any other input. Pim From: Pim van der Eijk [mailto:] Sent: 23 April 2010 19:55 To: 'Moberg Dale'; Subject: RE: [ebcore-cppa] 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
Next in thread →
Next in month →