IB - An Information Bus: A Multilayered Information Base Interface for Remote Applications Bjf:lrn Skjellaug Dept. of Information Technology, Centre for Industrial Research (SI), P.O.Box. 124 Blindem, 0314 Oslo 3, Norway. email. addr: skjellaug@si.uninelL ( Abstract • A framework for an information bus (IE) is presented. The IE integrates information bases and remote application systems. Within the framework we present an outline of an integration methodology, which includes integration analysis and conceptual specification of an information base interface. The analysis highlights and structures the strategic and technical aspects of an integration. The aim of the conceptual step is to describe the infom1ation in a formal and abstract way. This specification formalism is based on object- oriented methodology (as objects and operations). An example of application of the IE is given. Keywords and phrases: Framework for an information bllS, integrulion methodology, integration analysis, objcct·oricntcd conccplllUl specification, interfaces, inforrmnion bases. 1. Introduction This paper is. structured as follows; Chapter 2 IIltroduces an Illformal description of the strategic The ni neties will be a challenge to the hardware and the technical aspects of the framework. and software vendors. In the area of system Chapter 3 gives the formalized methodology for ~ow to ~orm a c............Object •---------. -~::> Transmission " , As an example we take an ODA4 or an EDlFACTs service document, here called an ODA or EDIFACT Figure 2 • Two integration aspects object. The interior of the object is the specific structure and contents of the document. If the object is exchanged from one system to an other, In figure 2, the two integration aspects are both systems can, if desired, interpret the illustrated by means of the horizontal and vertical information according to the agreed format and concepts - object protocol and object transmission language. service - which we define below. We say that both systems know the semantics. The description of the semantics is included in an 2.1.1 Horizontal Integration object protocol definition. This object protocol is then the horizontal integration solution. Horizontal aspects in this paper means the semantics of the information and the logical solutions which are closest to the application level. 2 2.1.2 Vertical Integration structures information as well as the required object services for transfer of the desired The vertical integration is the transmission of the information. information without any concern on what is transmitted. We may say that the transmission is some kind of an Object carrier, which carries the A Site information object from one site to an other. ~ Local 10 .............. ~ As in the example mentioned above, where we have an aDA or an EDIFACf object, we need a 1..':1 ~ . LocaVgkJbal m transmission of this object, i.e. an object connection transmission service. For both ODA and EDIFACT objects there are, to some extent, specified services for transmission of such '. objects. These services know the basic syntax Figure 4 • "Local" and "global" IB, and the structure, and are able to path the objects as interconnection of Ulese two. messages from one site to an other. The service definitions (as well as the object protocol ( standardization) is done within ISO and CCITT. 2.2.2. The In layers The object transmission service is the vertical integration solution. We shall describe the strategic parts of the integration analysis, divided according to the layers of the lB. All layers of the IB are ( strategically important within the decision 2.2 The IB Architecture making.They all influence the functionality of the lB. Still, the underlaying layers of an IB are In the previous section we have given a general transparent to the applications or the users. But description of the two integration aspects of the they are not transparent for those who perfonn the Information Bus. In this section we will describe integration analysis. Each layer represent a step of the architecture of the lB. We focus on each of the the integration analysis. layers, and show the sequence of steps that must be undertaken as parts of the integration analysis. In figure 5 the IB is presented with three main layers, each one is described below. Note that "an application" will here mean either the information ASilc ASHe base(s) or the remote application(s) connected The Informotlon Bus with the information base(s) through the lB. :",,, ASHe ASitc ( - Figure 3 - TIle Information Bus WiOI different sites e 3 ·5• conneclCd. 2 '0 ~ ( • ~ In figure 3 the IB (the hatched area) is illustrated • ..l as the communication bus which provide facilities for exchange and transfer of information. Each Ph)'Jl<'Ij nf!lwor site represents one or more activities that are integrated with other activities (locally or not) Figure 5 - lB's three layers (hatched area). through the lB. Thus, the lB can also be a concept for both the internal integration of activities, as well as integration of widely distributed activities, The lower layer of the 18 :Contains at most six see figure 4. layers corresponding to the 7 layered ISO's Open Systems Interconnection (OSI) reference model The IB does not intend to support distributed [7]. In the lB they are: the presentation, session, mechanisms such as those provided by distributed transport, network, link and physical layers from DBMS. It rather gives a strategic and technical top to bOllom. The problem with this layer of the basis for a requirement specification of the system lB is that network (and transport) services may integration analysis. This involves requirements support different solutions from one installation to on how the object protocol represents and 3 an other. They are named Connection-mode • Docs the system support some kind of extension for Network Service, CONS, and the Connection- user specific commands? less-mode Network Service, CLNS. The CLNS is • Does the system support any communication described in an addendum [8] to the OSI reference services? model. There are gateways which can interconnect networks of different types, but these are not at all At this stage the analysis only concerns the standards. The CLNS was first defined by application requirement input. And these DARPA6, and are supported by most of the requirements will be described in temlS of services computer vendors, known as the TCP/IP and information. When an information base is network. considered, the services are on the form store, retrieve and update. The application communication layer: Corresponds to what the OSI names as the The framework support these services as the basic application layer, layer 7 of the reference model. services to the applications. Be aware that these This layer provide communication services to the services have an additional description, and application systems. A DARPA protocol also should not be mixed with typical DBMS contains this layer, but does not include the layers operators, [10], with the same names. ( 5 and 6. These services are also named value- added network services (VANS), e.g. filetransfer • STORE (INSERT): This service acts as follow: The user has scnt a write request for some (FTP, FTAM), mail systems (MHS, X.400, information object to be stored into the information EAN), MAP, TOP, etc.. base, i.e. a new entry. The service will then call • upon the information base store mechanism, which The crucial point at this level of an IB rises two store the informalion object if OK. possible decisions concerning the VANS: • RETRIEVE: This scrvice acts as follow: The • The first concerns whether the organization is uscr has sent a read request for some information connecting its own IB to a global lB. Then the local object. The service will then call upon the IB must at least support (some of) the services information base retrieve mechanism, which returns which is supported by the global lB. Ule desired infonnation object if OK. • The second reflects only an internal inslllllation, • UPDATE (MODIFY): This service aCls as from scratch or as extension, of a local lB. Here the follow: The user has senl a request for an update of question is: how can one oblllin more and better some entry in the information base. The service will functionality between applications? Some services Ihen call upon Ihe informalion base updale may in some cases give more overhead because of a mechanism, which update the entry if OK. lot of human interaction in the point to point transmission, e.g. performing file transfer by a mail The framework does not consider how the user, system. Therefore, the organization will be better off here the remote application, actually performs a with a critical analysis on the possible services to request. But the framework intend to address the choose. connection, which the IB serve, between an information base and a remote application. The The application interface layer: Is illustrated in application interface virtually connects the figure 1 as the plus signs of system A+and system infOlmation base(s) and the remote application(s). B+ after the integration. This interface specifies the That· is the horizontal connection named as the special purpose or the extended functionality of object protocol, e.g. aDA and EDIFACT object the application. The openness of a system decides protocols. if a system can be integrated with some other system(s) or not [9]. The decision whether the The application interface layer of the lB is now system is "open" or not can be investigated desclibed by three possible services. At this stage according to the following criteria: we may for simplicity say that the above services include the object protocol and the object • Does the system have functions/commands to transmission services, i.e. both the horizontal and external system(s)? vertical integration aspects. We will later in this • Docs Ule system have operating system commands? paper show that the services on this layer in fact • Docs the system supporl s~1Ildard exchange formats? are defined with these aspects and give a Jllore • Does the system support some other known format(s)? clear distinction betwcen different objects handled • Is the internal information format described in the by the specification methodology. (So fare we manual, and may Ule have distinguished between two types of objects.) infonnation be read in ~omc way or an other? The conceptual specification, based on the • Is the system able to read and to manipulate analysis, must include additional properties of infonnation from each service. These properties are: an extemal system/device? 4 • Functionality, described above. • Primitives, what kind of system specific mechanisms are used, botll input to and output from 3. The Methodology application and communication systems. • Parameters, what type of information is handled, The previous chapter presented an informal both input to and output from application aud description of the IB. In this chapter we first communication systcms. The returned rcsult is present the integration analysis and then an object- positi ve or negative. i.e. success upon request or oriented methodology for the conceptual nOlo specification of the application interface. A more technical and detailed description of the application interface layer is given in chapter 3. 3.1 The Integration Analysis One of the objectives of the framework was to get 2.3 The Client . Server concept a better understanding of the complex environment faced by system integrators and that the integration In the previous section the application interface analysis should support the decision making. The layer of the I.B was described. This interf~c~ giyes previous chapter has described the layered IB and the descripuon of the conceptual speclflcauon the cmcial points of the integration process. (based on the object protocol definitions) of the information the remote application and the The output of the analysis is the strategic and information base may exchange. This leads to technical decisions (including the network view the remote application and the information interconnection, VANS and application interface.) base as the client and the server respectively, The analysis takes into account each layer of the exchanging information objects. IB, but the most critical bottle-neck is the "openness" of the end-systems, shown as the There may be different ways to implement the application in figure 5. interaction between a client and a server. The best known mechanism of such an interaction is the The three different layers of the IB require four "Remote Procedure Call" (RPC), first described in major analysis steps of the integration process. A [11] based on ordinary program-language natural language description of the analysis steps proc~dure calls. Here, the main idea is that it is of the methodology is given below: transparent to the user or the calling program/process whether the execution is • Arc tllCre diffcrent nctworks in the cnvironmcnt performed locally or transferred to a remote and is it possible to connect dlcm? process. Renects thc lowest layer of the lB. • What types of serviccs (and which VANS) do the All client-server interactions (of the specific networks support? application area in this paper) can be viewed as RcneCIS dlc second layer of d,c lB. illustrated in figure 6. • What kind of application rcquiremcnts are dlcre? ReneclS the upper layer of the lB. • Is thc conccptual spccification of the lB's Server application interface possiblc? Client Renccts the coordination of thc previous sleps. Remote Information Appllcntlon Base A breakdown of the analysis into tasks can be ~"'''\>,' k""", done with help of introducing a flowchart like symbolism as shown in figure 7. o Identification or Task Figure 6 • Client and Servcr intcraction o Task Decision The server-client concept within the framework is chosen because it provides the transparency for o Input IO/Output from Task client(s) when interacting with the server. The ~ Flow object-orientation may well be applied as a conceptual extension to the server-client concept. Coordirwtioll between tasks A wider description of the client and server Iteral ion? llacklmckingfTcrminaLion communication and interaction is found in [12]. Figure 7 - Symbols of an analysis flowchart 5 The integration analysis steps can then be The diagram of the network analysis are shown in described with these symbols as shown in the figure 9. diagram of figure 8. In figure 8, there are four steps indicated with the task symbol. Each of these tasks will in turn be described by other Req. Input diagrams. That is, a breakdown into input/output, task and flow symbols etc. OUIPlH lo iteration? _--.gical informatio.n b~se. The methodology presented in chapter 3, includes Each one is interfaced wIlh the commul1lcallon different data models for the definition of the systems with a so called Intelligent Enterprise information object contents. This part of the (Server) Interface (IEI). The levels of the methodology makes it possible to descnbe the application interface in chapter 3, are also p~esent integration of existing heterogeneous systems. in the lEI. The information base interface IS one service of the IEI and is descri bed by the The methodology is used to specify the static pans methodology presented in chapter 3. Thus, the lEI of the application interface. It has also Improved is more than an information base interface, it is a the understanding and stnlclliring of the Intelligent ( concept which interfaces all the services of the Enterprise Interfac.e, and wip be used as the enterprise [19]. technical documentallon of tillS lI1terface. The first prototype of the lEI will be implemented summer/autumn '89. The lEI prototypes wtll be installed by the pilot partners in other workpackages of this project. Acknowledgements: The frame,,:,ork presented here is mainly a result of the author s parllcipalion The IEI prototype is planned to exchar.lge and in the DIMUN project. A thank to all panners for transmit technical infonnation (CAD drawmgs and interesting discussions. as werecomments by Lise images) as well as business like information Arneberg and Heikki Hammiilnen on an earlier (orders and offerings) between different partners draft, and by Per Anton Fevang on the last version of the project. of this paper. For each type of information there is three objects to be defined and specified. The first is the References: application service, which gives the basis of handling of the information. The second IS the [I] Towards a Dynamic European Economy, Green information objects (i.e. object protocols) I1sted Papcr on thc Dcvclopmelll of ~le Common Market above for the three logical units. The third is the for Telecommunications Services and EqUlpmenl; transmission (i.e. object transmission service) Commission of the European Communities, DO which in DIMUN are ordinary VANSs. XII. May t 987. 12 [16] G. Di Battislll and C. Batini (2) "'UK- GOSIP, The Government Open Systems "Design of Sllltistical Da~~bases: A Mcthodology for Interconnection Profile", HMSO Publications The Conceptual Stcp", Information Systems, Vol. Centre, London, ISBN Oil 3305176 and ISBN Oil 13, No.4, pp. 407-422, 1988. 3305184. (17) Trygve Recnskaug [3] KA. Bringsrud, E. Mj~vik and T. Grimsllld "A Methodology for Design and Description of "'National Plan for OSI-net in Norway", Norwegian Complex Object-Oriented Systems", Version 0.1, SI text, NCC·note DTEK/08/88, Norwegian publication no. 87 01 26 - I, Oslo, Norway, 1988 , Computing Centre, Oslo, Norway. © 1988 Centre for Industrial Research, ISBN 82- 411-0103-1. [4) "ISONET-S", a IT4-project in Sweden Wolf Arfvidson, Sllldskontoret, Stockholm, Sweden. [18] O. Lehnnann Madscn and B. M~lIcr-Pedersen "What Object-Oriented Programming May Be- and [5] "COSINE, Cooperation for Open Systems What It Docs Not Have to Be", Proceedings Interconnection Networking in Europe", Cosine ECOOP'88, pp.I-20, Oslo,Norway, Eds. S. Policy Group, Commission of the European Gjessing and K. Nygaard, © Springer Verlag Berlin Communities, DG XIII-A2. Heidelberg 1988, ISBN 3-540-50053-7. (6) "Analysis of Status quo and Communication [19] "Specification of Information Bases and Interfaces" ( Requirements", DIMUN, project no. 1039, Ed. Bj~rn Skjellaug, SI publication no. 89 01 06 - Deliverable DI-2 to RACE Office, Commission of I, Oslo, Norway, 1988, ISBN 82-411-0129-5. the European Communities, DGXIII-F, Tele- communication, Information Industries and 1 ISO. International Standards Organization Innovation. CenT - Camite Consultatif lnternational Tclcgraphiquc ct Tclcphonique. [7] Open Systems Interconnection - Basic Reference 2 Computer Integrated Manufacturing. Model, ISO 7498 3 Qistributcd International Manufacturing 1!.sing CltiSling and developing public lictworks. Partly supported by the [8] Addendum to Open Systems Interconnection Commission of the European Conu11unities (DOXIlI.F). NTNF - Basic Reference Model, ISO 7498/DAD I . The Royal Norwegian Council for Scientific and Industrial Research - (granl no. IT.3.31.22917) and The Finnish [9) Skjellaug Bj~m and Solbakk Svein Arne 00Ven1l11ent's Technology Development Centre (project no. "Integration of Heterogeneous Systems", Norwegian 4200/87), and partly by the projeci members. text, SI publication no. 87 762 - 2, Oslo, Norway, 4 Opcn Document Architccture. Standard by ISO and CelTT 1987, ISBN 82-7267-952-3. 5 Electronic Data Interchange For Administration, commerce and lIade. Standard by ISO and CCITT [10] C. J. Date 6 Defence Advanced Reseach Projcct Agency· US Department "An Introduction to Dalllbase Systems" of Defence Third Edition, © 1981 Addison-Wesley Publihing 7 Initial Graphics Exchange Specification, published by U.S. Company, Inc. Department of Commerce. NBSIR 88·3813. [II) Bruce Jay Nelson "Remote Procedure Call", Dr. Thesis, May 81, ( Xerox Palo Alto Research Center, report no. CSL- 81-9, Palo Alto, CA, USA. [12] Gro OCtedal "The use of Remote Applications from a Smalltalk Workstation", Master Thesis, Jan. 87, Centre for Industrial Research (SI), Oslo, Norway. [13] K.R. Dittrich, A.M. Kotz, J.A. Mulle "A Multilevel Approach to Design Database Systems and its Basic Mechanisms", Proceedings IEEE COMPINT, Montreal 1985. (14) D.S. Batory and A. Buchmann "Molecular objects, abstract datatypcs, and dala models: A framework", Proceedings of VLDB, pp. 172-184,1984. [IS] P.P. Chen "Thc Entity-Relationship Modcl: Towards a Unified View of Data", ACM Transactions On Database Systcms, 1:1, pp. 9-36,1976. 13