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
suggest
>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.
>

<ac>
I believe Signals, as they are defined in BPSS, are considered
application
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
circumstances
under which piggybacking can be done in conjunction with synchronous
and asynchronous reply modes.
</ac>

<dalemoberg>
We intended to handle the specification of the agreement on how
piggybacking
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
arranged
in a SOAP with attachments package.
2. When we have signalsOnly, we need to be able to indicate that there
are
in effect two communication channels used in responding. The signal will
be returned on the requesting connection as a HTTP reply. The payload
(business
response) needs a URL to specify the endpoint that it is returned to. At
the
moment, we do not have enough apparatus available to express these
facts.
In addition, two different packaging formats need to be available to
reflect
the message containing the signal and the one containing the business
response.

Under the current XML modeling conventions, the ServiceBinding element
has
two attributes associating a channel with a package. The channel in turn
specifies an association of a transport with a docexchange. On the face
of
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
accomodate
the additional grouping, it would be a 1.1 matter. Proposals welcome.
If not, it may wait until 2.x.



</dalemoberg>


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


Powered by eList eXpress LLC