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??


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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC