A Type Management System for an ODP Trader J. Indulskaa, M. Bearmanband K. Raymondc acrc for Distributed Systems Technology, Department of Computer Science, University of Queensland, Brisbane 4072, Australia bcrc for Distributed Systems Technology, Faculty of Information Sciences and Engineering, University of Canberra, Bruce, ACT 2616, Australia ccrc for Distributed Systems Technology, Centre for Information Technology Research, University of Queensland, Brisbane 4072, Australia In order to use services available throughout an open distributed system, there must be a common understanding of the nature of those services. Also there must be a provision for system evolution, i.e. smooth replacement (without recompilation of clients applications) of existing services by their newer versions. Therefore, type description and type management functions are required to facilitate the dynamic service matching performed by an ODP trader. Also federation of traders should be supported. This paper examines the trader s requirements and presents a type model which is sufficient for those requirements. The model includes types and type relationships which are basic for ODP applications. Type descriptions and type relationships are used to find compatible service types in an open, multi-lingual environment. The paper also presents a type naming scheme and addresses the problems related to the federation of traders. Keyword Codes: C.2.4; D.2.6 Keywords: Distributed Systems, Programming Environments 1. INTRODUCTION Open distributed processing extends the OSI concept of openness in communication to openness in distributed processing, and must allow multi-vendor interoperability of distributed applications. The Basic Reference Model of Open Distributed Processing (RM-ODP) [9] is currently being developed as an international standard by ISO and CCITT. Its goals are to develop a framework which can support: interworking of heterogeneous systems and administrations, distribution transparencies, to mask the consequences of distribution,
portability of applications. The scale of open distributed processing is very large, and can even be world-wide. Within an open distributed system, there are many services available and the set of available services changes as the system evolves. Therefore, there must be mechanisms for both: selection of a service appropriate to an application s needs, and binding a client with the selected service at run-time. RM-ODP [9, 10] introduces the: trading function which is responsible for selecting services based on their types and other user requirements, and binding function which binds clients with servers at run-time. The trading function is implemented by objects known as traders. A server can advertise (export) its service within a trader. A client can request the trader to scan its advertisements to select services (import) that match the client s needs. Services are offered through interfaces (sets of operations). RM-ODP defines the concept of a computational interface type, which describes the signature and computational behaviour of a service. Selection of services through the trader involves the matching of interface types, but this alone is not sufficient. Many aspects of a service are not captured through a description of computational behaviour, e.g. cost and quality of service. These additional aspects are called service properties, and are usually drawn from non-computational specifications. Therefore, a service is described by its interface type and its service property values. In order to use services and information available throughout an open distributed system, there must be a common understanding of the nature of those services and information, independent of their representation or provision by a particular computer system. A type management system is required to describe and relate the types of services and information within an open distributed system. Type checking and type matching at run-time are facilitated in the RM-ODP infrastructure by the ODP functions [9,10]: the type description function, which provides a means to describe and compare types, and the type management function, which provides a means to record type names and their relationships. The term type manager is used in this paper to describe a type management system that provides the functionalities of the type description and the type management functions, required for dynamic checking and matching of types. An ODP type is defined by a predicate [9,14], allowing very general classification of objects. In addition to the common data typing required in programming languages and object-oriented databases, ODP is interested in types of behaviour, e.g. the types of operations and interfaces, and the types of services created from interfaces. An ODP type model must therefore allow descriptions of interface types and service types, and relationships between these types. In fact, the type model should be general enough to allow any predicated type to be described.
Since an ODP system facilitates cooperation of autonomous and independently created distributed systems, its type model should be able to express any type which can be defined in any specification or programming language. It also needs to reflect some features (e.g. subtyping) of the type systems used in specific languages whenever such features affect type matching during dynamic service selection or run-time binding. In particular, the type system has to support two forms of polymorphism: inclusion polymorphism to allow services to be replaced by compatible versions at runtime, parametric polymorphism to support the creation of generic functions. An ODP system must also support the merging of independent systems, which requires the federation of its infrastructure components (e.g. traders). An ODP type management system can support federation by providing a uniform model for information and services and a means to record type relationships. The main clients of the type manager are the ODP infrastructure (mainly the trading and binding functions), applications and application developers. The type manager supports all aspects of dynamic selection of services, binding among interfaces, and type checking during remote procedure invocations. However, in this paper, we focus only on the service type checking and service type matching required by an ODP trader. 2. TRADER S REQUIREMENTS OF TYPE MANAGEMENT A trader needs type checking and type matching facilities to ensure that: services and service properties, advertised or requested for trading, conform to the service type description, service types are checked for compatibility before selection can take place. A trader can only trade services known to its type manager. For each service type, there is a corresponding interface type, which is also known to its type manager. In addition, the type manager maintains a set of relationships over its interface types and service types. The relationships include super/sub-type relationships. When a trader receives a service offer (an export), it checks with its type manager that it is a known service type and the service properties expressed in the service offer are valid. Service offers are stored in a trader database. When a trader receives a service request (an import), it checks with its type manager that it is a known service type and the service properties in the matching constraints are valid. Using the service type of the service request, a trader finds from its type manager the list of service types that are compatible (sub-types) with the required service type. The trader uses the returned list to match service offers from its database. 3. TYPE MODEL This section presents a type model sufficient for an ODP trader. The trader will require a means to name and describe types, and to record relationships between types, leading to the development of type hierarchies.
3.1. Types The main function of our type manager is to enable selection of services in an ODP environment. Therefore, interface types and service types are of primary concern to the type manager. An interface is an abstraction of the behaviour of an object. An object can have many interfaces. An interface is an instance of an interface type. Interfaces that are instances of the same operational interface type have identical computational behaviour and operational signature. Interfaces that are instances of the same stream interface type have the same stream signatures and details of information transmitted or received such as format or coding. A service is a function provided by an object at a computational interface [10]. Every service is an instance of a service type. Services that are instances of the same service type have identical interface types. Services also include service properties, and therefore the service type in our model is defined as an ordered pair (interface type, set of property types). 3.2. Type Description To describe service types and interface types, the type manager must be able to represent: operations included in interfaces, domains of parameters and results used in operations, and domains of service properties used in service definitions. Therefore, the following types are first class citizens which have to be recorded and maintained by the type manager: data types, consisting of basic data types (e.g. char, integer, real), constructed data types (sets, records, unions), operation types, consisting of: operation names, names and types of input parameters, names and types of terminations and results, semantics of the operations, operational interface types, consisting of: a set of operation types, semantics of the interface, stream interface types, consisting of: a set of information flow types (type of information passed and the direction of the flow), semantics of the interface, service types, consisting of
an interface type (including null value), a set of service property types (names and types). For clarity, operational and stream interface types have been shown as separate types. In reality, an interface type is a union of operational and stream interface types. Currently RM-ODP assumes only one interface in the service definition. There is no provision for describing services involving several interfaces. Although our model currently conforms to RM-ODP (only one interface per service), the model can be easily extended to multiple interfaces within a service. Many notations can be used to describe types. While application developers can use language-specific notations to describe types, interworking is generally simpler if a canonical notation is used. The type manager could support mapping between different representations, providing a means to record and relate types in a multi-lingual environment. Semantics of operations and interfaces can be described in many ways, for example, using pre- and post-conditions as in the language Z or using temporal ordering as in LOTOS. 3.3. Type Naming The types known to the type management system can be of the following kinds: universal, known in every domain (e.g. boolean), conformant, standardised in a given domain (e.g. operation types for FTAM), private, known only in a user s own domain (e.g. an employee s record type). The type manager must identify (name) types and the naming method should be scalable. Since the type manager has to be able to manage universal, conformant and private types, its naming domain can be divided into the universal, conformant, and private naming subdomains. Universal types, which are primitive types (e.g. integer, boolean) are immutable. They are chosen and named by international standardisation bodies. Conformant types are not fundamental in nature, but their extensive use within a domain has necessitated their standardisation within the domain. Only appropriate authorities can assign names and versions to conformant types within a domain. Private types are specific to a user who assigns names and versions within the user s private domain. Since types must be uniquely identified within a domain, each domain can be divided further into a number of sub-domains (contexts) to make the name space more manageable. 3.4. Type Relationships An ODP type manager should be able to understand relationships and to learn about new relationships at run-time. Only relationships important for a trader are described here. A trader needs information about compatible services, i.e. services which are in a subtype or an equivalence relation. Interface subtyping is defined in Part 3 of RM-ODP [9]. That is, if interface type X is a subtype of interface type Y, then the following conditions hold: X has all of the operations defined for Y and operations common for X and Y are of the same kind (announcement/interrogation),
numbers of parameters for each common operation are the same and types of parameters for each operation in X has to be in a subtype relation to Y, numbers of result parameters for each termination are the same and types of result parameters for each termination in Y has to be in a subtype relation to X. Our model extends the sub-type relationship to service types. For service type S to be a subtype of service type T, it requires: interface type of S is a subtype of interface type of T, each service property named in T to be also named in S, for every service property P named in T, the type of the corresponding property in S to be a subtype of the type of P. Note: Semantic substitutability is the only basis for subtyping of service properties. Subtype relationships between data types used to represent these service property types do not imply subtype relationship between service properties. A type management system needs to manage types expressed in different languages and/or created by different users. Such types are equivalent but are described using different notations and cannot be identified as equivalent by comparing their type descriptions. For instance, one user might use a service property of price while another uses cost, or two interfaces might be structurally the same and provide the same service but the names of their service differ. A type management system needs to record such equivalences. Many different equivalence relationships exist (structural, syntactical, semantic) [13]. However, the trader is interested mainly in the can be mapped relationships. The can be mapped relationships can be either symmetric, or asymmetric (e.g. marks can be converted into grades, but it is impossible to reverse this mapping). Exports and imports within a trader can be expressed in any type: private, conformant, or universal. In order to find matching types, the type manager must consider (recursively) both subtyping and can be mapped relationship. The type manager should be able to record relationships between any two types. To satisfy the trader requirements, the type manager has to be able to record and maintain the following relationships: subtyping of services, subtyping of interfaces, mapping between equivalent types, mapping between service and interface types. Relationships between pairs of types can arise by two methods: the user supplies this information, the type manager derives it from the type descriptions.
3.5. Service Type Hierarchies To make the service type space manageable from a user point of view, service types can be considered as a hierarchy of services based on functionality. In this hierarchy, the root and all the intermediate levels are virtual services described by properties alone (and the interface type is undefined). The leaves of the hierarchy are the actualised service types and their interface types must be defined. A service must be an instance of an actualised service type and, therefore, is an instance of all of the virtual service types which are ancestors of the actualised service type in the hierarchy. A service cannot be an instance of only virtual service types. This refinement of virtual services is a form of subtyping. For trading, an exporter must offer instances of actualised service types while importers can search for either virtual or actualised service types. Figure 1 shows an example of a service functional hierarchy applicable to a file service. For each of the actual (leaf) service types, further subtyping relationships can be applied as shown in Figure 2. Grouping services that are semantically similar, even if they are syntactically different, makes importing easier for a client, and also allows an application developer to readily browse for service types based on functionality, which is usually how a user views a service. File service (NULL: Inttype, access control: enum) File transfer ( NULL: Inttype, transfer rate: range, transfer mode: enum) File management (NULL: Inttype, access control: enum) File access (NULL: Inttype, cost : integer, access mode: enum) FTP (inttype-1: Inttype, transfer rate: range, transfer mode: enum) NFS (inttype-4: Inttype, access mode: enum) FTAM transfer (inttype-2: Inttype, transfer rate: range, transfer mode: enum) FTAM (inttype-3: Inttype, access mode: enum) Fig.1. A functional hierarchy of service types
FTAM (inttype-3 (read, write), access mode: enum) FTAM (inttype-6 (read, write, extend), access mode: enum) FTAM (inttype-5 (read, write), access mode: enum, shared access: enum) FTAM (inttype-7 (read, write, extend), access mode: enum, shared access: enum) Fig.2. Subtyping services 3.6. Types and Federation In a federation of traders, a user expresses its service requests using its local types even though a user could be accessing a trader with different type syntax and/or semantics. Thus, for traders in a federation to interwork, a common understanding of types and the relationship between types must be achieved. Federating traders either use different type managers, or use the same type manager. In the first case, the federation of traders requires prior integration of type managers. Federated type managers have a mutual understanding of universal types and those conformant types which they have in common. However, relationships between other types will have to be derived from known information or be established by human intervention. The type manager should provide tools to facilitate the establishment of these relationships. In the second case, since the trader can operate on all types which are known to its type manager, the situation is no different than for a single trader with users using private types. Services can be exported and imported using private types or using existing equivalence relationships to conformant types. An N-by-N mapping of all types between private domains is clearly undesirable. The mapping of private types to conformant types makes exporting and importing more efficient, because it reduces the number of mapping relationships maintained by the type manager. Such mappings to conformant types are also the preferred mechanism for federated traders using different type managers.
4. OPERATIONS The type manager creates and maintains a repository of types and their relationships, and supports run-time type checking and type matching. For a trader and its users, the type manager should provide the following functions: operations on types: add type description (private, conformant, universal), delete type description (private, conformant), list type description (private, conformant, universal), create sub-domain (private, conformant), delete sub-domain (private, conformant), list sub-domain (private, conformant), browse (for convenience of trader users). For example browse by service type (including virtual types), by service property types, by interface types, etc. operations on type relationships add/delete a relationship between specific types, type-check for validity of exports and/or imports, check if two types are in a given relationship (e.g. is X a subtype of Y), list all types which are related by a given relationship to a given type (e.g. what are the subtypes of X), add/delete/list a relationship type (relationship definition). Changes to the repository of types and their relationships cannot be performed if they introduce inconsistency to the repository. The operations performed by the type manager are constrained by the naming schemes and the features of relationships. For example, types have to be uniquely identified. Also, if a relationship is anti-symmetric, as in the the case of the ODP subtype relationship, the operation add relationship has to check that the anti-symmetry is not violated. Checking for violations can be expensive, especially when transitivity is involved. It could require searching the closure of the relation. The full specification of necessary constraints can be found in [5]. 5. RELATIONSHIP TO OTHER WORK The problems of describing types and using relationships between them (e.g. inheritance, subtyping) have already been addressed in many research projects related to distributed operating systems and distributed computing. Object-oriented programming languages exploit inheritance relationship between objects for resource reusability [7] and compatibility relationship for system evolution, i.e. smooth replacement of one object by a compatible object [3]. Large area networks and distributed operating systems use attribute naming to support service selection [4].
Problems in federation of object-oriented databases have also triggered work on the models and relationships between types[6]. Research on platforms for distributed computing e.g. ANSAware [1], DCE [12], OMG OMA [11], and Comandos [2], have addressed problems of dynamic resource selection and system evolution, which in most cases (ANSAware, Comandos, OMA) has led to a design of a type manager for the given system. The functionality of these type managers ranges from a minimal type manager in ANSAware to a richer type manager in OMG OMA (not yet implemented). The ANSAware type manager maintains a directed acyclic graph of type names related by a subtype relationship, with information about the relationship supplied by the users (see further discussion in the description of our prototype in section 6). The type manager in OMG OMA will store descriptions of object interfaces and subtyping relationships; this information will be extracted automatically from the specification expressed in the OMG Interface Definition Language (IDL). 6. DEVELOPING TYPE MANAGERS In this paper, we have described only the basic functionality of our type manager, sufficient to support service trading in an ODP system. Since some distributed platforms already exist, our first type manager prototypes will be embedded in existing platforms in order to introduce or enhance late binding facilities. One of our prototypes has been built for the ANSAware platform to replace its type management by an ODP conformant one. This ODP-based type manager uses a general relationship model; relationships are treated as types and new relationship definitions can be added to the type manager database, thus allowing various relationships to be managed (for example, different definitions of a subtyping relationship). Many relationships can be found between types; some distributed applications need to store and use information about such relationships. For example, the allomorphic relationship is used by system management [8], inheritance is used for resource reusability, and various equivalence relationships (structural, syntactic, semantic) can be used for deciding whether two types are compatible or convertable. However, from the ANSAware trader point of view, our prototype provides the same functionality as the basic ODP type manager. Our prototype maintains the description of types (whereas ANSAware stores relationship between type names only) and uses the ODP definition of subtyping which is more general than that used in ANSAware. In particular, our type manager allows subtyping of parameters and results. This type manager is also able to trade services, not only interfaces. That is, it has knowledge about service properties and service subtypes. While the type manager is able to extract the type description from the IDL language, the user is also able to add type descriptions. When relationships between two types are introduced to the database, the type descriptions are checked to ensure that the relationship holds. Another prototype is being built for the DCE environment. It is not an enhancement of an existing type manager, but is a completely new element in the DCE infrastructure. The introduction of trading and type management will enhance DCE s ability for dynamic service selection and system evolution. Apart from implementation, we are carrying out research on a powerful type model, which includes the full functionality of the type manager (e.g. rich browsing facilities), federation of type managers, and methods for semantic description of types.
7. CONCLUSIONS The requirements of a trader and its type management system have been examined and a type model has been proposed. The type model includes: types of behaviour, i.e. interfaces and services, relationships between types. The type description function and the relationship mechanism facilitate dynamic selection of services, by providing a trader/user with information about services and their compatibilities. The type management system also allows multi-lingual environment, by relating types expressed in one language-dependent form to another language-dependent form or to a canonical form. In addition, the functionality of the type management system has been presented. An ODP-conformant prototype has been built for the ANSAware environment. Work is being carried out on a prototype for the DCE environment and in the enhancement (regarding semantics) of the proposed type model to strengthen its expressive power. ACKNOWLEDGEMENTS The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the department of the Prime Minister and Cabinet of the Commonwealth Government of Australia, and by Telecom (Australia) Research Laboratories through the Centre of Expertise in Distributed Information Systems. REFERENCES 1. Architecture Projects Management limited, ANSAware 3.0 Implementation Manual, Document RM.097.00, January 1991. 2. R. Balter, Construction and Management of Distributed Office Systems Achievements and Future Trends, Proc. of the 6th Annual ESPRIT Conference, Brussels, November 27-December 1, 1989, pp. 47 58. 3. A. Black, N. Hutchinson, E. Jul, H. Levy, L. Carter, Distribution and Abstract Types in Emerald, IEEE Transactions on Software Engineering, Vol. SE-13, January 1987, pp. 65-76. 4. M. Bowman, L. Peterson, A. Yeatts. Univers: An Attribute-based Name Server. Software Practice and Experience, 20(4), pp. 403 424, April 1990. 5. W. Brookes, J. Indulska, Object-Z Specification of ODP-based Type Management. Technical report. University of Queensland (in preparation). 6. R.A. de By, H.J. Steenhagen, Interfacing Heterogeneous Systems through Functionally Specified Transactions IFIP DS-5 Workshop on Semantics of Interoperable Database Systems, Lorne, Australia, 16-20 November, 1992. 7. A. Goldberg, D. Robson, Smalltalk-80 The Language and its Implementation, Addison- Wesley, Reading, MA, 1983. 8. ISO/IEC 10165-4, Information Technology - Open System Interconnection - Structure of Management Information - Part 4: Guidelines for the Definition of Managed Objects, 1992. 9. ISO/IEC CD-10746.3, Basic Reference Model of Open distributed Processing - Part 3: Prescriptive Model, December 1992.
10. ISO/IEC JTC1/SC21/WG7/N743, Working Document on Topic 9.1 - ODP Trader, November 1992. 11. OMG and X/Open, Object Management Architecture Guide, Revision 2.0, September 1, 1992. OMG TC Document 92.11.1. 12. W. Rosenbery, D. Kenney, G. Fisher, Understanding DCE, O Reilly & Assoc. Inc, 1992. 13. A. Sheth, V. Kashyap, So FAR (Schematically) yet So Near (Semantically). IFIP DS-5 Workshop on Semantics of Interoperable Database Systems, Lorne, Australia, 16-20 November, 1992. 14. C. J. Taylor, Object-oriented Concepts for Distributed Systems, Computer Standards and Interfaces, 1993.