D-Lib Magazine
October 1998
ISSN 1082-9873
Middleware for Digital Libraries
Jean Bacon
Jean.Bacon@cl.cam.ac.uk
University of Cambridge
Computer Laboratory
Pembroke Street
Cambridge CB2 3QG, UKRichard Hayton
APM Limited, A subsidiary of Citrix Systems, Inc.
Poseidon House, Castle Park
Cambridge CB3 0RD, UKKen Moody
University of Cambridge
Computer Laboratory
Pembroke Street
Cambridge CB2 3QG, UK
Abstract
We describe how distributed applications are supported at present by middleware and show that extensions are needed if new types of application are to be supported effectively. We have worked on middleware extensions in the areas of asynchronous operation and security. The former allows a system to respond immediately to the occurrence of asynchronous events, such as the detection of a mobile user or the withdrawal of access rights from an individual.
We describe our security architecture, Oasis, which runs on a middleware platform extended for asynchronous operation. Oasis is concerned with the secure interoperability of independently developed services. For scalability, an Oasis server may name its many users in terms of a number of roles; access rights are associated with roles. Entry to a named role of a service can be specified as being permitted only for those that can prove they belong to other named roles of this and/or other services. Our work is wide in scope, being applicable to many human organisations which have multi-service information systems. We use the provision of Digital Library services by universities as an example of a domain that poses many of the problems we aim to solve.
1.0 Introduction
Middleware platforms were designed in the late 1980s to meet the distributed processing needs of the computer industry, but the recent rapid evolution of technology has caused an explosion in distributed processing requirements. Developers of new applications now routinely expect support for multimedia and mobility of users and computers. Timely response to asynchronous events is crucial for such applications and is not yet adequately supported by current platforms; our extensions for asynchronous operation address this problem.
Secure interoperability of independent services in large scale, widely distributed systems remains an underlying need of both existing and emerging applications. The need for cross-organizational, cross-domain interactions arises from the nature of human organizations such as universities, public bureaucracies, hospitals, etc. The information systems must handle large numbers of users, be easy to use, internally efficient, secure, trustworthy, reliable and robust. Moreover, independently developed services must be able to work together with minimal extension. We have designed an open architecture for secure, interworking services (Oasis) to meet these requirements.
The provision of Digital Library services by universities poses many of the issues outlined above. There are many users in various categories: undergraduates, graduate students, lecturers, administrators, librarians. There are independent administrative services for registration and accounting, and each library service may have its own policy regarding who may use it and in what way. The libraries need to establish that their users are recognised by the university's administrative services. If the university has several campuses, there is a need to federate the services. Finally, the university may have negotiated access to external Digital Libraries (DLs).
We set the scene by describing the established model for distributed software that allows services to communicate. We then show how this middleware needs to be extended to meet the needs of new applications. Finally, we show how independently developed services may interoperate using Oasis, taking Digital Libraries as the main example.
2.0 Established support for distributed applications
Distributed applications should be able to run on a variety of hardware and operating systems. Middleware is a layer of software that makes this possible; it runs above such heterogeneous operating systems and communications systems and provides a uniform interface to distributed applications. We outline a general framework for distributed software which is compatible with current platforms, then highlight issues not fully addressed for emerging applications, including Digital Libraries.
2.1 Distributed software model
Whatever the physical architecture of a distributed system, we need to establish principles for designing and engineering the distributed software that is to run on it. The software model defines the entities that comprise the distributed system, how they interoperate and how their behaviour is specified. An object model is a realistic basis for software system design, including persistent data management, and underpins all recent middleware platforms. An object model implies data-driven software design. The types of data needed by the application are defined, and the operations (often called methods) that may be carried out on each data type are specified. The data is encapsulated with its type-specific methods to form an object, and may only be accessed through them. The specification of the methods, their names and arguments, indicates how to invoke the object and is called its interface.
The broad applicability of an object model comes from this separation of interface and implementation. A standard for specifying object interfaces allows distributed, independently developed, heterogeneous objects to be composed into a system. For example, the Object Management Group (OMG) and Object Data Management Group (ODMG) provide widely accepted, compatible, standardisation for both transmitted and stored data objects [corba95, cattell97]. Objects are defined using a standard Interface Definition Language (IDL) which allows object names, method names and their arguments to be specified in terms of IDLs, base types, and constructors. OMG-CORBA and ODMG support many programming language bindings; that is, software components may be written in different programming languages yet may interoperate.
2.2 Architecture
The software architecture defines how the communicating entities are named, located and protected:
Principal
A principal is an entity which is capable of initiating actions and to which access rights may be assigned. The general term principal includes an authenticated, logged-in user, a process acting on behalf of such a user, any process executing some named program, etc.
Service
A service is offered by one or more servers. A server is an object which carries out operations in response to requests from principals (its clients). A service may function as an object manager for objects of a specified type.
Naming and name-to-location binding
Name to location binding is a core function of middleware. It may be provided transparently as part of platform services or as a specific system service. Any service must be able to name the principals that may use it. Each domain in a distributed system (see below) is likely to register its users and allocate identifiers to them. In many systems logged in users, named by user-ids, are the only principals. We retain user-ids as the names defined by the registration and login services but allow other services to define names that reflect the roles of their clients. For example, a logged in user may be named "librarian" when using the DL service.
System services
Some services have generic roles in a system. For example, the interface specification of a service may be published in a name server (sometimes called an Interface Trader). An authentication service may be provided which is likely to be based on public keys associated with principals. Specific services may be associated with applications such as banking or Digital Libraries.
Access control
Access control is most naturally associated with individual services; each service should be able to specify which principals may use it and in what way; this assumes that principals may be identified, and their names are available and persist. If the service is an object manager, protected access to objects must be ensured; means of expressing and enforcing access policy must be provided. We expand on this throughout the paper.
Independent administrative domains
Distributed systems are partitioned into domains which reflect administrative and management responsibility. Domains also provide the means by which scale is managed. For example, the communications services which underpin distributed systems platforms are managed by the Domain Name Service in which nested management domains are defined. A distributed application may exist in a single domain. For example, an automated diary and room booking application may operate only for a single University Department. More generally, an application may need to operate across multiple domains; for example, the information system provided by the World Wide Web.
Digital Library Services may span many administrative domains; for example, a university may have several independently managed campuses, each with several DLs. Any user may wish to access DLs within the local domain, university-wide, or world-wide external.
Middleware platforms are designed to cope with heterogeneity; the world will not restrict itself to using a single hardware platform, operating system or programming language. It is also unrealistic to assume that a single middleware platform will come to dominate; in fact, the major players in the area are committed to supporting interoperability between their platforms.
3.0 Support for emerging applications
If they are to support emerging applications, current middleware platforms require extension in two major areas: security and asynchronous operation.
Security
An access control scheme based on a distributed system model, which is a flat space of objects with access permissions specified for individual objects in terms of users as principals, is inadequate; it does not scale for large numbers of objects and users, and does not capture the relationships between services. Taking a university example, any registered student may be allowed to use the university DL service where access permissions are specified for broad categories of stored object.
Independently developed and managed services need to cooperate, but mutual trust must be limited. An access control architecture should impose as little as possible on each service while allowing secure interaction between services. Services that run in different management domains need mechanisms that allow them to negotiate and interoperate. For example, a student registration service, the DL service on the campus local to it, and a remote DL service at a research institute may all be involved in negotiating access rights for broad categories of user.
Asynchronous operation: events
The model on which existing platforms are based is of synchronous method invocation; an object sits there passively until some principal performs an operation on it. This is inadequate for many current and emerging applications where asynchronously occurring events should trigger immediate system response. For example, a withdraw (credit-card-id) operation at a banking service may remove the record associated with that card at that service and add the card to a hot-list. If the withdrawal is because the card is being used fraudulently at this moment, it is not ideal to have this information sit in a data structure -- it should be notified automatically to affected services. We are concerned with providing efficient system mechanisms to achieve this style of notification.
If synchronous method invocation is all that's available, periodic polling can be used to test whether some event has occurred. We then have a dilemma. Frequent polling for all such events overloads communications. Infrequent polling means delaying the response to individual events, so that the application is perceived as sluggish and inadequate.
Group interaction. Suppose a participant in an online conference draws on a shared whiteboard object. The rest of the conference should be able to see the drawing immediately.
Multimedia support. Control of multimedia may be modelled partly as synchronous method invocation. For example, objects of type video have methods pause, restart, fast-forward, .... But these invocations may trigger and be triggered by asynchronous events. For example, "when the user clicks on a person on screen as a film is shown, invoke the pause method on the video object and show details of the person in a new window".
Mobility. Mobile users and computers will detach from networked systems and reattach later at some other location. For office applications, users will be detected as they move about by means of an active badge or similar infrastructure. Mobile and remote users may connect to several DLs, not merely the home sites at which they are individually registered. Detection of a mobile user or computer is an event that may require a response from the system.
Exceptions. Security violation, system overload, the occurrence of an emergency medical condition in a patient, component failure in a network, a stock market crash, are events that require rapid response. A DL user may be detected in some malpractice which requires immediate termination of access.
Management. Network and system management servers must be notified instantly when faults, heavy loading or resource allocation problems occur so that they can take immediate action.
We have worked on two major interrelated themes which subsume all of these issues: an open architecture for secure interworking services (Oasis) and provision of support for asynchronous operation by means of events, event classes, and events as object instances. For example, an event of type seen may have data attributes person, location. Event objects are simple and require few methods other than those to allow their data attributes to be read.
Oasis has obvious application to the provision of Digital Library Services as we show below. Although Oasis may be built above a synchronous platform, asynchronous operation allows immediate response to events such as withdrawal of access rights from an individual or failure of communications or services. Our implementation of Oasis is, therefore, built on a middleware platform extended with events.
4.0 Access control requirements for Digital Libraries
Gladney [gladney98] selects a number of issues relating to access control that must be addressed if Digital Library (DL) services are to be provided widely and used with confidence:
Scalability
The means of access management must be scalable to large numbers of low unit cost interactions, large numbers of users, immense collections, and constantly changing human relationships.
Independent expression of access control policy
Different resource custodians want different access rule schemes; we can, and should, permit flexible rules of access, without exposing the inherent complexity to end users or administrators who are not interested in the "plumbing".
Support for classification of content
Libraries differ from piles of books and papers because librarians oversee collection development, selecting only holdings within their institutional missions and of known authenticity and provenance, and organize what they select with catalogs and other means; access management systems must help administer the achievement of such values, which cumulatively make for the quality of the collections.
Overhead mainly on initial connection
Repeated, lengthy procedures to establish a user's right to use different DL services are undesirable. A procedure to establish credentials is acceptable on the first connection to a DL service in a network session.
Automation of procedures
Interruptions to provide information needed by access management are a distraction for end users -- a distraction which can and should be avoided; similarly, service administrators will not be able to deal with individual grants of authorization for each of many thousands of users.
Administrative integration
Authorization for library services must fit within other administrative processes, such as university student registration.
5.0 Events for timely response
As outlined above, many emerging applications need asynchronous as well as synchronous operation. Our work has shown how any of the widely used platforms such as OMG CORBA, Java RMI, or Active/X can be extended, very simply, to support asynchronous operation. The extension required is that any object, as well as publishing its interface in the standard way using IDL, can also publish, using IDL, the events it will notify to clients if asked.
Such an object has a register method in its interface and interested parties may register interest in any event, specifying parameters or wildcards. Event occurrences are created as objects of specified type. Events may therefore be named and parametrised at a fine grain, using the full range of IDL types, and notified at this granularity.
Access control is needed at event registration; a client without appropriate authority may not be allowed to register. When an event occurs, the service matches it against a stored template associated with each registration and notifies all parties, whose templates are matched, of the event that has occurred. Figure 1 shows the scheme; more details can be found in [sdne95]. Section 6.3 discusses further the filtering of notifications that may be needed for access control purposes.
Figure 1. A publish, register, notify event architecture.
The object publishes its interface, specified in IDL, in the usual way, including the events it will notify. A client may invoke the object synchronously, as usual, and may also register interest in events indicating parameters or wildcards. Events which match the registration template are notified asynchronously to the client.
A detailed study of how this event extension has been added to CORBA, to support asynchronous notification, is given in [usenix98]. Support for mobile users and computers is described in [ieeePC97, nomad96].
6.0 Oasis, An open architecture for secure, interworking services
In outline, Oasis allows each service to define access rights for broad categories of its users. A service may define its categories in terms of those of its own and other services. While using a service dynamically, a client holds a certificate which proves its right to do so and which may be revoked at any instant as a result of inter-service notification. More detail follows.
Each Oasis service is made responsible for the classification of its clients into named roles. Examples are: a Login Service may define the role logged-in-user with parameters (user-id, machine-name); a Patient Monitoring Service may define roles surgeon, doctor, nurse, patient with appropriate parameters; a Conference Service may define roles member, chairman; an Examinations Service may define roles candidate, examiner, chief-examiner; a Digital Library Service may define roles reader, librarian, head-librarian, administrator.
A role definition language (RDL) is provided so that services may specify precise conditions for clients to enter each role. RDL is in fact a formal logic based on Horn clauses. A client becomes authenticated by presenting "credentials" to a service that enable the service to prove that the client conforms to its policy for entry to a particular role. Figure 2 shows the general idea.
Figure 2. Authentication for entering a role. An enlargement of this figure is available.
For example, to become a candidate for an online examination in computing, you must certify securely that you are a registered student on the computing course, that you have paid your fees, and that you are logged in at a computer in the correct location at the correct time. Similarly, to use a university DL you must certify securely that you are a registered student, that you have paid your fees and that you have logged in successfully your used-id, machine-id and location are available to the DL service.
An authenticated client is issued a role membership certificate (RMC) to present with subsequent requests to use that service. An RMC is an encryption-protected capability which includes the role name, the identity of the principal to which it was issued and a reference to the issuing service, see Figure 3.
Figure 3. A Role Membership Certificate (RMC). The signature field is computed by applying an encryption function to the fields of the RMC which are to be protected from tampering together with a secret (random number) held by the issuing service.
So, to use a DL you must acquire an RMC for the named role reader. To achieve this, the DL service specifies in RDL that you must present: your RMC as a registered-student issued by the Registration Service, your RMC fees-paid issued by the Accounts Service, your RMC logged-in user (user-id, machine-id) issued by the Login Service. You pass your reader RMC with each request to the DL service.
An Oasis service maintains a credential record associated with each RMC it has issued. The credential record reference (CRR) in an RMC, see Figure 3, is used by the service to select the corresponding credential reference. We have seen that a proof rule of one service may refer to an authenticated user of another; that is, an RMC issued by one service may be required as a credential during authentication by another. As part of the authentication process, a data structure is set up that embodies the proof. This data structure spans the services involved, and communication channels are established between them; the related credential records are linked together. The data structure is a dynamically maintained proof tree which exhibits, among other things, the trust relationships between the services on which client entry to named roles depends.
For more information on Oasis, see [oakland98], where RDL is specified and examples are given; the data structures which maintain the dynamic proof tree are described in detail. Delegation of rights is also discussed and its implementation described.
6.1 Comparison with other capability schemes
There are many encryption protected capability schemes for use in distributed systems. The basic idea is that the service issuing the capability computes a signature for each capability which is the result of applying an encryption (one-way) function to the fields of the capability which are to be protected together with a secret random number, which is never transmitted. The signature is a field of the issued capability.
The principal must present the capability with any subsequent request for service. On such a request, the service performs the computation again and checks that the resulting digits are identical to the signature field in the capability. If the check succeeds, the protected fields of the capability have not been tampered with and the access may go ahead.
The Oasis scheme differs from traditional capability-based access control in a number of ways. First, it is principal-specific, as suggested by [gong89]; that is, the RMC contains the encryption-protected name of the principal. It is therefore protected from theft by other principals, such as by network tapping.
More novel is that RMCs are dynamically maintained. The RDL for acquiring an RMC indicates which conditions must remain true for the RMC to remain valid. Should such a condition become false, this may be signalled immediately to the RMC-issuing service, and the RMC may be invalidated instantly. Figure 2 shows the channels that are set up on authentication for signalling such violations. For example, if you are sent down in disgrace and are no longer a registered student, not only is your registered-student RMC revoked by the Registration Service but this service signals the DL service which immediately revokes your reader RMC; access to documents can be withdrawn from you immediately if that is the DL service policy. Selective and immediate revocation at the granularity of a single capability has not been achieved by other capability schemes.
6.2 Interdependence of Oasis and events
It will be seen from the previous section that Oasis is built above our asynchronous event infrastructure. During authentication of a principal into some role of a service, the service will interact with any other services that are specified in the role entry conditions. First, each RMC presented as a credential must be checked by the service which issued it using the encryption check described above. If all is well, event channels are then set up between the services via the publish, register, notify mechanisms described in Section 5 and Figure 1. As we have seen, notification of a security exception achieves immediate invalidation of any dependent RMCs.
Oasis may be used in systems where an asynchronous infrastructure is not available. In this case, each time an RMC is presented to a service, it may check with the services on which this RMC depends that the conditions against which it was issued still hold. This is less efficient in terms of computational cost and network usage. We discuss this further in Section 7.
6.3 Independence and interrelation of Oasis-conforming services
Some services will define Oasis roles (Oasis role-servers) and some may not, yet still be Oasis-aware. The latter type of service may wish to control which principals may use it in terms of RMCs issued by Oasis role-servers. This applies to both synchronous invocation and asynchronous registration and notification. Any service can specify that an RMC is presented as a parameter of synchronous method invocation. It may also specify that an RMC must be presented as a parameter of the register invocation. For example, a reader in a conventional library may be allowed to register interest in the whereabouts of any librarian. A service may ask an RMC-issuing service for an RMC validity check at any time, but see Section 7 for further discussion.
Access control may need to be carried out both on registration and on notification. For example, if the registration is "tell me everyone who enters the conference room", SEEN(*, conference-room), it might be that you are allowed to be told about some matching instances but not others. Access control checks may require access to a naming database; for example, a candidate for a particular examination may not be allowed to register interest in the whereabouts of the examiners for it. It is not immediately apparent that a student registering SEEN(person,*) is such a candidate and that the person specified is such an examiner.
The format of RMCs is quite general since they are designed to be used by many interworking services that require different numbers and types of parameter, as shown in Figure 3. In particular, each service is at liberty to use a different mechanism for signing its certificates. This allows the designers of each service to make appropriate tradeoffs in terms of signature length, computational cost, and security.
An application wishing to verify an RMC must present it to the issuing service. This will then validate the signature, to ensure that the certificate has not been tampered with, and check the client process's identity. The issuing service will then examine the credential record reference. This contains the identity of a record within the service that indicates whether the certificate has been revoked. The issuing service will then inform the client application of its decision.
As the integrity check against modification and the check for revocation use different techniques, an application is at liberty to record the fact that the result of the cryptographic check at the issuing service was successful. If subsequently the same certification is presented again, it is only necessary to validate the credential record reference. Indeed, as we have seen in Section 6.2, if the application expects to perform this check repeatedly, it may instead ask the issuing service to notify it if the state changes. This can considerably reduce the amount of network traffic, and reduce the access latency of authorization checks. This is particularly significant when one Oasis service wishes to communicate with another. Typically, this occurs when one service wishes to revoke certificates it has issued, should certificates issued by some other service be revoked.
7.0 Distributed implementation issues
A fundamental characteristic of distributed systems is that nodes and links may fail at any time. Components of a distributed software system may fail, or become unreachable but continue to work, and we cannot be certain which is the case.
Recall that Oasis servers cooperate dynamically to prove that authentication conditions remain true. The absence of a condition violation notification from one Oasis server to another means either that the condition is still true (all is well) or that there has been a failure in the relevant service or its connection. In this case, the condition might have become false, but the notification cannot be sent or received. For this reason, we use a heartbeat protocol between the Oasis servers concerned. The period at which a heartbeat is sent is tuneable pairwise between servers. In the absence of an expected heartbeat, each server may define its own action policy. A server with high security requirements might suspend the affected RMCs until heartbeats resume.
There is scope for optimisation here in that cooperating servers need a single event channel between them for heartbeats rather than a channel for each branch of each proof tree. Tradeoffs can also be made taking into account the frequency of use of RMCs at a server. Heartbeats may be less efficient than polling if there is a very low rate of presentation of RMCs at a service.
8.0 Meeting the requirements of Digital Libraries
We have shown in general terms how secure interoperation of independently developed services may be supported under the Oasis architecture. We have also shown that an object-oriented platform may be extended, very simply, to include asynchronous as well as synchronous operation and how Oasis may exploit this functionality if built above an extended platform. We now return to the requirements of Digital Libraries described in Section 4.
Scalability
Large numbers of users are managed efficiently by categorizing them into roles such as reader, librarian, chief librarian, administrator. Access control policy may be defined in terms of this small number of roles although fine-grain expression in terms of individuals may also be included in RDL expressions if required.
The access permissions for objects stored in Digital Libraries is specified in RDL. It may easily be arranged that objects share access control policy expressions. It is clearly non-scalable -- and unnecessary -- to be obliged to store an access control list with every object. Access is likely to be granted on the basis of a relatively small number of categories of object, although Oasis allows access control to be specified for individual objects if required.
Independent expression of access control policy
This is central to the design of Oasis. Each DL service may define its roles and express its access control policy in RDL independently of any other. For example, in a University context, one DL server may serve an undergraduate campus, another may serve a specialist research institute. Access may be made from within specified laboratories, general computing areas or student rooms. DL servers may each define roles appropriate to their locally registered users and may negotiate conditions for entry into these roles by clients who hold roles of other DL servers.
Support for classification of content
In an object oriented design, it is natural to define the rights of principals in terms of the rights to invoke methods or register interest in events. Rights such as add-object-to-collection, delete-object-from-collection, write-object-classification-attribute can be restricted to members of the roles librarian, chief-librarian. Members of the reader role may be allowed rights on specified sets of objects such as read, read-object-classification-attribute.
Overhead mainly on initial connection
When a client first uses a DL, it must establish its credentials for entering a role and acquire an RMC. This is presented with subsequent requests to use objects stored in the DL, and access will be allowed according to the object's access control policy. There is scope for optimisation by caching RMCs between logged on sessions. For example, librarians, administrators and many readers will maintain consistent patterns of use over long periods, and it may be possible to re-use cached RMCs.
Various scenarios are possible. In a university context, we assume that principals are registered in some domain where a record of their authentication information is held. A logged-in-user RMC is issued by an Oasis-aware service. DL services are assumed to have negotiated with such login services. In a non-institutional context, a home user may wish to use world-wide DL services. Such DLs may publish their services and costs. The design details depend on the specific context for DL use.
Inter-DL operation is based on negotiation between them. For example, once students establish their credentials for entering a role of their Departmental Library, the RMCs issued by that library should entitle them to enter a role of the University Library.
Automation of procedures
Possession of an RMC issued by a DL is sufficient to allow uninterrupted access to the DL. The first use of another DL is likely to require an explicit connect style of operation during which the policies negotiated between the DLs are checked, and an RMC for the new DL is issued. Uninterrupted use of the remote DL may then go ahead. Librarians and administrators are not involved in any of these decisions.
The procedure to remove access rights is also automated. Managers need only initiate a standard procedure for removing the access rights of an individual; perhaps a student is so late in paying fees that all rights are withdrawn; at the end of an academic year, the rights of all terminating students will be withdrawn. Perhaps a DL client is detected in some malpractice; for serious violations of the conditions of use of the DL, rights may be withdrawn immediately, or an exception report may be raised and appropriate action taken at the end of the current session, according to policy.
Administrative integration
Any service may be an Oasis role-server or Oasis-aware. Student registration and accounting servers may define roles and issue RMCs that are credentials for use of a DL. One may need to be an accredited rate-payer of a town in order to use its DL services.
9.0 Concluding remarks
We have built a prototype implementation of Oasis in the Computer Laboratory to establish proof-of-concept. Oasis is designed to be scalable to large numbers of users and objects, but a detailed, large-scale engineering design has yet to be carried out.
We would learn from such a project in many ways, both from setting up the Oasis architecture and from optimising the performance, once the basic interactions were in place. Oasis is designed for services which are under independent administrative control yet need to cooperate and interoperate over a long period of time. The challenge here is to achieve cooperation at a human as well as a software level. One can envisage various degrees of autonomy of services; those associated with a federation of institutes such as a university or an international company and those which are completely self-standing. A DL application provides all of these categories.
A substantial application, which includes independent but interoperating servers, will prove the practical application of the approach. Preliminary investigations suggest that Oasis fits the requirements of Digital Library Services admirably and that DLs provide an ideal testbed for Oasis.
Acknowledgements
We acknowledge the support of the UK EPSRC through grants GR/J42007 (Interactive multimedia presentation support) and GR/K77068 (Active systems), the latter in collaboration with Nortel Technology. Thanks to ICL for support of our research group. Thanks to members of the Opera research group for their contributions over the years to the work summarised here.
Bibliography
[sdne95]
Bacon J, Bates J, Hayton R and Moody K, Using Events to Build Distributed Applications, Proc. IEEE SDNE, pp 148-155, June 1995.[ieeePC97]
Bacon J, Bates J and Halls D, Location oriented multimedia, IEEE Personal Communications 4(5), pp 48-57, October 1997.[nomad96]
Bates J, Halls D, and Bacon J, A Framework to Support Mobile Users of Multimedia Applications, ACM Mobile Networks and Nomadic Applications (NOMAD), 1(4), pp 409-419, 1996.[cattell97]
Cattell R G, The Object Database Standard: ODMG 2.0, Morgan-Kaufmann 1997.[corba95]
OMG, The Common Object Request Broker: Architecture and Specification Revision 2.0, July 1995.[gladney98]
Gladney H M, Safeguarding Digital Library Contents and Users, Interim Retrospect and Prospects, D-Lib Magazine, July/August 1998. (http://www.dlib.org/dlib/july98/gladney/07gladney.html)[gong89]
Gong L, A Secure, Identity-based Capability System, Proc IEEE Symposium on Security and Privacy, pp 56-63, Oakland, CA, 1989.[oakland98]
Hayton R, Bacon J, Moody K, Oasis: Access Control in an Open, Distributed Environment, Proc IEEE Symposium on Security and Privacy, pp 3-14, Oakland, CA, May 1998.[usenix98]
Ma C and Bacon J, COBEA: A CORBA-Based Event Architecture, Proc USENIX COOTS'98, pp117-131, Santa Fe, New Mexico, USA, April 1998.Copyright © 1998 Jean Bacon, Richard Hayton and Ken Moody
Top | Magazine
Search | Author Index | Title Index | Monthly Issues
Previous Story | Next Story
Comments | E-mail the EditorD-Lib Magazine Access Terms and Conditions
hdl:cnri.dlib/october98-bacon
