Distributed client/server architectures nowadays appear as a must for the .... mark-up tags) that define the various components of a WEB dedicated document.
Integration of CORBA and WEB technologies in the VEGA DIS Alain Zarli, Philippe Debras Centre Scientifique et Technique du Bâtiment 290, route des Lucioles B.P. 209, 06904 Sophia Antipolis cedex, France Abstract. Distributed client/server architectures nowadays appear as a must for the wide information systems of the future virtual enterprise. At the same time, the continued growth of the Internet/WEB and its associated standard developments leads to new ways of world-wide information communication, distribution 1 and access to information. This paper introduces to the various developments undertaken in the VEGA 2 project for a tighter integration of STEP, CORBA and WEB technologies within a DIS . Thus, the VEGA platform will allow both the support of distributed heterogeneous and interoperable client/server information systems (through CORBA) and the support of WEB based access to information and services through an Internet based navigation, building upon CGI and Java technologies.
1. Context and problematical issues The Large Scale Engineering (LSE) and Manufacturing universe is nowadays facing an increasing competitive environment where flexibility and adaptability to change are the bound paths to success, leading companies to renew their way of working. This is due to economical and technological drivers. Indeed, industrial enterprises are now devoted to the specification, design and construction of still larger and more complex manufacturing products: it has become no more possible to a single even-wide enterprise to take in charge the realisation of the whole products, both for financial reasons and because the required skills are not all within the enterprise. Thus, companies and SMEs (Small and Medium Enterprises) are now on the way of constituting virtual enterprises (VEs) for each new project. In a VE, contractors, partners, suppliers and customers form a temporary aggregation of non co-located actors dealing with the same product, but focusing on their core domain of competence for the shared profitability of industrial projects. At the same time, current progress in IT3, providing more reliable and relevant mechanisms and software tools, the development of sophisticated new frameworks in client/server applications, and the continued growth of the Internet enable improved business processes and provide organisations with new business opportunities. Companies are now widely deploying their applications in Internet and Intranet4 environments, assembling advanced IT based architectures encompassing among others networking, distributed information systems and concurrent engineering. In such a context, the VEGA project is developing a mandatory infrastructure for the support of the LSE business processes, particularly on the base of main standards for information modelling and exchange, with STEP (ISO 10303) or the IFC developed by the IAI5, distribution and interoperability mechanisms with the OMG6 CORBA and IIOP de facto standards, and WEB technology based on HTTP7/CGI8 and Java. VEGA intends to cover the general needs of companies in VEs and Intranets, with a focus on the Building & Construction sector. Its main objective is to provide an information management architecture to guaranty interoperability among various software components running on different platforms, targeting STEP distributed technologies as an approach to bridge the gap between multiple and delocalised software systems in the construction industry. Within VEGA, the development of the DIS is a first approach towards an end-user oriented service for access to information through various forms. In the AEC field, large projects require the involvement of many body entities (client, architect, design engineers, various technical engineers, etc.) sitting at various locations, with different views and needs on the project, and managing different forms of documents like textual documents, structured documents, drawings, and so on.
Dealing with all these kinds of information representations on the client side lead to consider, as far as possible, standardised front-end services. Access to information can be related to EDI9 too. Until now, EDI has always been considered as a technology typically based on EDIFACT syntax and rules. But EDI can be considered as a kind of generic term, including all aspects of technical and commercial information exchange without mandatory requirements with respect to specific communication technology. Indeed, EDI can be considered from two different points of view: • the first one is a rather conceptual one: the EDI is a structured electronic exchange of data of any type between computer applications of parties involved in a transaction ; • the second is an operational one, where we consider means to realise the task as announced in the first point of view. With respect to these operational means, the Internet is nowadays more and more acknowledged as the common medium to support communication facilities within the development of client/server applications that deserve the larger audience. The WEB technology builds upon HTTP to provide the users with high-level graphical applications independent of the underlying client platform. Furthermore, the Java language now simplifies the development of WEB applications through the power and flexibility of a real object-oriented language. The Intranet perspective enfavours the use of WEB technologies on LANs10 on a company scale, whether it be real or virtual. Therefore, a different approach has been applied in the VEGA DIS, considering EDI in the broad sense and consequently managing EDI messages through distributed networked infrastructures, emerging WEB standards (mainly HTML and VRML formats), and WEB technologies like CGI and Java.
2. Integration of new technologies in the VEGA project 2.1 Overview of the VEGA project As previously mentioned, the VEGA11 project objective is to develop an IT platform enabling companies in a VE to work together. VEGA leans on available technology, and extend their capabilities as needed for engineering collaboration in a flexible distributed environment. To address the problem of information sharing, VEGA deals with 3 different technologies: • product-data modelling for the specification of meaningful project information; • middleware technology for the distribution of project information; • 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 above, including STEP and particularly 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 WfMC12 for design of process control, and information standards like SGML13 or various WEB de facto standards for the support of valueadded 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 (the COAST – COrba Access to STEP models [2]), for remote data access and manipulation of information models defined by explicit meta-models (or schemata) satisfying the STEP EXPRESS semantics.
2.2 STEP and the IAI If different software applications need 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. Such issues have led to dramatic research efforts to achieve effective product data exchanges, standardisation of methodologies, languages and technologies, especially in the context of PDT14, among them:
•
•
STEP15 ([3], [4]), developed in ISO TC184/SC416 for the product data representation and exchange. It allows the expression in a uniform and complete way of all the information required for a product life-cycle (especially through the EXPRESS language [5]), and supplies means for exchanging data physical files [6] and sharing product databases [7] with models and applications independent mechanisms. STEP is today deeply used for real world product information modelling, communication and interpretation. IFC17 [8], another major effort currently undertaken by a non-profit alliance (IAI) of the building industry including architects and engineers, building clients, software vendors, and so on. The main IAI objective is to specify the IFC as a universal model 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.
STEP and IAI share the same goals, i.e. application interoperability; data exchange and actor cooperation, but differ in their respective processes. The IAI promote a bottom-up approach, with an iterative and incremental development for fast implementation. STEP is a long-term project, with a top-down approach and is concerned with broad standardisation. The IAI, having a formal liaison status with STEP has partially adopted the STEP technology, mainly through an EXPRESS representation of the IFC. In the future, an integration of the IFC within STEP is planned. As an initiative driven by leading companies, the IAI is pushing the IFC as a de facto standard in the Building industry in a very near future. A key point of the VEGA infrastructure is to use PDT and especially EXPRESS to describe and store meaningful product information. Implementing the VEGA vision requires a tight coupling between STEP models and all the various components of the VEGA platform (including distribution layer, workflow, data storage). Eventually, the current IFC 1.5 release will be used in the final VEGA demonstration18.
2.3 The CORBA standard CORBA19 ([9], [10], [11]) is an OMG specification for application interoperability and portability in distributed architectures, allowing objects described in any language to be shared across heterogeneous operating systems and platforms in a network environment. Two main features of CORBA are the common neutral language IDL20 to specify the object boundaries and its contractual interfaces with potential clients, thus separating interface from implementation, and the ORB21, the middleware in charge of establishing the client-server relationships between objects and seamlessly interconnecting multiple object systems. CORBA implementations are on the way to offer secure transactional capability, but also high availability and load-balancing features associated with traditional transaction monitors, and the need to integrate CORBA architectures and services into a cohesive enterprise-wide solution is today more and more apparent. Behind CORBA, IIOP22 is the central standard messaging protocol implementing the OMG GIOP23 specification over TCP/IP, for improved communication mechanisms between application objects. It allows communication between any CORBA 2.0 compliant ORBs, and is also the underlying protocol for the future release of RMI24. Thus, IIOP is rising as a fundamental protocol for Internet/Intranet based developments.
2.4 The WEB and JAVA The WEB is an information framework running over the Internet, and a set of widespread WEB languages and technologies25 (e.g. HTML, Java, JavaScript, etc.) are used to make all kinds of information accessible via the Internet, some of special interest for VEGA and the DIS: • HTML26 is a simple mark-up language used to create hypertext documents portable from one platform to another, and providing a collection of platform-independent styles (indicated by mark-up tags) that define the various components of a WEB dedicated document. HTML documents are ASCII files which can be linked together by hyperlinks, and can contain hyperlinks to images, sounds and movies. HTML relies on HTTP, the WEB protocol for navigating between document with hyperlinks and dedicated for wide-scale Internet network27.
•
VRML28 is a modelling language to specify interactive 3D objects and worlds. A VRML-file is an ASCII-file with definitions of all kinds of 3D VRML objects, which together make up a virtual world of scenes. Scenes can be linked by hyperlinks, similar to those in HTML documents, for the inclusion of a scene into another one. VRML is designed to be used on the Internet, intranets, and local client systems, as a universal interchange format for integrated 3D graphics and multimedia, as it is capable of representing static and animated 3D and multimedia objects with hyperlinks to other media such as text, sounds, movies, and images.
A last standard is Java [12]. Hampered by the diversity of desktop systems until now, companies discover the power of enterprise-wide computer solutions with Java technology. Java is initially a development language (of Sun Microsystems), interpretable and portable (Java virtual machine), and designed to be adaptable to evolving environments. Its architecture-neutral property makes it a good candidate language to meet the challenges of dynamically distributing extensible software across networks. It also offers capabilities for providing static HTML WEB pages with dynamic behaviour and interactivity (Java code can be downloaded into any WEB browser). Java is: • Object-oriented, allowing the inheritance and reuse of code both in a static and dynamic fashion. Java has the look and feel of C++. • Platform independent, as the language is interpreted: this means that every computer can run it if it has a Java interpreter to convert the Java code into some native machine code. • Robust, as Java gets rid of traditional problems programmers face with creating sound code. The language and runtime environment features make sure that the code is consistent. This comes primarily as a result of portability efforts, and the need for improved applications that won’t bring down a system when a user stumbles across a home page with a small animation. • Secure, as the necessities of distributed computing demand the highest levels of security for client operating systems. Java provides security through several features of the Java-runtime environment: a bytecode verifier, run-time memory layout, file access restrictions. Java was initially used to create applets, which are small Java programs that can be included in an HTML page, much like an image can be. When using a Java-compatible browser to view a page that contains a Java applet, the applet's code is transferred to the client system and executed by the browser. This feature allows to develop significant complex interfaces on the client site, but only offers the ability to download complete applications, and not to communicate with other applications (and even less with other objects) or establish any kind of network connection. This is why numerous works have been done in the meantime to transform Java as a platform for the deployment of distributed applications, with large object classes libraries along with APIs, interfaces to existing technologies (databases, middleware, etc.) and a full execution environment. The Java platform incorporates predefined libraries, including RMI that allows Java code to call a Java method on a remote application, using internal JRMP29 and serialisation for Java-to-Java communications across virtual machines. Thus, RMI is similar to CORBA in the way it makes a distributed Java program look like a local program on the client application, and can be considered as a possible alternative to CORBA, but only for distributed full fledged Java applications. Eventually, directly related to Java have appeared the JavaBeans, forming a portable component model written in Java, developed in collaboration with industry leaders. It enables developers to write reusable graphical components, benefiting from the platform-independent power of Java. JavaBeans act as a bridge between proprietary component models and provide a seamless and powerful means for developers to build components that run in ActiveX container applications.
3. The VEGA DIS 3.1 Complementary of CORBA and WEB technologies VEGA proposes a global infrastructure with new needs for integration, where CORBA is the federative component, but which have to integrate other fundamental provisions for information systems like the WEB. The backbone of the VEGA platform is the COAST, a CORBA based
integration platform to give transparent access to remote data specified by EXPRESS schemata, CORBA ORB and services being the key components for objects interoperability and concurrent engineering. Around this COAST core, several services are provided, including loading and management of EXPRESS schemata and STEP data, automatic and transparent configuration and management of the COAST, schema interoperability service and workflow management system. As part of the VEGA project, the objective of the Distributed Information Service (DIS – [13]) is to enlarge the support and distribution of information from product data to marked up documentation, electronic messages and information in the large, by means of STEP based technologies and especially the COAST. Further on, such an infrastructure appears to be a sound candidate for the implementation of future distributed standardised electronic document and information management system, gaining from an homogeneous integration of information related to the elaboration of products including engineering product data, documents, administrative and financial material, electronic messages, etc. But client/server architectures and remote information access technologies are nowadays strongly influenced and impacted by the WEB infrastructure and standards. As presented herein above, the WEB offers standards and technologies for open global networks like the Internet, to be potentially useful in Intranet contexts as well. Besides interactivity, cross-network and platform, and dynamic properties, the WEB leads to common interface for the end users, and this is a fundamental key point: it suggests a unique universal client through the support of WEB interfaces by any platforms and the use of WEB browsers. This new approach for relationships between clients and information servers through system-neutral interfaces and technologies and fully open infrastructures, introduces a radical evolution in client/server applications within the enterprise and offers a set of services which complement basic distributed architecture. As an objective of the DIS is to access distributed information through COAST middleware and to present this information at end user desktops level, the DIS can also be considered as a service integrating the WEB (end user presentation layer) and CORBA technology (communication layer). This is why the DIS relies both on CORBA (COAST) and WEB technologies and standards assessing its Internet and Intranet interests, leading to an open system for access to enterprise data according to two adapted ways: • internal access, needing most of the time performance, and dealing in the more specific context of VEGA with STEP-based documents accessible through the COAST ; • external access, so as to be able to deal with any kind of multimedia documents and to indifferently answer to any external request.
3.2 The DIS WEB-oriented objective The DIS can be viewed as a bunch of services for document generation and access in the large, i.e. internal enterprise documents, structured using SGML30 for instance, as well as external WEB documents, provided that these documents are compliant with de facto or de jure document standards like SGML, HTML, VRML, and visualised through WEB browsers or plug-ins. Two kinds of interactions between client applications and the DIS can be envisaged (see figure 1): either the client belongs to an Intranet or a VE, or is a component of an Extranet or the Internet, consequently accessing information through potential protection mechanisms (firewalls). This infrastructure relies both on the COAST backbone and the WEB network. As any other COAST compliant services and intranet applications, the DIS has to be plugged to the COAST, thus partially relying on a language binding (COAST API - [14]) for its application runtime system. Nevertheless, the DIS has not to be considered at the same level as other integrated services developed in VEGA, i.e. COAST integration system [2], distributed workflow service [15] or distributed persistent service. These services are designated to be fundamental services to any global distributed information system and application. The DIS is supposed to be an additional generic common service for Internet and Intranet information management, to be coupled with the COAST.
Client 2 (INTERNET)
WEB browser
Client 1 (INTRANET) Internet
HTTP server (DIS) Distributed Information Service
COAST Client Run-time System
2 1
COAST (Corba Access to STEP models) (WMS) Workflow Management Service
(SIS) Schema Interoperability Service
COAST compliant Database server
figure 1: Intranet and Internet access to the DIS.
In the case of an Intranet (figure 1: interaction 1), the request from a client application to the DIS is managed via the COAST integration system and on the base of the COAST API. The COAST ensures the seamless and transparent access to DIS services for such a client application directly connected to the COAST. The COAST API is a reduced set of functions allowing dynamic (onthe-fly) requests and transactions at level of the middleware. There are two outcomes in such an interaction: • DIS services are supposed to be based on some EXPRESS schemata known by the COAST integration system, the data instances are accessed within the DIS database through COAST functional calls, following similar interactions as for distributed engineering data. • In that case, the result as sent by the DIS through the COAST has then to be converted/translated in such a way that is useful for the client application (this conversion/translation has to be done a priori on the client side), except in the case of COAST compliant application native data on the client side In the situation where an information request is coming from an external site (“Internet mode”, figure 1: interaction 2), the request is directly sent to the DIS through a WEB server (HTTP daemon) linked with the DIS. In that case, the connection of the DIS to the COAST is used to have access to distributed information within the internal information system of the virtual enterprise. Results of the request is then sent back to the client application under HTML, VRML or any WEB oriented format. This scenario is able to deal with any kind of multimedia documents and to indifferently answer to any external request. Two different developments have been done in the context of the DIS, one based on CGI mechanisms, and the other using Java based technology: • management of WEB documents with HTML and CGI ; • management of STEP geometric information through VRML conversion and a Java server. These developments are currently under experimentation in the framework of the final VEGA demonstration, leading to illustrative cases in the AEC sector. They are now detailed herein after.
4. Generation of HTML reports for compliance checking The specification of a DIS dealing with EDI messages exchanged at conception and design phases of an LSE project first rely on trying to identify the communication types and various interactions between the numerous project designers. In B&C, a project for building design makes interact various participants and business people like architects, engineers (acoustics, structures, heat, etc.), contractor and sub-contractors, and so on: in actual practice, the communication mode and so the building design steps are fundamentally asynchronous. Most of the time, they all work at the same
time on different parts of the building or even different topics, and get a need then at a given point in time to synchronise themselves. Through most of its supporting technologies, the WEB seems to be an interesting solution and a good candidate for asynchronous tasks. Ways of communication based on the WEB and HTTP technology are mainly corresponding to communication protocols in design processes. On the other hand, information to be exchanged over communication networks is of disparate nature: text, graphics, charts, maps, multimedia database objects, all objects the WEB can deal with. Moreover, a major advantage of relying on the WEB is that the supporting tools for interpretation, editing or browsing already exist. Eventually, the use of CGI scripts allow to associate to the WEB server more complex procedures: CGI programs may interface to database servers (accessing them through database front-ends), taking inputs from a WEB server (corresponding to the client request) and realising some action, like putting the content of a form into an e-mail message, turning the data into a database query, creating an HTML document, and so on. The tackled issue is the generation of HTML reports related to queries from end-users in the specific application field of the compliance checking of legal dispositions (regulations) for accessibility of Public Buildings by disabled people. The approach relies on a digital mock-up supporting the automated verification of the compliance of any building design against regulations31. We don’t detail here the targeted end-user application, nor the main steps of the global process of compliance checking: for more information, the reader should refer to [16]. This application has initially been developed on top of a classical STEP platform (SDAI/C++ late binding), then ported on top of the COAST platform. The main components of the architecture are described in figure 2, integrating the client application itself, technically based on CGI as it is quite well suited for such an operation32, the COAST backbone, the workflow management system, and another integrated application (based on EDM33, a pure STEP database) in order to simulate a real VE, especially through workflow mechanisms allowing to deal with requisite security. Client Desktop
Workflow management (PRM) 2
1
WEB Browser
6
Wf_application server HTTP daemon
5
CAD/CAM tool Wf_application server
8 HTML stream
3
EDM application
CGI Bin
SPF file (STEP Part 21)
Rules code
COAST client binding COAST API functional calls
COAST client binding 7
IFC 1.5 EXPRESS schema
4
COAST middleware
COAST Metadata Repository
IFC 1.5 models Objectivity DB
figure 2: Integration of the COAST with a code compliance checking client application.
The major steps establishing the VE for that specific application are as follows (failures and raised exceptions are not mentioned for simplification purpose): 0. As a preliminary procedure, the EDM application loads some building design through its STEP representation (here, an ISO Part 21 SPF) as provided by a CAD tool, the information extracted from the CAD tool corresponding to the IFC 1.5 model (EXPRESS schema).
1. The WEB browser asks the WEB server for some HTML data through a special HTML page. This page is formatted so that when the user submits the query, it calls the WEB server with some parameters to pass to the CGI-Bin program. 2. The server executes the CGI-Bin program with these parameters corresponding to the client choice. It is first required that the current IFC set of instances be loaded into the COAST server (Objectivity): thus, the client application asks for such an operation to the workflow management system (PRM), through a Workflow application (Wf_application) server, which is a software wrapper allowing the connection of the application to PRM. 3. The PRM system transfers the order coming from the client application to EDM. 4. EDM fills the Objectivity database COAST server with the appropriate IFC set of instances. 5. EDM notifies the PRM system that the expected operation has been successful. 6. The PRM system informs the client application of the EDM notification, so that the CGI then can launch the executable code on the server side for the checking process. 7. Checking is done through the execution of an inference engine interpreting the various rules as specified for accessibility regulations and making calls to the COAST when required. The CGI program gets the results, and generates a document compliant with some WEB standard: in that case, the results are translated into an HTML stream in order to show the results to the client under a textual form (but a translation to a VRML stream could also have been possible, for example, for a 3D visualisation of the results under a VRML WEB plug-in). 8. The server gets back the HTML stream from the CGI-Bin client and forwards it to the WEB browser, which accepts the incoming stream and visualises the HTML report on the client desktop. CGI offers language independence, process isolation and architecture neutrality: complementary to a WEB server, a CGI program allows the connection to an application server. But CGI also presents some deep limitations, especially regarding the lack of context management (stateless), its low adaptation to full concurrent distributed architecture, and low performance too. Java provides enhanced features with respect to CGI, particularly when dealing with more flexibility at level of the client/server middleware, as demonstrated in the next section.
5. Java-based VRML conversion of STEP geometric information The initial innovation of Java is the applet concept, offering mobility of executable code to the client side, portability (through the Java Virtual Machine) and easy deployment while at the same time satisfying security issues as a Java applet cannot access files and resources on the client. But dealing with a simple applet only fulfils some interface-oriented requirement as it is only download code on the client side, leading to fat clients. A first progress can be done with an RMIbased applet, but this is confined to full-fledged Java frameworks. A major additional feature can be considered if the applet is empowered by CORBA, as shown in figure 3: in such a situation, the applet is still downloaded from the WEB server (sometimes with an ORBlet, i.e. the ORB client runtime environment, if it is not already on the client site), but can be then managed as a CORBA client, invoking CORBA server objects and accessing services through the network without having to explicitly download these services in turn. These kinds of applets are adapted to heterogeneous distributed environments, no matter objects on application servers are implemented using Java or not, and consequently can be considered as real communicating CORBA/IIOP mobile agents. But even CORBA-enabled, the main issue of Java applets is that they are running on client desktops, which means that some of the treatments have to be executed on the client side, mainly executing the client-side logic and not really promoting the future 3-Tier client/server architectures. Moreover, they need a virtual machine to be installed on the client desktop to run. This is why another investigation has been done in the VEGA DIS, based on the servlet concept, introducing a new set of API for Java on the server side.
Client Desktop
Java-enabled WEB Browser
HTTP call (through applet tag)
WEB Server
Download of applet &stubs (+ ORB if required)
CORBA/ORB CORBA compliant applet
CORBA/IIOP request to CORBA server
DB server
DB server DBMS
DB server
DBMS
DBMS
figure 3: CORBA-adapted Java applet in heterogeneous environments.
Java servlets (also mentioned as “server-side” applets) first are programs directly running on the WEB server, but not only. Indeed, they improve CGI technology as they can run similarly to CGI programs, answering HTTP requests and accessing databases, but they are able to maintain a state between user visits and may run independently of a WEB server, taking requests from other servlets and programs directly over the network, using all the Java technology. Thus they allow the creation of Java-based interactive applications on the server side, leading to more enterpriseoriented application solutions. A possible interesting use of a servlet is the following: consider a user application needing some intermediate translation (or even semantic conversion34 first and then translation) when accessing to a particular set of enterprise data, this specific conversion and/or translation operation typically can be done on the server side by the servlet, between the data storage layer and the user application, avoiding the execution of this task on the client desktop. The application presented hereinafter concerns a 3D representation of STEP-AP225 based geometric information through VRML conversion, using any VRML plug-ins for WEB browsers. It involves the STEP AP225 [17], a STEP application protocol. AP225 specifies the information required for the exchange of building element shape, property and spatial configuration information between application systems with explicit shape representations. Building elements are physical components such as structural elements, service elements, fixtures and equipment, and spaces. These elements are geometrically defined, and therefore are very close to any geometrical description language, like VRML for example. The conversion from an AP225 model to a VRML one relies on few simplifications of the AP225 model. Since AP225 models contain very complex geometrical description of building elements, each element having many properties and sub-elements, the focus has been established on the few real entities that are suitable for conversion; i.e. structure enclosure elements, fixture elements, service elements and spaces (they all inherit from the building element entity). Another focus has been set on a small part of all the possible geometrical definitions in AP225. AP225 has every kind of geometrical definition one can think of, from curve based models to faceted b-reps. The choice has been to use only the later definition for the conversion because only faceted b-reps models were available to convert. The conversion mechanisms remain the same, except the need for an extra conversion from the geometrical definition to a faceted b-rep definition since VRML only handles very simple geometrical shape like facets, cubes, spheres, cylinders or cones. The main components of the client/server architecture are exhibited on figure 4.
Client Desktop
Client Desktop
WEB Browser (+ VRML plug-in)
WEB Browser (+ VRML plug-in)
VRML stream
WEB Server (HTTP daemon + Servlet Runner)
AP225->VRML conversion + VRML generation
(Java) Servlet
COAST API functional calls
RMI (IIOP) JNI
COAST middleware AP225 EXPRESS schema
AP225 models
COAST Metadata Repository
STEP Database
figure 4: AP225/VRML transformation based on Java servlet and the COAST.
The following main comments can be done on such an infrastructure: • The models as considered in this case rely on the AP225 EXPRESS schema, and the native VRML model. An AP225 to VRML conversion is required followed by some VRML stream generation (translation step): these tasks are undertaken by the Java servlet. • The client does not need to be Java dependent (i.e. there is not need for a virtual machine on the client desktop), on the other side the WEB client must be VRML-enabled. • The Java servlet indeed has to be CORBA-empowered through the use of the COAST API and the adequate runtime system binding it to the COAST middleware (COAST Java binding). Nevertheless, another intermediate-level middleware technology could have been envisaged for accessing internal enterprise information, like for instance the use of RMI in a full Java environment, or the use of JNI35 to wrap the COAST API implemented in C language. The aim of this example is to demonstrate the use of AP225 data to extract 3D information using the VRML 2.0 specification in order to make them visible within a VRML browser, through Java technology connected to CORBA middleware. Thus, automated information retrieval from STEP databases is possible, on the basis of WEB and CORBA based technical information interchange.
6. Conclusion The WEB offers means of dissemination and access to world-wide (most of the time unstructured) information sources, and macroscopic communication services like e-mail, news, hypertext navigation, but poor co-operation, co-ordination and control (transactions, workflow, management, etc.) services for enterprise information systems and applications. However, new technologies are extending the WEB capability towards more interactivity (client side) and flexibility (server side), especially with developments around Java. At the same time, as more and more (virtual) companies deal with multiple platforms and languages in their information systems, CORBA promotes an open software bus (the ORB) for various software components on different operating systems to work altogether, along with a set of high level services. One of the languages of choice for developing CORBA objects is nowadays Java. The recent choice of IIOP as a communication protocol for RMI and future Java components confirms this interrelationship between Java and CORBA, so that any Java component will be able to access any CORBA application.
We promote in the DIS the joint application of CORBA/COAST as developed in VEGA and WEB technologies, first using CGI, then Java based mechanisms. Main advantages of the approach are: • an extension of the WEB features through access to CORBA-like services, • an integration dealing with generic WEB server gateway (and not only specific when using IDL stubs), relying on the COAST API, the COAST object meta-model, and possible dynamic requests on the fly thanks to the COAST implementation. The implementation works of COAST and DIS are still currently on-going, their integration must lead to a prototype version being part of the future final VEGA demonstration. An initial set of benchmarking is also planned for the end of 1998, trying to identify the most critical areas for such benchmarks regarding CORBA and the WEB, and as far as possible focused on an end-user point of view. These benchmarks must conduct to more precise results and allow in the future deeper recommendations about the integration of all these new technologies. But it is already clear that the combination of technologies like the WEB and CORBA must bring efficient solutions for robust and scalable computing infrastructure to support the new business dynamics of tomorrow, including external (Internet) and internal (Intranets) business application integration and the future electronic commerce, thus leading to the tremendous promises of the information highways. Acknowledgement: the authors want to thank all the VEGA partners, and especially Michel Böhms from TNO, together with Manfred Köthe and Karsten Schulz from DEC, for their valuable help, not without forgetting their CSTB colleagues Jean-Luc Monceyron, Fadi Sandakly and Patrice Poyet.
7. References [1]
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.
[2]
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.
[3]
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.
[4]
J. Fowler. STEP for Data Management, Exchange and Sharing. Technology Appraisals 1995.
[5]
Industrial automation systems and integration - Product data representation and exchange Part 11. Description methods: the EXPRESS language reference manual. 1994.
[6]
Industrial automation systems and integration - Product data representation and exchange Part 21. Implementation methods: Clear text encoding of the exchange structure. 1994.
[7]
Industrial automation systems and integration - Product data representation and exchange Part 22. Standard Data Access Interface. 1995.
[8]
International Alliance of Interoperability, URL http://iaiweb.lbl.gov/
[9]
The Common Object Request Broker Architecture and Specification (CORBA) Revision 2.0. July 95. URL http://www.omg.org.
[10]
Robert Orfali, Dan Harkey and Jeri Edward - The Essential Distributed Objects Survival Guide, John Wiley and Sons Editor.
[11]
J. Siegel & Al. - CORBA Fundamentals and Programming, John Wiley and Sons, April 96.
[12]
Java, SUN – Javasoft, URL http://java.sun.com.
[13]
P. Debras, A. Zarli, V. Amar, P. Poyet - The Distributed Information Service in the VEGA project, Proceedings of the CIB W78 Workshop’97 – IT Support for Construction Process Re-engineering, July 9-11 1997, Cairns (Australia), p. 123-137.
[14]
M. Koethe, K. Schultz, A. Bernotat, V. Amar, A. Zarli – COAST Architecture: the CORBA Access to STEP Information Storage Architecture and Specification, EP 20408 VEGA Deliverable D301, Rev. 1.8.7, February 1998.
[15]
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. [16]
A. Zarli, P. Debras, J.L. Monceyron, W. Bakkeren, M. Böhms – Supporting Tools for the Distributed Information Service, EP 20408 VEGA Deliverable D402, January 1998
[17]
ISO 10303 TC184/SC4 - Industrial automation systems and integration - Product data representation and exchange Part 225. Application Protocol 225: Building elements using explicit shape representation, ISO Draft International Standard, 12 July 1996.
1
EP 20408 VEGA: Virtual Enterprises using Groupware tools and distributed Architectures. Internet site: http://cic.cstb.fr/ILC/ecprojec/vega/home.htm. 2 Distributed Information Service (VEGA WorkPackage 4). 3 Information Technologies. 4 An Intranet is an internal network accessible to employees, and based on WEB technologies. Intranets allow to share internal documents, get access to legacy data, and simplify the exchange of information amongst employees. They can be connected to the Internet through protection mechanisms known as firewalls. 5 International Alliance for Interoperability, a leading industry driven initiative in the AEC (Architecture, Engineering and Construction) sector. 6 Object Management Group. 7 HyperText Transfer Protocol. 8 Common Gateway Interface. 9 Electronic Data Interchange. 10 Local Area Network. 11 For more background information about VEGA, the reader should refer to [1]. 12 Workflow Management Coalition. 13 Standard Generalised Mark-up Language (ISO 8879). 14 Product Data Technology. 15 STandard for the Exchange of Product data. 16 Industrial data and global manufacturing programming languages. 17 Industry Foundation Classes. 18 The final VEGA demonstration has to display the application of VEGA outputs in a shadow simulation of a real construction engineering project, showing end users’ ability to work concurrently in a distributed VE. 19 Common Object Request Broker Architecture. 20 Interface Definition Language. 21 Object Request Broker. 22 Internet Inter-ORB Protocol. 23 General Inter-ORB Protocol. 24 Remote Method Invocation, the communication protocol for distributed Java applications. 25 The developments of those new de facto emerging standards like HTML, dynamic HTML, VRML, XML, etc., are guided by the World Wide Web Consortium (W3C). 26 HyperText Mark-up Language. 27 In that sense, HTTP reveals of lower level than IIOP, which allows communication between any kind of objects, and not only WEB documents. 28 Virtual Reality Modelling Language. 29 Java Remote Method Protocol. 30 Considering that SGML documents can be regarded as typical product data specifications, the VEGA DIS also deals with the management of SGML documents through the modelling of a generic structure for any SGML documents and their storage in a STEP database, and access through the COAST in the specific context of VEGA. This specific development is not tackled in this paper. 31 Compliance of the building design is checked against French accessibility regulations. 32 Nevertheless, the checking is globally realised in one process: implementation choices must be different if one wants to have control of the launching order of the various checking rules, for instance by a workflow controller. 33 EXPRESS Data Manager. 34 A translation is a simple format conversion between two applications (supposed to rely on a same semantic model), whilst conversion is related to some semantic mapping between two different models. 35 Java Native Interface.
