Re: FW: Receipt Messages for the demo!!

[mwsachs@us.ibm.com]

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