OMS Connect : Supporting Multidatabase and Mobile Working through Database Connectivity

Transcription

1 OMS Connect : Supporting Multidatabase and Mobile Working through Database Connectivity Moira C. Norrie, Alexios Palinginis and Alain Würgler Institute for Information Systems ETH Zurich, CH-8092 Zurich, Switzerland fnorrie,palinginis,wuerglerg@inf.ethz.ch Abstract We present a general model of database connectivity for the controlled sharing and migration of information across databases as supported in the object-oriented database management system OMS Connect. A database may connect to one or more other databases, thereby enabling remote data to be viewed, processed and copied within the local database in such a way that consistency of the user working space can be maintained. Further, the objects of the remote database may be extended locally with attributes and methods and additional classifications. Importantly, operation of the local database is not dependent on such a connection and remote objects may be replicated locally with explicit synchronisation points, thus making the system suitable for mobile computing. 1. Introduction An increasing number of applications require information to be managed across a number of databases rather than in a single, monolithic database. Major reasons for multiple database working are the need for physical distribution in networked application systems and for interoperation between existing systems. Here, we consider the creation of multiple databases as a means of logically structuring an information space which may, or may not, be physically distributed. Thus, a user or group of users can organise their information space into one or more modular database units in a way that enables controlled and dynamic sharing of both data and metadata among users and applications. Support for multidatabase working has appeared in many forms over the past two decades ranging from distributed databases [2, 11], through federated databases [4, 14] to more recently proposed integration architectures such as [3, 1, 7]. The various proposals tend to cater for differing application requirements in terms of the degree of node autonomy, the forms of heterogeneity, the kinds of transaction models to be supported and the system evolution history. Further, they may vary in terms of the intended network architecture and nowadays this extends to the realm of mobile computing where nodes may be disconnected and operating independently for long periods of time due to network failure or low bandwidth (see for example [13, 12]). However, in almost all cases, distribution tends to be physical and static from the perspective of the user in the sense that their database view is fixed and distribution occurs at the level of query processing and data delivery. Indeed, physical distribution occurs in most systems in terms of client/server architectures intended to increase throughput and utilisation through the distribution of processing tasks in a manner that is transparent to the user. In contrast, we want to support the logical structuring of an enterprise s information space into locally maintained databases as part of a cooperative user working environment. Data may be shared through a connection mechanism which dynamically extends the user s working space to include both the schema and data of other databases. Such a database connection allows a user to not only view, process and copy remote objects, but also to extend them locally with additional attributes, methods and additional classifications. Importantly, operation of the local database is not dependent on such a connection and remote objects may be replicated locally with explicit synchronisation points, thus making the system suitable for mobile computing. Recently, Oracle Corporation introduced their product Oracle Lite [10] which is intended to support small and mobile information systems. Users can replicate parts of a server database on a mobile client for remote working. However, data objects cannot be locally extended and there is limited support for synchronisation. We have implemented our model of connectivity in an extension of the object-oriented data management system OMS [9, 8] called OMS Connect. A major factor in our implementation was to allow maximum flexibility in terms of how a particular application system could be configured

2 with respect to distribution and data sharing. This means that instead of imposing particular models of synchronisation, access controls and replication, these are to some extent left open for the user/application designer to specify. We were particularly interested in supporting more relaxed models of synchronisation suited to cooperative working environments. A user may connect to one or more databases at any time, thereby enabling them to access data and metadata of remote databases within a single database working space. This capability supports many forms and activities of multidatabase working including shared access to server databases and both schema and data migration and integration. Additionally, it allows parts of server databases to be replicated and annotated locally with later synchronisation of updated and new objects if desired. This would allow, for example, a salesman to copy relevant product information along with configuration processes into his al database and generate new customer orders in this database at the customer site while disconnected from the server database. When he later returns to his office, a connection between the central sales database and the salesman s database can be established and the new order information automatically copied into and synchronised with the central sales database. In section 2, we describe the basic structures of OMS Connect objects and their identifiers. Section 3 introduces our notion of database connectivity in terms of client and server databases. In section 4, we describe the client view of server objects and client replication of server objects. Section 5 examines the notion of client remote object copies and user working spaces. A description of the system implementation, including access controls, is given in section 6. Concluding remarks are given in section OMS Connect Objects In an object-oriented multidatabase environment, all objects must be uniquely identifiable over all possible interconnected databases. We use a hierarchically structured scheme of object identifiers (IDs) with * used as a delimiter between the parts. For example, the object 1*2*3*4 would belong to the database with ID 1*2*3. Each database is associated with a Domain Object ID Server (DOIDS) which generates the IDs of specific databases. A DOIDS generally corresponds to an OMS installation instance. Then the object 1*2*3*4 belongs to database 1*2*3 which is associated upon creation with DOIDS 1*2. Each DOIDS is in turn associated with a DOIDS further up the hierarchy and so on until the root DOIDS is reached as shown in figure 1. In this way, only root DOIDS have to be administered centrally. Each DOIDS includes a routing mechanism to DB: 1*1 objs: 1*1*0 1*1*1 1*1*2 connect DOIDS: 1 DB: 1*2*1 objs: 1*2*1*1 1*2*1*2 1*2*1*3 DOIDS: 1*2 OMS Site DB: 1*2*2 objs: 1*2*2*1 1*2*2*2 Figure 1. Domain Object ID Servers avoid dependency on physical network addresses. Every DOIDS has a routing table with the address of all its direct neighbours. Database connection requests are specified in terms of the database ID. The DOIDS of the client will propagate the request to its neighbours if no corresponding entry is found in its routing table. The routing tables are dynamically updated from the DOIDS which can be managed through a GUI administrator tool. There are a number of features of the OMS System [5, 8, 9] and its underlying data model OM [6] that make it particularly suited to distribution and sharing of both schema and data. Most important is that all information both data and metadata is represented as objects and this allows both schema and data to be handled uniformly with regard to distribution and sharing. Every OMS Connect database contains special system objects which provide the basic structures and functionality of the system. These objects are common to all databases and are locked to prevent any attempt to update or delete them. These system objects have an ID starting with 0*... in every database thus guaranteeing that all created entities are ancestors of these global entities. Further, this avoids any attempt to transport them over the network. An OMS object can have many types and the attributes and methods associated with a given type can be thought of as defining a view on an object. We illustrate this with an example in figure 2 which shows the classification and representation of an object with ID1*2*10. The object1*2*10 is of type and also of type where is a subtype of. This means, in the usual way, that an object viewed as an object has both the attributes defined for type and the attributes inherited from the supertype. However, our model differs from those found in most object-oriented database systems, for example O 2 and

3 Collections Persons Employees subcollection Objects 1*2*10 name: john ; phone: ; salary: 12000; phone: ; subtype Information Units ( 1*2*10,, [ john, ] ) ( 1*2*10,, [12000, ] ) Figure 2. Object Classification and Representation Objectivity/DB, in that an object can be viewed not only in terms of its most specialised type, but also in terms of any of its other types. An object is always accessed through a type context. For example, objects are classified into collections which have an associated member type. When an object is accessed through a collection, the member type specifies the view of that object. Thus, if the object 1*2*10 of figure 2 is accessed through Persons, the phone attribute refers to that associated with type which may, for example, be a home number. If however, the object is accessed through Employees, the attributes of both and are visible, but the phone attribute of, for example an office phone number, is seen rather than that of. Using a type as a view on an object is very flexible in that it also allows different implementations of methods to be applied to the same object in different contexts. For example, a print method on an HTML document viewed as type document could print the HTML source text, whereas, for the same object viewed as type html document, the print method could print a Postscript file of the document as displayed through an HTML browser. Corresponding to our notion of types and subtypes, object representations are composed of information units one for each type of which the object is an instance. As shown in figure 2, an information unit is a triple consisting of the object ID, a type specification and a list of values for the properties associated with that type. The properties associated with a type are those that explicitly appear in the type definition and excludes those inherited from supertypes. Any access to an object can be thought of as composing the set of attribute values from the appropriate set of type units in such a way that those of the subtypes override those of the supertypes. Information units of the same object can reside in different databases. It is this horizontal partitioning of objects into information units that supports extensibility of remote objects in a client database as shown with the introduction of the subtype in figure 2. The OMS way of handling objects, types and subtypes provides a clean way of distributing objects and allowing shared objects to be extended locally. Further, as we shall see later, OMS represents associations between objects as a separate construct rather than using reference attributes and this also facilitates distribution and sharing by enabling objects to be cleanly partitioned into information units with small closure spaces. 3. Client and Server Databases We view the information space of an enterprise or multiple enterprises as being logically structured into databases each of which defines a sphere of management and control. This means that the users of a particular database have ownership of that data and overall responsibility for its currency and consistency. However, users can share data by making data from one database visible within another. Further, the data and its schema can be extended and/or copied locally. These extensions and copies of remote data are in the sphere of control of the local database. In this way, it is easy for users to not only access remote data, but also to annotate, replicate or migrate remote data within their own database. Data and schema sharing is achieved by means of a database connection mechanism. If a server process is started on a database, other databases may request connections to that database. The committed schema and data of the server database will then be visible within the client databases. Databases can freely connect in the sense that any database can be both a server for one or more databases and a client for one or more databases. Further, for any pair of databases the role of client and server are not fixed. This means that given two databases A and B, it is possible that A is sometimes a client accessing the data of B and some-

4 Type Objects Objects Server Database 1*2 1*2*5 type name : string; phone : string; 1*2*10 name : john; phone : 63642; Client Database 2*4 2*4*8 subtype type salary : integer; grade : string; 1*2*10 salary : 12000; grade : 15A; 1*2*10 (copy) name : john; phone : ; 2*4*9 name : mary; phone : ; Figure 3. Client Objects times B is a client accessing the data of A. To explain how a client may access, extend and create their own copies of server objects, consider the example of server and client objects shown in figure 3. As stated previously, all information in OMS both schema and data is represented as objects. Type information is therefore also represented in terms of type objects. We assume a server database with ID1*2 which has objects. We show an example of a object 1*2*10 and the corresponding type object 1*2*5. When another database with ID 2*4 makes a connection to database 1*2, the objects of the server database 1*2 become visible within the client database 2*4 (subject to access controls). The client database can extend the remote data by associating its own attributes with objects of the server database. This can be done, for example, by creating a new type object 2*4*8 for in the client database with the specification that it is a subtype of the remote type object 1*2*5. The client database is then able to create locally new information units of remote objects for type. Thus, we see that the server object 1*2*10 has an information unit (1*2*10,, [12000,15A]) which is visible in and belongs to the client database. The client may also choose to create its own objects of type such as 2*4*9. The client could also introduce its own classifications of and objects both local and remote by introducing new collection objects. They can also introduce new methods, constraints, triggers or associations to other objects within the context of their own database. We note here that the ability to work with objects of a server database within a client database and to attach new client methods to server objects including collection objects provides a very simple and convenient way of migrating data between databases. On the client side of figure 3, we also show a copy of the server object1*2*10. This local copy has a different phone number attribute from that of the server. Effectively, the client is able to generate its own local views of remote objects, by creating his own client copies of information units. For example, it may be that the client knows thatjohn has a mobile phone and chooses to see that number rather than the one stored on the server. The question arises as to what happens when the connection between the client and server is closed and how objects visible within the client database are synchronised with activities on the server. Since it was one of our objectives to provide a system that could be configured to suit a variety of application requirements, we actually have various alternatives for making remote objects visible within a client database as illustrated in figure 4. In figure 4, we show four different kinds of objects in the client database local, remote, remote persistent and remote copy. We shall explain each of these in turn. The local objects are those created in the client database. A remote object is one which is located on the server, but visible within the client as long as the client-server connection is established. Note that OMS Connect does indeed use caching of remote objects on the client side to improve performance, but here the logical view is that the object resides on the server. When the connection is closed, the object will no longer be visible in the client database. For mobile computing environments, it is important for the client to be able to access server data within its database even though there is no current connection. For example,

5 local Server Database synchronised on commit checked on commit local remote Client Database remote persistent remote copy update Figure 4. Client and Server Databases we earlier described the situation of a salesman configuring an order at a customer site using an application on his laptop computer. In OMS Connect, this can be achieved by his connecting to the product database and specifying that the required objects become remote persistent within his own database on his laptop computer. In this case, the remote objects are not only visible in the client database, but are also stored within that database with the effect that they remain visible after disconnection from the server. Since the database is object-oriented, this means that the salesman can copy with ease not only the product data, but also the associated methods that implement the configuration process itself for those products. In the cases of both remote and remote persistent objects, these objects will be synchronised with the server. This means that when updates are committed on the objects of the server database, these changes will be seen in the client database. Clearly, in the case of remote persistent objects, synchronisation cannot take place after disconnection. However, they will be synchronised later when connection is re-established. In many practical applications, such behaviour is adequate since the required server data tends to be stable, e.g. the portions of the product catalogue accessed by a salesman. A final form of remote object is that known as remote copy. In this case, the object is not only visible and stored within the client database, but also it is no longer synchronised with the corresponding object on the server database. This corresponds to the situation where a client chooses to have their own view of an object which may differ not only in terms of form, but also in terms of values from that of the server. Whenever a client performs an update on a remote object, a remote copy of that object will be generated automatically. Additionally, the user may explicitly request a remote copy of an object. The effect of a remote copy within the client database is that a commit operation on the client database requires not only local consistency, but also consistency with the server database. This notion of remote copy is interesting in terms of both its handling and use and we therefore defer further discussion until section Client View of Server Objects In this section, we describe in more detail the client s view of database connectivity and working with remote objects. The main control panel of OMS Connect has a Network menu as shown in figure 5. Figure 5. Network Options Through the Network menu, the user can obtain information as to which objects are remote copies or currently remote persistent (Net Persist). They can also remove all of the current remote persistent objects from their database by means of theempty option. The Network menu also provides a menu of saved client connections through which the user can easily view, close or open a connection at any time. Such connections are saved as client objects in the database and the user can at any time create or delete these objects. All that is required to connect to a given database is its ID and access authorisation as specified by the server. Once a client has established a connection to a server database, the objects of the database are visible on the client and can be browsed in the usual way. While the system

6 Server Database Client Database remote persistent remote copy remote persistent local remote Figure 6. Client View of Server Objects keeps the distribution aspects transparent to the user, in practice, it is often useful for the user to be aware of logical distribution properties of information. To help user awareness as to which information is remote and in what form, colour preferences can be set for the display of information. For example, we use four shades of grey in the object displays of figure 6 to distinguish the four forms. On the left of figure 6 is a object of the server database. The object has various attributes name, phone, , birthdate, photo etc. It also has four methods send , view www,age andwork place which have buttons displayed alongside. The same object is visible on the client side. However, we may assume that the client database deals with customer orders and therefore has three additional local methods all orders, last order and undelivered orders to display order information. Methods are objects linked to type objects and so these three additional methods are simply objects of the client database with links to the type object of the server database. The methods are coloured light grey to indicate that they are local objects. Dark grey is used to denote information stored remotely. Thus, all the attributes of the client view of the shown server object are coloured dark grey. On the client side, we show another object with different colourings since it has been made persistent (and part of it copied) in the client database as described below. In the server database, the type is in fact a subtype of a typecontact which is used to represent contact information about both s and organisations. Thus, the objects are actually composed from two information units one for type contact and one for type. For the rightmost object, the contact information has been made persistent in the client database. This means that this information will still be visible after a disconnect operation. An object is made persistent in the client database by simple menu selection on the object s File menu. When an object is made persistent, all objects on which it depends are also made persistent. This means that the type object for contact and also the associated method objects will automatically be made persistent as well. Thus, the contact methods send and view www are coloured to denote that they are persistent and this applies to both objects. Finally, the client user has performed an update on the home phone attribute of the rightmost object to record perhaps a mobile phone number which they know about and prefer to use. This causes a remote copy of the information unit of that object to be generated within the client database. The issue of dependency between objects is the problem of determining object closure. In the case of OMS, this applies over data and schema objects. It does not apply to system metadata objects which, as stated previously, are distinguished objects which have IDs starting with 0*..

7 remote copy space department 0:* 1:1 Departments Works_for Employees type subtype (, ) department association method send_mail Figure 7. Remote Object Copy Space and are stored in all databases. The problem in many object-oriented systems is that the closure of an object may involve large numbers of objects as a result of following references within objects. In OMS, associations between objects are represented by a special association construct between collections of objects as shown in figure 7. Here, s are associated with their departments through a Works for association between the collection Employees and the collection Departments. Therefore, references within objects are used only when associations will be traversed in one direction and, as a result, they tend to be used rarely. This avoids the tendency for spaghetti objects and eliminates problems associated with object closure. The remote copy space for an object of type would therefore involve mainly schema objects such as type objects, subtype objects and method objects as indicated in figure Remote Copy Objects We now examine the notion of remote copy objects in more detail. Remote copy objects differ from usual replicated objects in that there is no attempt to synchronise the objects. Rather, the whole idea behind remote copy objects is that the client database has its own al variant of an object created by the server. Thus, updates to the object on the server side are not propagated to the client object and updates on the client side are only visible within the client or, in turn, to any of its clients with permitted access. Consider the situation portrayed in figure 8 involving a server database and two client databases. We can assume that at some past point in time, clients C1 and C2 both made a remote copy of an object of server database S. This can be done as an explicit operation on an object, as well as happening as the consequence of updating a remote object as discussed previously. Since that time, both clients have updated their remote copies and the server has also updated its copy. We now have the situation that there are three versions of the object that of S, C1 and C2. All copies of the object have the same ID and, in that sense, they represent different views of the same server object. Consequently, there is still a binding of the client remote copies to the server database. This binding takes effect when a client performs a commit operation on their database. The consistency checks performed at commit time include the remote copy and so the scope of the commit is extended to include the server database. This means that a client may update a remote copy provided that it remains consistent with the server database. Thus, remote copies are still within the sphere of consistency of the server database since the remote copy, as identified by its ID, still belongs to that database. This ensures that the semantics of the object are not violated. Currently, we are investigating the use of a special form of versioning scheme to deal with possible synchronisation conflicts resulting from different users attempting to commit workspaces which conflict in terms of global consistency of the multidatabase environment. In cooperative working environments, such inconsistencies arise from user differences and semantic issues and must therefore be resolved at the user level. The system simply provides tools to help the cooperation process by detecting the inconsistency and notifying the involved parties in order that they can negotiate. In the meantime, we ensure that no data is lost and all users can maintain their view of the database. It is possible to use a standard OMS duplicate operation on a server object to create a local clone of a server object as shown in client database C1 of figure 8. However, this local copy would have a different ID and all references to the server object would not be carried over to the local copy. There would also be no further binding between the client clone and the server. We denote this in figure 8 as a local

8 Server Database S sphere of consistency sphere of consistency local copy remote copy remote copy Client Database C1 Client Database C2 Figure 8. Consistency of Remote Copies copy outside of the server s sphere of consistency. The model of working introduced with this notion of remote copies is much more in line with that of al working spaces and synchronisation models required for cooperative working. The OMS system itself is based on a transactional working space model in which all updates to a database are persistent and transactions correspond to work activities which may span several OMS sessions. A commit operation corresponds to making the effects of a logical work activity permanent by writing the updates of the working space to the database. The commit is performed only if the working space is consistent meaning that the commit will result in a consistent database. A rollback operation simply clears the current working space. The fact that transactions represent logical work activities means that, in many applications, they tend to be of long duration and commit operations occur relatively infrequently. As a result, synchronisation of remote copies also occurs relatively infrequently and so the required overheads are minimal. We note here that the system may also support more traditional models of synchronisation in terms of object locking. It would be possible for a client to obtain a write lock on a server object and retain that lock as long as necessary. Given that transactions in our system typically represent interactive work activities of possibly long duration, this could be likened to a form of check-in/check-out model. However, while useful in some application scenarios, it is too restrictive and performance inhibiting for many others. We therefore prefer to provide alternative, more flexible and open models of synchronisation and leave it to the application programmer to choose what is appropriate. 6. OMS Connect as an Extension of OMS The concepts of the OMS system and its support for extensibility enabled OMS Connect to be implemented as an extension with minimal changes to the core of the system. Two new system types that enable connections were added to every database instance. These are the types client and server which allow the creation of client and server objects. A server object has a status (active/disabled) and methods to start, stop and trace activities. Applications for a distributed database environment must simply reference the attributes and methods of these client/server objects. A client object specifies the database ID of the database to be connected, the current connection stream (if connected), authentication information and methods for connecting and disconnecting along with communication primitives such as ping. Connecting to a remote site simply involves creating a client object, specifying the remote database ID, specifying the login name and password and executing the connect method. As shown previously, these actions are simplified further for the user by providing a special Network menu with options to create new client objects and to execute connect or disconnect on existing client objects. A server database is opened for potential client connections by executing a start method on a server object. Further, the administrator of a server database may choose to operate on either an open or a closed basis. A server database is open if its access controls are such that they specify access restrictions. This means that the default is that all objects are visible to a connected client. On the other hand, a server database may be configured as closed

9 if the default is that no objects are visible to a connected client and the access controls specify access rights to allow certain users visibility of specified objects. 7. Concluding Remarks We have presented a system developed to support data and schema sharing in the OMS environment. The system is based on general database abstraction mechanisms which support a logical notion of client/server connectivity among databases. It is important that connection is dynamic thereby supporting not only mobile computing, but also notions of both schema and data sharing and reusability. Further, we believe that the the capability to be able not only to read data from another database, but also to annotate it and even alise it affords many benefits. The system was designed in such a way that it can support many possible configurations with respect to the forms of data sharing, synchronisation and access controls. Different applications have different requirements and it is also true that many systems require much more flexible and less restrictive models than those of traditional systems in order that interactive and cooperative working can be effectively supported. To date, the system has been used for a number of prototype application scenarios that demonstrate the ideas of data sharing and data migration. However, we note that it is also useful for a typical teaching situation where students can, not only access a demonstration database for querying, but can also freely update and extend both the schema and data of the database without fear of corruption of the original database or interference with each other. Our future work will focus on extending the current system specially for the cooperative working environment. In particular, we are investigating approaches to maintaining a set of possibly inconsistent user views in such a way that conflict is detected and can be resolved without loss of user data. References [1] O. A. Bukhres and A. K. Elmagarmid, editors. Object- Oriented MultiBase Systems. Prentice Hall, [2] S. Ceri and G. Pelagatti. Distributed Databases: Principles and Systems. McGraw-Hill, [4] D. Heimbigner and D. McLeod. A Federated Architecture for Information Management. ACM Transactions on Office Information Systems, 3(3): , [5] A. Kobler, A. Steiner, and M. C. Norrie. OMS/Java: Model Extensibility of OODBMS for Advanced Application Domains. In Proc. 10th Conf. on Advanced Information Systems Engineering (CAiSE 98), Pisa, Italy, June [6] M. C. Norrie. An Extended Entity-Relationship Approach to Data Management in Object-Oriented Systems. In 12th Intl. Conf. on Entity-Relationship Approach, pages , Dallas, Texas, December Springer-Verlag, LNCS 823. [7] M. C. Norrie and M. Wunderli. Modelling in Coordination Systems. Intl. Journal of Cooperative Information Systems, 4(2 & 3): , [8] M. C. Norrie and A. Würgler. OM Framework for Object-Oriented Data Management. INFORMATIK, Journal of the Swiss Informaticians Society, (3), June [9] M. C. Norrie and A. Würgler. OMS Object-Oriented Data Management System. Technical report, Institute for Information Systems, ETH Zurich, CH-8092 Zurich, Switzerland, [10] Oracle Corporation. Oracle Lite, [11] M. Özsu and P. Valduriez. Principles of Distributed Database Systems. Prentice-Hall, [12] E. Pitoura. A Replication Schema to Support Weak Connectivity in Mobile Information Systems. In Proc. of 7th Intl. Conf. on Database and Expert System Applications (DEXA), sep [13] E. Pitoura and B. Bhargava. Building Information Systems for Mobile Environments. In Proc. of 3rd Intl. Conf. on Information and Knowledge Management, nov [14] A. Sheth and J. Larson. Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. ACM Computing Surveys, 22(3): , September [3] G. Gardarin, B. Finance, and P. Fankhauser. Federating Object-Oriented and Relational Databases: The IRO-DB Experience. In Proc. 2nd Intl. Conf. on Cooperative Information Systems CoopIS 97. IEEE Computer Society Press, 1997.