OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: One issue pertaining to Arvola response to Marty to Hima on v1question4

>4) What are the endpoints used for Ping, Pong, StatusRequest,
>StatusRepsonse, DeliveryReceipt, Acknowledgment, MessageError
>Ping -> "request"?
>Pong -> "response"?
>StatusRequest -> "request"?
>StatusResponse -> "response"?
>Acknowledgement -> "response"?
>DeliveryReceipt -> "response"?
>MessageError (ErrorList)-> "error"?
>MWS: Any of the above which are application-defined may be associated
>with whatever endpoints the business wants to use.  The ones you
>are one possibility.  Signals and MSH to MSH messages are outside the
>scope of the CPA.  Addressing of those messages should be defined in
>the Message Service specification.

I believe Signals, as they are defined in BPSS, are considered
level messages. The CPP/A attribute syncReplyMode can take on values
like signalsOnly, signalsAndResponse, etc. Therefore, I don't think they
are outside of the scope of the CPA. Intermediate acknowledgements
and end-to-end delivery receipts, used to implement the exactly once
delivery semantics of reliable messaging are purely MSH to MSH, but
they can also be piggybacked on top of application level messages.
I particularly would like to see some clarifications on the
under which piggybacking can be done in conjunction with synchronous
and asynchronous reply modes.

We intended to handle the specification of the agreement on how
was to be done via packaging. This has not yet occurred. Here are some 
issues needing resolution on the way to getting this done:

1. When we have signalsAndResponse true, and syncResponse true, then the
packaging should describe how the signal and Response (payload) are
in a SOAP with attachments package.
2. When we have signalsOnly, we need to be able to indicate that there
in effect two communication channels used in responding. The signal will
be returned on the requesting connection as a HTTP reply. The payload
response) needs a URL to specify the endpoint that it is returned to. At
moment, we do not have enough apparatus available to express these
In addition, two different packaging formats need to be available to
the message containing the signal and the one containing the business

Under the current XML modeling conventions, the ServiceBinding element
two attributes associating a channel with a package. The channel in turn
specifies an association of a transport with a docexchange. On the face
it, the conventions do not have a natural way to store all the related
information that needs to be grouped together. 

If we could find a conservative way to extend the conventions to
the additional grouping, it would be a 1.1 matter. Proposals welcome.
If not, it may wait until 2.x.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC