Virtual Network for Development Execution

Check out more papers on Communication Computer Computer Networking

A Mobile Ad hoc Network (MANET) is a self-configuring network that is formed and deformed on the fly by a collection of mobile nodes without the help of any prior infra-structure or centralized management (Xiao et al., 2006). These networks are characterized as infrastructure less, mobile, autonomous, multi-hopped, self-organized and self-administered, having dynamic topology and unpredictable traffic patterns etc.

A great deal of research is being carried out to solve various issues of MANET. These issues include Routing, MAC Layer Issues, Power Management, Transport Protocol, Quality of Service, Billing, Addressing, Service Discovery, Data Management and Security, etc., (Sesay et al., 2004), (Quan et al., 2004) and (Royer et al., 2004).

One of the most important questions in MANET is the middleware Konark, designed specifically for discovery and discovery of services available around the vicinity of any node. A service can be any hardware, software or any other entity that a user might be interested to utilize and Service Discovery is the process of discovering the services based on user preferences. An efficient and scalable approach to service discovery can lead to the development a large number of potential applications. For example, in a vehicular ad hoc network, vehicles might be interested in knowing the services provided by a near by fuel station. Similarly, in a battlefield soldiers might be interested in sharing the situation about the whole battlefields.

Due to the dynamic nature of MANET, there are always spatial and temporal variations in the availability of services. Hence a service discovery strategy should be highly robust, efficient and dynamic in nature.

In this paper we have proposed an efficient and flexible approach to service discovery in MANET by extending the work of (Danta et al., 2004). Rest of the sections are organized as follows: first we will provide a review of existing approaches to service discovery. We will then discuss our approach to virtual network architecture. Then we will discuss about the proposed model. Then the Simulation result. Finally we will conclude the paper with future work.

LITERATURE REVIEW

The service discovery protocols that have been proposed in the literature can be classified as directory less (e.g.IBM DEAPspace, UPnP and Konark) or directory based architecture (e.g. Salutation, JINI, SLP) (Cho et al., 2005) SLP (Sesay et al., 2004), (Service Location Protocol, 1999) and represents the service by means of URL and attributes. JINI is based on Java and uses Interfaces and RMI mechanisms for service discovery process. Due to the lack of semantic information, the protocols can only perform exact matching of services using identifier and attributes.

To support service discovery based on semantics, DReggie (Sesay et al., 2004) (an extension of JINI) is proposed. DReggie semantically represents the services by means of DAML and compares the service using a PROLOG reasoning engine. GSD (Quan et al., 2004) also describes the services semantically by means of DAML. They group all the services based on semantics for efficient discovery of services.

In order to address heterogeneity of MANET, (Helal et al., 2003) proposed a middleware Konark, designed specifically for discovery and delivery of device independent services in ad-hoc networks. (Danta et al., 2004) Proposed a totally different approach to service discovery by extending AODV protocol and provided service discovery at network layer. As a result when a service discovery request is initiated to discover a service, a route is also established towards the service provider. Hence, when the client wants to use the service, a new route request is not required.

VIRTUAL NETWORK ARCHITECTURE

Virtual network is based on service-oriented architecture. Implementation of virtual network in the form of an extensible set of distributed services enables on-demand user-driven creation of logical communication space. Moreover, since both distributed applications and virtual network are based on the same architecture, distributed applications can manage the virtual network.

Separation of logical and physical communication space is based on indirect service invocation. Each physical node that constitutes virtual network contains a locally installed Overlay Service. The Overlay Service is a special-purpose service that receives, transmits, and delivers the messages in the virtual network communication space. The locally installed Overlay Service receives the messages from the distributed programs executing on local node and delivers them to the Overlay Service on the target node.

The Overlay Service executing on the target node delivers the messages to the target services on behalf of the calling distributed programs. In order to invoke application services or coordination mechanisms, distributed programs use target service WSDL document to generate the proxy for the target service. Service proxy contains the instructions for formatting the SOAP messages for interaction with the target service and target service communication parameters. Indirect service invocation is achieved by the modification of the proxy communication parameters. Physical address of target service contained in the WSDL document is modified and redirected to the physical address of the local Overlay Service. Additionally, service proxy puts the logical address of target service into the header of the SOAP message. The Overlay Service on the local node accepts the message from the distributed program, analyses logical addresses in the message header, and redirects the received message to the Overlay Service on the target node. The Overlay Service on the local node determines the physical address of the target node based on the locally stored mapping relation. Mapping relation is stored in the Naming Table document. The Overlay Service on the target node contains the service proxies for all locally installed services. It selects the proxy for the target service and delivers the message to the given service on behalf of the calling program. The path of the message through the network is determined during the run-time according to the virtual network mapping relation.

To enable secure invocation of services in logical communication space of virtual network, we introduce certain extensions to the SOAP message structure.

Figure 1 shows the structure of a SOAP message used for secure service invocation in communication space of virtual network. Elementary SOAP message, often called SOAP envelope, consists of SOAP body and SOAP header. SOAP body contains application-specific data used for regular service invocation. SOAP header is an extensible data structure. We use the SOAP header extensions defined in the WS-Addressing and WS Security specifications. WS-Addressing elements contain the information about logical addresses of the invoked services. WS-Security elements contain the security-related information about the encrypted and digitally signed portions of the SOAP message, encryption keys, and cryptographic and hash algorithms. Since all information necessary for message processing are embedded into the message, the message is self-contained and independent of the physical transport protocol.

Overlay Service consists of five modules:

Local Interface Directory (LID), Router, Address Resolution Manager (ARM), Secure Communication (SC), and Membership Manager.

The Local Interface Directory (LID) module contains the proxies of the locally installed services.

Each time new service is installed on the local physical node, it should be registered in the LID module of the local logical node. During the service registration, the LID module builds the service proxy for the registered service. Service administrator or an application for automated service installation starts the service registration by providing the WSDL document of the installed service to the LID module. Based on the information contained in the WSDL document, the LID module compiles the executable code of the service proxy and embeds it into the local file system. The executable code of the service proxy is used by the Router module during the delivery of messages to the locally installed services.

The Address Resolution Manager (ARM) module maintains the information about the virtual network mapping relation. Mapping relation is stored in the Naming Table document as the (logical address, physical address) value pairs. The ARM module adds the records into the Naming Table if new node is joining the virtual network, removes the records from the table if an existing node is leaving the network, and updates the table if logical node migrates from one physical location to the another one. Joining and removing logical nodes to and from the virtual network are user-driven processes. Migration of logical nodes among physical nodes is application-driven process that can be initiated by an application monitoring network conditions, node workloads, node failures etc.

The Secure Communication (SC) module performs the encryption/decryption and the digital signing of the SOAP messages. To keep the messages self-contained and independent of the physical transport protocol, the SC module performs message-level security in accordance with the WS-Security specification. The Router module is a central module of the Overlay Service. It coordinates the process of the delivery of messages to the target services. The Router module accepts the messages on input interface and routes them to the specified destination. If message destination is a local node, the Router module delivers the message to the locally installed service. Otherwise, it forwards the message to the Overlay Service on the remote logical node. Central unit of the Router module is SOAP Parser. SOAP Parser analyses addressing information contained in the header of the received message. Using embedded XPath expression, SOAP Parser fetches the logical address of the destination node from the SOAP message header. Logical address of the destination node is compared with the logical address of the local node. If two addresses match, the Router module delivers the message to the local service.

If they differ, it forwards the message to the remote node. The Router module sends the message to the SC module to decrypt the message content and to verify the digital signature. During the analysis of the plaintext message, the Router module fetches the service name from the message header. Then it contacts the LID module in order to retrieve the proxy for given service. Using service proxy, the Router module delivers the message to the target service. The interaction scenario if message is designated to the remote logical node. The Router module contacts the ARM module in order to retrieve the physical address of the destination node. Before forwarding the message to the remote node, the Router module sends it to the SC module to encrypt and digitally sign the message content. Using the retrieved physical address, the Router module forwards the message to the Router module of the destination node's Overlay Service.

Service-oriented architecture of the virtual network enables on-demand creation of logical communication space according to the requirements of distributed applications. Distributed application administrators can manage the membership of the virtual network by adding and removing logical nodes dynamically. To join the network, new logical node has to exchange the virtual network mapping relation with the existing nodes. The Membership Manager is a module of the Overlay Service that coordinates the exchange of the virtual network mapping relation among logical nodes.

The administrator of new node provides logical and physical addresses of this node to the local Membership Manager module. This module contacts the ARM module of an existing node in order to retrieve currently valid virtual network mapping relation. It extends the retrieved mapping relation with its own (logical address, physical address) value pair and embeds it into local ARM module. The process of joining new node to the virtual network finishes with propagation of the new node mapping relation record to all remaining members of the virtual network. Reverse algorithm will be started if an existing node is leaving the virtual network.

Virtual network provides a basis for the development of advanced mechanisms for managing portability, reliability, and performance of service-oriented applications. Basic elements of an execution environment for virtual network based applications are shown in Figure 2. Service Deployment and Discovery subsystem and Reliability and Performance Management subsystem utilize virtual network to perform application transparent service migration. Service Deployment and Discovery is a distributed system for remote on-demand installation and uninstallation of services. Reliability and Performance Management monitors operability and load of network nodes. If non-operational node or node under heavy load is detected, Reliability and Performance Management subsystem instructs Service Deployment and Discovery subsystem to migrate services from such node to node offering better performance. At the same time, Reliability and Performance Management subsystem updates the naming table of virtual network, redirecting the messages for same logical node to different physical location.

PROPOSED MODEL

1. SERVICE DISCOVERY IN MANET:

We are proposing an efficient approach to service discovery for MANET by extending the concept proposed in (Danta et al., 2004). Nodes will be using an extension of AODV routing protocol to search on demand for a service provider along with an appropriate route to access that service. We are extending the concept of (Danta et al., 2004) by allowing a node to not only pull the service provider information on-demand, but a node will also be pushing the service advertisements periodically along with the route information.

The novelty of our strategy is that unlike most of the service discovery protocols (e.g. JINI, UPnP, Deapspace and SLP), an appropriate path towards the service provider is available after the completion of service discovery process. In addition to employing AODV, we are also explicitly pushing the service advertisement to adjacent nodes along with appropriate routing information. This information can be saved by adjacent nodes based on their preferences and can also be propagated ahead. So, in most of the cases, a service discovery SREQ request can be served from nodes local service table and doesn't need to be propagated on the network. The integration of service discovery with the network layer is motivated by the survey done. The development of a cross layer service discovery solution is always useful in the network of energy constrained mobile devices because: 1) putting service discovery at the network layer will reduce the control messages Overhead 2) less number of messages is exchanged among devices, hence processing overhead is reduced. We believe that the periodic advertisements of services (as done in our approach) will not cause too much traffic overhead because a number of service advertisements can always be transmitted in a single message. Also, for each service discovery, service discovery and route determination is done in a single request. Hence, less number of messages is exchanged among nodes. However, the disadvantage of our approach is that it is dependent on routing protocol and can work only for AODV routing protocol.

The details of our proposed approach in pseudo code are described. Every node will maintain a Routing Table to hold routing information and a Service table to maintain information about the services provided by it and other nodes along with other information like the life time of the services, the provider of the service etc. The nodes will periodically broadcast the services provided by it to its peer nodes by means of a message UPDATE_SERVICE_TABLE (UST). The message contains the service advertisements along with the routing information corresponding to the provider of each service.

The receiving node can store the service advertisements it heard from its neighbour based on its preferences and interests.

In addition, to avoid network congestion, if a node hears a service advertisement it reschedules its broadcast at a later time to avoid network congestion. If a node wants a service, it will first of all check its service table for a possible match. If a service is found in the service table, node can immediately requests the provider for the desired service. However, if no appropriate service provider is found in the local service table, a service discovery request 'SREQ' will be issued to find out a service provider for this service. The SREQ is served based on 'Ad hoc On Demand Distance Vector Routing Protocol' (Danta et al., 2004). The SREQ message is propagated along the network. Any node receiving the SREQ message will first check in its service table for corresponding service. If a match is found, an appropriate reply 'SREP' message will be generated. If no match is found, the intermediate nodes will propagate the message SREQ to adjacent neighbours. In addition to that, it will create a temporary reverse route towards source of the message. When a node receives an SREP message, it will check its routing table, delete the corresponding temporary reverse route and create a forward entry towards the destination. The node will then send the SREP message towards the source. The RREP message will contain complete details of the services it provides.

2. SERVICE ORIENTED COMPUTING

Virtual computing for service-oriented applications introduces a level of indirection between distributed application and physical network. Virtual computing establishes logical communication space on top of physical network with an application-level defined addressing scheme.

Distributed programs that implement coordination logic of distributed application are developed in logical communication space of virtual computing. Instead of addressing physical locations of application services and coordination mechanisms, they use logical addresses defined by virtual network computing.

Using logical addressing, distributed application is logically separated from the physical network. Logical separation of distributed application and physical network enables application transparent migration of services, because distributed application uses logical service distribution.

During the application execution, virtual network masquerades the changes in the physical locations of services from the coordination logic of distributed application. Organization of the virtual network is shown in Figure 4. Virtual network consists of logical nodes. Logical nodes are services that virtualize physical nodes into application-level controlled resources. Application-level control of physical nodes is enabled through application-driven management of virtual network mapping relation. Mapping relation determines the arrangement of logical nodes over physical nodes.

Virtual network computing mapping relation allows the assignment of arbitrary number of logical nodes to the single physical node. Many-to-one characteristic of mapping relation enables the adjustment of virtual network computing to arbitrary configuration of physical network. Adjustment of the mapping relation during the application setup enables portability of distributed applications between different working environments, regardless of available number of network nodes and their physical addresses. Runtime adjustment of the mapping relation enables application transparent migration of services, which can be useful for managing the reliability and performance of distributed application.

SIMULATION RESULTS

To simulate our approach, we have developed our own simulation software. The simulator creates 'n' nodes dynamically and links them randomly. Every node is randomly chosen to be either capable of storing or not storing advertisements. Nodes are randomly assigned a number of services. While simulation is running, after every half second, a random number of requests are generated and based on an improbability of 0.5 either a link is randomly created or broken. We have compared the results based on Request Acquisition Latency i.e. the time duration in which a service discovery request is initiated and the service discovery process is completed. The result when no service advertisement is broadcasted periodically with the result when broadcast capability is added.

The situation when 50 nodes were simulated with a total of 25 services available on the network.

In this situation, 174 requests were generated in a simulation time of 30 seconds. When no broadcasting was done 147 requests were replied with request acquisition latency between replied in between 0-0.2s. But when broadcasting was done, the 154 requests were replied in between 0-0.2s. This shows that by adding broadcasting functionality, performance of service discovery strategy has improved. Similarly in the case of 100 nodes, we can see that broadcasting of service advertisements has improved the request acquisition latency.

CONCLUSION

In this paper, we propose a model for development and execution of service-oriented applications based on virtual computing in mobile ad hoc network. The proposed approach is very flexible, efficient and can be adopted to work in any environment. Advanced mechanisms built upon the virtual network utilize logical communication space and service migration to provide distributed application portability, reliability, and performance. Virtual network computing consists of a set of distributed overlay services capable of receiving, transmitting, and delivering messages on behalf of application services. Service-oriented architecture of the virtual network enables user and application-driven management of logical communication space.

As part of our future work, we plan to extend the virtual network computing infrastructure with an application-level routing procedure for anonymous communication to preserve the privacy of service providers and consumers. Furthermore, we plan to upgrade the virtual network with an extensible security framework that allows user and application-driven customization of the service access control, service usage tracking, and communication security by integrating custom developed security services into the virtual network.

ACKNOWLEDGEMENT

We wish to thank Mr. I. JayaramA­A­an, Assistant Librarian, Anna University, Coimbatore for providing the literature and Mr. Babu, Head, Department of CSE, Kings Engineering College for encouraging us to carryout research activity.

Did you like this example?

Cite this page

Virtual Network For Development Execution. (2017, Jun 26). Retrieved March 29, 2024 , from
https://studydriver.com/virtual-network-for-development-execution/

Save time with Studydriver!

Get in touch with our top writers for a non-plagiarized essays written to satisfy your needs

Get custom essay

Stuck on ideas? Struggling with a concept?

A professional writer will make a clear, mistake-free paper for you!

Get help with your assignment
Leave your email and we will send a sample to you.
Stop wasting your time searching for samples!
You can find a skilled professional who can write any paper for you.
Get unique paper

Hi!
I'm Amy :)

I can help you save hours on your homework. Let's start by finding a writer.

Find Writer