[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-dev] CPA Delivery Channel for Asynchronous ebMS Acknowledgments
|
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----- 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 ebxml-cppa-comment@oasis-open.org as you indicated. Thanks for a prompt response. Pim -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: 16 November 2005 22:07 To: Pim van der Eijk; ebxml-dev@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 ebxml-cppa-comment@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:lists@sonnenglanz.net] Sent: Wednesday, November 16, 2005 1:52 PM To: ebxml-dev@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:lists@sonnenglanz.net] Sent: 02 November 2005 12:41 To: ebxml-dev@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:lists@sonnenglanz.net] Sent: 07 April 2005 20:51 To: 'Bryan Rasmussen'; ebxml-dev@lists.ebxml.org Subject: RE: [ebxml-dev] messageID globally unique 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:brs@itst.dk] Sent: 07 April 2005 15:21 To: 'ebxml-dev@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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]