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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

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


Subject: Re: Ack Message Payload??


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.

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!).

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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC