Re: Ack Message Payload??

[jacques durand <jacques@savvion.com>]

Hi  Sanjay, Nick:

Even so that could spare some message exchanges,
I see the following difficulties in trying to use BP-level Acks and MS-level Acks

as substitute to each other:

- Even if we have Acks at MS level (i.e. in case using Rel Msg)
these probably do not replace BP-level Acks, which can be loaded with
payloads, as is the case in GCI processes for Tokyo.

- In the case of MS-level Acks that are generated for Rel Msg,
they indeed do not have any payload so far - do not need to
( that could create lots of overhead!) They only need to correlate
with the acknowledged message, based on messageID (RefToMessageId).
There will be lots of them , so they better be short.

- By "aware of ebXML", I assume you mean the MS could "forward"
the MS-level Acks it receives (or some of them) to the BP?
Then that becomes a new contract between BP and MS, for a kind of notification
service.
(This could also concern error messages generated by the MS), that BP modelers
cannot assume for now...

Jacques


Nicholas Kassem wrote:

> Sanjay,
>
> I don't feel this area has been adequately addressed in the specs so what
> follows is just my opinion. I think there are at least the following cases
> to consider:
>
> 1) BP's modeled assuming an unreliable
>          a) BP's unaware of ebXML
>          b) BP's aware of ebXML
>
> 2) BP's modeled assuming a reliable MS
>          a) BP's unaware of ebXML
>          b) BP's aware of ebXML
>
> I think almost all the cases we have seen so far fall in category 1.a.
> Which means that there is no notion of MS Acks therefore all Acks are at
> the Business level. It is therefore up to the BP to define the payload *if
> any*.
>
> My hope is that the verticals will start considering cases 1.b & 2.b and
> factor that in their modelling activities.
>
> Case 2.a is also very common but typically have no open interoperability
> requirements.
>
> Nick
>
> At 07:41 PM 10/25/2000 -0700, Patil, Sanjay wrote:
>
> >Stumbled upon an old issue with Acknowledgment message payload,
> >which we had left unresolved in San Jose ...Please ignore this message
> >if the issue has already been thought and resolved (of course, let me know)
> >
> >What should be the payload of Acknowledgement message?
> >What is the scope of these Ack messages?
> >If the scope is limited to TRP layer only, then
> >a> Should the Ack payload generated by ebXML TRP layer be based on
> >      ebXML Header of the original message only?
> >b> Are we going to use the Ack messages for NonRepudiation,
> >      in which case digest of the original message comes in picture
> >If the scope is Business Process, then
> >a> Do we have any specification for processing the incoming
> >      payload, or it is pretty much left to the Business Process.
> >      If it is up to the Business Process, then I would consider it
> >      as a business document which  happens to be Ack.
> >
> >When I went through the payload docs for the POC, it is apparent
> >that the Ack Message and the Acceptance messages have ditto
> >same payload. This just emphasizes the need of clearer definition
> >of the Ack message type, usage, etc. I had several Email
> >communications before the last POC on this topic and had to finally
> >agree with using RosettaNet Ack payload for demo purpose only.
> >
> >For the Tokyo POC, can we not have any payload for the Ack messages
> >(which is anyway same as the Acceptance message ex. ItemCreateAck.xml
> >and ItemAlign.xml have same content. Same with OrderCreateAck.xml
> >and OrderAcceptance.xml) and leave it to TRP WG to decide.
> >
> >thanks,
> >Sanjay Patil
> >----------------------------------------------------------------------------
> >------------------------------
> >Work Phone: 408 350 9619
> >http://www.netfish.com