OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project


now i am really worried.

are you suggestion because legacy software was built with weak architectures, we have to continue to use it?  clearly there is a need for some form of message service interface to deal with electronic document exchange, but we should not constrain the role of this module with how EDI gateways and translators work today.

to use a real world analogy, the accounts payable clerk should not be expected to have access to the envelope the invoice came in before they can pay the bill.  You will find that the invoice has all the details necessary.  In my experience, some EDI applications have corrupted this modularity of function (by having business applications process enveloping details).  This has always been a case where the implementors have confused business transactions with document exchange transactions.  

Despite the similarities of many elements within the envelope and those in the business document, these are not (and should not be) the same things.  To use a trite example, the From (SMTP) is not the Sender (ebXML MSH, UNB.S002.004) of an Order document is not the Buyer (the business application).  I think you will find this model holds true for all the elemnts you are considering for a 'generic header'.  As another example, a messaging thread is not the business thread of document exchange. If we want to reference which order we are responding to, we use a business components such as 'ReferencedOrder', we don't try and kludge this using enveloping information.  

I note a thread along this vein is now running in ebxml-dev, so perhaps i am not alone is this concern.  To use their example, the ebXML MSH ConverstionID should not be used to denote a business thread (e.g. this is my response to your order)  it is to denote a document exchange (e.g. this is the second attempt to send this response).  

EDI implementations sometimes do this because it is a band-aid solution, simpler than trying to correct the message/document definition.  

If, as you say, this is not a business modeling problem, then I  would encourage the ATG folks to participate in discussion with the ebXML MS team (and specifically the role of a Message Service Interface).  I suspect this is where the mechanics will be resolved, not by peeling off EDI band-aids and sticking them on UBL.


A Gregory wrote:
Tim:

I think there might be some confusion here. You are correct in pointing out
that this is duplicative of messaging fields, and that point has not been
lost on those doing the Generic Header project - alignment is key. The point
is that long before the message envelope has been created, and after the
envelope has been received and opened - some of the messaging information is
still needed by applications that *cannot* access the envelope information.
This is a very common problem, especially with tools such as EDI translators
that are now being equipped to handle XML (they always relied on the control
fields in the message). The idea is to have an optional, standard place to
put this data *in the message* should that be needed.

Melanie can probably better answer your questions, but I would point out
that this is not a business modelling concern - it is strictly mechanistic,
to accomodate the capabilities of tools and applications.

Cheers,

Arofan

-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Monday, February 10, 2003 6:24 PM
To: A Gregory
Cc: UBL-NDR; UBL LCSC; mkudela@uc-council.org
Subject: Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project


I must admit to being confused by this.  I recognise the concerns that
EDIFACT folks might have about this data, but I am not sure that they
need to have any.  It is being tackled by the OASIS ebXML MS TC.

Either I missed soemthing here, or what you describe sounds to me like
the ebXML MS specification, which i think you will find covers the same
ground.

Therefore, my first reaction would be to suggest that rather than
re-invent this protocol we remain agnostic of it.

However, I would like to make a few observations and ask some further
questions, either of Arofan or Melanie....


A Gregory wrote:

  
This is an incredibly common set of data - we found ourselves adding it in
xCBL, and every other major e-business vocabulary lists this data,
    
typically
  
as a set of attributes on the document-level element. It includes such
information as who sent the message, who is receiving it, what business
process it is part of (correlation IDs), and similar. It is very similar to
some of the control fields found in EDI messages.


    

The reason that every major e-business vocabulary lists this data is
that they want to remain independant of messaging and transport
protocols.  The problem with this is that you establish  duplicate and
possibly conflciting data sets.  One of the strengths of the ebXML
framework is that is separates the 'business/core components' ,
'business processes' and the 'messaging, routing and transport'
protocols.  They do not overlap. Rather, they work with each other (but
do not rely on each other).

I must plug a ( :-[ ) reference for this comparison
(http://www.amazon.com/exec/obidos/ASIN/1861005903/qid%3D1044929975/103-7202
419-8491066).
 Specifically, chapter 15 compares EDIFACT control fields with ebXML MS
elements.

  
The generic header project is standardizing the names and datatypes for
these fields. It would be fairly simple to adopt the proposed standard, and
fit this information in as a set of standard, optional attributes at the
document level. (And I can guarantee that of we don't include this basic
information in our version 1.0, we'll have requests to include it in our
    
1.1
  
release...)


    
Isn't this a 'higher level' protocol?  doesn't it run the risk of
overlapping with others?  I think you will find that the ebXML MS spec
has mappings to the EDIFACT control fields (UNB-UNZ, UNG-UNE, and
UNH-UNT) - this is not accidental, those building the ebXML MS spec used
these (and the NASI counterparts ) as a basis for their work.

  
Typically, these fields are used by translators that are communicating with
a back office application, and which are capable of only performing the
translation on a single XML document at a time. If the envelope information
isn't present, then the translator has to make calls out to a database or
other place where the envelope information is stored. This is often not
possible, especially for users with less sophisticated systems, since a
    
link
  
to the envelope received and opened at a corporate gateway doesn't always
exist.


    
Again, what you decribe is the business proccess interface that is part
of ebXML  BP definitions.  Isn't this a CPP reference accessed from a
repository?

  
Melanie and her group can supply materials describing the project, but I
think it would be great if we could adopt this standard as a part of the
    
UBL
  
library, and figure out how to implement it. At the very least, I'd like to
add it to the agenda for discussion at the next NDR con-call.


    
I am all for unified standards , but i am not clear what problem this
project is addressing that ebXML isn't already working on.

Perhaps we can see the materials you refer to, and specifically how this
varies from that of the ebXML MS OASIS technical committee (ref:
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v1_092.pdf) ?

  
Cheers,

Arofan Gregory




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



    

--
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

  

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC