Good point. I recall that the intent of the OverrideMshChannel was to be enable a more general overlay, but it does not seem to read that way very obviously. Clearly the presumption was that "normally" one channel would be used for the return flow for sync reply mode of "none"

Sacha also pointed out to me in discussion that Action values are not necessarily unique in a CPA, and even if we tied the signal return channel to a specific Action value, we could fail to handle cases where the Action value is not unique.

Or how would we handle specifying different channels for Error or Acknowledgment MSH actions for a given action, even if we used a Request's Action value within OverrideMshChannel?

I think it will be worthwhile to raise this in the 2.1 maintenance discussions in OASIS at least to fix the language, and explain conventions for usage more fully.

It could also be that we need to make room for dynamic endpoint references, like in WS-Addressing, possibly requiring "perMessage" values.

The uniqueness problem that Sacha raised will probably require some decisions also. The granularity of the overrides to be supported also needs review. If you have additional requirements in this area, please forward them to the comment list.

Otherwise, because the defaultMshChannelId is on the PartyInfo element, your proposal to use separate CPAs would seem to be the remaining workaround.

-----Original Message----- From: Pim van der Eijk [mailto:lis...@sonnenglanz.net] Sent: Wednesday, November 16, 2005 2:18 PM To: Dale Moberg; ebxm...@lists.ebxml.org Cc: ebxm...@oasis-open.org Subject: RE: [ebxml-dev] CPA Delivery Channel for Asynchronous ebMS Acknowledgments

Hello,

I read that section as indicating a way to use a particular channel for a

special MSH action (e.g. "Acknowledgment") as different from the default

channel for all other MSH actions (i.e. Error, StatusRequest,

StatusResponse, Ping, Pong). If I read it correctly, it would not

distinguish between a single MSH action in response to different messages.

I've copied ebxm...@oasis-open.org as you indicated.

Thanks for a prompt response.

Pim

-----Original Message-----

From: Dale Moberg [mailto:dmob...@cyclonecommerce.com]

Sent: 16 November 2005 22:07

To: Pim van der Eijk; ebxm...@lists.ebxml.org

Subject: RE: [ebxml-dev] CPA Delivery Channel for Asynchronous ebMS

Acknowledgments

Hi,

Please take a look at the CPPA specification, section 8.4.58 on the (not

very frequently used) OverrideMshActionBinding...

The OverrideMshActionBinding element can occur zero or more times. It has

two REQUIRED attributes. The action attribute identifies the Message Service

Handler level action whose delivery is not to use the default

DeliveryChannel for Message Service Handler actions. The channelId attribute

specifies the DeliveryChannel to be used instead.

It sounds like your situation is one that this optional element is intended

to cover, but if not, post to ebxm...@oasis-open.org and we will

discuss the use case further as part of the maintenance process.

Dale Moberg

-----Original Message-----

From: Pim van der Eijk [mailto:lis...@sonnenglanz.net]

Sent: Wednesday, November 16, 2005 1:52 PM

To: ebxm...@lists.ebxml.org

Subject: [ebxml-dev] CPA Delivery Channel for Asynchronous ebMS

Acknowledgments

Hello,

In an ebMS v2 application we are distinguishing two types of asynchronous

business messages.

Both of them request asynchronous ebMS acknowledgments.

- In one case, the business message is digitally signed, and the ebXML MSH

acknowledgment is also to be digitally signed.

- In the other case, neither the business message nor the acknowledgment are

to be digitally signed.

How can we specify this behaviour in a CPA?

The defaultMshChannelId attribute sets a single default for all asynchronous

messages sent from a Party.

I don't see how I can set it to use different channels in response to

different message types.

A workaround might be two CPAs with diffent CPAId and use them in parallel,

but I keep thinking I am missing something obvious.

N.B. I am talking about ebMS acknowledgments, not ebBP ReceiptAcknowledgment

business signals.

Pim

-----Original Message-----

From: Pim van der Eijk [mailto:lis...@sonnenglanz.net]

Sent: 02 November 2005 12:41

To: ebxm...@lists.ebxml.org

Subject: [ebxml-dev] Ebusinesswatch report on ebXML

I got an email that pointed to the "sectoral e-business advisory",

ebusiness-watch.org.

There is a recent document that provides some interesting comments:

"Systems such as ebXML have reached a point where they are now ready for

full deployment".

"If, as some contend, the market for Web Services has peaked, and Grid

Services are already the next big venture ... it is advisable for SME

managers to be very cautious before risking their business ... ebXML

represents a far safer and more viable option at this time".

"the investment in ebXML will continue to pay dividends for the

foreseeable

future".

URL

http://www.ebusiness-watch.org/resources/documents/TR03_Interoperability

_200

5_web.pdf

-----Original Message-----

From: Pim van der Eijk [mailto:lis...@sonnenglanz.net]

Sent: 07 April 2005 20:51

To: 'Bryan Rasmussen'; ebxm...@lists.ebxml.org

Subject: RE: [ebxml-dev] messageID globally unique

Bryan,

The MessageId string format has to conform to the RFC 2822 production

rules,

which specifies a.o. there has to be a "@" symbol in the middle of the

msg-id string value. An implementation that just reuses a MIME library

function may report syntax error faults for ebXML messages without "@"

in

their MessageIds. The algorithm suggested to get a unique value is just

an

example. In the case of UBL you could probably generate a syntax valid

unique MessageId by concatenating the UBL Invoice "ID" or "GUID" element

value, the "@" symbol and some string value derived from IdentifierType

subelements.

Pim van der Eijk

-----Original Message-----

From: Bryan Rasmussen [mailto:br...@itst.dk]

Sent: 07 April 2005 15:21

To: 'ebxm...@lists.ebxml.org'

Subject: [ebxml-dev] messageID globally unique

Hi

from 3.1.6.1 of the ebxml Messaging services spec:

The REQUIRED element MessageId is a globally unique identifier for each

message conforming to MessageID[RFC2822]

By this is it just meant that MessageId must be globally unique and it

is up

to the application to make sure that it is or is it meant that MessageId

must be generated using the recommended algorithm from RFC 2822 as

follows:

"The message identifier (msg-id) itself MUST be a globally

unique

identifier for a message. The generator of the message identifier MUST

guarantee that the msg-id is unique. There are several algorithms that

can

be used to accomplish this. Since the msg-id has a similar syntax to

angle-addr (identical except that comments and folding white space are

not

allowed), a good method is to put the domain name (or a domain literal

IP

address) of the host on which the message identifier was created on the

right hand side of the "@", and put a combination of the current

absolute

date and time along with some other currently unique (perhaps

sequential)

identifier available on the system (for example, a process id number) on

the

left hand side. Using a date on the left hand side and a domain name or

domain literal on the right hand side makes it possible to guarantee

uniqueness since no two hosts use the same domain name or IP address at

the

same time. Though other algorithms will work, it is RECOMMENDED that the

right hand side contain some domain identifier (either of the host

itself or

otherwise) such that the generator of the message identifier can

guarantee

the uniqueness of the left hand side within the scope of that domain. "

I would hope for the first one (and am supposing it is the first one but

this kind of confusion can arise when moving across specs) as I have my

own

globally unique id that would make more sense for our application.