MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] Business (Legal) analysis of ebMS 3.0
Ian,
> Jeff Turpin is working on the spec at the moment and a some major additions and changes are likely to be included in the next few weeks, completion of the Reliability section (inclusion of a pull profile) and changes to use SOAP 1.1 not 1.2.
>
Thanks, Looking forward to its release.
> <>The question I have is what level of receipt acknowledgements are
> you looking at as this will be a many layered protocol, the transport
> layer could be acknowledging, the Reliability component may be
> acknowledging the ebMS could be acknowledging ( we have not completed
> this section yet it may not be needed, we need to complete the
> Reliability section first), the application/business level may be
> acknowledging.
In this study any layering has been removed, in other words I look at
the total number of message needed to transport one "data message"
between two or mor parties. In a business and legal sense layering has
little or no meaning, they fill primarily a function of separation of
concerns.
>If your concern is the potential number of acknowledgements messages that could be sent in the worst case scenario it could be very many, this is the problem of having a flexible system that has many level of reliability.
>
>
Im not so much concerned with the effeciency aspect of too many mesage.
The aspects Im looking at in this study are more legal consideration and
relationship to Trading Partner Agreements
> The issue may be having applications use what is appropriate, if they can handle the retry etc. they do not need the reliable functionality of the lower levels, but they are available. If people want to make the process very complex and turn on all the possible levels they can and should be allowed to do this as we do not know of their reasons. I think as long as we explain in the specification(s) what is happening it should be up to the message handler/system vendors and users to configure the runtime implementations as they wish as long as the retain interoperability to support the acknowledgement level the need.
>
>
In some sense I agree, parties can agree on technical details and their
effects.
However there are aspects that one cannot ignore and the concepts of
dispatch and reach are two. If a party "has access to a data message"
then the data message is available for receiver to act upon., The time
when this occurs is important and must be differentiated from time of
dispatch of acknowledgement. The first time an indication of receipt
reaches the originator the originator knows that the message was
properly received. If the originator get HTTP 2xx its an Ack but its an
Ack with poor non-repudiation properties. A signed ack would be better
but does not change the *fact* that the message was received. If the
reciver disputes that he got the message then the originator may claim
access to recivers information system and if the data message is found
there the ruling will most likelly be that the data message was
properly recieved.
These are prime concerns for a business protocol but may not be so
important for a protocol used for business purposes.
/anders
>
>Ian Jones
>Chair OASIS ebXML Messaging Services TC
>
>