[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen ericHeader' Project
In WSCI and BPML we had to solve exactly that problem. We chose a slightly different approach by separating the 'data' from the 'message'. 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. It may be specific to a given message, in which case it is defined as part of the payload. It may be generic to all messages, in which case it is defined as part of the header (e.g. the creation timestamp). Since we already have a list of pre-defined headers and that information is included in all messages, it can be passed to the process without having to replicate that information in the payload. Yet, the process does not have to receive the entire set of headers, most of which are of no interest to the process. It receives only those headers it has interest in. The process is not aware of how the information in the message is transformed into the inputs of the process. The process only cares about the names, types and semantics. Any transformation is done at the messaging level and is defined as part of the messaging-layer definition (in our case WSDL). There is no need to list 'address' in the architecture document. However, if 'address' is included in every header then it could be described using UBL and can be propagated to the process instead of duplicating 'address' in both header and payload. arkin > -----Original Message----- > From: Duane Nickull [mailto:duane@xmlglobal.com] > Sent: Monday, February 24, 2003 9:49 AM > To: Burdett, David > 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 > > > David: > > Your solution #1 is what both the UMM and architecture have been saying. > IF you desire having a generic header, then place it into the payload > with the rest of the business information. That is the same for any > business information needed by the parties. > > Business information is > > 1. identified as needed during the modeling phase > 2. developed using UMM > 3. expressed in the syntax for the transaction. > > What members of the architecture team expressed was that adding business > information into a space in the ebXML MS is a Pandora's box. Where do > we stop? If someone now says they need a second element for giving > their applications a direction for more specific processing, do we place > that as an architectural component too? > > I personally like clean and clearly defined areas of functionality, > consistent with OO programing methodology. Keep the messaging layer > doing messaging etc. > > There is nothing in the architecture document that says you cannot have > a generci header in the business payload. It is clearly allowed when > following the process of UMM to model a business payload. If it is > identified as needed, then it will be there. > > If we call attention to it with a sentence, then what else would we have > to call attention to? Do we have to list "address" in the architecture > document, along with "name" "po number" and other business elements? I > personally would be against listing any specific syntax of business > information in the architecture document. We already allow all > information that any user deems necessary - one of the key strengths of > ebXML and related specifications. > > Duane Nickull > > I am sure this will be discussed in greater detail in > > > Burdett, David wrote: > > As counter thought (I would not put this as strong as an > opinion), there is > > one use case for having a generic header. > > > > If, for example, you take using UBL with ebXML MS, then there > is information > > in the ebXML MS header that "might" be useful to the process that is > > handling the UBL document, for example the time the message was > created, or > > its identity. > > > > I would guess that most implementations separate the ebXML MS > envelope from > > the UBL document, therefore there is a risk of this information > being lost. > > There are a number of ways around this, including: > > 1. Copying the information from the ebXML MS header into a > "generic header" > > within the UBL document - this should be optional, if done at all. > > 2. Providing an API to the ebXML MS implementation that allows an > > application to derive this information. > > > > Just my $0.02c. > > > > David > > > > -----Original Message----- > > From: duane@xmlglobal.com [mailto:duane@xmlglobal.com] > > Sent: Saturday, February 15, 2003 6:18 PM > > To: tmcgrath@portcomm.com.au > > Cc: 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 > > 'Generic Header' Project > > > > > > > >>I don't want to buy into this debate, just get a clearer view of the > >>architecture being proposed. ...> As Duane Nickull has indicated on the > >>ebxml-dev list, this is an> architectural issue, not one that > those in the > > > > ebXML MS team > > > >>necessarily appreciate (from their comments i suspect they just think > >> > > > > Tim: > > > > To clarify my own opinion, I do not see any need for a generic header > > since this does duplicate infromation already avaiable to both > sender and > > receiver. As such, our architecture team made a decision NOT to place > > the GH in the architecture. > > We did agree, however, that in certain circumstance, one or > both parties > > may feel that they desire the generic header (identified via UMM?) and > > can use it. > > The architecture does not prescribe it or disallow it. > > > > Duane Nickull > > > > > > > > ---------------------------------------------------------------- > > 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> > > > > . > > > > > -- > 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC