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: Receipt Messages for the demo!!

Agree. Now one technical question - how is the receiving trading partner supposed
to generate a non "smoke & mirror" RN Ack payload without receiving RN Service
Header from the sending trading partner.

Sanjay Patil
Work Phone: 408 350 9619                                 http://www.netfish.com

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Monday, July 31, 2000 9:50 AM
To: marcb@webmethods.com; Ebxml-Poc (E-mail)
Subject: Re: Receipt Messages for the demo!!

Marc. I agree. We should not invent (smoke & mirror)  ebXML transport Acks and focus on demonstrating (implementability and realization of)  what has been *specified* by ebXML.


Marc Breissinger wrote:

 This is exactly what we are targeting and it is the one specified in the POC proposal document.  I have added some more verbage in the latest revision explaining the *very important* difference between transport level acks and business level acks.  The ebXML TR&P Reliable Messaging specification (first draft has been distributed) will lay out the transport level ack choreography required of TR&P service providers.  In essence, the transport level ack will acknowledge receipt and, optionally, hardening of the message (depending upon the QOS required by the message as specified in the TPA).  Note that the RosettaNet ACK message goes far beyond this level to include validation of the document itself, requiring knowledge of the structure of the payload itself.  Therefore, the RosettaNet ACK message is a business ack above the transport ack.The intent of the demo is to borrow both the business documents and the business process from PIP3A4.  Without the business level acks, we don't have PIP3A4.  We want to be able to demonstrate a "full" business process.  When the reliable messaging specification is more complete, we can add the additional transport level acks to the scenario as required by the current level of the TR&P specification, rather than making up a "smoke and mirrors" style substitute for next week.marc 
-----Original Message-----
From: Patil, Sanjay [mailto:Spatil@netfish.com]
Sent: Monday, July 31, 2000 12:23 PM
To: 'Prasad Yendluri'; Patil, Sanjay
Cc: Ebxml-Poc (E-mail); Askary, Sid
Subject: RE: Receipt Messages for the demo!!
Does this mean that we are going to support a message flow as follows for the San Jose demo. Trading Partner A [Optional Backend] --> [RNService] --> [ebXML TR&P Service]  ===to TP B ==>Trading Partner B== from TP A==> [ebXML TR&P Service] --> [RNService] --> [Optional Backend]Note the requirement of RNService in the setup, since its the one which understands the RN signal messages.

Are we targeting for something like this? We need some clear-cut direction here.

Frankly, I was not considering this setup until I saw Parsad's Emails about supporting the entire PIP 3A4 for the demo, as opposed to borrowing just business documents from the 3A4 PIP. My take on this is - RN does not clear distinction between business messages and transport messages. ebXML is a new and evolving standard and can learn from the pitfalls of other standards. I get a similar feeling from the mails of other experts on this thread, as I see suggestions to use just ebXML header for the Ack messages since ebXML has not defined the Ack message payload yet. thanks,
Sanjay Patel
Work Phone: 408 350 9619                                 http://www.Netfish

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Sunday, July 30, 2000 11:09 PM
To: Patil, Sanjay
Cc: Ebxml-Poc (E-mail); Askary, Sid
Subject: Re: Receipt Messages for the demo!!
The POC doc clearly says,

"RosettaNet Demo Scenario The initial proof of concept demonstration scenario involves the execution of RosettaNet PIP3A4 (Create Purchase Order business process) among the participants in the environment.  Specifically, the appropriate RosettaNet action and signal messages as defined in the PIP specification will be transported within the ebXML TR&P framework."

We are executing the entire RN 3A4 business process  within the ebXML TR&P framework.

Please see my comments below tagged PY2.

"Patella, Sanjay" wrote:

[SP] 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.
<PY2>I am sensing a disconnect here. May be a discussion off-line might be worth. Anyhow,
1. RN ReceiptAcks are generated after making sure the "payload" is structurally valid. Not just by looking at / based on Service Header.
2. TR&P does not have access to Service Header and does not need to understand it. The Acks are for the RosettaNet entity (Service) that sent the original business message. ebXML TR&P is being used as the pure package and delivery mechanism, overlaying the *entire* RN-3A4 BP</PY2>
[SP] 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.
<PY2>RN Acks are business-level Acks. In fact they must include the digest of the received message for non-repudiation of receipt (when called for!) and they must only be sent after validating the received business message to be valid structurally  There is no conflict there</PY2>
[SP] But a simple solution could be to have ebXML Acks without payload or quick build simple eBXML Ack payload for demo purpose.
<PY2>ebXML does not have any Acks defined yet. Even when defined, they are supposed to be transport level Acks, where as RN Acks are business level Acks. The RN Business process entities should be immune to the transport mechnism used.</PY2>

"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 fromthe 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'sservice, since the signal messages are consumed by the particular standard's service.

<PY2> No we are showing the execution of entire 3A4 PIP. Not just 3A4. See the excerpt from the POC proposal I listed at the beginning of this message.

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"
<PY2> It makes sense to make the descriptive entities as descriptive as possible. These fields are meant for human consumption (typically)</PY2>
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 notdefined 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 RosettanetPIPs are tightly coupled with the Implementation framework.
<PY2> It does not matter where the schemas for the Acks are defined, when they occur in the PIP they are part of the PIP. They are business level Acks and are part of the business process. We *defined* them in the RNIF as that is a central place to define this. BTW, we did this only in RNIF2.0. For 1.1, the Acks are not part of RNIF. I hope I know this :-) I wrote RNIF1.1 and am the lead architect for 2.0 and authored a major portion of it.</PY2>
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.

Sanjay Patil
Work Phone: 408 350 9619

-----Original Message-----
From: Prasad Yendluri [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!!


This was already discussed. We said, the RN acks would simply be payload as
as ebXML is concerned. The  Packaging section of the POC proposal document
shows <RN-Action-Message> or <RN-Signal-Message> in the payload. There are
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

[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