=Paper=
{{Paper
|id=None
|storemode=property
|title=IB - An Information Bus: A Multilayered Information Base Interface for Remote Applications
|pdfUrl=https://ceur-ws.org/Vol-961/paper16.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/Skjellaug89
}}
==IB - An Information Bus: A Multilayered Information Base Interface for Remote Applications==
https://ceur-ws.org/Vol-961/paper16.pdf
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