+1. Placing the "generic header" as its own payload, and identifying it as such in the message manifest makes more sense from an architectural point of view than embedding it in the MSH headers. Not only do we keep the responsibilities of the MSH and Application separate, but we allow the generic header to be used in ebMS v2 implementations, and not just a future release of ebMS. -Matt Duane Nickull wrote: > 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> >> >> . >> > >
S/MIME Cryptographic Signature