[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ebXML metamodel write-up
Actually, it is quite common that a customer will send you information in whatever their native format is and you try as best you can to figure out if you can map it to your internal system. The customer doesn't give a hoot. If you are missing some particular piece of information that is absolutely critical, then you would go back and ask the customer for it. We do several billion dollars worth of business that way every year. In or business processes, there is a big difference between a SalesOrder (info the customer sent us in their native format) and a SalesOrderConfirmed (which now has all the info you need so you can execute on it). In the end, the customer still doesn't know and doesn't care what we call the bits of info. regards pk >On page 3 you wrote: > >>>>Independence of ebXML sub-metamodels > >Although clearly interrelated, the ebXML sub-metamodels are not tightly >dependent on each other, and implementations of one can be very >beneficial even in the absence of implementations of one or more of the >others. <<< > >This is totally not true in the case of business process and business >information. The business process is dependent on being able to specify >which core components (data Elements) are necessary for each party to a >transaction to meet their respective legal and business requirements. >One cannot exist effectively without the other. I can't just say "send >some information to me" to place a Purchase Order. It has to be >specified "Please send me the thing I call address, the thing I call >name, the thing I call telephone number etc. Each of those objects has >to also have the ability to be referenced via a repository so the sender >also knows what they are. The semantic reference from a repository >dictates that the RegRep access process be integrally bound to >potentially all transactions (at least in an abstract way - we are >suggesting the use of a cache in the application to ease congestion to >the repository query daemon). > >Also - A core component cannot be used effectively without a contextual >guide to allow it to be instantiated correctly depending on the business >process it is part of. I can't just say Item <a> is equivalent to Item ><b> if there are ten places in each document where there are instances >of those elements. I need to know the context in which thety are being >used. > >TRP as a stand alone - yes - excellent work being done there. > >I look forward to seeing more on the subject of using the UML -> XML >process for data elements and business processes. This is an area we >are concerned about. > >Duane Nickull Peter Kacandes Application Planning, Architecture & Strategy phone number: X36529 WWOPS IT/Supply Chain Management email: peter.kacandes@ebay
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC