ebXML-Core Components' Context:
ebXML-BP Report - Draft
Brian Hayes [brian.hayes@commerceone.com]. 26 June 2000
This report provides my understanding of the "Context" concept of the ebXML-Core Components team and how it maps to ebXML-Business Process team's meta-model. The information in this document is based on the Core Components Presentation [CCP00], two email messages from Lisa Shreve, Project Team Leader for Core Components, and a discussion with Core Components team members Arofan Gregory and Sue Probert. Excerpts from these references are provided in this document.
Note: Except for the opening comments by Lisa Shreve, this section is my own interpretation of Core Components and Context and how they will and could be used within the ebXML framework.
Lisa Shreve [lms@wwnet.com], Project Team Leader for Core Components, has written the following:
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 interoperability unnecessarily complex & expensive! One size fits all business usages [process] and all industries messages, leads to very large, complex, semantically 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 extension methodology for all the "customization" necessary for real world implementation. [Shrieve00]
When you analyze a collection of business-to-business documents, you see that there is a great deal of commonality. Looking at purchase order, purchase order acknowledgement, change order, change order acknowledgement, and order request, you could assert that all the documents are of type "order." If you further analyzing the structure of the document you would notice a number of patterns. First, the documents have structure. A simple document might have a header (e.g. order header) and a body (e.g. list of line items). Upon further inspection you would notice that there are common structures within a document and across documents. At the lowest level, there would be common "core" elements such as date/time, address, and allowance/charges.
From core elements we can specify composite elements on up to a document.
While attempting to identify the common structures (core components) in a set of documents, you might notice that there are variations in structures that you would like to be common. For example, the required elements in "party" might vary depending on industry and business process. We would like to define a core component, Party, which specifies just the elements that are common across all industries and business processes. Then, by using schema extension mechanisms (similar to object-oriented sub-classing), we can then create new party schemas that extended Party with appropriate elements to support a particular usage context. For example, you could have a standard purchase order header that supports basic ordering (perhaps just indirect goods) and, through the schema extension mechanism, have a direct-goods order header that contains additional elements required for direct goods ordering.
It should be possible to model core elements, composite elements, and documents using a modeling language or notation such as UML. From the model, we should then be able to create a specific schema representation of the elements or documents. The schema could be DTD, SOX, XSDL, XDR, and even X12 and EDIFACT.
If we just use the schema extension mechanism to create variations in core elements we end up with lots of schemas for these extended elements. We can package the various extensions into namespaces that are aligned with the context in which the extensions are developed. For example, you could have a Purchasing namespace for standard purchasing elements and documents and you could have a Purchasing.Automotive for an Automotive market/portal's unique extensions to purchasing elements and documents in the automotive industry (which, of course, extend Purchase documents and elements).
The extension mechanism is required to extend the core components to provide the necessary variations. However, our EDI experience tells us that even with this ability, we will still require implementation guides so that trading partners can get their systems to talk to each other. It is likely there will be many optional sub-elements in core components and extended core components as a result of trying to satisfy too many needs. There is no dynamic way to specify exactly what elements are required in a given context. The Context concept solves this problem (or significantly helps to solve the problem). Traditional message implementation guides are no longer needed since the Context specifies exactly what is needed.
Context revolves around four concepts: a Core Component Library (actually, this is a soft requirement as I will explain later), a Context Classification scheme, a Context instance and a document's Context Rules Definition. A document schema instance is determined by a Context instance, a Context Rules Definition instance, a set of schemas from the Core Component Library and schemas from other schema libraries (whose elements are built upon the Core Component Library) .
The Context Rules Definition in conjunction with Core Components specify how to assemble the schema of a document for a give Context. For example, the Context Rules Definition instace for a purchase order may indicate that the EuropeanTax element is required where the usage Context of the document is "Europe." A Context instance might specifiy, for example, "Direct Goods," "Automotive," and "North America."
The acceptable values for use in a Context are specified in Context Classifications. A Context Classification is a set of context names/identifiers ("Purchasing," and "Aeorspace" are examples of context names). There will be multiple Context Classifications, where each Context Classification lists the context identifiers for a single subject.. Likely subjects are industry, product, region, and business sub-process. The actual context naming scheme is hierarchical and draws from various standards. "Each aspect of context has a hierarchical nature to it, but the various elements of context (business process relative to industry, for example) are not hierarchically related." [Shreve0623] Ideally, instances of the ebXML-Business Process meta-model will contain the information to define a document's context.
The Context Rules in a Context Rules Definition may be applied to refine existing core documents and to refine the elements of an existing core document. Refinement may be additive (extensions) or subtracive). Context Rules can also be used to specify the optionalality of elements in a core component.
Document Rule Definitions can occur at various "layers" in the ebXML business process model. There can be Document Rule Definitions at the market level for documents owned or controlled at the market level. Businesses, processes, and services may also have Document Rule Definitions. Presumably, an analysis tool can be used to compare to different Document Rule Definitions for two different services.
Reference The ebXML Business Process Metamodel First Draft Technical Specification, Draft Version 1.0, 26 May 2000. This is my first cut at introducing Context into the model.
Work In Progress:
The Information Flow (Business Message) specifies the Document Schema Reference (name) which specifies the Document Definition (the schema or a Message Implementation Guide) which is created by applying the document's Document Definition Rules and the Context specific to is usage. There may be a registry that maps a document schema (its URN) to the Context and the Document Definition Rules that were used to create the associated schema instance.
Rename Document to DocumentDefinition or DocumentDefinitionReference. [DocumentSchemaReference] refers to [DocumentSchema]. An instance of [Document Schema] is defined by an instance of [Context] and a [ContextRulesDefinition].
Section 4, Business Service Interface. Instead of modeling " Information Flow defines Business Signal," model "Context defines Business Signal." And, if you want to be eCo like, drop Business Signal, and have three relationships between Business Service Interface and Context: "Context defines input Information Flow," "Context defines output Information Flow," and "Context defines error Information Flow."
The Dictionary represents the registry of Core Component schemas, other component (e.g. documents and aggregate elements) schemas, ContextRuleDefinitions instances, and Context Classifications, and/or Document types. From eCo, we learn that the types are specified as URIs. It may be desirable to have multiple registries: one for Information Entity schemas, one for Information Entity schema types, one for Context types, one for Document types, and one for Context instances. Since a Document can be consider just another Information Entity, we probably don't need special Document related registries.
Excerpts from the Core Components Presentation at the May 2000 ebXML Conference, Brussels [CCP00].
"World does not need another PO!"
Scope of Core Components PT
What is Context?
How is Context Used?
Multi-level Context Classifications
[Brian Hayes] I don't know what this means. However, I could imagine that one could analyze a pre-deployed release of an [BP] Information Model instance to identify patterns and core components. After this is done, the Information Model is redone to make use of the core components and Context.
Registry/Repository
The following notes came from a discussion I had with Arofan Gregory of the Core Components team. Notes are always subject to ones interpretation; I have distinguished notes/concepts which may have not come from Arofan and may be my own derived thoughts with "[Brian Hayes]."
Referece [Shreve0602].
... ******* 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.
Referece [Shreve0623]. This email was sent in response to the first version of this report, 14 June 2000.
I have a few comments:
1) in the summary, I'd incorporate the thoughts
- operating on an exception basis, for handling differences
- brings order to the implementation process
2) in the "context" section
- paragraph 4, each aspect of context has a hierarchical nature to it, but the various elements of context [business process relative to industry, for example] are not hierarchically related
- paragraph 5, context will 1) shape the document at the highest level, 2) extend (+ or -), and specify appropriate code sources at the lowest level
- paragraph 6, I'm not sure at all that we will have a context specification language, but it is clear that if we can write code in advance to produce the desired results, we have a deterministic solution. The deterministic nature of the solution is the point to emphasize here.
3) Information Flow and Documents
- first paragraph, I think I understand what you are trying to say here, how does the following sound to you.
Using context to specify a document is significant. Instead of thinking of traditional documents, we can think in terms of events/actions, and information flows. An information flow can be thought of in terms of the functional composition of that messages, independent of traditional document boundaries. For example, instead of the point of focus being concentrated on a Purchase Order document specification, we are concerned with the Action of Ordering, and the functional elements for that Order, and specifying the context for which that Order applies. The Context, combined with the functional elements of the Order, specifies the exact information set. Moreover, the documnt elements can be dynamically specified, dependent on context.
I'm not sure what do with the last example in the paragraph. I do think you need an order document to extend, it is merely what that order document contains that is in question.
lms
Context represents a revolutionary concept in the specification of documents and information flows. The added complexity that Context brings is outweighed by the benefits it provides in facilitating interoperability a global electronic market.
---