RE: Next revision of the Proposal

[Marc Breissinger <marcb@webmethods.com>]

See my responses in purple below.

 

Thanks,

marc

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Friday, July 28, 2000 7:51 PM
To: marcb@webMethods.com
Cc: ebXML POC Mailing List
Subject: Re: Next revision of the Proposal

Marc,

1. RosettaNet has several constraint parameters that PIPs must follow:
E.g. retries, timeouts on Acks etc.

Is this something, that we expect to put in TPA? I mean do we want to retry messages etc.?
Or for simplicity should we not bother with it? I move for the latter.  

I vote that we leave this out for simplicity for now.   I believe that info is something that we expect to put into the TPA (e.g., using <ServerServiceTime>, <ResponseServiceTime>, <NetworkDelay>, <ServiceTime>, <Duration>, <InvocationLimit>, <ConversationLife>, ...).  Given the fact that we are not implementing reliable messaging or exception processing in the POC yet, I don't see what value expressing this in the TPA today would give, other than proving that a mapping exists between the RosettaNet spec and the tpaML spec.

2. Please do clarify the following. Thanks, Prasad

Marc Breissinger wrote:

3. In the description under "Payloads", I don't quite understand what is meant by the second sentence in the text that I reproduced below. Can you please clarify / elaborate?
    "Payloads generated for the messages should adhere to the appropriate RosettaNet PIP 3A4 DTD specifications.  Additionally, those participants assuming the role of “Requester” in the environment must publish any field mappings from their request message that are required for the “Responder” to generate a valid response/acknowledgement message" 

The idea was that if a requester was actually generating PO data from some back end system, and needed certain information to be present in the response/ack payload in order to process the response/ack correctly, the requester must state what they need so responders could respond appropriately. 

<PY> I need to see the details but, the payload should simply follow the payload specification. In this case  RosettaNet Action/Signal message specifications. I don't think we want to couple specific back-end requirements and open / interoperable frameworks and payloads. Especially not in addition to what the framework (ebXML-Header) and payload (RosettaNet standard Action/Signal) already accommodates. Can you give couple of examples here? Where is the real need for it? Thanks.</PY> 

 

I was just trying to cover my bases as I hadn't examined the actual DTD for the response message in the scenario.  I thought, from a demonstration perspective, that if payload data elements were linked between the request and response, it might be nice to actually show that.  Alos, if a participant did want to integrate to a back-end system, the other side would need to know the appropriate way to respond in order to ensure the response is processed correctly.  I wasn't trying to couple things to any back-end integration, just recognize that it might be a long term goal for demo purposes and plan for it.  I can strike it from the document.  No problem.

Marc Breissinger wrote:

Here is the latest revision with changes made from comments that I have
received.  I have still not gotten a chance to actually complete the
template TPA that Chris sent out.  The TPA included in the doc is identical
to Chris's template.  I will work on getting it done over the weekend.  Some
things that I can see need to be done are: (1) Participant information needs
to be completed; (2) Delivery channels and their components need more
descriptive ids; (3) Transport information needs to be completed; (4) two
more services need to be added to accomodate the business level acks defined
in the scenario.  Might be some other stuff - we'll see.  Thanks to Chris
for taking the time to create the template.

Hope everyone enjoys their weekend and is ready to drive through the final
details next week,
marc

p.s. - Changes have been turned on in the Word doc but are not displayed.
You can turn them on if you want to quickly spot what has changed from the
last time.

==========================================================================
Marc Breissinger                                   voice (W): 703-460-2504
Director, Product Strategy - webMethods, Inc.      voice (C): 703-989-7689
Email:  marcb@webmethods.com                               We're hiring!!!
Email2: breissim@earthlink.net              URL: http://www.webmethods.com
==========================================================================

  ------------------------------------------------------------------------
                                    Name: ebXML POC Proposal.doc
   ebXML POC Proposal.doc           Type: Microsoft Word Document (application/msword)
                                Encoding: base64
                         Download Status: Not downloaded with message