An Architecture for Composing Registries when ... - Semantic Scholar

An Architecture for Composing Registries when Ambient Networks Compose Fatna Belqasmi, John Mattam, Concordia University, Montreal, Canada Roch Glitho, Ericsson and Concordia University, Montreal, Canada Rachida Dssouli, Ferhat Khendek, Concordia University, Montreal, Canada Abstract- Ambient networks refer to a new networking

concept for beyond 3G. They use automatic network composition to enable dynamic and instantaneous interworking between heterogeneous networks on demand. Ambient networks can host several registries (e.g. management information bases, context information bases). When they autonomously compose, the hosted registries have to follow suit and compose. This paper focuses on the issues related to the autonomous composition of registries when ambient networks compose. We identify a set of requirements and propose a general architecture for autonomic composition. We also discuss cursorily information discovery after composition.

1. Introduction Ambient networks refer to a new networking concept for beyond 3G that enables the cooperation of heterogeneous networks belonging to different operators or technology domains [1]. Autonomic network composition, a concept that goes far beyond network inter-working as it is known today, is being explored in-depth in the context of ambient networks. This has led to several publications [2][3][4]. However, to date there has been no work on the composition of registries as part of ambient network composition. A registry is any authoritative store of information or repository of data. It can be centralized or distributed. It can store information of different types (e.g. raw/aggregated information) and different format (e.g. object oriented/relational database). It can also use different protocols and/or APIs for information discovery and publication (e.g. a P2P protocol, UDDI APIs). Some examples are web service registries, management information bases, and context information bases. Autonomous registry composition is very challenging. The differences between the registries to compose can cause different composition problems. In this paper, we focus on the definition of a general architecture for the composition of registries. We identify the requirements to be fulfilled by the composition solution and propose a novel architecture. We also discuss cursorily information discovery after composition. The next section gives background information on ambient network composition. The third section derives the requirements for registry composition and discusses related

work. The overall novel architecture is presented next. The fifth section provides the cursory discussion of information discovery after composition, followed by an illustrative scenario. Section 6 presents the implementation details. We conclude by identifying the items for future work.

2. Composing ambient networks An ambient network (AN) can be defined as one or more network nodes and/or devices that share a common network control plane called the Ambient Control Space (ACS) [2]. The ACS is the set of all the control functions and management tasks of the control layer (e.g. QoS, Mobility)(figure 1). The main AN interfaces are the Ambient Network Interface (ANI) and the Ambient Service Interface (ASI). The ANI enables communication between different ANs, and the ASI allows access to the services offered by the AN [3]. An AN can be any type of network, provided that it has a control space and the necessary interfaces [2].

Figure 1: Ambient network control space and interfaces AN composition enables dynamic and instantaneous interworking of heterogeneous networks on demand and in a transparent fashion, without manual configuration and offline negotiation. It also enables dynamic and automatic access to new services [2]. Three types of AN composition are possible: network interworking, control sharing and network integration [4]. In the first type, each network controls and manages its own components. With control sharing, some of the components of the composing networks are gathered into a new network. The composing ANs exercise joint control

1-4244-0667-6/07/$25.00 © 2007 IEEE

503

over the shared resources. In network integration, all of the participating networks merge into a new common composed network.

3. Requirements and related work

gateways that are created and configured offline, and so they do not enable on-the-fly composition and decomposition. For the same reason, they do not need composability verification and the requirement of composition duration is not relevant.

4. Our overall composition architecture

3.1. Requirements The requirements we have identified are divided into three categories: Requirements for what must be done before starting the registry composition process, requirements for the process itself, and requirements for what should be ensured after composition. Before the process (R1). It should be possible to verify the degree of composability of the registries. It may not be possible to compose them or the composition may be too costly. (R2). The verification process must take much less time than the composition process itself. The process itself (R3). The solution should allow for composition in a wide range of cases. In other words, non-composability should be the exception. (R4). The solution should support all three types of AN composition (i.e. inter-working, control sharing and integration). (R5). The solution should provide a fully automated composition (decomposition). (R6). The registries (de)composition process should not take longer than the other key processes (e.g. composition of functional areas) of network (de)composition. (R7). The solution should scale in terms of the number of networks that compose. After the process (R8). At the end of the (de)composition process, entities should still be able to discover and publish. (R9). After composition, decomposition should be possible and vice versa (R10). After (de)composition, the publishing and discovery policies of the composed registries should not be violated.

3.2. Related work Reference [5] describes the most advanced approach in the creation and composition of registries on the fly to facilitate interworking. It focuses on the connectivity between two nodes that belong to distinct and heterogeneous ad hoc networks. This approach does not address the composition of registries that already exist in the involved ad hoc networks. It supports only the interworking type of network composition and requires that the involved networks host the appropriate gateways that enable them to access each other. The verification of composability is limited to the availability of gateways. The approaches for network inter-working as known today somehow tackle the same issue but are less advanced. There are three approaches [6] to protocol inter-working: protocol conversion [7], protocol overlapping [8] and protocol complementation [9]. These approaches are based on

The architectural components are presented, followed by the overall procedure for registry composition

4.3. Architectural components

As part of our overall architecture, we add a new functional entity called the Registry Composition Entity (RCE) to the ambient network architecture. This entity is responsible for orchestrating the registries composition process and it communicates with the composition functional area of ambient networks. The composition functional area is responsible for the entire ambient network composition process. Figure 3 presents the functional entities that make up the RCE. Registry Composition Entity

Co-ordination Module

CA negotiator

Composition Agreement

Composition manager

Figure 3: RCE functional entities The co-ordination module enables inter-coordination between the different RCEs involved in the process. The Composability Checker checks the degree of composability of the registries and generates the composition agreement. First, the composability checkers must verify, for each registry, the protocol stack used for publication and discovery, the type of discovery approach used (e.g. centralized, peer-to-peer) and the information publication and discovery protocol (IPDP) used. Using this information, the different composability checkers then communicate through the co-ordination module to negotiate the composition agreement. The composition manager is responsible for executing the composition agreement.

4.4. Overall procedure for registry composition

Composition of the registries is initiated by the composition functional areas of the composing networks. Indeed, when the network composition reaches the stage where the registries must compose, each composition functional area informs the RCE of its own network. When the registry composition process is initiated, the RCEs check the registries’ composability and create the composition agreement to be executed by each RCE. Different solutions are possible for the creation of the registry of the composed network (i.e. the output of the registries’ composition), depending on the network composition type. With network inter-working, the composing registries are kept as they are. In the case of

1-4244-0667-6/07/$25.00 © 2007 IEEE

504

control sharing, a new registry (physical or logical) is created to store the shared resources, and the composing registries are kept to store the resources of their networks. For network integration, the solution can range from creating a single new registry to keeping all the composing registries. If the composition is permanent and the content of the composing registries is similar and relatively small, a new registry is created (or one of the existing ones is selected) and the content of the composing registries is copied to this registry. If this content is too heterogeneous, the first solution is used.

5. Cursory Discussion of Information discovery after composition Considering that after composition, the composed network may host several registries; these registries must communicate in order to respond to clients’ requests. One potential approach is to organize the different registries in a logical ring, where each registry knows the address of the next node in the ring. When a registry receives a discovery request and it does not have the information that the client is looking for, it forwards the request to the next node. If that node has the requested information, it responds to the originating registry. If not, it also forwards the request to the next node. Each registry adds its address to the request, before forwarding it to the next node. This procedure it repeated until the information is found, or the request reaches the originating registry. The registries are configured at composition time, to execute this extra step. Then, because different registries can use different IPDPs, the RCEs have to negotiate an interworking solution between the different registries as part of the composition. They also have to negotiate how to implement this solution on the fly. Inter-working between heterogeneous registries can be provided using two approaches. The first is to create a gateway(s) between the registries concerned on the fly. The other option is to deploy a common protocol on the fly to these registries. This can be either a standard protocol specified off-line, or one of the protocols supported by the registries, chosen during the negotiation. The first approach requires the ability to create the necessary inter-working protocols on the fly, or their existence in the network before composition. The second approach requires reconfiguring the registries to use the old protocol to maintain communication with the clients that use that protocol (clients must not be changed), and use the newly installed protocol to communicate with the other registries. The two approaches require on-the-fly deployment of protocols (e.g. deploy the common protocol to registries or inter-working protocols to the gateways). The choice of approach to use will depend on several parameters, including the existence of the inter-working and common protocols in the network and the possibility to install a given protocol (e.g. resources’ availability and security issues). Several distinct solutions can be developed, based on either of the two approaches. One example is to use the second approach to create an overlay network that will

support the common protocol and each of the IPDPs of the different registries. To communicate with each other, registries will use the overlay network.

6. Scenario John is a very busy businessman, who decides to take a vacation. He is visiting Paris for the first time on a guided tour in a bus. He also wants to keep up-to-date on the status of his business. So, he is often connected to the Internet using his laptop. Today, he received an important document that he has to review as soon as possible. To do this, he needs to get the document printed. Unfortunately, the moving network available in the bus does not provide such a service. However, his preferences and requirements for printing quality and format are added to his profile and stored in the moving network. During one of the bus stops, a wireless static network with a printer that provides a service that fulfils John’s printing requirements (figure 4) is available. Moving network (Net-1) WLAN

P1

Static network (Net-2)

P2

Figure 4: Registries composition scenario The two networks use distributed registries for storing information about the services provided and they use different discovery protocols; let us say P1 and P2. The registries’ composition is activated by the composition functional area when the networks’ composition is automatically initiated, once the two networks get close enough. When negotiating the composition agreement, the RCEs of the two networks determine that composition is possible. Indeed, using the interchanged network characteristics and some predefined policies, the two RCEs realize that in order to enable the inter-network service discovery, P2 must be deployed in the Net-1 registry. Furthermore, this deployment is deemed to be possible through some verification carried out by the RCEs. Next, the composition agreement is executed and the Net-1 registry prepares to communicate with the registry of Net-2. According to their policies, the discovery and use of Net2 services by Net-1 does not violate the discovery policies of Net-2 (nor those of Net-1). So, Net-1 automatically discovers the printing service, creates a connection between John’s laptop and the printer using the WLAN interface, the document is formatted using John’s preferences and added to the printer spool. John is informed that his document will be ready in 2 minutes and that he can pick it up before his bus leaves. He is also provided with detailed instructions so that he will find the printer.

1-4244-0667-6/07/$25.00 © 2007 IEEE

505

7. Implementation In this section, we focus on the information discovery after composition, and more precisely, in on-the-fly protocol deployment, especially since it is required by the two approaches to information discovery. We discuss how to deploy a new protocol, using mobile code and network programmability, and we present a software architecture that will enable this deployment. Next, we present a prototype implemented using this architecture. The proposed architecture is based on active networks and network programmability. Network programmability refers to the ability to inject executable mobile code into network elements (e.g. router, switch), to create new functionalities at run time [10]. Active networks are programmable networks and they are extensible at runtime [11][12]. They can enable on-the-fly protocol deployment. For this reason, we use them as the foundation for our architecture.

7.1. Protocol deployment on the fly To enable the automatic deployment of protocols, as part of facilitating inter-registry communication, we are proposing the following solution: for each network, we use a protocol server where we store the IPDP of the local registry, the standard protocol, and/or the interworking protocol(s) needed for gateway creation. We assume that the gateway solution is chosen only if the required inter-working protocols are available in the network (i.e. these are not created on the fly, due to the significant overhead that would be generated). When protocol deployment is needed, RCEs negotiate the protocol to deploy and use one of the protocol deployment approaches [11][12] provided by active networks to make the protocol available. The protocol agreed upon is downloaded to and installed in all of the appropriate nodes (registries and/or gateways). This deployment is enabled using the software architecture presented in the next section.

7.2. Software architecture for protocol deployment on the fly The software architecture that we propose is based on DINA, a programmable network platform that enables the deployment and management of programmable services [9]. The main service components of our architecture are the policy server, the protocol installer and the installation broker (figure 5). The policy server and the protocol installer components are added to the RCEs. The policy server includes and manages the policies that regulate the registries’ composition. The protocol installer is part of the composition manager entity and is responsible for initiation of the protocol installation. The installation broker is added to the DINA platform on the gateway/registry side to enable and control the actual protocol installation and activation. Figure 5 presents a scenario for deploying a protocol that resides in a protocol server. After the composition agreement is created, the protocol installer creates the active packet that is sent to the node where the protocol must be installed (steps 1 and 2). When this packet is received by the session broker on the gateway/registry side, an installation active session is

created to execute the active code (step 3). It will start by downloading the required protocol, and then it will use the installation broker to install and activate the new protocol in the current node (steps 4,5,6 and 7, respectively). 4 Protocol Installer

Policy Server 1

Protocol Server

5

Installation Session 3

6

Installation Broker

Session Broker

Session Broker

DINA

DINA 7

RCE OS

GW/Registry OS 2

Figure 5: Protocol deployment using DINA

7.3. Prototype 7.3.1. What is implemented As a prototype, we have implemented the scenario presented above. The registry (R1) of Net-1 is a distributed registry and it uses Chord [13],a P2P protocol, for information discovery and publication. The registry (R2) of Net-2 is implemented as a UDDI [14] registry and the printing service is implemented as a web service [15] that is published to the UDDI registry. To access the R2 content, an implementation of UDDI APIs is used. The stack of protocols (and their respective versions) used by R2 to communicate with the clients is SOAP 1.1/HTTP 1.1. To use the printing web service, the client (i.e. the laptop) has to start by discovering the service, through R1. Since R1 does not include a UDDI API implementation, the laptop is unable to discover the existence of the printing web service. So, at composition time, Net-1 and Net-2 decide to make the laptop UDDI client compliant (i.e. the laptop becomes the gateway between R1 and R2). Then, using the implementation architecture presented earlier, the client UDDI APIs are installed in the laptop, as is the protocol SOAP 1.1 because the laptop does not initially support this protocol. We assume that the laptop supports HTTP 1.1. For this prototype, we assume that the composition agreement has already been created and that it consists of automatically deploying the UDDI APIs and the SOAP protocol. We also assume that the RCE that initiates the protocol deployment knows the address of the protocol server. 7.3.2. How it is implemented The protocol installer, part of the protocol deployment architecture, is implemented via the class ProtocolInstallerInterface. This class has one main public method, called the createInstallationPacket. This method is responsible for creating the active packet to send to the registry, in order to ask it to install a new protocol. The active

1-4244-0667-6/07/$25.00 © 2007 IEEE

506

packet includes the protocol server address and the name of the protocol to deploy. The installation broker is implemented by the class InstallationBrokerInterface. This class provides the functionalities required to download, install and activate the new protocol. Its main methods are: downloadProtocol; and installProtocol.

8. CONCLUSIONS For future work, we will look at how to verify registry composability and how to negotiate a composition agreement on the fly. We will identify the composability parameters and conditions, and define an automated negotiation framework. We will also investigate how to compose the content of different registries on the fly, and propose a complete solution for information publication and discovery after composition. We will investigate how to use overlay networks to enable automatic publication and discovery, identify requirements for the common protocol, and propose procedures for information publication and discovery. We will also look at how to execute the composition agreement in general.

9. References [1]. N. Niebert et al. “Ambient networks: An architecture for communication networks beyond 3G”, IEEE Wireless Communications, vol. 11, no. 2, Apr 2004, pp. 14 – 22. [2]. N. Akhtar et al, “Connecting Ambient Networks-Requirements and Concepts”, Deliverable 3.1, Version 1.0, Sixth Framework Program, Project 507134 WWI Ambient Networks, June, 2004 [3]. R. Campos et al, “Scenarios for Network Composition in Ambient Networks: a new paradigm for Internetworking”, 11th Wireless World Research Forum Meeting, Oslo, June 04

[4]. D.Zhou et al, “Ambient Network Interfaces and Network Composition”, Global Mobile Congress, October 2005 [5]. M.Patini et al, “A Middleware Architecture for Inter ad-hoc networks Communication”, Fourth IEEE International Conference on Web Information Systems Engineering Workshops, Page(s):201 - 208, 2003 [6]. J. Chang, M.T. Liu, “An Approach to Protocol Complementation for Internetworking”, First IEEE International Conference on Systems Integration, Page(s):205 – 211, April 1990 [7]. Z.P.Tao et al, “An Efficient Method for Protocol Conversion”, 4th IEEE International Conference on Computer Communications and Networks (IC3N 95), Page(s):40 – 47, September 1995 [8]. F. J. Lin and M. T. Liu, “A Formal Model for Protocol Interworking in ISDN”. IEEE International Conference Communications, vol.1, Page(s):107 – 113, June 1988 [9]. D.Subir et al, “Network interconnection and protocol conversion-A protocol complementation approach", Joumal of the Institute of Engineers, Vol. 75, May 1994. [10]. UPC, “Specification, design and implementation of the necessary components for the enhancement of an active platform for the validation of the project approach”, CONTEXT-WP4UPC-D4.2-101204 [11]. D.L. Tennenhouse et al, “A survey of active network research”, IEEE Communications Magazine, Vol. 35, No. 1, Page(s):80 – 86, January 1997 [12]. J.M.Smith et al, “Active Networking: One view of the past, present and future”, IEEE Transactions on Systems, Man, and Cybernetics, Page(s):4 - 18, Feb. 2004 [13]. I.Stoica et al. “Chord: A scalable peer-to-peer lookup service for internet applications”, Proceedings of the 2001 ACM SIGCOMM Conference. [14]. OASIS, “Introduction to UDDI: Important Features and Functional Concepts”, http://www.uddi.org/, October 2004 [15]. W3C Working Group, “Web Services Architecture”, Note 11 February 2004. http://www.w3.org/TR/ws-arch/ [16]. W3C, http://www.w3c.org/TR/SOAP/

1-4244-0667-6/07/$25.00 © 2007 IEEE

507