ECIMF



Proposal for CEN/ISSS Workshop Project within ISSS/WS-EC/99/055 on E-Commerce Integration Meta-Framework (ECIMF)

CEN/ISSS/WS-EC/ECIMF

Final draft, version 1.3

April 25, 2001

Purpose and Project proposers

WebGiro AB, and Nada/CID at the Royal Institute of Technology in Stockholm, Sweden, supported by associated partners Hewlett-Packard, Microsoft and MCI WorldCom have proposed CEN/ISSS to start a workshop project within Electronic Commerce Workshop, regarding a standardized meta-framework for describing and aligning various aspects of already existing e-commerce frameworks, with the aim of increasing their interoperability, end-to-end Quality of Service (QoS) and to lower the barriers for wide-spread adoption of electronic commerce. The parties will within their business environments support and implement the result on a global basis starting in the EU-countries.

The proposal for this Workshop project is made in the context of the dialogue with the IT-Industry partners and e-commerce users regarding the exploding demand for Quality of Service in this area. Several initiatives have been taken to open the interoperability between various systems and service providers. Due to the identified additional needs WebGiro AB and associated partners are now proposing this initiative according to the following Workshop Project Objectives.

Project Objectives

4 Background and the Problem Statement

There have been many standardization activities in the area of e-commerce communication. The standard bodies and industry groups in multi-national levels have been promoting several standards. Some of these, with long-standing tradition (like EDI variants), have gained significant acceptance, especially among large industry players. However, these standards are often criticized for their complexity, high implementation cost, multitude of local variants, and extensive demand for expertise knowledge. Other frameworks for electronic commerce, defined more recently in the Internet age, try to avoid those mistakes, and they also have seen some acceptance in selected industry sectors (RosettaNet, OBI, cXML, xCBL, upcoming ebXML …).

However, the proliferation of mutually incompatible standards and models for conducting e-commerce resulted in even more increased demand for interoperability and expert knowledge, as business parties trying to adopt some of these frameworks discover that their choice doesn’t offer them as much interoperability as one would expect from “standards-based” solution. So, overall, the isolated efforts of industry groups and standard bodies created quite the adverse effect from what was intended, when it comes to wide acceptance of electronic commerce, especially in the SME market.

These issues slow down the spreading of e-commerce applications, and for this reason the industry is looking for methods to meet the exploding demand in the “new economy” to offer increased QoS, reduction of manual labor and cost, and to meet the requirements of nearly real-time reaction to changing market demands. At the same time the industry is aware that existing e-commerce frameworks require costly adjustments in order to fit their business model to that of specific frameworks, with the perspective that similar costs will follow if the business player wants to participate in other frameworks as well.

5 E-Commerce Integration Meta-Framework scope

In response to these concerns from the industry, WebGiro AB together with its partners, and in cooperation with Nada/CID, submits this initial proposal for an E-Commerce Integration Meta-Framework (ECIMF):

A meta-framework, which offers a modeling language, methodology, and prototype tools for all e-commerce users to achieve secure interoperability of the service regardless of system platforms and without major adjustments of existing systems.

The main purpose of this meta-framework is to facilitate the interoperability by mapping the concepts and contexts between different existing e-commerce frameworks, across multiple architectural layers. An important premise for this project proposal is the following definition of interoperability:

The interoperability, as seen from the business point of view, takes place when the business effects for the two involved enterprises are the same as if each of them conducted a given business process with a partner using the same e-commerce framework.

As a consequence of this premise, the project proposes using a top-down approach to the comparative analysis of the e-commerce frameworks, which starts from the business process level. The project should also reuse the experiences of other projects in the area of Business Process analysis and modeling.

6 Benefits

The development and adoption of the ECIMF standard should benefit especially the following groups:

• SME market:

The small companies no longer will be forced to restructure at all costs their internal systems in order to conform to whatever framework their bigger partners have. The interoperability bridges that conform to ECIMF will allow them to do it gradually, based on the economic principles, while at the same time allowing them to participate in the e-commerce. This should result in more SME-s joining the e-market, even though their internal economy systems may not yet follow any standard e-commerce framework.

• System integrators:

The system integrators will be able to use a consistent methodology, and a precise framework for defining the integration bridges. The results of their work can be implemented on various conforming platforms, no longer locking them (and their customers) into a single proprietary tool. The overall cost for the implementing the integration solution, its maintenance and amount of manual labor will be reduced.

• Software vendors:

The software vendors will be able to offer competitive integration products that conform to the standard framework. This means that their products will be more attractive to the customers, who are more likely to choose a solution that guarantees them certain level of independence. At the same time though, the conformance to ECIMF should allow software vendors to offer clearly understood added values, which are now very often misunderstood because of the difficulty in comparing proprietary methodologies.

7 Relationship to various global e-commerce frameworks

The aim of the ECIMF project is not to propose yet another e-commerce framework. We recognize the efforts of various standardization bodies and industry groups to provide global solutions in this area (e.g. ebXML[[i]], RosettaNet, xCBL, OAGIS framework, Hewlett-Packard’s e-Speak[[ii]], Microsoft’s BizTalk[[iii]]), as well as other projects offering tailored solutions for specific market or industry sector.

The ECIMF project does not compete with any of these frameworks. We welcome and look forward to cooperate with their representatives in order to enhance the results of this project. The need that the ECIMF wants to address is the interoperability between these frameworks, especially for the transitory periods in SME environment (economic and manpower limitations), which are required for adoption of any of the frameworks.

In our opinion at least two factors will continue to adversely affect the wide-spread adoption of e-commerce: one is the fact that quite a few businesses already made commitments to some of the existing frameworks, in terms of internal expertise, investments, partnerships, and adjustments to the technology and models for business interaction imposed by these frameworks. This situation is combined with the current approach to system integration, which very often locks up the companies to specific system integrator and specific proprietary solutions.

The other limiting factor is that extensive knowledge and experience is still required to adequately understand the differences between the frameworks, and even more to implement some level of interoperability – both between the e-commerce frameworks themselves, and between legacy systems and any given framework. Also, though more and more modern frameworks use UML to describe parts of their models, there is no general meta-framework that would allow comparing them in a meaningful way, not to mention the fact that many frameworks are defined using imprecise, natural language descriptions.

It’s worth noting a fact that is often overlooked: the differences between e-commerce frameworks are much deeper than just differences in their protocols, scenarios and data formats. There is a need for a unified methodology to compare and align also the semantics of basic building blocks in order to properly understand these differences.

The development of the ECIMF standard will build on the experiences from projects such as ebXML [1] (specifically BP, CC, CPA), UN/CEFACT Unified Modeling Methodology (TMWG-N090R9), eCo framework [[iv]] (and its implementation in e-Speak [2]), RosettaNet [[v]], BizTalk [3] (and BizTalk Server tools), OMG’s Model Driven Architecture, and others in order to provide a sufficiently broad and general model for alignment between the frameworks.

Consequently, we see the ECIMF project as a complementary and necessary part of e-commerce adoption, reducing the cost and amount of labor required to adopt any e-commerce framework.

Project Details

See Annex 1 for the detailed description of the project scope and the proposed methodology.

The following list shortly describes the scope for the ECIMF definitions:

• Meta-framework modeling methodology – an approach to model the interactions and transformations required for mapping between different e-commerce frameworks:

• Top-down analysis, based on the business process integration

• Multi-layered modeling approach

• Calibration of concepts within corresponding contexts

This part of the project requires close collaboration with the experts in order to reuse as much as possible the experiences collected by groups like ebXML, RosettaNet, OAG, EDI community and others.

• Meta-framework modeling language – a precise notation to describe the concepts of the e-commerce frameworks, the contexts in which they occur and interact, and the required transformations between them:

• Semantics of the base building blocks (actors, messages, transactions), data models

• Scenarios for message exchange (business processes)

• Access to external resources (URLs, directories, catalogues, databases, etc…)

• Messaging models

• Security models and services, as far as they affect the business process and interoperability on the technical level

• Transport protocols

• etc.

For the business process modeling we suggest substantial reuse of the results of ebXML BP work, with additions of the modeling notation and language to express the transformations between the business processes on different layers.

• Proof of Concept – the project will aim to provide a Proof of Concept implementation of the tool-chain needed for realization of the proposed methodology, demonstrating the interoperability between some concrete e-commerce frameworks. The tools developed by the project will be published under Open Source license, freely available for both private and commercial use.

Project Deliverables and Timescales

The timeframe for this project is set up initially to be 18 months. The manpower allocated to this project will be at least as follows (expressed in percentage of time involvement times number of people):

• WebGiro: 1 person, 50%

• KTH: 2 persons, 25% each

• HP: 1 person, 50%

• Microsoft: 1 person, 50%

Additionally, in later stages of the project, we intend to find enough interest for the proof of concept implementation of the ECIML-compliant agent from our industry partners to allocate additional programming resources.

We invite other workshop members, groups and industry representatives to contribute their resources to broaden the scope of the project. The choice of particular topics for proof-of-concept activities results from the limitations of the resources, and the need to provide useful results in a limited time.

Assuming the above resources, the planned deliverables will consist of the following:

• General ECIMF methodology (ECIMF-GM):

A document (CWA) describing in detail the multi-layered approach, and the specification of the ECIMF methodology (notation and use). This part will result from the discussions on the general methodology on how to approach the business process integration. The intention is to keep this part vendor- and tool-independent. Depending on the involvement of the project members, this document can have a value of either general guidelines, or formalized methodology. Our aim is to provide the latter.

• ECIMF technical specifications (ECIMF-TS):

A document (CWA) containing the formal technical specification for the serialized form for the models (i.e. the ECIML specification), and a Proof of Concept (example mapping between BizTalk and e-Speak). This part may include additional examples of mapping, depending on the contributed resources.

• The reference tools (ECIMF-RT):

These tools include the ECIMF Navigator based on the Conzilla for conceptual navigation and calibration, integrated with a ManifestFactory implementation in order to produce the MANIFEST recipes based on the model. If the timeframe and the resources available will be sufficient, a basic ECIML-compliant agent implementation will be created to support the Proof of Concept mapping.

The following milestones are planned for delivering the results:

10 Initial Proof of Concept (POC) for the approach

Deliverables:

• Reformulate and elaborate on the FAM CWA material in order to show how Conzilla tool can provide structured and contextualized added value to a textual description.

• Provide an initial description of the methodology for comparing the e-commerce frameworks (this will form the draft of ECIMF-GM document).

• Prepare a simple example of mapping the differences between two e-commerce frameworks (e.g. BizTalk and e-Speak), using the proposed approach.

Timescale: 12 June 2001 (Oslo meeting)

11 Initial ECIMF specification and basic integration with Conzilla

Deliverables:

• Initial version of the ECIMF-GM and ECIMF-TS documents, and models of a concrete business process in BizTalk and e-Speak.

• Customization of the Conzilla tool to support the modeling notation introduced in ECIMF-GM.

Timescale: mid-October 2001

12 Refined ECIMF specifications and extended tool-chain

Deliverables:

• Refinement of the ECIMF specifications based on further comparative modeling of the selected frameworks (e.g. BizTalk and e-Speak)

• Extended support for the process in the tool-chain: integration of Conzilla, scripting language and the ECIML code generation to form the ECIMF Navigator tool.

Timescale: 1Q2002

13 Further refinements to ECIMF specifications, and a reference ECIML-compliant agent implementation

Deliverables:

• More refined ECIMF specifications, and additions to the tool-chain to support the specification.

• Depending on the support from industry partners, a basic reference implementation of the ECIML-compliant server.

Timescale: 4Q2002

Project resource funding

The project resources, as mentioned in the previous section, are funded primarily by WebGiro. We are also in the discussion with our partners regarding the level of their participation.

After the project completion, in order to spread the adoption of the developed models and techniques, there will be a need for specific resources to set up and maintain the registry and repository of the MANIFESTs, as well as provide further refinements to the ECIMF. It is yet to be defined how these resources will be funded (e.g. industry group, membership community, already existing or upcoming registries [ebXML, UDDI], …).

External Liaisons

The project team should coordinate its activities with the following projects:

• CEN/ISSS/EC-WS/Architectures

• CEN/ISSS/EC-WS/DAMSAD,

• ebXML,

• BSR,

• RosettaNet,

• CommerceOne,

• OAG,

• OMG,

• others – tbd.

Summary

The ECIMF proposal described here is intended as a generic meta-framework modeling approach, which allows the domain experts, system integrators and e-commerce parties to define precisely what is needed for the different frameworks to interoperate. The present situation when multiple conflicting e-commerce models are advertised and to some extent accepted calls for a systematic approach to more and more frequent interoperability and quality of service issues.

The project deliverables will include the meta-framework definitions, the methodology for analysis and transformation between e-commerce frameworks, and the prototype tools for navigation and alignment.

We are also aiming at providing an Open Source implementation of the basic functionality for the ECIML-compliant agent (E-Commerce Integration Toolkit – “ECIT”). The full-fledged version of the ECIT can be realized e.g. as an infrastructure service, or as an in-house server for specific organizations or corporations, and may include competitive commercial solutions from the software vendors.

Annex 1 – Project Details

The E-Commerce Integration Meta-Framework

The language

The ECIMF initiative proposes the use of UML-like modeling language to express relationships between the semantics and models of the e-commerce frameworks. This E-Commerce Integration Modeling Language (“ECIML”), to be defined as a result of the project, would be a concrete instance of the OMG’s MOF meta-meta-model, at the same time re-using as many concepts from standard UML as possible. This puts it in the following relationship to the standard modeling approaches:

[pic]

Figure 1 Relationship between the ECIML and other modeling standards.

We will build on the experiences of the projects like pUML (The Precise UML Group), using also the OMG’s standards (e.g. CWM, standard UML 1.4 profiles, UML Profile for EAI and UML Profile for EDOC) when appropriate, in order to define a suitable meta-model.

One could use the standard UML for modeling these concepts, but we feel that in its current form it’s too generic and lacks necessary precision, and though it’s extensible, the way the extensions are specified is often implicit (e.g. stereotyping). In the ECIML meta-model they would be precisely defined. Some of these issues will be addressed in the next major revision of UML standard (2.0), at which point we will evaluate the possibility to use that standard as the sole basis for ECIML.

Consequently, one of the goals of this project will be to define a suitable set of modeling constructs to more adequately address the needs of meta-framework modeling and transformations.

The methodology

The proposed methodology for analysis and modeling of the transformations between the e-commerce frameworks follows the layered classification approach.

This approach means that in order to analyze the problem domain one has to split it into layers of abstraction, applying top-down technique to classify the entities and their mutual relationships:

• First, to identify the top-level entities and the contexts in which they occur.

• Then, to proceed to the next layer in which the interactions between the entities are analyzed.

• Then, to go to the lowest, the most detailed level to analyze the messages and data elements in communication between the entities.

Starting from the top-most level, the contexts in which the interactions occur are analyzed and collected, and these contexts affect the semantics of the interactions occurring at the lower layers.

The second dimension of the proposed approach conforms to the Meta-Model Architectures, as described in the MOF standard, introducing the meta-model, model and data layers.

The example classification layers are presented in the following picture, where the vertical dimension is the methodology abstraction layers, and the horizontal dimension is the model abstraction layers:

[pic]

Figure 2 ECIMF methodology and the meta-model architecture.

In order to navigate through the framework models and concepts, a prototype tool named Conzilla is introduced, which in later stages will be augmented with other modules (like data format translating software, automatic generation of interfacing state machines, routing and packaging translators, etc).

The project will define a recommended methodology (named E-Commerce Integration Modeling Methodology – “ECIMM”) and base tools needed to prepare specific comparisons of concrete frameworks, which in the end should result in clear implementation guidelines for system integrators and software vendors on how to ensure interoperability and semantic alignment. This generic integration meta-framework will be expressed in the ECIML language, providing mapping and transformation descriptions/recipes that can be implemented by an ECIML-compliant agents/intermediaries. This ultimately should allow the frameworks to interoperate without extensive manual alignment by the framework experts.

[pic]Figure 3 The ECIMF concept of frameworks transformation and alignment.

The meta-framework definitions/recipes for interoperability are named “MANIFEST”. The language to be used in these definitions will be called E-Commerce Integration Modeling Language (“ECIML”), and will be based on XML representation of UML-like meta-models, rules and definitions.

The following diagram describes how the ECIMF approach is used in order to align the two different frameworks:

[pic]

Figure 4 The process of modeling and alignment between two e-commerce frameworks.

MANIFEST recipes

A MANIFEST recipe described with ECIML will be identified by a unique ID, and stored in the repository from which an ECIML-compliant agent can retrieve it. The agent, based on the transformations specified in the MANIFEST recipe, will create necessary processing structures to align the message handling and interactions between the agents belonging to different frameworks. It is expected that the repository will be able to also store commonly used templates for inter-framework alignment, so that less experienced or knowledgeable users can leverage the accumulated expertise of framework experts, and by making relatively minor adjustments re-use the templates as their own MANIFEST recipes.

The specifics of the repository need to be further discussed. Initially we suggest possibility of using either ebXML or UDDI to store the MANIFEST recipes.

It is yet to be defined what kind of language will be used to describe the transformations between the models. The following is a short list of the requirements that need to be satisfied:

• Preferably Open Source implementations available

• Highly portable

• Well-known: this is needed in order to ease the adoption

• Strongly typed: the transformations need to be precisely defined, and it’s preferred that most logical errors would be discovered during the parsing/compilation, not at the runtime.

• High level (additional tools for manipulation of complex programmatic structures, database and directory access, etc…)

The candidates that we consider at this stage are Java, XSLT and Python.

The Toolkit

The intention of the E-Commerce Integration Toolkit (“ECIT”) is to offer a simplified and affordable solution to conform to the existing and upcoming standards without the burden of having to know all the complex technologies behind them.

We will aim to provide a simple implementation of the ECIT and make it available on an Open Source basis. However, in order to fully leverage the ECIMF approach, we expect the software vendors to follow our initiative and provide complete implementations as proprietary products – still, compatible with the open standard.

[pic]Figure 5 Example of ECIT (ECIML-compliant agent) facilitating message exchange.

Example

This example presents step by step how a meta-framework recipe for interoperability could be prepared, between hypothetical e-commerce frameworks Framework1 and Framework2.

Note: the diagrams have been prepared using a generally available UML modeling tool. Some of the concepts could not be presented appropriately (e.g. lack of notation constructs, or wrong constraints applied).

First, a formal model of both frameworks needs to be built based on the available models, natural language descriptions and domain expert knowledge of the frameworks. This model is built using the ECIMF approach. The scope of the model depends on the scope of the integration task at hand, i.e. it doesn’t necessarily have to be a complete model. However, the modeling and the analysis follow the structured, layered approach:

[pic]

Figure 6 Modeling the frameworks

Then, using the ECIMF Navigator or a similar tool, the framework experts calibrate and align the concepts common to both frameworks.

|[pic] |[pic] |

Figure 7 The top-most layers of the Framework1 and Framework2 models.

Let’s look closer at this example. The figure 8 presents the Semantics elements of both frameworks in a more detailed fashion. We notice several similarities here. They are marked in the following pictures using the same colors and stereotypes for the corresponding concepts:

|[pic] |[pic] |

Figure 8 Comparing the corresponding semantic elements.

This is an important step that will affect many other modeling decisions during later stages. The ability to find the corresponding concepts is the basic premise for any successful attempt at interoperability.

When using the ECIMF Navigator tool, we could imagine this step to look like the following figure:

[pic]

Figure 9 The ECIMF Navigator compares the semantic elements of the frameworks.

Then the modeling process proceeds to the next layer, where the framework integrator concentrates on the specific business scenarios that need to be integrated.

So, in the first step the framework integrator prepares a formal model of activities for e.g. Order Management business process for the Framework1. This is presented in the Figure 10. We use here the standard UML Activity Diagram notation, as it has been found to be flexible enough (see Annex 2 for comparative study of the notations).

[pic]

Figure 10 Framework1 business process of OrderManagement.

Then, using similar approach, the system integrator models the corresponding OrderManagement process in the Framework2 that leads to the same business consequences as the one in Framework1.

As the following picture shows, that process is different from the corresponding process in Framework1. The result is presented in Figure 11.

[pic]

Figure 11 Framework2 business process of OrderManagement.

As the last step on this level of modeling, he proceeds to preparing the model of interactions for the ECIML-compliant agent (mediator). The mediating agent will play the role of Responding Party to the Requesting Party in the Framework 1, and the role of Requesting Party to the Responding Party in the Framework 2.

Note: at this stage, we concern ourselves only with binary collaborations. It is possible to present multi-party collaborations as series of binary collaborations.

In addition to that, the mediating process will use the information elements from the messages, as well as information available from the external resources, in order to fill in the values in the necessary data elements.

Figure 12 The process specification for ECIMF mediator.

Since preparing a complete meta-model might prove to be a very complex task, he concentrates on specific business scenarios that are required to interoperate.

The framework experts and integrators may use several strategies to approach this task (top-down analysis, best practices, already existing recipes, heuristics), gradually narrowing down the gap between the two frameworks. Finally, they end up with a sufficient (parameterized) meta-model of meaningful interactions between the two frameworks for the given business scenarios.

This model provides an abstract recipe for interoperability between Framework1 and Framework2 (within the given scope). The model can then be processed by an independently implemented ManifestFactory tool that will prepare a machine-readable abstract definition (F1F2Manifest), expressed in the ECIML, defining how to construct the adaptation implementation.

So, the whole process can be summarized by the diagram presented in Figure 13.

[pic]

Figure 13 ECIMF Navigator aligns all layers of the frameworks.

In the next step, as previously presented in Figure 5, the ECIML-compliant agent receives the F1F2Manifest and instantiates the necessary adapters. This may involve setting up processing pipelines for messages, creating state machines to keep track of complex interactions, creating translation maps for message elements, reading parameters provided by the communicating parties, etc. This reference environment for execution of the MANIFEST recipe can be provided as a commercial product.

Finally, at this stage it is possible for the parties to successfully establish business interaction, even though they use different e-commerce frameworks to express their activities.

22 Conzilla – the prototype tool for navigating the standards manifold.

Conzilla is the name of a software tool that has been developed during the past 3 years by the Interactive Learning Environments (ILE) group at the Centre for user-oriented IT-design (CID) at the Royal Institute of Technology (KTH) in Stockholm, Sweden (). Conzilla is the first prototype of a concept browser, which is a new type of tool for the exploration and presentation of electronically stored information that has been invented by Ambjörn Naeve, a mathematician and researcher within the ILE group at CID. In contrast to most hyperlinked information systems, like e.g. the ordinary web (www), a concept browser supports a clear separation between context and content, and lets you navigate the different contexts (of a so called knowledge manifold), and view the content of a given concept within a clearly defined and displayed context. For a more detailed discussion of the ideas behind conceptual browsing see the report by Naeve: Conceptual Navigation and Multiple Scale Narration in a Knowledge Manifold, which is available in PDF format at .

The basic design principles for concept browsers can be expressed as follows:

• separate context from content.

• describe each context in terms of a concept map.

• assign an appropriate number of components as the content of a concept

and/or a conceptual relationship.

• label the components with a standardized data description (meta-data) scheme.

• filter the components through different aspects.

• transform a content component which is a map into a context

by contextualizing it.

When desiging concept maps it is important to use a conceptual modeling language that adheres to international standards. At CID, we make use of UML, which has emerged during the past 5 years as “the Esperanto of conceptual modeling”. As for meta-data we make use of the IMS-IEEE proposed standard for learning objects ().

Conzilla is being developed as an open source project. See for more information about the Conzilla project.

The ECIMF project will use Conzilla as a prototype tool for browsing and comparing different e-commerce framework models. One of the goals of the ECIMF project will be to extend this tool by necessary backend(s) producing abstract machine-readable interoperability guides (MANIFEST recipes), expressed in ECIML language.

Annex 2 – Comparison of the modeling notations for Business Process and EAI modeling

Note: this annex, due to its size, is provided as a separate Word document.

-----------------------

[i] The ebXML project, .

[ii] The e-Speak framework, Hewlett-Packard, both as a commercial product , and an OpenSource free Java implementation of the complete framework at .

[iii] The BizTalk framework, Microsoft, , BizTalk repository at , and commercial product BizTalk Server , which additionally contains the mapping and orchestration tools.

[iv] The eCo Framework, CommerceOne, .

[v] RosettaNet, .

-----------------------

[pic]

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download