[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Ack Message Payload??
Hi,
Yep, for Tokyo POC we can live with this. But this should not be the final
position, we need to discuss this further, as there are a lot of issues to
be considered when we talk business message level acks.
cheers
-----Original Message-----
From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
Sent: Saturday, October 28, 2000 9:55 AM
To: Nicholas Kassem
Cc: Chris Ferris - Sun East Coast IR Development; Patil, Sanjay; Mark
Hale; Ebxml-Poc (E-mail)
Subject: Re: Ack Message Payload??
I agree at this point for POC that a Normal message with no payload is a
business ack.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
Nicholas Kassem <Nick.Kassem@eng.sun.com> on 10/27/2000 02:52:50 PM
To: Chris Ferris - Sun East Coast IR Development
<chris.ferris@east.sun.com>
cc: "Patil, Sanjay" <Spatil@netfish.com>, Mark Hale
<mark.hale@ajubasolutions.com>, "Ebxml-Poc (E-mail)"
<ebxml-poc@lists.ebxml.org>
Subject: Re: Ack Message Payload??
At 08:09 PM 10/26/2000 -0400, Chris Ferris - Sun East Coast IR Development
wrote:
>Let me see if I can make this clearer. A Business
>ACK is NOT the same as a MS-level ACK. A Business
>ACK would NOT use a MessageType="Acknowledgment"
>because that is reserved for MS use.
I think this is understood.
>A Business ACK is of MessageType="Normal" and has
>an appropriate payload (or not as the case may be,
>but it is NOT clear at all how an empty payload is
>supposed to be interpreted by the receiving
>business service/application!).
For the purposes of the POC we could agree that a "Normal" message with no
payload is a business level ACK. As a general point I don't think BP's
should be modeled in this way but that's another story.
Nick
>Cheers,
>
>Chris
>
>Nicholas Kassem wrote:
> >
> > The key issue here is that we need to be clear about what is within
> > our sphere of control and influence. The MS level ACK (used in RM) is
> > within ebXML TRP's sphere of influence - while Business level ACKs is
> > not. The BP ACK is something that is meaningful to the Business
> > application and its' associated state. MS level ACKs haVE no meaning
> > outside of the MS.
> >
> > So no payload for ACK messages is OK with me but this needs to be
> > consistent with the CGI/AIAG BP modelling. Mark are you OK with this ?
> >
> > Nick
> >
> > At 02:43 PM 10/26/2000 -0700, Patil, Sanjay wrote:
> >
> > >
> > > Nick/Chris/Jacques
> > >
> > > So, do we all agree with no payload for Ack messages.
> > > The Business Processes we are using for the POC
> > > are not utilizing different payloads for Ack and Reply
> > > messages anyway. Reliable Messaging also seems
> > > to work better with no payload for Ack messages per
> > > Jacques's Email.
> > >
> > > Please comment/decide.
> > >
> > > thanks,
> > > Sanjay Patil
> > >
> > >
>
----------------------------------------------------------------------------
-----------------------------
> > >
> > > Work Phone: 408 350 9619
> > > http://www.netfish.com
> > >
> > > -----Original Message-----
> > > From: Chris Ferris - Sun East Coast IR Development
> > > [mailto:chris.ferris@east.sun.com]
> > > Sent: Thursday, October 26, 2000 12:56 PM
> > > To: Nicholas Kassem
> > > Cc: Patil, Sanjay; Ebxml-Poc (E-mail)
> > > Subject: Re: Ack Message Payload??
> > >
> > > Nick/All,
> > >
> > > The Acknowledgment payload is a NULL payload. The Ack message
> > > is reserved for ebXML MS in support of reliable messaging.
> > >
> > > HTH,
> > >
> > > Chris
> > >
> > > 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
> > >
> > > --
> > >
> > > Christopher Ferris
> > >
> > > _/_/_/_/ _/ _/ _/ _/ Enterprise Architect - EMA
> > >
> > > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
> > >
> > > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
> > >
> > > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop:
> UBUR03-313
> > >
> > > _/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA
> 01803-0903
> > >
> > >
> > >
>
>--
> Christopher Ferris
> _/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced
>Development
> _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
> _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
> _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
>_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC