Re: FW: Receipt Messages for the demo!!

[Nicholas Kassem <nick.kassem@eng.sun.com>]

Thanks Marty. Good to see that we are on the same page. The challenge is in 
mapping BP's with a different design center onto ebXML TR&P. Dealing with 
(pre-)existing BPs is critical in the adoption of ebXML as a whole.

Nick

At 08:41 AM 7/31/2000 -0400, mwsachs@us.ibm.com wrote:
>I completely agree that a clear separation of function between BP and TRP
>is crucial.  Without such a separation we will be continually battling with
>the confusion of overlapping and duplicated function.  Separation of
>function is the only way to define a boundary where two different
>implementations (business process and messaging) meet.  It doesn't preclude
>a tightly-coupled implementation either.
>
>In defining the draft of tpaML, we drew the distinction on the message
>payload.  If a piece of information is in the payload, the function that
>gets or puts that information is part of the business process layer and is
>not addressed in the TPA.
>
>Regards,
>Marty
>
>*************************************************************************************
>
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>*************************************************************************************
>
>
>
>Bob Haugen <linkage@interaccess.com> on 07/31/2000 07:21:04 AM
>
>To:   "'ebXML-BP@llists.ebxml.org'" <ebXML-BP@lists.ebxml.org>
>cc:   "'Nicholas Kassem'" <nick.kassem@eng.sun.com>
>Subject:  FW: Receipt Messages for the demo!!
>
>
>
>I'm forwarding this message from the POC list because
>of its obvious relevance to BP.  The discussion of
>RosettaNet acks as business messages has been
>going on for the whole weekend.  Another example
>of BP overlap with TR&P?
>
>-Bob Haugen
>
>-----Original Message-----
>From:     Nicholas Kassem [SMTP:nick.kassem@eng.sun.com]
>Sent:     Sunday, July 30, 2000 10:03 PM
>To:  Patil, Sanjay; 'Prasad Yendluri'
>Cc:  Ebxml-Poc (E-mail); Askary, Sid
>Subject:  RE: Receipt Messages for the demo!!
>
>Sanjay/Prasad,
>
>I have been silent on this matter so far but it's near and dear to my
>heart. The issue isn't new and came up in the early days of  ebXML TR&P. I
>am of the opinion (and I believe I'm in the minority) that a clear
>distinction between BP and Transport functionality is important. The notion
>that the folks implementing the BP and the transport infrastructure are one
>and the same is a historical artifact. This is unlikely to continue to be
>the situation as transport frameworks sediment onto suitable platforms. My
>hope is that BP models of the future will make a clear distinction between
>transport (hopefully based on ebXML TR&P :-) functionality and the BP.
>Tightly coupled implementations (as in the case of RN) tend to blur the
>layers.
>
>The issue is far less confused when Reliable Messaging is folded in.
>Hopefully there is little argument about the fact the the BP should not see
>any of the "signal" messages in support of RM. I think for the purposes of
>the POC we could handle the ack as a message payload - but I think we
>should be clear that these acks should not be characterized as BP messages.
>I pushed for clarification in the ebXML specs. but so far to no avail.
>
>Regards.
>Nick
>
>At 06:30 PM 7/30/2000 -0700, Patil, Sanjay wrote:
> >
> >Let me give a simple argument  to make the point clear ....
> >A receiving service in Rosettanet makes use of the RN Service Header
> >of the incoming message for generating the RN Receipt Acknowledgement.
> >ebXML TR&P just does not  understand the RN Service Header,
> >ruling out any real processing of the RN Ack payload in ebXML framework.
> >
> >I understand that this is a subtle issue. Although I see this important,
> >if the group does not see any great risk of giving a misleading impression
> >(such as ebXML service can be layered on top of RN service)
> >by using Rosettanet Ack  for payload,  that is fine with me.
> >
> >But a simple solution could be to have ebXML Acks without payload or
> >quick build simple eBXML Ack payload for demo purpose.
> >
> >Please see my comments below for further clarification.
> >
> >thanks,
> >Sanjay Patil
> >------------------------------------------------------------------------- 
> ---------------------------------
>
> >
> >Work Phone: 408 350
> >9619
> ><http://www.netfish.com/>http://www.netfish.com
> >-----Original Message-----
> >From: Prasad Yendluri [mailto:pyendluri@vitria.com]
> >Sent: Sunday, July 30, 2000 10:38 AM
> >To: Patil, Sanjay
> >Cc: Ebxml-Poc (E-mail); Askary, Sid
> >Subject: Re: Receipt Messages for the demo!!
> >
> >Please see my comments below in <PY></PY>
> >
> >Regards, Prasad
> >
> >"Patil, Sanjay" wrote:
> >>The packaging section of POC proposal document treats the acknowledgement
> >>payload as business document instead of treating it as a protocol signal.
> ><PY>Yes. That is by design. All RosettaNet entities are payload as far as
> >ebXML is concerned. Without the Acks it won't be a RosettaNet PIP.</PY>
> >[Patil, Sanjay]   Let me get this clear. My understanding was, we are
> >demonstrating  that the
> >ebXML TR&P framework can handle any payload ex. Rosetttanet POR defined by
> >3A4 or
> >OAG BODs, etc.  To meet this end, we can just borrow business documents
>from
> >the other standards for our demo. By using the signal messages from a
> >particular standard,
> >we are giving an impression that ebXML services can be layered on top of
> >other standard's
> >service, since the signal messages are consumed by the particular
> >standard's service.
> >>ex. The DocumentLabel field in the ebXML header for Request
> >>Acknowledgement has the value of "Purchase Order Request
>Acknowledgement".
> >>There is no such document type defined by Rosenttanet.
> >>Rosettanet does not create  custom acknowledgement messages
> >>based on the received message.
> ><PY>This is not a custom acknowledgment. The label is just a textual
> >description of what is in the ebXML payload. However the TAPId.Action
> >field should have the correct value from PIP3A4, which is simply "Receipt
> >Acknowledgement".</PY>
> >[Patil, Sanjay]  The  DocumentReference.DocumentLabel should also be
> >"Receipt Acknowledgement" instead of "Purchase Order Request
> >Acknowledgement" or
> >"Purchase Order Acceptance Acknowledgement"
> >
> >>My point is, we are creating confusing scenario by mixing the
> >>Rosettanet business documents (defined by PIPs) and signal
> >>messages (defined by and scope limited to RNIF).
> ><PY> I don't understand distinction you are trying to make. Both business
> >documents and Acks *are* defined by RosetaNet and are part of the PIP
> >(PIP3A4 in this case). Again without the Acks there is no PIP.</PY>
> >[Patil, Sanjay]  Agree, without the Acks there is no PIP. But Acks message
> >type is not
> >defined by PIP, but it is just used in a PIP. It's only the business
> >document types which are
> >defined by the PIP and the Ack type is defined by RNIF. Again, this is
> >because Rosettanet
> >PIPs are tightly coupled with the  implementation framework.
> >>Instead we can live with just ebXMLHeader and no payload for
> >>acknowledgement messages. This will at least keep the matters clean.
> ><PY>If you don't need or  handle the Acks, you can simply choose to throw
> >away the payload for the acks. Others need it.</PY>
> >[Patil, Sanjay]  Acks are useful and ebXML Acks at this point can simply
> >be defined by
> >the header itself. At this point, even if we decide to demonstrate backend
> >integration,
> >I don't understand how one is going to use the the Rosettanet Ack payload.
> >Rosettanet Ack payload is also based upon the Service Header of the the
> >incoming
> >Reosettanet message and ebXML TR&P won't understand that.
> >
> >>Just my thoughts.
> >>
> >>thanks,
> >>Sanjay Patil
> >>------------------------------------------------------------------------ 
> ----
>
> >>------------------------------
> >>Work Phone: 408 350 9619
> >><http://www.netfish.com>http://www.netfish.com
> >>
> >>-----Original Message-----
> >>From: Prasad Yendluri
> >>[<mailto:pyendluri@vitria.com>mailto:pyendluri@vitria.com]
> >>Sent: Saturday, July 29, 2000 7:13 PM
> >>To: Patil, Sanjay
> >>Cc: Ebxml-Poc (E-mail); Askary, Sid
> >>Subject: Re: Receipt Messages for the demo!!
> >>
> >>Sanjay,
> >>
> >>This was already discussed. We said, the RN acks would simply be payload
>as
> >>far
> >>as ebXML is concerned. The  Packaging section of the POC proposal
>document
> >>also
> >>shows <RN-Action-Message> or <RN-Signal-Message> in the payload. There
>are
> >>no
> >>ebXML level acks.
> >>
> >>Regards, Prasad
> >>
> >>"Patil, Sanjay" wrote:
> >>
> >> > This is about "Receipt Acknowledgement" messages for the demo.
> >> > Are we planning to use any payload for these messages? Since these
> >> > messages are consumed by the service and not passed to the backend,
> >> > we need to have ebXML specific payload, if any.
> >> >
> >> > I am not sure if TR&P has identified different signal message types
> >> > as acknowledgement, exception and defined types for them.
> >> >
> >> > Of course, we can use RN payload for the demo, but that demonstrates
> >> > no ebXML feature, as the ebXML service is not going to process the
> >> receipt
> >> > payload in the receipt messages.
> >> > Instead, maybe we can just use the ebXML header's DocumentLabel field
> >> > to identify the "Receipt Acknowledgement" and not have any payload.
> >> >
> >> > Please ignore this message if this topic has already been discussed
>and
> >> > decision has been made (I would still need to know the decision
>though).
> >> >
> >> > thanks,
> >> > Sanjay Patil
> >> >
> >>------------------------------------------------------------------------ 
> ----
>
> >> > ------------------------------
> >> > Work Phone: 408 350 9619
> >> > <http://www.netfish.com>http://www.netfish.com