[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: XML Gave A War, But Nobody Came
Robert, I'd like to agree with much of what you have said, with some additions. > >[snipped] > > > >Therefore, why not spend our collective efforts on developing a common > >framework/infrastructure that will support interoperability of any and all > >variants? That's much more achievable than developing a single common > >document format and then getting the world to adopt it. > > Having lurked for some time, I am venturing from my bunker to say > a few words. > > I would have thought that he natural OO approach would be to > think of a PO (or whatever) as a class and develop a tree of PO's. > The root of the tree would comprise a common subset of data > and functionality, and descendent classes would elaborate parent > classes to satisfy real application contexts. > Root classes would most naturally belong in Core Components. > > I had assumed that an OO approach to EC would include this idea, > extending to multi-transaction scenarios - but I have > not seen much evidence of this way of thinking in recent ebXML > material. Please correct me if I have missed something. > > By exploiting polymorphism and inheritance it should be > relatively easy to construct software components that handle > any of a subtree of PO's or whatever and achieve interoperability > between them. > >From the perspective of one person from Core Components PT, As the Project Team Leader for CC, I'd like to repeat again what we have been saying from the start ... we recognize that the last thing the world needs is yet another PO! That said, what can we do? Well, we sure know quite a bit about what doesn't work! Independent industry development leads to a proliferation of incompatible messages, and makes interoperabililty unnecessarily complex & expensive! One size fits all business usages [process] and all industries messages, leads to very large, complex, semanticall vague and very costly implementations. OK, what do we do? Well, we can build a framework, capitalizing on levels of stability where we can achieve core object "standardization" and provide an extention methodology for all the "customization" necessary for real world implementation. And, very simply put, what we are doing in Core Components. How might that look ******* my own personal theory ****** First, our levels of stability, starting on the data side with the core Message. That message has two characteristics: Structure and content. Strictly from a structure perspective, this message is probably made up of three components: Header, Detail and Summary. Header contains information that is relevent to the entire message: Document References and the Role Players [simple case = requester/responder pair, complex cases involve agents and brokers for requester/responder]. The Detail section could have a variety of structures: flat, flat loop, hierarchical loops, etc. From a content standpoint, there are a limited number of conceptual or abstract classes which repeat through out messages: Requester, Responder, goods, packaging, payment, etc. Then, at the lowest level, there are other *stable* core elements, such as name, address, quantity, amount, etc. Now on the process side of the house, clearly there is a core business process for PROCUREMENT ... and in that procurement process there are a series of core messages, ORDER, ORDER ACK, ORDER CHANGE, ORDER CHANGE ACK, ADVANCE SHIP NOTICE, etc. These Core messages, within this business process, probably have an abstract description, based on Content abstract classes: Role Players, Document References, Goods, Pricing, etc. What we will find is that there is significant content overlap amongst these messages, which is exactly what we want. Now, when JOE INDUSTRY wants to build "JOE INDUSTRY PROCUREMENT PROCESS", they start with the CORE Procurement business process, and then begin to subclass the process [using the meta model as a guide], and those messages such as the Core ORDER message, and for each high level abstract class, given the set of stable low level core elements, each industry can build the industry specific components such as Joe Industry Goods descriptions. Some abstract elements of the message should not be industry specific, such as payment details, which may occur in multiple formats, but not as many as one for each industry. Next, context. Based on some handful [small number] of contextual clues [business process, industry, etc.] combined with an organization scheme, one can predict [deterministic] which Goods descriptions, Requester/Responder descriptions, etc., apply to any specific message object. What do we have now, 1) an architecture which supports industry specific needs, 2) an infrastructure which encourages reuse, 3) concise messages which do not depend on additional "implementation guides", 4) reusable components, at a variety of levels, which are semantically consistent [one way to say one thing], and 5) extensibility which facilitates the reuse process with a mechanism to add to or reduce existing sub-components. Obviously, having a registry/repository which facilitates sharing, reuse, and organization will be of tremendous value! On the subject of how this aids the SME, I hope the answer is obvious ... one way to say one semantic thing, concise messages, and an infrastructure for organization, etc., aid application developers to incorporate ecommerce into applications ... shrink wapped solutions become feasable. I doubt that anything that is done in ebXML can impact the ability to "duct tape" ebXML to legacy systems, however, the very same qualities that make shrinkwrapped applications feasible, result in the availablility of semantically stable middleware that can be "duct taped" to legacy applications. Regardless of the level of technological sophistication, in the end we all depend on implementors/industries/standards developers to assume a mentality of compliance, and recognize the cost of non-conformance to the community at large. Standards built need to be considered a "neutral" representation, not an image in existing internal systems. As long as we can concatenate, parse, cross reference, bridge, etc., to and from the standard without violating semantic integrity, there should never be a reason to modify the core. All this said, this is one persons vision. Until the project teams are allowed to complete their work, we won't be able to determine if this theory of "stability points" is any better than other guesses. So, I'd like to propose that we call an end to this theoretical discussion, until technical research tells us how we put the pieces together to solve this problem. I have tried to put this in business terms, and have tried to stay away from jargon, but if this message needs to be made clearer, I propose that this discussion be taken over by marketing, and moved to the marketing and awareness project team. Thank you, lms
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC