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

[Assaf Arkin <arkin@intalio.com>]

> -----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>