Dynamic Network Policies Using Aspect Oriented ... - Semantic Scholar

Dynamic Network Policies Using Aspect Oriented Network Framework Sufyan Almajali, Tzilla Elrad Illinois Institute of Technology, Computer Science, Chicago, USA {almasuf, elrad} @iit.edu Abstract Computer networks and network applications change continuously. New laws and policies are released constantly in every field. Many of these laws and policies have a great impact on network operations and applications. To support new policies and laws, network administrators and application developers perform many activities, such as changing application programs to support the new policies, downloading, installing, configuring, and activating the new versions of the application. In this paper, we introduce a new networking framework called Aspect Oriented Network Framework (AONF). AONF simplifies network management and dynamic policies support. By using our framework, organizations will better control their networks through easier management of organization policies. It allows the network and network applications to adapt dynamically to different organization policies. Furthermore, many of the network administration tasks can be automated and a higher degree of network transparency can be provided for network users.

1. Introduction Computer networks and network applications are growing and changing continuously. New network applications with complicated network and software requirements are emerging. For instance, wireless networks (both local area networks and wide area networks), hot spots, and Internet cafés are becoming common. The applications associated with these network types require great dynamicity from the underlying network and software technology used to build them. Wireless Local Area Networks (WLANs) cater for mobile users, so there is less control over the machines. Users can move their laptops from one network to another, making them difficult to keep track of.

In addition, network access is becoming more complicated for WLAN users. Users may need to access various WLANs with different policies, services, and capabilities. This may require both the network users and the administrators to tediously configure user profiles and services in order to give the users access to the required services and applications. This decreases the level of network transparency and seamless access that users desire. Also, current WLAN and wired LAN designs make it more difficult for network administrators to modify the network design and settings to reflect new organization policies, which may be changed periodically. This may require changing the software or application configuration, or introducing a new protocol or rule. For instance, a company may want to deploy a new security policy. This may mean the introduction of a new network authentication protocol, and access rights for specific users or groups may need to be modified. Organizations may also change the accounting policy for a publicly-accessed WLAN. For example, an internet café providing wireless network services may want to alter its accounting rules that charge for printing, saving files on the server, and accessing the Internet. Providing such a policy change requires a complex software design, tedious administration work, or both. Two main factors impact the network’s flexibility toward deploying new policies to an existing network: the software design, and the network protocols used for deploying new software changes. With respect to software design, flexibility, dynamicity and modularity are key features. Object oriented (OO) and AOSD are promising technologies for flexible and modular software designs. By introducing the concept of aspect, AOSD stepped one more level over OO toward more modular software designs. Aspect is used to address a concern that its representation crosscuts multiple parts of the software application. By localizing the representation of the aspect into one part in the application design/code, applications become more modular, easier to change in

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

the future, and easier to read and follow overall. In addition, some AOSD systems/languages support dynamic weaving and unweaving of the aspect at runtime. This gives the application an extra flexibility and dynamicity. Examples of these systems are JAsCo [27], JBoss [15], and Steamloom [5]. AOSD uses different components to represent an aspect. This includes join points, point cut designators, advice, and a weaving/unweaving process. Unfortunately, the current representation of the different aspect components focuses on capturing the aspect at the application level. The aspect and the join point model definition are unaware of networks and can not be expressed form network perspective. This limits the application’s capability to adapt to different network settings and policies. Consequently, applications designed using OO and AOSD software technologies require an extremely complicated software design in order to be dynamic and flexible toward new organization and network policies. Having a complicated software design makes deploying new changes, in case this becomes inevitable, difficult. Also, in some cases it will be impossible to design software that is flexible toward changes unanticipated at the application design time. In addition to the software design factor, the network protocols that are available for deploying new network policies and settings focus on the concept of computer host configuration and host settings, such as the DHCP protocol. Network protocols used for deploying new network settings are software independent in general. Being software independent isolates the network protocols from the application and makes them application unaware, which complicates the deployment of new application changes over a network. This ends up requiring more network administration work in order to support new changes and policies. In this paper we address these two factors (software technology and network deployment protocol), and provide a new approach to implement applications that are network aware and can adapt easily toward network and organization policy. Our main goal is to come up with a technology that simplifies the application designer/programmer and network administrator jobs so that deployment of new organization/network policy can be done in a seamless and dynamic fashion with a minimum of work. The paper is structured as follows. Section 2 presents two applications explaining what we want to enable. Section 3 describes AOSD and our newly suggested AOSD changes toward network applications.

Section 4 explains the details of the AONF framework. Section 5 discusses comparisons to related work. Finally, Section 6 concludes the paper.

2. AONF Design Goals In this section, we present two network applications to explain what we want to enable and to show the challenges associated with implementing these using current technologies.

2.1. Dynamic WLAN Accounting Policy The first application example we consider here is WLAN accounting policy. Imagine the following scenario: an Internet café business has multiple services (applications) offered to its clients. For now, let us focus on three services: Web browsing, file saving, and printing services. Users need to register to the network first, and can install or download for the first time only the different client applications that will allow them to access the network’s services. Now, assume that the manager of the business wants to set up an accounting policy to charge clients for the different services. Different factors contribute to the overall cost of the WLAN services the manager offers them. For instance, web download, web upload, the size of printed files, the number of printed pages and the quality of printing, the size of folders on file server, the size of local traffic, and other factors. The accounting policy could be a static policy, but a dynamic policy would give the business owner or manager a greater chance to attract more clients and to adapt the way they are charged according to such factors as the time of year, user usage history, competitors’ prices, and so on. Predetermined policy rules can be implemented easily using current software technologies. By treating a specific application policy as an aspect, policy representation can be done in a clean and clear way. When the policy is at the network level, rather than at the individual application level, then policy representation tends to be more complicated. In addition, should the owner or manager want to make such a policy more dynamic, the job will become still harder. Our goal is to develop a system that allows the representation of the accounting policy easily from the programmer’s perspective, and allows its deployment to be dynamic, flexible, and easy from the user’s perspective. Also, the underlying software technology should allow for the building of a policy as a function of many parameters that users may like to have in the

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

future without requiring a major change to the underlying system. The only changes allowed are plugging in new rules and policies (preprogrammed or newly programmed), rather than reprogramming, recompiling and reinstalling a system application or applications for all network hosts.

2.2. Dynamic Network Security Policy Our second application example is the implementation of a dynamic security policy across an entire network. Network users access network resources and perform other functions using a set of applications available to them through the network. Some are client/server applications and others are standalone applications. Network security involves three different aspects: confidentiality, integrity, and availability. This application example focuses on the confidentiality aspect of security. Confidentiality means the protection of network resources and private data from unauthorized access. This is usually accomplished using such mechanisms as authentication, authorization, auditing, and encryption. Network administrators and system managers prefer to implement strong security policies and have dynamic ways of changing these policies to meet new laws and rules. For example, assume we have a network of three applications: two are client/server applications and one is a workstation standalone application. The network contains 100 users, and each user has a workstation. In addition, the network may contain additional wireless users (laptops). Network administrators may like to implement a new authentication policy across the network. This authentication policy may impact either specific application(s) across the network or specific users only. For example, each time users want to run applications 1 and 2, they will be prompted for a new authentication. The new authentication rule will validate user/password information according to new rules, protocols, and servers defined by the network administrator or programmer. Also, a new policy for auditing all user actions may be required according to a new law. This could include authentication events (both failures and successes), specific resource access events, specific procedure execution events, and so on. Our goal is to develop a system that allows the representation of a network security policy easily from the programmers’ perspective, and which is dynamic, flexible and easily deployed from the network users’ and administrators’ perspective. If a network administrator or business owner needs to implement a new security policy, the only changes needed would be

to plug in a new rule and policies (preprogrammed or newly programmed), rather than to reprogram, recompile and reinstall the system application or applications for all network hosts.

3. AOSD and Network Aspects In this section, we describe our newly designed dynamic aspect oriented language: Network Dynamic Aspect C++ (NDAC++). This language will simplify implementing dynamic network policies. We start our discussion by briefly introducing Aspect Oriented Software Development.

3.1. Aspect Oriented Software Development Separation of Concerns (SoC) is a core principle in software engineering. Conventional software technology provides some mechanisms for separating concerns (principally subprograms and inheritance). However, we are coming to understand that every system decomposition has some concerns whose implementation crosscuts that decomposition. The driving idea behind the development of Aspect Oriented technology is to expand our ability to capture each concern as a modular software unit and to realize these concerns in actual systems. Keeping the representation of concerns separate throughout the software life cycle produces more flexible and reusable software. Aspect Oriented Software Development (AOSD) refers to the refinement of software according to the aspect-oriented feature. AOP terminology and concepts Our discussion is aided by introducing several AOP concepts and terms: Crosscutting concerns. Software development addresses concerns, both at the user/requirements levels and at the design/implementation level. Often the implementation of one concern must be scattered throughout an implementation. We say that such a concern is crosscutting. For example, in many systems, the implementation of both high-level policies such as security, reliability, fault tolerance, accounting and manageability, and low-level mechanisms such as caching and prefetching, must be scattered throughout the implementation of many modules. Code tangling. In a conventional environment, implementing crosscutting concerns usually results in code tangling—the code for the several concerns becomes intermixed. Ideally, software engineering

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

principles instruct us to modularize our system software in such a way that (1) each module is cohesive in terms of the concerns it implements and (2) interfaces between modules are simple. Software that complies with these principles tends to be easier to produce, more naturally distributed among programmers and easier to verify and test, as well as easier to maintain, reuse, and evolve to future requirements. Crosscutting works against such modularization. Join points. Join points are places in the structure or execution flow of a program where additional behavior can be attached. A join point model provides the common frame of reference to enable the definition of possible join points. The most common join points are method calls, though aspect languages also have defined join points for a variety of other circumstances, including field definition, access and modification, exceptions, execution events and states. Pointcut designator. A set of join points described by a pointcut designator. This is an important feature of AOP because it provides a quantification mechanism— a way to talk about doing something at many places in a program with a single statement. A programmer may designate all the join points in a program where, for example, a security code should be invoked. This eliminates the need to refer to each join point explicitly and reduces the likelihood that any aspect code would be incorrectly invoked. Advice. Advice is the behavior to execute at a join point. For example, this might be the security code to do authentication and access control. Many aspect languages provide mechanisms to run advice before, after, instead of or around join points of interest. Advice is oblivious in that there is no explicit notation at the join point that the advice is to be run here the programmer of the original base code may be oblivious of the evolving requirements. Aspect. An aspect is a modular unit designed to implement a concern. An aspect definition may contain some advice and the instructions on where, when and how to invoke it. Depending on the aspect language, aspects can be constructed hierarchically, and the language may provide separate mechanisms for defining an aspect and specifying its interaction with an underlying system. Weaving. Weaving is the process of composing core functionality modules with aspects. Aspect languages

have defined several mechanisms for weaving, including static compilation, inserting aspects at system load, or dynamically recognizing when aspects should execute.

3.2. Network Policy as an Aspect A specific network policy can be viewed as a concern that crosscuts multiple hosts within a network and crosscuts multiple applications within the same host and crosscuts multiple parts with the same application. In other words, network policy needs a new way to define an aspect that can capture the definition of concern across an entire network rather than specific application. Current AOSD research defines an aspect within the scope one individual application. This does not allow the definition of network aspects.

3.3. Network Aspects Using a Network Aware Join Point Model Join points are places in the structure or execution flow of an application where additional behavior can be attached. A join point model provides a common frame of reference to enable the definition of possible join points. The most common join points are method calls, though aspect languages also have defined join points for a variety of other circumstances, including field definition, access and modification, exceptions, execution events, and states. These types of join points allow the definition of application aspects, or, in other words, aspects that can be woven at application level. Network aspect is defined as a concern that crosscuts multiple hosts in a network. The realization of this concern can exist in an application installed in multiple hosts in a network or in more than one application spread over a network’s hosts. Network aspect expands the definition of application aspect and does not eliminate it. Application aspect can crosscut multiple parts of the application code and representation. This means network aspect can crosscut the different application parts exactly as application aspect does. To be able to realize the aspect in such a new definition, we need to define our new join point model. The new join point model space is based on multiple dimensions join point model. Class, class instance, method, and thread are already defined dimensions in traditional aspects of current AOSD languages and research. Network and Application dimensions are two new dimensions defined in our model. For the network dimension, our systems allow the following type of joint points: based on broadcast

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

address, based on network or subnetwork address, based on a multicast address, based on a group of addresses, and, finally, based on an individual machine address. An application join point dimension allows an aspect to crosscut either multiple applications or one individual application per network host.

3.4. NDAC++ Language Syntax To understand the new language syntax and the new join point model better, consider Figure 1 as an example of the dynamic security application we want to enable. A LAN network for a company has three departments (Sales, HR, and Administration). All departments use one common application to access the main company’s database. Assume it is called DBapp. In addition, each department has its own application to access the department’s specific resources: Salesapp, HRapp, and Adminapp.

pointcut designator, a pointcut designator, the weaving of specifications, and, finally, the aspect and its advice. 3.4.1 Defining Join Points and Pointcut Designator over Network Join Point Dimension. As previously defined, join points are places in the structure or execution flow of a program where additional behavior can be attached. A set of join points are described by a pointcut designator. This is an important feature of AOP because it provides a quantification mechanism – a way to talk about doing something with a single statement at many places in a program. Each join point type has two components: type and value. Starting with network points, there are six types of network join points (ALL, SUBNET, MULTICAST, HGROUP, HOST, and LOCAL). To define a network pointcut designator over a network join point dimension, we specify the type first, and then we assign a value for that pointcut designator. Figure 2 (lines 1, 2, 3 and 4) shows how to define the network pointcut designators for our dynamic security example. Line 1 specifies the network pointcut type to be BROADCAST which represents all departments. Line 2 uses SUBNET type, and assigns the subnetwork IP address 192.168.64.0/26. This allows representing the Sales department network. 1 2

Figure 1. Dynamic Security Policy Example. Now, assume that the network administrator wants to define the following policies: 1) For all network users, all application start events are supposed to be logged for auditing purposes. The scope of this policy is represented by the line surrounding all departments together. 2) Sales department users are supposed to access the network application from their own PCs only. The dashed line represents this policy. 3) The sales and administration departments’ applications need to be authenticated through a specific network server. 4) HR application events (add new employee record, modify employee record, and delete employee record) need to be audited along with HR user information. To define these policies using NDAC++, we need to define the following for each policy: join points, a sub-

NetworkPC net_pc1(BROADCAST,""); NetworkPC net_pc2 (SUBNET ,"192.168.64.0/26"); 3 NetworkPC net_pc3(HGROUP, "192.168.64.0-63, 192.168.64.128-191"); 4 NetworkPC net_pc4 (SUBNET ,"192.168.64.64/26"); 5 ApplicationPC app_pc1(ALL,""); 6 ApplicationPC app_pc2(ALL,""); 7 ApplicationPC app_pc3( GROUP, "Salesapp , Adminapp"); 8 ApplicationPC app_pc4 (NAMEMATCH,"HRapp"); 9 ClassPC class_pc1 (GROUP ,”square,rectangle”); 10 MethodPC meth_pc1(GROUP, "add_emp,modify_emp, delete_emp");

Figure 2. Pointcut Definition Examples. For the rest of the join point types (application, thread, class, instance, method, and variable), we have three types only (ALL, GROUP, and NAMEMATCH). Figure 3 (lines 5 to 8) shows how to define application pointcut designators. Line 5 specifies the type to be ALL which means all application. Line 7 uses GROUP for the application pointcut designator type. This means that the aspect will be woven in a specific group of applications but not all. The targeted applications are

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

specified in the value section “Salesapp, Adminapp”. With respect to thread join point dimensions, none of the policies require weaving at a specific thread or group of threads, so we use the ALL type, which is the default for the thread join point type. In case we want to weave on a specific thread, then we use NAMEMATCH for the type and specify the name of the thread in the value section. Similarly, class, instance, method and variable pointcut designators can be defined in the same manner. For example, to target a specific class or classes, we can use the GROUP or NAMEMATCH join point type. Figure 3 (line 9) shows how to target square and rectangle classes in one class pointcut designator. Figure 3 (line 10) shows how to define the method pointcut designators for the four different policies. 3.4.2. Defining Sub-Pointcut Designator and Pointcut Designator over Multi-dimensional Join Point Space. The sub-pointcut designator type is used to define a pointcut designator over multiple dimensions. This is accomplished by specifying the pointcut designator value for each individual dimension. Joining these values together defines the value of the pointcut designator over multiple dimensions. Pointcut designator types allow the programmer to have multiple sub-pointcut designators used in one pointcut expression. Figure 3 shows how to define both sub-pointcut designator and pointcut designator variables. One important thing to notice is the high modularity and reusability in defining pointcut expressions. Both sub-pointcut designators use the same network pointcut expression. 1 2 3 4 5 6 7 8 9

SPCD spcd1, spcd2; spcd1.setnetworkpc(net_pc1); spcd1.setapplicationpc(app_pc1); spcd2.setnetworkpc(net_pc1); spcd2.setapplicationpc(app_pc2); spcd2.setmethodpc(meth_pc1); PCD pc1; pc1.add(spcd1); pc1.add(spcd2);

Figure 3. Sub Pointcut and Pointcut Designator Definition Examples. 3.4.3. Defining Weaving Specifications. For extra modularity and reusability, we isolated the weaving specifications from the aspect and pointcut definitions. The weaving specifications include the weaving target and its type. The three main types are Method_W, Variable_W, and Application_W. The type values that can be assigned to each one are (Pre_T, Post_T, and Around_T), (Pre_T, and Post_T), and (Start_T and

Finish_T), respectively. For example, to make an aspect target a specific method or methods using Preweaving mode, we set the weave type to be Method_W and the weaving type to Pre_T. This approach allows high code modularity and reusability. The same weaving specifications can be used to weave different aspects of different pointcut expressions. 3.4.4. Defining an Aspect. Aspect definition includes defining a new class inherited from a predefined aspect class. Programmers need to specify the following things when defining a new aspect: aspect advice, aspect member variables, and functions, in case they are needed. Every aspect has two member variables inherited from the original aspect definition. These are the weaving specifications and the pointcut expressions. The values for these two variables are specified later, when or after the aspect becomes instantiated. Every aspect has to have one member function (method) defined with the name advice, otherwise the compiler generates an error message of an aspect missing an advice. That member function is considered the aspect advice. All other member functions are considered internal aspect member functions and can only be accessed from inside the aspect definition. This gives the advice more programming power. Figure 4 shows how to define two aspects for the first two policies mentioned in our above example. 3.4.5. AOP Engine and Host Agent. NDAC++ has a runtime engine that controls the weaving and unweaving processes over the application and the network. In addition, each computer (network host) has an agent. The purpose of the agent is to allow the AOP engine to communicate weaving requests to other network hosts. Before starting to weave aspects into the application and network, each application needs to register itself with the AOP engine. To do that, programmers use AOPEngine::Register( “application name”, Host Role) function. The AOP engine communicates this information to the host agent exists on the same computer. This keeps the agent aware of what applications are running locally. This directs the agents on how to forward the weaving requests that come over the network. The host role type is used to direct the AOP engine and the host agent on how to deliver the weaving requests come form the application or over the network. NDAC++ allows the following types of host role: Server, Client, Local, Client_Local, and Client_Server. In case of Server role type, the AOP engine delivers the weaving requests to the host agent.

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

1 { 2 3

4 5 6 7 8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

class LoggingPolicy: public

Aspect

LoggingPolicy(); Advice() { /* code to log user info here, programmer can define other member variables and functions*/ } class CheckSalesUsersPolic: public Aspect { CheckSalesUsersPolicy(); Advice() { /* code to get user name first, get machine's mac address next, send to server for validity and authorize*/ } int main () { WeaveSpecs w1; w1.setweavetarget(Application_W); w1.setweavetype(Start_T); NetworkPC net_pc1(BROADCAST,""); NetworkPC net_pc2 (SUBNET ,"192.168.64.0/26"); ApplicationPC app_pc1(ALL,""); SPCD spcd1, spcd2; spcd1.setnetworkpc(net_pc1); spcd1.setapplicationpc(app_pc1); spcd2.setnetworkpc(net_pc1); spcd2.setapplicationpc(app_pc2); PCD pc1,pc2; pc1.add(spcd1); pc2.add(spcd2); LoggingPolicy aspect1; aspect1.setweavespecs(w1); aspect1.setpcd(pc1); CheckSalesUsersPolicy aspect2; aspect2.setweavspecs(w1); aspect2.setpcd(pc2);

Figure 4. Aspect and Weaving Specs Definition Examples. The host agent does the rest by communicating the weaving request to the other host agents inside the network. Then other hosts’ agents communicate the weaving request to their local AOP engines. In case of Client role type, the AOP engine rejects all weaving requests come from the application. For Local role type, the AOP engine rejects all weaving request come from network. This is used in case the users want to allow hosts to run independently. Client_Local role type allows weaving requests to come form network or application. This role is used in case the application has multiple aspects, in which some will be woven based on server weaving requests, and others will be woven based on local weaving requests by the host itself. Client_Server role type allows application to run as client and server for weaving requests. The

AOPEngine::ChangeRole(Host Role) can be used to change the role type at runtime. After registering the application, programmers can start weaving aspect instances into the program or computer network. The AOPEngine::Weave( “aspect instance name”) function is used to weave aspects at runtime. AOPEngine::Unweave(“aspect instance name”) function is used to unweave aspect. NDAC++ allows defining new aspect at runtime. Programmers can compile aspects alone. This generates the aspect meta data along with object code of the aspect. To introduce a new aspect at runtime, AOPEngine::AddNewAspect (“ path to meta data file“,”aspect name”) function is used. The AOPEngine::CreateAspectInstance(“aspect name”, PCD, WeaveSpecs) function allows to create an aspect instance that can be woven as any other aspect defined at initial application deployment time.

4. AONF Architecture AONF framework has five main components: Management Station, Host agents, Application agents, AONF Protocol, Network information database and dynamic AOP language (NDAC++). Each of these will now be presented in detail.

4.1. AONF Management Station For each network, AONF framework will have one or two management station (MS) devices. The main functions accomplished by the MS are the following: • Hold a database of information about the network. Information includes policy and applications information. • Enforce organization policies by communicating to AONF agents installed on network hosts. • Provide users with new application upgrades in case of a new policy require new software upgrade. Network can have one or more MS. Having one MS per network can make the network susceptible to single point of failure in case the MS goes down. A second MS can be deployed for backup purposes. In case of using two MSs, the main MS will be in primary mode and other will be in standby mode ready to take over in case of failure.

4.2. AONF Host Agent The host agent is a piece of software that will be installed on every network host. Every host will need

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

the agent to be able to adapt to a new network policy. Agents stay in contact with MS using the AONF protocol. The AONF agent enforces the organization policy by pulling the rules from the MS and activating them at the user host machine and user applications. Host agent communicates to applications agents hosted in the user machine. This two-way communication allows the host agent to gather information for user applications and deliver dynamic aspect weaving requests coming from client.

message and the agent predetermined TCP port number. App1 App2

Agent

H1

H2

4.4. AONF Protocol The AONF protocol (AONFP) represents the heart of our framework. AONFP allows the different AONF components (MS and agents) to communicate with each other and perform their various functions. AONFP uses different types of messages to implement the processes of our framework. AONFP has the following messages: • New network policy deployment request. • Policy request. • Policy Reply. • Network policy deactivation request Two technologies have been used to achieve dynamic network policy deployment: agent system and interprocess communication (IPC). Consider Figure 5, a network of four different hosts and one management Station. The network administrator requests activation of a new policy A. This results in sending a weaving request of Aspect A. Assume that the aspect is suppose to impact only application App1 in the network. Then, the system should weave the aspect at both hosts H2 and H3 application app1. There are multiple ways to achieve interprocess communication. Examples are Named Pipes, Shared memory, Message queues, and TCP/IP protocol [12]. We used TCP/IP protocol technique to make it operating system independent technique. When a host agent gets turned on, it starts listening on a specific reserved TCP port for all messages coming form local applications or other network hosts. AOP engines communicate messages to the agent using regular TCP

Request: Deploy Policy A Weave Aspect A

IEEE

App4 App7

MS

H3

App1

Agent App4

Figure 5. Aspect and Weaving Specs Definition Examples. When an application registers with the AOP engine, the AOP engine reserves a TCP port number from the operating system. The TCP port number along with the application name is communicated to the host agent during application registration process. This gives the host agent the mean to call the application back in case of a network weaving request. One more thing, the AOP engine has a separate thread that listens to all weaving requests come form the local agent. AOP engine ignores all messages coming from other senders. This describes how aspects are woven at the network level. Once the weaving request is delivered to each individual application, the NDAC++ AOP engine weaves the aspect at the application level to get attached to the different targeted locations inside the application [3]. If a network host receives a weaving request for a specific policy (network aspect) and it does not have it, then the host sends a policy request message from the MS. The MS replies with policy code to allow the host to use this policy.

4.5. AONF Information Database Our AONF uses a database of information to track the different networking processes executing on the framework. This information is saved on the MS. Information includes the following categories: • Organization Rules and policies: this is application and network specific. Policies are represented using network aspects.

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

Agent

H4

4.3. AONF Application Agent The application agent is a piece of software that is added to the different targeted applications. Every host agent communicates with the different application agents installed on its machine.

App1

App3

• Application Information: this includes the application name, the application file(s), and version number of the application.

5. Comparisons This section compares a number of related systems with our AONF system.

5.1. Application Level Dynamic AOP Systems There are three main classes of dynamic weaving in AOP at the application level: Pre-Run-Time Instrumentation, Run-Time Event Monitoring and RunTime Weaving. Examples of these systems are EAOP[9], JAC[13], JBoss AOP [15], PROSE [22] and DAO C++[1,2,3], Steamloom [5], Wool [24], a .NETbased approach [25], AspectS [4], JAsCo [27], AspectWerkz [28] and others. In general, these systems have the capability to express a pointcut expression over joint points inside the application only. Their join point model is not network aware. This makes it challenging to implement a dynamic network policy.

5.2. Distributed Object AOP Systems There are dynamic AOP systems that allow weaving for distributed programming systems such as AspectIX system [16] and QuO [10]. These approaches in general are distributed object based approach. There main focus is to support adaptable distributed objects depending on current distributed programming capabilities such as JAVA with remote method invocation and CORBA Programming. Our design is a network based approach that can work for client/server network model, peer-to-peer network model and distributed object programming as well. This makes our solution more generalized and can help all network scenarios. QuO [10] is a domain specific implementation focusing on adapting systems that are implemented using middleware. The aim of this work is to improve Quality of Service (QoS) provided by such systems by applying adaptations to the system. A limitation of this is that QuO requires the various definition files all to be compiled to generate the application before it is executed. This complicates the deployment process compared to our solution. In addition, the join point model defined is focused at inside of the application. Also, the aspect definition used by QuO is not modularized which decreases the level of reusability compared to our work. Another interesting system is DJcutter [21], In DJcutter, the join point model has been expanded to

capture aspect in distributed environment for a specific application. DJcutter is a load-time weaving system. AONF is a runtime weaving system that allows us to define and weave new aspects without reloading anything. In addition, AONF join point model allows us to define an aspect at the organization level. AONF allows aspect crosscut multiple applications in one host and multiple hosts in one network. When an aspect is written in DJcutter, it is going to be for a specific application. AONF aspect can be used by multiple applications. There are some mobile agents systems which support static extensibility, for example the MOA platform [20] and Gypsy [14]. Other systems support dynamic reconfiguration at the application level, like DynamicTAO [17]. DynamicTAO is a reflective CORBA ORB, built on top of the TAO ORB. TAO is an extensible ORB with support for static reconfiguration. Dynamic TAO extends TAO to allow on-the-fly reconfiguration. The Distributed Multimedia Research Group at Lancaster University has been working on a reflective architecture [27] based on the Python interpreter language. This architecture supports dynamically adding and removing of methods from objects and classes, and even changing the class of an object at run time. Although our work has some things in common with these systems, it has a different focus. These systems focus on creating general architectures with support for dynamic reconfiguration that can be later applied to different application domains. Our work focuses specifically on mobile agents systems, with the objective of creating an easily managed and extensible WLAN by using aspect oriented programmed applications with agents enabled at the host level rather than in the application. These other approaches are mainly object oriented approaches. This makes the task of application development for systems that have crosscutting concerns like the one we had a very complicated task. Consequently, to allow dynamic policy change and adaptation for cases like the accounting policy, the level of complexity will increase.

6. Conclusion AONF uses dynamic aspect oriented programming and extends the join points expressiveness to enable dynamic network policies management. This is accomplished by allowing an individual aspect to span across multiple network hosts and multiple applications. AONF allows the representation of an organization policy as an aspect. This high level view

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE

of the aspect simplifies the design of applications by localizing many organizational level policies and rules into modular units. In addition, being a dynamic network aspect gives the network users and administrators high level of flexibility toward new laws and policies.

7. Acknowledgment This work is partially supported by CISE NSF grant No. 0137743.

10. References [1]

S. Almajali, and T. Elrad, A Dynamic Aspect Oriented C++ using MOP with Minimal Hook Weaving Approach. In Dynamic Aspect Workshop, Lancaster, England. March 2004. [2] S. Almajali, and T. Elrad,. Dynamic Aspect Oriented C++ for Upgrading without Restarting. In proceeding of Conference on Advances in Internet Technologies and Applications with Special Emphasis on E-Education, E-Enterprise, EManufacturing, E-Mobility, and Related Issues, Purdue, USA, July 8-11, 2004. [3] S. Almajali, and T. Elrad, Coupling Availability and Efficiency for Aspect Oriented Runtime Weaving Systems , Proceedings of the 2005 Dynamic Aspects Workshop (DAW'05) as part of AOSD’05 (Chicago, USA, March 2005) [4] AspectS Home Page. http://www-ia.tu-ilmenu.de /~hirsh/ Projects/Squeak/AspecS/. [5] C. Bockisch, M. Haupt, M. Mezini, and K. Ostermann, Virtual Machine Support for Dynamic Join Points. In AOSD 2004 Proceeding. ACM Press, 2004 [6] S. Chiba, A Metaobject Protocol for C++. In Proceeding of ACM Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), page 285-299, October 1995. [7] DAC++ Home Page. http://www.iit.edu/~almasuf/dacpp.html [8] R. Douence, O. Motelet, and M. Sudholt. A Formal Definition of Crosscuts. Technical Report 01/3/INFO, Ecole des Mines de Nates, 4 rue Alfred Kastler, 44307 Natescedex 3, france, 2001. [9] R. Douence, and M. Sudholt, A Model and a Tool for EventBased Aspect-Oriented Programming (EAOP). Technical Report 02/11/INFO, Ecole des Mines de Nantes, 2002. [10] G. Duzan, J. Loyall, R. Schantz, R. Shapiro, J. Zinky. Building Adaptive Distributed Applications with Middleware and Aspects. in AOSD 2004. 2004. Lancaster, UK. [11] R. Hirschfeld, Aspect-Oriented Programming with AspectS. http://www-ia.tu-ilmenau.de/~hirsch/Projects/ Squeak/ AspectS/Docs/AspectS_NODe02_Erfurt2_rev.pdf [12] Interprocess Communication Info. Site. http://www.tldp.org/LDP/lpg/node7.html

[13] JAC Home Page. http://jac.aopsys.com [14] M. Jazayeri, W. Lugmayr, Gypsy: A component-based mobile agent system, in Proc. of 8th Euromicro Workshop on Parallel and Distributed Processing(PDP2000), Rhodos, Greece. 2000. [15] JBoss AOP Home P. http://www.jboss.org [16] R. Kapitza, F. Hauck, and H. Reiser: Decentralized, Adaptive Services: The AspectIX Approach for a Flexible and Secure Grid Environment Proc. of the GSEM 2004 Conferences (GSEM, Erfurt, Germany, Nov. , 2004); Springer, LNCS 3270, 2004. [17] F. Kon, M. Roman, P. Liu, J. Mao, T. Yamane, L. Magalhaes, and R. Campbell: Monitoring, Security, and Dynamic Configuration with the dynamicTAO ReflectiveORB, in Proc. of the IFIP/ACM Int. Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’2000), New York. April 2000. [18] J. Levine, Linkers and Loaders. Morgan-Kauffman, October 1999. [19] S. Lippman, Inside the C++ Object Model. Addison-Wesley, 1996. [20] D. Milojicic, W. LaForge, D. Chauhan: Mobile Objects and Agents (MOA), in Proc. of USENIX COOTS’98,Santa Fe, New Mexico. April 1998. [21] M. Nishizawa, S. Chiba, and M. Tatsubori, Remote Pointcut: a language construct for distributed AOP. In AOSD 2004 Proceedings. ACM press, 2004. [22] A. Popovici, T. Gross, and G. Alonso. Dynamic Weaving for Aspect Oriented Programming. In AOSD 2002 Proceedings. ACM press, 2002. [23] A. Popovici, T. Gross, and G. Alonso. Just-in-Time Aspects. In AOSD 2003 Proceeding. ACM Press, 2003 [24] Y. Sato, S. Chiba, and M. Tatsubori. A Selective Just-in-Time Aspect Weaver. In F. Pfenning and Y. Smaragdakis, editors, GPCE 2003 proceedings, colume 2830 of LNCS, pages 189208. 2003. [25] W. Schult, and A. Polze, Dynamic Aspect Weaving with .NET. http://www.dcl.hpi.uni-potsdam.de/dcl/papers/ GI2002.ps [26] O. Spinczyk, , A. Gal. and Schröder-Preikschat, W.. AspectC++: An aspect-oriented extension to the C++ programming language. Fortieth International Conference on Technology of Object-Oriented Languages and Systems (TOOLS Pacific 2002), volume 10 of Conferences in Research and Practice in Information Technology. ACS, 2002. [27] W. Vaderperren, and D. Suvee, Optimizing JAsCo dynamic AOP through HotSawp and Jutta. In Dynamic Aspect Workshop, Lancaster, England. March 2004. [28] A. Vasseur, Dynamic AOP and Runtime Weaving for JavaHow does AspectWerkz address it? In Dynamic Aspect Workshop, Lancaster, England. March 2004.

Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICNICONSMCL’06) 0-7695-2552-0/06 $20.00 © 2006

IEEE