Re: ebXML Proof of Concept Proposal v0.5

[Prasad Yendluri <pyendluri@vitria.com>]

Marc,

Please see some follow up below in <PY>

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>

5. If SMTP is part of the Hub model, I am not sure if we can guarantee "hub should not cause any alteration of the envelope, header or payload of the messages". I mean SMTP (mail) servers are likely to add additional headers to the (transport) envelope, which gets into the message envelope also (per ebXML scheme)! 

> The
> point was that the hub should not alter the ebXML message envelope,
> header or payload.  The transport envelope can be modified at will.
<PY> But the message envelope becomes part of
transport envelope during transport (in ebXML) and gets put back as message
envelope on  the receiving side. So, any changes to transport envelope
could potentially have an impact on the message envelope especially in
SMTP case.

I agree with your description and point below. That would have been a better approach.</PY>

In fact, part of the value add of the hub could be to connect partners that support different protocols that otherwise would not be able to talk to each other.  This does bring up a larger issue on maintaining the separation of the ebXML Message Envelope from the transport envelope.  For example, if we truly maintained the spearation of the ebXML MIME message envelope from the transport envelope, an HTTP transport ebXML message would look like the following:

POST destination-server-ebxmlhandlder-URI HTTP/1.1

Content-Type: multipart/related; 

boundary=transport-envelope-boundary

 

--transport-envelope-boundary

Content-Type: multipart/related; 

type=”application/vnd.eb+xml”; 

boundary=ebxml-envelope-boundary

 

--ebxml-envelope-boundary
    <ebXML Header>

--ebxml-envelope-boundary

< Payload > 

--ebxml-envelope-boundary--

--transport-envelope-boundary--

This scheme would allow for a hub to route a message without affecting the ebXML message envelope.  The hub could switch protocols from HTTP to SMTP to FTP to whatever without affecting the ebXML envelope.  However, the current packaging specification mixes the definitions of the ebXML message envelope with the transport envelope and we should follow the specification.  Thus, I suppose we have to allow the hub to alter the ebXML envelope (much to my dismay).

<PY> I concur with your conclusion above.</PY>

7. Again in packaging (para following the above) says:   "It should also be noted that the payload Content-Type must be application/x-rosettanet as outlined in the RNIF 1.1 specification."

I am sorry, that is not true. It should simply be "application/xml". The example ebXML message "payload" content-type also must be changed to application/xml from "application/x-rosettanet". 

You are, of course, correct.  My bad.  I will change in the doc.  However, it does bring up an interesting question for the broader group.  Namely, if ebXML TR&P is allowed to carry many different kinds of payloads from many different standards, should we enforce a requirement that vertical industry payload standards conforming to ebXML standards define a unique sub-type?  That would allow an ebXML service provider to route a RosettaNet payload to a generic RosettaNet handler, an OAG payload to an OAG handler, an OTA payload to an OTA handler, etc.  Just a thought.

<PY> The nature of the payload is identified in
the ebXML-Header. Is it not complete enough? </PY>