[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: FW: Receipt Messages for the demo!!
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, email@example.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 <firstname.lastname@example.org> on 07/31/2000 07:21:04 AM > >To: "'ebXML-BP@llists.ebxml.org'" <ebXML-BP@lists.ebxml.org> >cc: "'Nicholas Kassem'" <email@example.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:firstname.lastname@example.org] >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:email@example.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:firstname.lastname@example.org>mailto:email@example.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
Powered by eList eXpress LLC