Workshop 3, Working Group 1:

I.L. Kotsiopoulos, Attiko Metro S.A., Greece, (Group Reporter)

C. Bremer, EESC, University of Sao Paolo, Brazil

J. Dorne, Renault S.A., France

K. Kosanke, CIMOSA Association, Germany

M. Zelm CIMOSA Association, Germany

Abstract. The subject of migration and subsequent integration of existing (heritage) applications has been overlooked by the enterprise integration community. The working group calls for the definition of an Application Integration Architecture, in the sense of a semantically uniform platform encompassing: models of services, migration constructs such as interfaces or wrappers, schema sharing (by services or by users) and model mapping facilities. Besides the basic features of this architecture, aspects of a stepwise method guiding its deployment are also considered.

Keywords. Enterprise Integration, Enterprise Architecture, Application Integration, Heritage Applications, Application Migration, Migration, Integrating Infrastructure, Services, Schema, Schema Architecture, Client-server, Wrappers, Application Sharing, Semantics, Enterprise Models, Presentation Schema, Schema Sharing, Standards.

Enterprises are characterised by their mission and by the means they employ to achieve it. The latter is a set of co-operating processes relying on effective information exchange between them. The degree to which this information is accurate (of the right content), timely (at the right time) and available (at the right place) for each process’s needs is a measure of the degree of integration of the enterprise and is directly proportional to the enterprise’s ability to perform its mission.

Not all forms of integration can be served equally well by such a measure, however. Indeed, the two lower levels of the AMICE categorisation of enterprise integration [3], namely physical and application would be adequately characterised, while the same cannot be said for the third (business level integration).

Despite this deficiency, this measure is still significant: business level integration cannot exist without application level integration and this, in turn, can rarely afford to ignore existing (inherited) applications with proprietary interfaces. It is in fact this reason, i.e. the difficulty of existing applications integration, that has prevented many enterprises from proceeding towards business integration.

Data processing in most enterprises today is made by software applications which are characterised by indispensability and heterogeneity. The former is due to the usually prohibitive financial and operational cost associated with rewriting an existing application and the latter to the multi-vendor environments and products coexisting within the enterprise. Both factors contribute to insufficient information transfer among those applications and, consequently, to a low degree of integration of the enterprise. It is therefore apparent that full scale integration of such heritage-bound enterprises is preconditioned by integration at the application level (application integration) and this, in turn, by migration of existing applications into the newly proposed integrated environments.

The working group identified that poor or no attention has been paid to these areas, resulting in an almost complete absence of any Application Integration Architecture able to lead to a migration path as a necessary step towards business integration. For example, access to information originating at a source application (server) and required at a sink application (client) is a frequently encountered need. In most cases, however, no public interface exists, meaning that information must be captured either through a device-specific interface, or not at all.

The problem becomes paramount when the business requirements point to the deployment of the concept of virtual enterprise, where the time constraints associated with the setting of such enterprises require fast and unambiguous inter-operation of various relevant models as well as applications.

Based on the problem identified above, the working group believe that satisfaction of the following objective would be a critical factor in any deployment strategy: "The definition of an Application Integration Architecture which is not only capable of accommodating new applications complying with its constructs but, most importantly, enables integration of existing (heritage) applications, its degree being determined by the availability of the right information, at the right place, at the right time, throughout all members of the architecture".

Identification of the characteristics of information to be exchanged among applications is a prerequisite for any migration effort aimed at application integration. This exchange can be of a rich semantic content, characterising data, objects or various other service requests and therefore can be modelled as formal specifications, scripts, service objects and other constructs used by various proposed integrating infrastructures, such as the CIMOSA IIS [2], [3].

We advocate that clearly defined semantics and models of services should be key features of an Application Integration Architecture. Existing heritage applications however, as opposed to those which are "integration platform ready", tend to use proprietary forms of services exchange, thus necessitating the use of application specific software (wrappers) to facilitate service exchange compatibility. Wrappers are presentation shells compatible to standard services of the integrating infrastructure and, as such, they should be an essential part of the proposed architecture.

Any effective architecture for wrapper creation should not only be as generic as possible, but should also aim to isolate the user from detailed knowledge of how the specific information is exchanged between content of wrapper and its outer shell. The term used by J. Fulton seems particularly appropriate: a semantic plug and play architecture, whose basic features, (see [5]), adapted for the purposes of a wrapper architecture would require the following:

• a semantic classification of
• the mechanisms for information exchange between applications, an initial type categorisation being:
• client-server
• linking
• procedural access
• declarative access
• the services requested and provided by the application under wraps, an initial type categorisation being:
• data services
• object services
• processing services
• knowledge services
• reference models of those services
• reference models of the infrastructure services
• a model integration facility to present those models to the enterprise model and to map semantically:
• the content of wrapper services to shell services
• the shell services to enterprise model services.

Note that the semantic mappings undertaken by the model integration facility refer to some predefined common schema (i.e. services required or provided), shared by all applications, to which the architecture of the enterprise has assigned the role of a general broker for service exchange monitoring. This can be either the conceptual schema (three schema architectures), or the internal schema (two schema architectures) or even the external schema (one schema architectures).

All semantic structures described so far must be considered as basic features of an Application Integration Architecture, which, in addition, should provide for a modelling repository. This should act as a superset-container of enterprise models, wrapper models and application models (for those applications which are integration platform ready). Finally, languages for modelling should be there to express architectural constructs, logic, syntax and inference rules within an industry-wide standard framework.

As stated before, a schema defines the services required or provided by an application and, if shared by all applications, can play a central role to model mapping and therefore application integration. It may be the case, however, that the concept of a commonly shared schema is not applicable to heritage applications, of otherwise immediate relevance to the enterprise mission, which, due to enhanced integration needs, may be required to support multiple sites and users. In other words, the information a heritage application is able to supply is now required more often (right time) and by more sites (right place).

The bad news is that, in many cases, sharing of the application’s services through a common schema encompassing multiple copies of the application may not be possible. The good news is that sharing through the user’s interface may be. We elaborate on this in what follows.

The benefits of integration are perceived by the user through some representation of business objects, called the presentation schema [5]. Presentation schemata are part of nearly all heritage applications of importance to enterprises and have the advantage that they can be directly mapped to a public interface towards the organisational and the human resource structure of the enterprise. In other words, what cannot participate in a common conceptual schema shared by services, can possibly participate in a common presentation schema shared by users.

In such cases, it is not the infrastructure services which first share the schema and then present it to the users (presentation schema), but the users themselves who directly share the presentation schema, while the infrastructure is unaware of it. This configuration, frequently called application sharing has recently emerged as a cheap alternative to common schema application integration in a wide variety of formats, ranging from simple hardware sharing to teleconferencing [10].

The sharing of both input and output devices is of interest to application integration. The shared component manages some input/output devices (monitor, keyboard, mouse), while being simultaneously seen by all session partners. Management is flexible; the mouse, for example, can be moved and seen by all participants, although a large communication bandwidth is required due to the number of hardware elements being shared.

Finally, teleconferencing, can boost cross-platform compatibility, helped by recent standardisation work [8].

A typical presentation schema shared through a teleconferencing system can comprise:

• a contact window, enabling the visualisation of the conference counterpart (audio and/or video conference component),
• two main windows presenting
• the common working object (a virtual blackboard) and
• the (shared) presentation schema (may include instances of shared data),
• an active conference control bar for managing the tele-cooperation environment (session),
• message and data transfer as optional parts of the system.

Sharing between users can be synchronous (simultaneous work of participants) or asynchronous (non simultaneous work outside the session).

Although the problem of IT application integration has been considered by most proposers of integrating infrastructure platforms, their efforts remained mostly at the level of specification and the side of the platform. There has been no attempt so far to consider the application-specific side by addressing issues such as categorisation of applications, types of information exchange required (see part 4 and 5), accessibility of information and others. In what follows, we list selected published material followed by specific comments on the foreseen relevance to our approach:

• CIMOSA Integrating Infrastructure (IIS, [2]), which defines a set of five service entities, namely Business, Presentation, Information, Common and System Management. Examples relevant to our goal would mainly be the Presentation services, whose specification includes wrappers for application integration. Other supporting services of relevance to consider in the CIMOSA IIS would include Information and Common services.
• CNMA [4] defines a platform supporting MMS-based environments, which would be of help in drawing a specification for application integration.
• EMEIS [1], a CEN effort on analysing current approaches in Integrating Infrastructures and defining requirements for Enterprise Model Enactment and Integration Services. Same degree of relevance to the CIMOSA IIS.
• MMS [7], an ISO standard defining communication contents and protocols for IT application in Manufacturing. Relevant topics could be the Virtual Manufacturing Device and its object definitions.
• OSI, the ISO standard defining a standard communication protocol for information interchange. Examples relevant for our work may be identified.
• STEP [7], an ISO standard defining the product data and their representation. STEP has defined application protocols (APIs) which may provide some additional insight on standardised information exchange.
• TCP/IP, the de facto communication protocol standard for information interchange. Examples relevant for our work may be identified.

Of the papers recently presented, we mention:

• the Semantic Plug and Play environment of J. Fulton [5], which we used in parts 4 and 5 to define the basic features of an Application Integration Architecture.
• G. Morel, [9], with a communication protocol defined for agents at shop floor level, features of which may be relevant to our work.

Although the condition of the state of the art today appears unclear, systematic and detailed exploitation is possible once all concepts and architectural constructs are seen under some common footing. Some preliminary attempt in this direction was made in part 4, under the "Semantic Plug and Play" framework [5]. The impact such efforts would have on our goal could be:

• more explicit definitions on information objects to be exchanged between applications,
• suitable categorisation of applications, and
• identification of both application dependent and independent functionalities needed at the wrapper level.

Finally, with regard to the EI Capability model presented at the report of Workshop 2 of this conference [6] we must add that heritage-bound enterprises may not be in a position to make the transition from level 1 (fragmented islands of automation) to level 2 (rigid integration) without a clearly defined migration path built on an Application Integration Architecture. The islands may simply be justifiably unwilling to give up their streamlined internal structure for the fear of not acquiring it again!

Although an Application Integration Architecture is essential to the migration process, a stepwise method for deployment is necessary. Issues such a method should address range from problem placement criteria (is the problem encountered an enterprise integration problem?) to actual guidelines for implementation.

The following is proposed as a skeleton contents list of a methodology for application integration.

• Identification and classification of problem:

1. Problem analysis: identify, analyse and describe problem, verify problem as relevant to enterprise integration (need of specific information at specific place and time).
1. Problem area definition: define problem domain and domain boundaries, identify related processes (employ enterprise models).

• Implementation of application integration:

1. Process analysis: identify expected information sources and information sinks (applications to be integrated and/or heritage applications to be migrated
1. Application analysis: identify application types (sources and sinks) and information types involved (prepare for integration type selection).
2. Integration economics evaluation: estimate cost/benefits for integration alternatives taking into account application complexity and duration of application, for example application wrapping (common shared schema) vs. application sharing (presentation schema sharing plus common schema).
3. Wrapper definition: identify application dependent functionality.
4. Presentation schema sharing (application sharing) definition: identify organisational implications and required changes for effective operational support of application sharing.

The table below summarises the main issues facing application integration today and the current state of the available methods to tackle them.

Application integration has not been given the consideration it deserves within the enterprise integration bibliography and practice, especially when heritage applications are concerned. In this paper, we presented the topics which appear to be the most prominent in the area, under a semantically uniform framework. Further work needed can be classified within the following context:

1. Research: define categories of applications for application integration and then create, apply, verify and disseminate application migration methodologies within the framework of enterprise integration.
1. Product development: identify services and tools to support application integration. Those services would have to be specified as regards both their application-independent part (common schema) as well as their application-dependent part (wrapper content).
1. Standardisation: identify possible emerging standards from areas 1 and 2 above and include those in a semantically uniform proposal for integrating infrastructures.

[1] CEN/TC 310/WG1, "CIM Systems Architecture. Enterprise Model Execution and Integration Services (EMEIS). Statement of Requirements". Report CR1832, Brussels 1995.

[2] CIMOSA Association, "CIMOSA, Open System Architecture for CIM, Technical Baseline, Version 3.2", Release 1996.

[3] ESPRIT Consortium AMICE (eds), "CIMOSA, Open System Architecture for CIM", 2^nd edition, Springer-Verlag 1993.

[4] ESPRIT Consortium CCE-CNMA (eds), "CCE: An Integration Platform for Distributed manufacturing Applications", Springer-Verlag 1991.

[5] Fulton J., "Semantic Plug and Play", Joint Workshop on Standards for the Use of Models that Define the Data and Processes of Information Systems, Seatle, USA, September 1996.

[6] Goranson T. et al, Working Group 2 Report, Workshop 2 on Enterprise Metrics and Strategic Standardisation Policy, this conference, NIST, April 1997.

[7] ISO/TC 184, "Manufacturer’s Message Specification (MMS)" and "Standard for Exchange of Product Data (STEP).

[8] Labriola D. "Standards, Standards Everywhere", PC Magazine Ziff Davis Inc., issue of 12^th May 1995.

[9] Morel G., "Contributions to the CMMS-IAMS Modelling Reference Framework", Workshop 3 on Enterprise Integration Applications, this conference, Brussels, June 1997.

[10] Ziegler C., Weiss G. "Multimedia Conferencing on Local Area Networks", Proceedings of the IEEE, pp. 52-61, 1990.