4.4 Naming And Directory Services

1. 4.4 Naming And Directory Services CSC-8320 Lakshmi Narayana Gupta Kollepara 09/20/2009

2. Outline • Part 1 : Name & Directory Services • Part 2 : Recent Studies on COSA transformation • Part 3 : Future work

3. Name & Directory Services(Chow, Johnson, 1997) • Making a request to a service or accessing an object by means of interprocess communication requires that one must first locate the service or object. • Service are abstractions of objects. They are usually represented by processes with a service access point. • Object may be users, computers, communication links or other resources such as files.

4. Services and Objects are normally identified by textual names. Alternatively, if names are unknown, service or object entities can be described by using attributes associated with them. • Although services and objects have distinct meanings, their naming issues are similar • Name and Directory services, in a narrow sense are look-up operations. • The terms name service and directory service are often used interchangeably. (Chow, Johnson, 1997)

5. X.500, defined by CCITT, is an example of a directory service. • Resolution process – the operation of locating an object. • Resolution involves two stages: 1.Name resolution: Mapping of server name to its port address is an example of name resolution. 2.Address resolution: Mapping of a server to its Ethernet port is an example of address resolution (Chow, Johnson, 1997)

6. Object Attributes and Name Structures • In the context of name resolution, we are particularly interested in two special object attributes, name and address. • The collection of names, recognized by a name service with their corresponding attributes and addresses, is called a name space. • A name structure that uses only a single attribute for the names is called a flat naming structure. • Conceptually simple but unique naming is difficult to achieve without global coordination. (Chow, Johnson, 1997)

7. If a name is partitioned into several attributes, an ordering of attributes may be imposed. For instance, a user with a name attribute <chow>, an organization attribute <ufl>, and a country attribute <us> may form a compound attribute <chow.ufl.us> as the name attribute. [popularly used by the DNS service] • In more general case without an ordering of the attributes, an object can still be referred to or located by specifying a collection of attributes, such as <(U=chow, C=us, O=ufl)>. • The following figure gives a better view of these name structures. (Chow, Johnson, 1997)

8. Naming Structures(Chow, Johnson, 1997)

9. Name Space and Information Base • Using X.500 terminology, the conceptual data model for storing and representing object information is called the Directory Information Base (DIB). • The Directory Service (DS) of the CCITT X.500 standard provides structural and syntactic rules for specifying a DIB in a hierarchical Directory Information Tree (DIT). • A large name space and its corresponding DIT can be decomposed and distributed into naming domains and naming contexts. • Naming contexts are the basic units for distributing the information base to Directory Service Agents (DSAs), which are the servers for the name service. (Chow, Johnson, 1997)

10. X.500 (Chow, Johnson, 1997)

11. A name resolution process is initiated by a Directory User Agent (DUA), working on behalf of a user process. • The resolution request is sent from one DSA to another until the object is found in the DIT and returned to the DUA. • Whether the resolution scheme is structured and name-based or structure-free and attribute-based, the interaction among DSAs can be in one of the four modes shown in the following figure. (Chow, Johnson, 1997)

12. X.500 (Chow, Johnson, 1997)

13. Techniques to enhance the performance of name resolution • Caching and replication. • Recently used names and their addresses can be kept in a cache to reduce the need for name resolution. • Naming contexts can also be duplicated in different DSAs to shorten the resolution path. • Finally, object entries in a directory may be an alias or a group. • Aliases and groups are pointers to other object names and are leaf nodes in the DIT. • They add flexibility in naming for users of the name/directory services. (Chow, Johnson, 1997)

14. A name service is a key component in every distributed system. • For cooperative autonomous systems, the name service must be extended to support a communication infrastructure for identifying and locating all autonomous objects in the system and managing connection and delivery of data between objects. • The Object Request Broker (ORB) is such a central facility in the CORBA architecture for cooperative autonomous systems. (Chow, Johnson, 1997)

15. Part 2 : Recent Studies • An Automatic Transformation from COSA Software Architecture to CORBA Platform (Alti et al. , 2008) • Middlewareas an abstraction layer is completely integrated in development environments for resolving heterogeneity and guaranteeing the transparency communication of distributed components. • An automatic transformation from COSA (Component-Object based Software Architecture), which is a software architecture model that describes systems as a collection of components and connectors, to a standard platform - CORBA.

16. The goal is rapid mapping and smooth integration of COSA concepts into CORBA middleware platform in order to achieve a higher level of abstraction. • CORBA is a standard platform that simplifies the development for other platforms. • Middleware is integrated in CORBA platform as abstraction layer for resolving heterogeneity and facilitating communication and coordination of distributed components. • The main benefit of the profile transformation is a higher abstraction level of MDA platform and more quick integration of architectural concepts within MDA. (Alti et al. , 2008)

17. Advantages of transformation of COSA to CORBA - Fast mapping and smooth integration of most of COSA concepts especially the concepts that are not defined explicitly such as connector, configuration, roles, to achieve a complete MDA framework. - Satisfying a higher level of abstraction for CORBA platform by adopting high abstraction level from COSA UML Profile. • Automatic elaboration rules at the transformation process by using the same UML meta-models • (Alti et al. , 2008)

18. Part 3 : Future work • Future work can be mapping at the meta-meta level, i.e. from an architectural meta-meta model into MOF (Meta-Object Facility). (Alti et al. , 2008) • Also transformation of COSA towards other middleware plat-forms (e.g. EJB, .NET, etc.). (Alti et al. , 2008) • The integration of COSA + behavioral concepts (Alti et.al, 2007) in the MDA platforms to achieve a complete MDA framework.

19. References • Randy Chow,Theodore Johnson, “Distributed Operating Systems & Algorithms”, 1997 • Alti, A., Djoudi, M., and Smeda, A. 2008. An automatic transformation from COSA software architecture to CORBA platform. In Proceedings of the 8th international Conference on New Technologies in Distributed Systems ).  Link • Alti, A., Khammaci, T., Smeda, A. Using B Formal Method to Define Software Architecture Behavioral Concepts, IRECOS Review, 2(5), September 2007, pp.510-519.

20. Thank you Brainstorming and Comments…