An open flexible distributed architecture for the Large ... - CiteSeerX

Published in the Proceedings of the Product Data Technology Days 1998 (PDT Days ’98), 25-27 March 1998, Garston, UK.

An open flexible distributed architecture for the Large Scale Engineering Alain Zarli, Olivier Richaud, Virginie Amar Centre Scientifique et Technique du Bâtiment 290, route des Lucioles B.P. 209, 06904 Sophia Antipolis cedex, France [email protected], [email protected], [email protected]

Abstract New information and advanced computer technologies today provide relevant powerful and reliable tools for PDM, enhancing companies business processes. Nevertheless, their deployment in Inter/Intranet environments becomes increasingly complex. This paper investigates the major ones of these technologies together with their possible inter-working, and suggests an open and scalable 3-Tier architecture, including advanced concepts like business objects and generalised plug-ins. These studies 1 2 are undertaken in the context of the ESPRIT projects VEGA and WONDA .

1 Introduction and context 3

IT have become critical for companies competitiveness, and advanced computer oriented methodology 4 and technology nowadays provide reliable and relevant mechanisms and tools for PDM . Indeed, current evolutions in computing technology enable improved business processes and provide organisations new business opportunities. Nevertheless, IT imply an increasingly complexity in software architecture, development and use. Meeting the enterprises needs (faster time-to-deployment, higher quality, flexible applications fulfilling the business needs) mandates to exploit emerging technologies such as common product data representations, object-oriented component based development, distribution in conjunction with Inter/Intranet, thus following new approaches of integration of these technologies in a businessoriented and fast reactive enterprise framework. At the same time, it is no more conceivable that a unique integrated (monolithic) system or application be able to deal with all the aspects or issues of PDM in the large, and responds to all the needs of companies or Virtual Enterprise (VE) business. In a similar way, the vision of some unified global data banks which could be uniformly accessed by any type of applications seems no more realistic, as the needs of companies, the so various views applications can have on data, and the widespread existing store data and diversity of software are too large to get a consensus. Thus, the time is now for policies based on open and adaptable generic infrastructures for communication, able to mask the complexity of operations common to any kind of development like for instance data exchange or inter-operation between systems, and where dedicated components and applications would be seamlessly plugged to such an infrastructure so as to work together. This appears to be the only way towards flexible solutions for the enterprises exigencies, moreover on line with the current trends and evolution of computer based technology, and especially the WEB, with its universal infrastructure and 5 standards, and other world-wide developments as promulgated by industrial consortia like the OMG . This paper aims at making a synthesis of new software technologies and at proposing a computer-based open, scalable and customised architecture for the support of the Large Scale Engineering business processes. These technologies are related to currently developed standards, and are mainly: •

1

Information modelling and exchange, with the STEP (ISO 10303) standard, or the IFC model 6 developed by the IAI , the leading industry driven initiative in the Building Construction sector.

EP 20.408 VEGA: Virtual Enterprises using Groupware tools and distributed Architectures. EP 25.741 WONDA: WOrld wide eNterprise DAta interoperability. 3 Information Technologies. 4 Product Data Management. 5 Object Management Group. 6 International Alliance for Interoperability. 2

•

Information storage with relational SQL/ODBC and object-oriented OQL/ODMG’93 compliant DBMS, and SDAI for STEP database.

•

Distribution and interoperability mechanisms with CORBA/IIOP de facto standard, its challenging Microsoft proprietary solution with Windows DNA/DCOM/ActiveX, and the JAVA/RMI alternative.

•

WEB technology based on http, including CGI.

•

Code mobility with JAVA and JavaBeans for components exchange.

The proposed architecture is based on an open and flexible 3-Tier approach, and includes advanced concepts like business objects and rules encapsulation, together with a generalised notion of plug-in. Such an infrastructure based on existing or emerging software technologies will deliver in a very near future a new and challenging generation of tools and information infrastructures, further supporting the true deployment of PDT and concurrent engineering within the forthcoming VE business processes.

2 Advanced technologies for PDM Data modelling & exchange If different software applications want to communicate and inter-operate, they first need to share the same information, without misunderstanding or loss of semantics. This implies a common way to represent and exchange the semantics of data. Such issues have lead to dramatic research efforts to achieve effective product data exchanges, standardisation of methodologies, languages and technologies, especially in the context of Product Data Technology (PDT). •

STEP: STEP ([Björ95], [Fowl95]) is formally ISO 10303 , and includes a number of full International Standards (IS) like the EXPRESS language [ISO94a] for information modelling, the STEP Physical File (SPF [ISO94b]) providing neutral format for data exchange, and the SDAI [ISO95] specifying a computer independent API (Application Program Interface) to share product databases.

•

IFC: Besides STEP, another major effort is currently undertaken with the IAI, a non-profit alliance of 8 the building industry. The IAI objective is to integrate the AEC/FM industry by specifying the IFC (Industry Foundation Classes: [IAI97]) as a universal language to be a basis for collaborative work in the building industry and consequently to improve communication, productivity, delivery time, cost, and quality throughout the design, construction, operation and maintenance life cycle of buildings.

7

Software technologies and architectures The current evolution of hardware and software technologies, the development of sophisticated new architectures and frameworks in object-oriented client/server applications, and the explosion of the Internet and the WEB, are changing the approach application design and usage and enabling new business processes. Emerging new technologies such as object-orientation, component based development, distribution and the Inter/Intranet following have to be combined in the specification of a business-oriented and fast reactive enterprise framework. •

CORBA (OMG) and IIOP 9

CORBA ([OMG95], [OHE96], [Sieg96]) is an OMG specification in the field of client/server and distributed architectures based on object-oriented technology. Its main objective is application interoperability and portability, allowing objects described in any language to be shared across different operating systems and platforms, in a heterogeneous network environment. Two of the key features of CORBA are:

7

•

The Interface Definition Language (IDL) is a common neutral language to specify the object boundaries and its contractual interfaces with potential clients, and is used by CORBA to separate interface from implementation. IDL specifications have to be mapped (IDL binding) to programming languages, currently C, C++, Smalltalk, Java, Ada95.

•

The Object Request Broker (ORB) is the middleware that establishes the client-server relationships between objects and seamlessly interconnects multiple object systems. The ORB manages the client requests and invokes operations on servers.

Product Data Representation and Exchange. Architecture Engineering Construction / Facilities Management. 9 Common Object Request Broker Architecture. 8

CORBA also defines a common collection of system-level distributed middleware object services (Naming, Transaction, etc.), complementing the ORB functionality. They are packaged as components with IDL-specified interfaces and allow to elaborate components without any concern for middleware services, then mixing these components with any combination of the CORBA services through the IDL specifications. The need to integrate CORBA and service technologies into a cohesive enterprise-wide solution is now more and more manifest, particularly considering solutions for transactional capability, but also high availability and load-balancing features associated with traditional transaction monitors. 10

11

IIOP is a standard message format, which is the implementation of GIOP over TCP/IP. It reveals to be of higher level than HTTP from improved communication mechanisms between application objects (while http is for navigating between document with hyperlinks, and dedicated for wide-scale Internet network). •

JAVA/RMI & JAVA code mobility (SUN/JavaSoft)

With the Java platform [Java97], Sun/JavaSoft provides enterprise-wide computer solutions for Intranets and 3-Tier bases infrastructure. The main features of Java platform are the following: Java as a development language : Java is first a true object oriented language, with a syntax close to C++ and an auto garbage collector, interpreted and portable (Java Virtual Machine), designed to be secure and adaptable to evolving environments. The architecture-neutral and portable aspects of the Java language make it a quite good candidate for distributing applications over the internet on various platforms. Java as a platform for the deployment of distributed applications, with large object classes libraries along with APIs, interfaces to existing technologies (databases, middleware layers, etc.) and a full execution environment. The Java platform includes a lot of predefined libraries. Another important feature is RMI (Remote Method Invocation) allowing some Java code to call a Java method on a remote server or 12 application, using internal JRMP and serialisation for Java-to-Java communications across virtual machines. Thus, RMI enables to transparently distribute full fledged Java applications. •

Windows DNA/DCOM/ActiveX (Microsoft)

Besides standards as those promulgated by the OMG and efforts of SUN/Javasoft for promoting Java and RMI (note that convergence of RMI towards CORBA is on the way), Microsoft is developing more proprietary solutions in the field of distributed architectures. Solutions as offered by Microsoft have similar characteristics than other distributed architectures, but don’t provide true platform independence. 13

Windows DNA is a unified approach for building distributed, scalable, multi-tier applications that can be delivered over any network. Windows DNA is the first application architecture to integrate the Internet, client/server, and PC models of computing for a new class of distributed computing solutions. 14

OLE is a set of libraries and applications for compound documents, including storage, data exchange and integration of elements within documents. DCOM - the Distributed Component Object Model - is a technology that enables software components to communicate directly with each other across networks, including the Internet and intranets. The model allows to get benefits from a component-based approach across a broader scale of multi-user applications in a distributed component architecture. Active X is an extension of OLE for the specific context of the WEB and the Internet. It is the Microsoft infrastructure for compound documents, communication between clients and servers of distributed objects, and the integration of objects within WEB pages for Internet and Intranet applications.

3 A Three Tier IT architecture for the enterprise information system Trends in software architectures are evolving towards the new concept of 3-Tier architecture, identifying, as depicted in Figure 1, three main separated parts/components (instead of 2 in previous client/server architectures) within a networked enterprise computer infrastructure. Such an architecture reveals to be 10

Internet Inter-ORB Protocol. General Inter-ORB Protocol. Java Remote Method Protocol. 13 Distributed interNet applications Architecture. 14 Object Linking and Embedding, originally specified for integration of data from Microsoft tools. 11 12

the better answer for Intranets and VEs, also opened to the Internet. It must be viewed as an information broker for producing both Intranet and Internet solutions aiming at dynamic content management and services delivery. It must be based upon object oriented technology, and must offer access control to information, legacy system interfaces for data acquisition, tailored delivery to each user and dynamic content generation. Eventually, the framework itself may be scaleable (e.g. with full load balancing features, and the ability to manage system configuration) and customisable in the sense it allows custom built applications to be created which are as far as possible tailored to exact customer requirements.

Business Object Model

Intranet/WEB

(Business Logic)

Database (Persistent Data storage) ...

...

...

HTTP server

Internet/WEB

Middleware Figure 1: a 3-Tier architecture for the enterprise business. For each main component (tier) of this infrastructure, the following comments can be made: •

Information servers (DBMS) level: this is the data storage and server level. Access to basic data within DBMS can be realised through gateways (native gateway for direct connection to legacy systems, co-operative gateway using the network interface of the accessed database, or procedural gateways for access to the database through inside procedures or TP monitors), or through a middleware layer in a distributed environment (CORBA/ORB, DCOM, etc.).

•

Middleware/central tier level: it contains the embedded business logic, with one (or several) business objects model(s). From a client point of view, this business model expresses the business domain (without technology consideration), and provide the end-user with some unified view on data hiding the underlying data sources. From the architecture viewpoint, it implements the business rules and processes. Customer-oriented views on that business model can also be managed here, whatever it may be filtering views or views associated with model conversion/transformation.

•

Client applications level: this level is mainly concerned with GUI . WEB de facto standards (HTML, etc.) offer standardised interfaces to the client, this dealing with Intranet as well as Extranet/Internet 16 users. Depending on the fact that client computers are simple PC or NC computer, or on the other side powerful workstations, specific treatments can be localised on the client side.

15

A flexible and evolving architecture must integrate models and rules so as to control treatments on engineering knowledge, both at level of managing and massaging the information and at offering various views and interfaces to client applications and end-users. These models and rules, forming a computerised form of a business model, cannot be managed on the client side, in order not to produce fat clients and generate hard difficulties in clients and applications administration. They preferably have no more to be managed by the DBMS, as this could lead to additional load of the server, thus largely decreasing performance. Moreover, it is not the task of a DBMS to deal with client interfaces and ergonomics issues. This role is indeed devoted to a central tier component, acting as a specific applications server for fundamental services encapsulating objects and views with their procedures and rules in business objects as a modelling of the business enterprise. The central tier has to manage generic services as information search, object or server identification, etc. at level of the distribution layer, while at the same time dealing with complex operations on the business model such as object mappings or links, views filtering, fine-grained security issues, and so on. Eventually, global rules (not related to business objects, but rather to their inter-working in the context of 15 16

Graphical User Interface. Network Centric.

the full enterprise model) can be handled at that level too, like rules defining actions when a given program execution has failed, actions to undertake in some specific context defined through global variables, workflow considerations, etc., together with client interface rules mainly based on Web standards and technology. Such a component can be physically divided on several servers (in that case, one talk about n-tier architecture) so as to make load balancing between servers. It has to work in close contact with the architecture middleware, relying both on a clear isolation of a lot of enterprise control and management issues from all the applications, and on agile solutions for high interoperability between heterogeneous applications and optimised performance in terms of functionality and time.

4 Technologies for 3-tier architecture components This clear separation between the three major parts of the global information system for the VE, augmented with a specific fourth one linking them (the middleware), allow to choose adequate technologies for each part. The challenge for the designer/developer is determining which combination is appropriate for his or her application needs. End-user component and extended plug-in concept The end user is primarily and mainly concerned with information presentation and user interface. On this side, the emergence of the WEB has deeply transformed the client desktop. The WEB standards technologies now provide what can be called a universal interface, with generic protocols and formats. The end user can use the WEB browser of his choice (Netscape navigator, Microsoft IE) and visualise a large set of information under various formats (Text, 3D, images, etc.), taking benefits of standards like 17 18 HTML, VRML , XML , etc. Other interest of the integration with the WEB is taking benefit of current pure WEB oriented technology developed, like for instance the push paradigm driven by data suppliers. Besides the fundamental aspect of data visualisation, another issues are related to operations and transformations of data on the client side, through more dedicated software tools like for instance CAD/CAM tools, and the use of specific components as available in knowledge software libraries for use within and between enterprise, dealing with existing product knowledge and advanced knowledge paradigms. This implies client-side persistency, under the form of specific medium to store the information (databases associated to the tools) on the client site, and if required means to convert and/or transform the server objects into the client objects. A possible solution to these last concerns can be found in the concept of “ extended plug-in” . A plug-in is defined as a small piece of dedicated software, dealing with specific kinds of (information) format and/or specific functionality. Thus, it can add several new features to a larger software through communication with this software, and extensions of programs are then naturally possible in a dynamic way using as many plug-ins as required, without the necessity of integrating all the features into a single huge program. This concept of plug-in can be implemented according to various technologies, depending on the fact that 19 the extended tools are WEB tools (WEB plug-in ) or specialised tools (Intranet plug-in). In a general WEB context, a plug-in can be considered as a piece of code loaded into a WEB browser dedicated to a specific task. For example, a STEP plug-in might be able to read SPF files, thus leading to “ STEP 20 powered” browser. Plug-ins may be delivered within DLL according to a specific API in order to directly interact with the WEB browser. As this solution is tightly coupled to the WEB browser, Java applets tend to offer a more scalable solution by enabling easy deployment using Java code mobility. Moreover, Java applets encompass security by denying access to local files and remote connections to untrusted servers. Concurrently, Microsoft proposes ActiveX as its WEB solutions while not fully addressing security issues. Middleware The basic requirements for distributed computing services are to distribute application processes across multiple machines, networks, operating systems, and data formats, to locate those processes, and to communicate among them, and this is the main role of a middleware. It operates between the application logic and the underlying physical network, and encompasses a wide range of services including 17

Virtual Reality Modelling Language. eXtensible Markup Language. 19 A WEB plug-in is a software extension dedicated to a specific WEB browser and specialised in the management of a given type of document, most of the time identified by its format: mpeg, vrml, etc. The actual main issue is that current plug-ins are developed for a given browser, and thus the end-user becomes fully dependant of this browser and its plug-ins. 20 Dynamic Linking Library. 18

messaging communications (marshalling and unmarshalling, queuing, etc.), database access, distributed transaction processing through transactional support. Other services are also required, such as remote object integration and access to often incompatible data sources, maintaining security of the data, etc. In order to accomplish these tasks, the WEB infrastructure and technologies, so adequate to deal with a lot of issues on a “ universe client” site, reveals not powerful enough, since it corresponds to a quite classical client/server architecture, moreover dealing only with static electronic documents and not distributed 21 22 objects. The current CGI paradigm, even with extensions like cookies or dedicated APIs (ISAPI , 23 NSAPI ), is no more effective to achieve middleware tasks. CORBA/IIOP appears to be the adequate solution for process integration and interoperable networked heterogeneous applications, able to deal with the complex requirements of VEs. CORBA is a very complete distributed object platform. In this context, the ORB plays a major role, making effective the cooperation between applications and taking in charge messages management in a quite transparent way from the end user point of view. New architectures based both on CORBA and IIOP should be able to integrate existing information systems without disturbing the way they initially run, and with no need to redesign any portion of the application itself. The Java based RMI mechanism is on the way to be implemented on top of CORBA/IIOP, which proves that Java technology needs to be complemented with a full distributed object infrastructure like CORBA. This means that the proprietary ORB on which RMI is 24 currently built will be abandoned, and the new JDK 1.2 will integrate a CORBA ORB and support JavaIDL, a development environment for generating CORBA stubs and skeletons from IDL. Middle Tier One of the components of today emerging architectures is a “ business-centred” middle tier. As previously told, this part of the global enterprise information system has in charge to model and implement products (with their behaviours), services, rules and constraints characterising the business domain, and aiming at a representation of this information directly understandable by the end users and usable in the conduct of the business. One of the current main efforts currently done in this area is the concept of “ Business Objects” (BOs) as specified within the OMG. A deeper presentation of BOs is offered in section 5 of this paper, so let’s only give a general definition of this concept, inspired of the description of an OMG BO: BOs are representations of the nature and behaviour of real-world things or concepts in terms that are meaningful to the business. Thus, they constitute a key factor to ensure that engineering data as contained in large databases or libraries and accessed through components can be available to the end users in such a way they can use them directly and “ naturally” . In terms of implementation, the concept of BO has to be correlated to the one of software component, and a BO can be viewed as an end-user oriented evolution of a component. In a 3-Tier architecture, the connection of BOs to large databases is done through a plug and play to the middleware, with conversion mechanisms from raw data as contained in databases to BOs: these converters can be wrappers or adapters, except if re-engineering methods and tools are used for the transformation of legacy systems in order to make them directly compatible with middleware and BOs. While CORBA has been clearly identified as the best candidate for middleware technology, Active X and JavaBeans are software component based architectures, and provide a powerful framework for building complex multi-tiered distributed application and for incorporating complex business rules into Intranets and Extranets, thus implementing BOs. Short presentations of Active X and especially JavaBeans are exhibited in section 5. However, one can notice, from now on, that Java (and consequently JavaBeans) gets a lot of interesting opportunities with respect to BOs. As a mobile object system, Java allows CORBA objects to run on every kind of machines, and to distribute code in large CORBA systems, through the “ bytecode” paradigm. Thus, Java reveals to be an appropriate language and system for objects on the client side, but also for Java-based middle tier that conforms to CORBA and IIOP with BOs (CORBA objects implementing a set of component services) packaged as Enterprise JavaBeans encapsulating the business logic. Sometimes, a last advantage of a Java-based middle tier implementation is that CORBA 25 objects can access the data storage level (third tier) directly through JDBC . Databases third tier 21

Common Gateway Interface. (Microsoft) Internet Services API. Netscape Server API. 24 Java Development Kit. 25 Java DataBase Connectivity, an ODBC (Object DataBase Connectivity) binding for Java developed by Sun. 22 23

The third and final tier is related to what is accessible by the CORBA middleware, i.e. implementation of objects in RDBMS or OODBMS, related to data persistency. This can be done either through hand-made dedicated adapters for DBMS, or using procedural TP monitors associated to the DBMS, or even through components encapsulating the third-tier functions. In each case, the major issues to address is the discrepancy between the (CORBA based) middle-tier BOs model and the internal database model, and the specific problem of how to deal will all the legacy information. With respect to the third case (higher level components encapsulating the DBMS functions), and provided these components are Java based, an immediate mean to connect is through JDBC interfaces. From a functional point of view, Java applications in this context can naturally access databases, the only remaining issue being the constraint for the developer to manipulate two types of data models (OO and relational), thus having to bridge them. However, new developments of higher level in the ODMG standard are underway, promoting modelindependent solutions for connecting OODBMS as well as RDBMS. Eventually, Figure 2 gives and overview of the various technologies presented herein above, and their potential relationships with the various components of a global enterprise information system. Firewall

Firewall HTTP, HTML

CGI API (NSAPI, ISAPI) Java applets &servlets JavaBeans

Internet WEB client (Netscape browser, etc.)

DB server WAN

WEB server

DBMS

LAN NC Client

Intranet/Middleware (communication through synchronous/asynchronous messages, transactional behaviour, etc.)

CORBA, IIOP Java, C/C++ JavaBeans OLE/DCOM Active X

PC Client Legend WAN : Wide Aera Network LAN : Local Aera Network DBMS :DataBase Management System

DBMS

Applications server

Rules server (Business model)

Figure 2: technologies for support of a 3-Tier architecture.

5 Business Objects in future distributed information systems The concept of BO is fundamental in 3-Tier architectures and specifically in the middle tier, it has in charge to gap the bridge between enterprise data available in database and end-user application through services implementing the real logic related to a specific business domain. In such a context, the OMG intends to promote a standard framework for business applications residing on top of CORBA through the specification of the OMG Business Object Architecture. This section firstly introduces the concept of BO as specified by the OMG followed by a short overview of the OMG Business Object Architecture and finally, presents the Enterprise JavaBeans defined by Sun Microsystems. The Business Object concept A BO is a concrete representation of an active thing in a specific real business domain and is uniquely identified by its name in the business domain. Based on an underlying object technology, a BO is characterised by a set of attributes allowing to catch transient or persistent data, relationships, operations and constraints [Casa97] which are not only integrity constraints, but also triggered business rules. Conceptually, BOs add value over other representation because they give a higher level view and package the main concepts of the business model they represent. BOs are expected to facilitate communication, design and modelling between implementers and business domain experts because they can share the same concepts, they model the real world so that people focus on main characteristics and relationships among BOs. BOs must support distribution to be easily integrated in client/server architectures. They promote the 3-tier architecture and are key components to bind end-user interfaces to

enterprise data. The implementation of BOs must rely on well-defined interfaces and use extensively late binding in order to be implemented separately. As the enterprise business evolves, BOs must play several roles to meet the enterprise needs. As a consequence, a BO must not only be highly scalable, but also easily ready to ship. The hope is that BOs would facilitate the creation of a reusable component market. The OMG Business Object Architecture 26

In response to a RFP issued by the OMG for Common Business Objects and Business Object Facility 27 [OMG96], the Combined Business Object Facility Proposal [CBFO97] introduced a general architecture for providing a coherent solution for BOs. Elements that are part of this solution are: •

The Business Object Architecture (BOA), which is the underlying layer which would enable BOs. It integrates a meta-model which describes constructs and types as well.

•

The Component Description Language (CDL), dedicated to writing down BOs in a textual form. CDL helps to standardise BOs, thus providing a unambiguous way of specifying properties, behaviours, business rules and so on.

•

The mapping from CDL to IDL, encompassing the necessity of interoperability. A given specification using CDL would produce IDL interfaces which would take into account the various specified BOs and the underlying framework.

As consequence, BOs expressed through CDL are CORBA objects and then must be network accessible 28 through an ORB: this implies that the BOA is built firmly upon the OMA . In order to represent an entity or a process in a specific business domain, a BO may have: •

Attributes to provide information about the associated data elements of the BO. Existence of attributes depends on the BO that refers to.

•

Operations to manipulate and operate on BOs. The set of operations supported by a BO refers to its behaviour as commonly accepted in object oriented programming.

•

Events for the externalisation of state changes when operations are invoked on BOs. An event model is intended to avoid tight coupling while integrating several BOs in a specific system. By doing so, changes are easier to manage.

•

Business rules so as to focus on the semantics of the component in a specific domain. An appliance rule is plugged into a container on which the rule applies. The BO’s behaviour is partly defined by this sort of sub-component. The BOA specification specifies some rules as for instance, invariant appliances define rules that must always hold for the component.

•

States to symbolise the mutually exclusive conditions a component may be in. Moreover some states may be reached only when pre-defined conditions yield.

•

Relationships in order to connect two types, helping to make components interact and avoiding them to be isolated islands of knowledge. They allow bi-directional traversal between instances of different types. Moreover, they permit loose coupling of co-operative distributed components and a way to easy assembly components originated from different vendors. Several kinds of relations may be supported by BOA implementations, because each type of relationships covers some specific semantics.

Enterprise JavaBeans: a model of Business Objects One implemented model of BOs is the Enterprise JavaBeans (EJB), currently specified by Sun Microsystems in order to provide a component architecture for development and deployment of distributed enterprise-wide objects and also to support an architecture for distributed transaction-oriented computing. This model aims at offering scalable, transactional and reusable components. Any Java enabled platform may run these components, provided that they use a corresponding EJB component enabler. An EJB developer will define a remote interface which will gather all the business methods callable by a client while the business logic will be implemented in the corresponding EJB component. In order to manage the creation and deletion of those components, one or more factories must be implemented. The EJB model addresses the development of BOs, but integrates their deployment and customisation 26

Request For Proposal. This submission is still in the early stage of development and may change rapidly in order to follow the trend. 28 (OMG) Object Management Architecture. 27

too. EJB components may be assembled in order to build higher level EJB components, with possible EJB descriptors to set up the components according to enterprise requirements. Moreover, an EJB developer must supply the environment properties EJB components need at runtime. Whatever, defining properties is not enough: an EJB component must supply a descriptor which helps to discover its meta-data which are useful in the deployment stage since EJB can be assembled using graphical development tools. Because EJB components aim at being widely distributed and highly reliable while being used by several end-users at a time, the support of distributed transactions is a major feature of EJB components. This allows an application developer to write a multi-tiered application that safely updates several databases in a single transaction unit. Nevertheless, an EJB developer or client must not deal with distributed transactions. This is up to the EJB server provider (typically, an ORB vendor or an OS vendor) to implement the burden of managing distributed transactions. An EJB server provider will deliver an implementation of an EJB server which supports at least the widely and acknowledged flat transactions 29 30 model . Transaction support may be addressed through the use of the JTS which is mapped on the Object Transaction Service standardised by the OMG. The JTS API, which is a lower level API, should be implemented in the core of each EJB server and higher interface should be provided. Eventually, it is worth noticing that in CORBA 3.0, due by the end of 1998, the OMG plans to incorporate the EJB model in order to deliver “ CORBA Beans” . For now, CORBA lacked the ease of use known in DCOM. This will both enable rapid development of CORBA objects and integration using graphical tools. Moreover, CORBA objects may be easily and seamlessly combined with Active X components.

6 Current and future works Several ESPRIT projects are focusing on the elaboration of fundamental parts of 3-Tier architectures as 31 exhibited in this paper. Among them, the EP 20.408 VEGA project ([Amar97], [Zarl97]) is to develop an IT platform enabling companies in a VE to work together. VEGA will use currently available technology, and extend their capabilities as needed for engineering collaboration in a flexible distributed environment. To address the problem of information sharing within the VE, VEGA will use 3 different technologies: •

product-data modelling for the specification of meaningful project information;

•

middleware technology for the distribution of project information; and

•

workflow management for the control of the flow of information and work in the VE.

The VEGA platform relies on high level open standards for the three technologies listed below, including STEP and especially EXPRESS for the neutral specification of product model data, CORBA for communication between distributed applications and distribution of objects over networks, workflow technology as defined by the Workflow Management Coalition (WfMC) for design of process control, and information standards like SGML or various WEB de facto standards for the support of value-added distributed information services (exchange of administrative messages, document handling, presentation of information). Thus, VEGA is currently elaborating the fundamental grounds for distributed architectures, defining a service layered on top of CORBA, for remote data access and manipulation of information models defined by explicit meta-models (or schemata) satisfying the STEP EXPRESS semantics. 32

On the other hand, the EP 25.741 WONDA project aims at extending the infrastructure and services of current world wide networks towards a wider industrial and commercial usage, for the deployment of the information and communication infrastructure in the industry, especially B&C and banking sectors. Its main objective is a better industrial exploitation of the large information sources located both on the WEB and in large enterprises databases accessible through the WEB. Thus, WONDA aims at turning the WEB into a viable infrastructure for industrial manufacturing, marketing and commerce, by specifying and developing a three-layers architecture based on a set of de jure or industrial standards: •

A federated database level in order to search and access information within various heterogeneous databases throughout a unified interface (OMG/ODMG’93, STEP/SDAI, etc.).

•

A WEB Mapper, which is a schema mapping layer enabling electronic knowledge bases to be seamless interconnected, and thus dealing with availability and interoperability issues. This mapper

29

Because the nested transactions model is an emerging and powerful model which is supported by an increasing amount of vendors, EJB may support this model in the future as well. 30 Java Transaction Service. 31 VEGA Internet site: http://cic.cstb.fr/ILC/ecprojec/vega/home.htm. 32 WONDA Internet site: http:/www.bild.ie/wonda (site under construction).

will ensure the liaison between the federated database level and any Internet/Intranet application in a model, language and application independent way. •

A third level defining “ plugs-in” for domain specific applications, for intuitive access to WEB information by end users using their usual applications, and based on product data and financial BOs to bind the client logic and presentation with the enterprise stored data.

A last specific WONDA development will be a security toolkit for data protection and confidentiality levels configuration, so that applications can be securely linked, thus enabling WONDA to be exploited for real industrial and commercial applications. Thus, WONDA will focus on a framework for business solutions and open and interchangeable tools, based on 3-Tier distributed architectures. The VEGA and WONDA projects aim at leading to complementary developments in order to provide adapted and complete solutions for the future VE information systems.

References [Amar97]

V. Amar, M. Koethe, K. Schultz, A. Zarli.- An open STEP-based distributed infrastructure : the COAST Platform, Proceedings of the 1st International Conference on Concurrent Engineering in Construction’97, July 3-4 1997, London, p. 227-240.

[Bakk97]

W. Bakkeren, M. Koethe, K. Schulz – Using Workflow Management to Control the Information Flow in Virtual Enterprises, Proceedings of the 1st International Conference on Concurrent Engineering in Construction’97, July 3-4 1997, London, p. 122-130.

[Björ95]

B.-C. Björk. Requirements and information structures for building product data models. Espoo : Technical Research Centre of Finland (VTT). 1995. VTT Publications N° 245.

[Casa97]

C. Casenave, Business-Object Architectures and Standards (white paper), 1997, URL http://www.dataaccess.com/Dat/BOPaper.htm

[CBFO97]

Combined Business Facility Object proposal, URL http://www.dataaccess.com/Dat/JBOF.htm

[Cole95]

D. Coleman, R. Khanna, Groupware: Technologies and Applications. 1995: Prentice Hall

[Fowl95]

J. Fowler. STEP for Data Management, Exchange and Sharing. Technology Appraisals 1995.

[IAI97]

International Alliance of Interoperability, URL http://iaiweb.lbl.gov/

[ISO94a]

Industrial automation systems and integration - Product data representation and exchange Part 11. Description methods: the EXPRESS language reference manual. 1994.

[ISO94b]

Industrial automation systems and integration - Product data representation and exchange Part 21. Implementation methods: Clear text encoding of the exchange structure. 1994.

[ISO95]

Industrial automation systems and integration - Product data representation and exchange Part 22. Standard Data Access Interface. 1995.

[OHE96]

Robert Orfali, Dan Harkey and Jeri Edward. The Essential Distributed Objects Survival Guide. John Wiley and Sons Editor.

[OMG95]

The Common Object Request Broker Architecture and Specification (CORBA) Revision 2.0. July 95. URL http://www.omg.org.

[OMG96]

RFP for Common Business Objects Specification, URL http://www.omg.org/pr96/bomrfp.htm

[OMG97]

OMG Business Application Architecture, white paper (OMG – Business Object Management Special Interest Group), URL http://www.tiac.net/users/jsuth/oopsla/bowp2.html

[Sieg96]

J. Siegel & Al. "CORBA Fundamentals and Programming," John Wiley and Sons, April 96.

[Java97]

Java, SUN – Javasoft, URL http://java.sun.com.

[Zarl97]

A. Zarli, et al. - Integrating emerging IT paradigms for the Virtual Enterprise: the VEGA platform, th Proceedings of the 4 International Conference on Concurrent Enterprising (ICE’97), Oct. 8-10 1997, Nottingham (UK), p. 347-359.