RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric H

["David Connelly \(OAGI\)" <dconnelly@openapplications.org>]

Title: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric Header' Project

Hi Assaf,

 

Two payloads are not necessary.  With a good schema design, one can accomplish both.  The OAGIS BODs have an application area and a data area for each schema that accomplishes exactly what you are striving for.

 

Example picture is attached.

 

thanks

 

dc

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Wednesday, February 26, 2003 3:49 PM
To: Burdett, David; Duane Nickull
Cc: tmcgrath@portcomm.com.au; MKudela@uc-council.org; ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric Header' Project

I think the use of 'payload' is somewhat confusing.

 

For the business application the 'payload' I am talking about is the business payload which may include information such as when the message was created. So I could say something like:

 

payload := po, createDate

 

For the messaging layer the 'payload' is what you send over the wire, and you can standardize that some payload always exists whether it's sent as part of a header in one protocol or elsewhere in another protocol, something like:

 

message := header(createDate,...),body(po,....)

 

Let's say I define a business transaction in which the payload createDate always exists. I elect to use ebXML TRP, so that business payload is carried in the ebXML header. Nice. No let's say I want to use a different protocol, so somehow that payload has to be carried in that message and whoever defines that other protocol to support by business transaction has to figure out where to carry it and how to create it.

 

If they have a messaging layer than can support that header, e.g. WS-RM, then they will just map that payload from that particular header (easy). If they don't, then they'll have to somehow in their messaging layer (so it doesn't pollute the business application) figure out where to put it and how to create it.

 

Of course you end up having two schemas: one for the business payload and one for the over-the-wire message. Not a big thing if you're using a good type system like XML Schema which can easily accomplish that using extensions, content models, etc. But eventually you don't really care what travels across the wire. Do we validate Ethernet frames? TCP acks? HTTP URLs? All we care about is the business content and that's all we have to validate, inspect and in fact talk about ;-)

 

arkin

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Wednesday, February 26, 2003 1:28 AM
To: Assaf Arkin; Duane Nickull
Cc: Burdett, David; tmcgrath@portcomm.com.au; MKudela@uc-council.org; ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric Header' Project

The original use case for including the "header information" in the payload is to support some of the existing translation/mapping software tools that can only handle one "document" at a time. They are unable to support message information in a header and simulataneoulsy handle the document itself. Copying the information into a header in the document solves this problem. This is really no more than a different representation of the message information.

But is this the right way of solving the problem?

The questions we need to answer include:
1. Does creating a standard set of header information help? I think the answer is yes at it reduces development cost for *those instances* where you have a business or technical need to do it.

2. Should such a header be a standard (optional) part of each message? I don't think so since in many cases it will not be needed at all

3. Should you define a standard way of including it in a message when needed? I think you should as sometimes you will need it. In this case handling it using XML Schema and its extension mechanism makes sense, I think.

Bottom line, message metadata information should normally go in the header and not in the document but a method of putting or copying the information into the message itself should be defined for use when needed.

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, February 24, 2003 12:02 PM
To: Duane Nickull
Cc: Burdett, David; tmcgrath@portcomm.com.au; MKudela@uc-council.org;
ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG
'Gen eric Header' Project

> -----Original Message-----
> From: Duane Nickull [mailto:duane@xmlglobal.com]
> Sent: Monday, February 24, 2003 11:43 AM
> To: Assaf Arkin
> Cc: Burdett, David; tmcgrath@portcomm.com.au; MKudela@uc-council.org;
> ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
> Subject: Re: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG
> 'Gen eric Header' Project
>
>
>
>
> Assaf Arkin wrote:
> ...
> > The information exchanged between the processes is described in
> one place.
> > Let's call it 'input' for a second. If the process needs to
> know when the
> > request was made than it's input will include some property
> 'tns:createdAt'.
> >
> > The manner in which that information is contained in the
> message is defined
> > elsewhere.
>  >>>>>>>
> Assaf:
>
> Yes - we also do that.  In fact, a party knows exactly what the content
> is before they look at the payload.  This is determined by a number of
> artifacts.
>
> In ebXML architectures, the BPSS + state, along with the assertions of
> CPA ID and Conversation ID in the incoming message can alone determine
> the exact content.   If someone uses the entire ebXML arch, there is no
> need for an additional Generic Header.
>
> The need for this arises out of partners who do not use the stack.  They
> would identify a requirement for the GH then include it in the payload,
> where it belongs.

Let's say someone uses a different stack that does not include the
standardized ebXML headers.

In the definition of the payload they say what information is required in
order to process the message, including time at which it was created.

To deploy the implementation the stack must be able to somehow transmit that
information. From its perspective it may include it in the header or the
payload. I may extend the payload to include that information. I may also
use some other standard header to include that information (e.g. WS-RM).

All you need is to differentiate between the input/output of the process and
the actual message that travels over the wire (protocol dependent). You can
then let the stack determine how to encode the input/output, whether to
include it in the payload or header, and which header (e.g. SOAP header,
HTTP header, etc).

So the input would look something like:

1. purchase order
2. created by
3. created at

And the messaging layer would include way to encode that information in
different ways for different protocols.

arkin

>
> Duane
>
> --
> VP Strategic Relations,
> Technologies Evangelist
> XML Global Technologies
> ****************************
> ebXML software downloads - http://www.xmlglobal.com/prod/
>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>

BOD.jpg