LNCS 4276 - Developing Mobile Ambients Using an ... - Springer Link

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model Nour Ali, Carlos Millán, and Isidro Ramos Department of Information Systems and Computation Polytechnic University of Valencia Camino de Vera s/n E-46022 Valencia, Spain {nourali, cmillan, iramos}@dsic.upv.es

Abstract. Nowadays, distributed and mobile systems are acquiring greater importance and becoming more widely used to support ubiquitous computing. However, developing systems of this kind is a difficult task. Instead of concentrating on how problems should be solved developers must worry about implementation details. Ambient Calculus is a formalism that provides primitives to describe mobile systems in an abstract way. Aspect-oriented software development and software architectures promise to achieve reusability, maintenance and adaptability, which are all essential for the development of distributed systems. In this paper, we present how a platform-independent model called Ambient-PRISMA combines both Ambient Calculus and AspectOriented Software Architecture for the specification of distributed and mobile systems. A platform-specific model in .Net for supporting Ambient-PRISMA code generation is also presented.

1 Introduction Computer networks have become pervasive and ubiquitous. They allow users to communicate and to collaborate independently of their locations. They also involve new devices that form part of our daily life such as PDAs or smartphones. Nowadays, software systems have to cope with these advances in order to exploit their distributed nature. Distributed software systems have to take into account particularties; for example complex structures, new non-functional requirements such as fault tolerance and security, and dynamic adaptation. As a result, software development processes must be able to support the distributed, mobile and ubiquitous nature of software systems. The development of these software systems is a difficult task. Currently, decisions about these characteristics are usually postponed to late stages of the software life cycle (design and implementation). As a result, there is a loss of traceability, and the system is subject to a specific technological platform. Developers of distributed systems also have to spend more time programming than solving and considering distribution problems. The development of systems of this kind introduces important challenges such as: how to specify distribution and mobility features in a technologyindependent way; how to consistently manage a distributed state; and how to support non-functional requirements such as security or fault tolerance. R. Meersman, Z. Tari et al. (Eds.): OTM 2006, LNCS 4276, pp. 1633 – 1649, 2006. © Springer-Verlag Berlin Heidelberg 2006

1634

N. Ali, C. Millán, and I. Ramos

Model Driven Engineering (MDE) [1] is a software development approach based on the transformation among models. Model Driven Architecture (MDA) [2] is the MDE approach proposed by the Object Management Group (OMG). The MDA proposes the development of software by using Platform Independent Models (PIMs), to describe a system in a technology-independent way. Then, PIMs are transformed to a Platform Specific Model (PSM), which describes a system based on a specific technology. An application can be generated from the PSMs. Component Based Software Development (CBSD) [3] and Aspect-Oriented Software Development (AOSD) [4] are two techniques that promise to achieve reusability, flexibility, and maintainability through the software development process. CBSD proposes to construct the system by connecting entities that provide and require services. AOSD allows the separation of concerns by modularizing crosscutting concerns in a separate entity called an aspect. In this paper, we present a metamodel called Ambient-PRISMA that allows the definition of distribution and mobility characteristics in a technology-independent way. Ambient-PRISMA extends the PRISMA metamodel [5] with Ambient Calculus (AC) [6] concepts. PRISMA integrates CBSD and AOSD to specify software architectures. AC is a formalism that describes distribution and mobility properties in an abstract way. In addition to the metamodel, Ambient-PRISMA uses the Aspect-Oriented Architecture Description Language (AOADL) [7] to allow the description of the distribution and mobile characteristics of software architectures at a PIM level. This work shows how a mobile agent case study can be described in a platformindependent way using the AOADL. A PSM is also proposed in order to support the generation of PIMs that are based on the Ambient-PRISMA metamodel to .Net technology. The paper is structured as follows: Section 2 presents the state of art of distribution and mobility characteristics supported in Architecture Description Languages (ADLs). Section 3 gives an overview of AC. Section 4 presents the AmbientPRISMA metamodel and describes how the distribution and mobility characteristics of a PIM can be specified using the AOADL. In addition, a PSM of AmbientPRISMA in .Net technology is introduced. Finally, Section 5 presents conclusions and future works.

2 The State of Art of Distribution in Architecture Description Languages Currently, few ADLs support the specification of distributed system properties. The first research that provided significant results in distributed software architectures was carried out in the Darwin ADL [8]. Darwin uses π-calculus [9] to define the semantics of distributed message-passing. It builds architectures by defining composite components that are given locations and bound at instantiation time. Darwin also has been used in the CORBA environment to specify the overall architecture of component-based applications [10]. However, in the literature, we have not found new advances to Darwin in constructing software architectures with mobile components. As Darwin is based on π-calculus only, mobility can only be simulated

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1635

by the movement of channels. It lacks primitives to express the movement of components that cross boundaries. The work in [11] introduces features such as composition, reusability, and configuration that an ADL should consider in order to specify dynamic and distributed software architectures. It presents a configuration language that describes a method for a reconfiguration model at run-time. However, the reconfiguration model is not formal. Moreover, it neglects a distribution model that specifies distributed message-passing among components and connectors. The works of Mascolo and Ciancarini [12] [13] introduce MobiS, which is a specification language that is based on a tuple-space model that specifies coordination by multiset rewriting. MobiS can also be used to specify architectures containing mobile components. However, it does not specify the mobility concern separately from the rest of the functionalities of the software architectures, reducing reusability and adaptability to changes. The ADL C2Sadel has adapted a style to support both distribution and mobility. The style [14] provides software connectors that are able to move components. It also has an implementation infrastructure to support this architectural style. However, this approach has the drawback that there is no separation between coordination and distribution. Therefore, the components are the only architectural elements that are mobile and the connectors are static. The work of Lopes in [15] describes the semantics of externalizing a distribution dimension to support distribution and mobility for software architectures. This distribution dimension is very similar to a connector, but instead of containing the business logic, it controls the rules for mobility and location. In this way, a separation between computation, coordination and distribution is achieved. A difference between our work and Lopes’s work is that our work defines the semantics of distribution and mobility by using Ambient Calculus. This allows our approach to have an explicit primitive to represent a location with boundaries, which allows the specification of security and authentication.

3 Ambient Calculus Ambient Calculus [3] (AC) is a process algebra that extends π-calculus [11] to introduce the concept of ambient. An ambient is a bounded place where computation occurs. Thus, an ambient can be anything with a boundary such as a laptop, a web page, a folder, etc. Each ambient has a set of running computations that can control it. These are responsible for moving an ambient. In addition, an ambient can contain other subambients that have running computations. Thus, mobility is performed at an ambient level, i.e. ambients are mobile. Mobility is also performed by crossing ambient boundaries. AC provides mobility and local communication primitives. These primitives can be expressed in a textual syntax and in a graphical syntax which is called Folder Calculus [3] (see Figure 1). Folder Calculus is a graphical metaphor for AC where ambients are visually represented as folders. For example in Figure 2, the folders n and m represent ambients. In our work, we have chosen a visual notation similar to the one of Folder Calculus as it will be noticed in the paper.

1636

N. Ali, C. Millán, and I. Ramos

AC uses some of the constructs inherited from π-calculus such as naming, restriction, parallel processes, inactive processes and replication. However, the names in AC are names of ambients instead of names of channels as in π-calculus.

Fig. 1. The Textual and Visual Syntax of Ambient Calculus constructs taken from [3]

Some of the primitives that AC provides are called capabilities. Capabilities are actions that can be performed on ambients. There are three main types of capabilities: enter, exit, and open capabilities. The enter capability orders an ambient to enter another ambient on its same hierarchy level (see Figure 2). The exit capability orders an ambient to exit its parent ambient. The open capability dissolves an ambient leaving the processes that were in it.

Fig. 2. Applying the enter capability to the ambient n

Cardelli proposed an algorithm for implementing ambient calculus in Java [16]. The implementation describes a tree structure where each node of the tree is an ambient. The tree structure is modified through operations that implement the enter and exit capabilities. However, this implementation has a limited application as it does not consider distributed nodes and has to be extended for distributed applications. To date, we have only found a few implementations that support distributed software systems for ambient calculus. In [17], a scheme is proposed in C# for supporting ambient calculus primitives in distributed applications through an ambient runtime that sits above the .Net framework. Nevertheless, there has been no futher work to implement or apply the ambient runtime.

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1637

4 Supporting the Development of Mobile Ambients Through an Aspect-Oriented Software Architecture Model In this section, we present the Ambient-PRISMA metamodel that combines ambient calculus primitives and Aspect-Oriented Software Architecture in order to allow the description of the distribution and mobility characteristics in a Platform-Independent way. Then, the AOADL will be used to describe the mobile and distribution characteristics in a case study of the mobile agent field. A PSM in C# will also be presented to support the generation of code from PIMs. The concepts of the AMBIENT-PRISMA are mapped to .NET. 4.1 Ambient-PRISMA Metamodel A metamodel is needed to allow the definition of PIMs. A metamodel defines the ontology used to define a PIM. This section presents the metamodel of AmbientPRISMA that allows the definition of PIMs of distributed and mobile software systems. The Ambient-PRISMA metamodel extends the PRISMA metamodel [5] by introducing concepts of the ambient calculus. The result of the Ambient-PRISMA metamodel is to allow the description of distributed and mobile system software architectures by using both the aspect-oriented and the component-based software development techniques. W eaving (f ro m W e a v e r)

0.. *

we aves 1 h as

P ort 1 ..*

C om po ne nt

im p ort s

A rc hit ec tura lE lem en t

A s pec t 1.. *

0.. *

1

C on ne c to r

A m bien t

(f ro m C o n n ec to rs )

(fro m A m b i e n ts)

(fro m A sp e c t )

Fig. 3. Ambient as an aspect-oriented, component-based architectural element

The Ambient-PRISMA metamodel introduces the ambient concept as an architectural element (see Figure 3), which is responsible for providing mobility features to distributed architectural elements. As a result, an ambient inherits the CBSD and AOSD characteristics of PRISMA (as do other architectural elements of PRISMA such as components and connectors). The CBSD characteristics describe an ambient as a black box where it communicates with others by using ports that send and receive invocations of services. To enable the communication among architectural elements, channels called attachments are defined. Each attachment is defined by attaching two ports of different architectural elements. In Ambient-PRISMA, ambients are complex architectural elements that represent the places where components, connectors and other ambients are located. Therefore, in the metamodel, the ambient is associated with the other architectural elements (see Figure 4(a)). For example, in Figure 4(b) the Component and Connector are located in

1638

N. Ali, C. Millán, and I. Ramos {(s elf.A s pec t.c onc ern= "M obility " ) --> ex is t )} Co mpon ent E ac h am bient m us t have a M obility A s pec t.

(fro m Co m p o n e n ts)

Co nnec tor (fro m Co n n e cto rs)

0 .. n

{(s elf.A s pec t.c onc ern= "Coordination") --> ex is t )} E ac h am bient m us t have a Coordination A s pec t.

1..n

{(s elf.A s pec t.c onc ern= "Dis tribution" ) --> ex is t )} E ac h am bient m us t have a Dis tribution A s pec t.

1 1 0..1

1..n

A t tac h

- A Non-s ite c annot c ontain a S ite nor a G atew ay . -A s ite c annot c ontain a gateway nor other S ites . - A n arc hitec tural elem ent in a S ite that needs to ex it it als o has to have an enter

A m bient

(f ro m A tta ch e m e n ts)

1

c an c ontain Gat ew ay 0.. n

S ites 1

1

1..n

Non -S ites 1

0..n 0..n

(a) An Ambient in the Metamodel Ambient subAmbient

Distribution Aspect

Mobility Aspect

Coordination

Aspect

Distribution Aspect

Mobility Aspect

Coordinat ion

Aspect

Weaving

C om pone nt

Weaving « con necto r»

Conn ecto r

(b) Graphical notation of an ambient Fig. 4. The Ambient package in the Metamodel

the same ambient. Also, an ambient can have other subambients. This allows the hierarchy of distributed and mobile systems to be modelled in Ambient-PRISMA. An ambient offers two type of services to architectural elements located in it: mobility services and distributed architectural element services. Architectural elements that need these services are connected to the ambient through attachments (lines in Figure 4(b)). The AOSD view describes the PRISMA ambient with a set of aspects that can be weaved. Weavings indicate that the execution of an aspect service can trigger the execution of services in other aspects. Weavings are the glue of the aspects of an architectural element. This glue is defined using temporal operations called weaving operators. For example, if a weaving with the after operator is specified between service s1 of aspect A1 and service s2 of aspect A2, this means that s2 of A2 is executed after s1 of A1. The ambient uses different aspects to specify the services it offers and requests. As Figure 4(a) shows each ambient must have a Mobility, a Coordination, and a Distribution Aspect. These constraints are specified in the Object Constraint Language (OCL). As ambients are responsible for the mobility concern, all ambients must have the Mobility Aspect to provide mobility services to their local architectural elements. These services are the ones that provide the ambient calculus capabilities. The following are the Mobility Aspect functionalities:

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

-

1639

It allows an ambient to offer the exit service to the subambients that need to exit from it. (The specification of the AC exit capability). It allows an ambient to offer the enter service to the subambients that need to enter other subambients. (The specification of the AC enter capability). It allows an ambient to create subambients. (The specification of the AC restriction). It allows an ambient to accept a new ambient from external ambients. It allows an ambient to execute the open service. The open service allows a subambient to be destroyed without destroying its local architectural elements. As a result, the architectural elements of the destroyed subambient become part of the including ambient. (The specification of the AC open capability)

The separation of the Mobility Aspect concern from the rest of the concerns provides better maintainability of these functionalities because they are not scattered through the ambient specification. In addition, this is a generic aspect that must be reused by all PRISMA ambients. As a result, ambients are defined by importing the generic mobility aspect and adapting it to the needs of the software system through weavings. For example, a LAN ambient may need some security policies that are different from a PC ambient inside of the LAN. Therefore, both the LAN and PC ambient import the same Mobility Aspect, but the Mobility Aspect is weaved with different security aspects. The coordination aspect of an ambient is needed to coordinate its architectural elements with the exterior. This coordination aspect receives calls from external architectural elements of the ambient (distributed calls) and redirects them to corresponding architectural elements of the ambient. It also receives calls from its architectural elements and redirects them to the exterior. This aspect, like the Mobility Aspect, is also a generic one that all ambients must reuse. The Distribution Aspect of an ambient stores the name of its parent ambient. This aspect also specifies whether or not an ambient is mobile. A mobile ambient is an ambient that requests mobility services from its parent ambient. When an ambient is mobile, its parent ambient can be changed. In Ambient-PRISMA, we have defined three types of ambients: Sites, Non-Sites, and Gateways (see Figure 4(a)). This separation is necessary since each one of them has its own semantics and constraints. Sites are ambients that represent devices; that is, they have a physical address. A Non-Site is an ambient that represents a collection of software elements. A Non-Site can only have subambients of type Non-Site. This restriction is important because Sites cannot be located in Non-Sites. Also, a Non-Site can be located either in a Site or in another Non-Site. An example of one use of a Non-Site ambient is to move a group of architectural elements together. Another example of a use of a Non-site is to separate certain architectural elements in a Nonsite since they share some security protocols. A Gateway is a virtual ambient that groups either a collection of ambient Sites or other gateways. A Gateway ambient that consists of a collection of Sites represents the borders of a network (e.g. a Local Area Network). The modelling of a Gateway hierarchy can represent the hierarchy of LANs to form a Wide Area Network (WAN). Different gateway hierarchy levels can be represented in the software architecture depending on the software architect and on the distributed requirements. In Ambient-PRISMA there is always a default Gateway ambient that represents the Root.

1640

N. Ali, C. Millán, and I. Ramos

4.2 Case Study: Mobile Agents in an Auction Site Mobile Agents [18] are components that can move from one site to another in order to perform tasks in an autonomous way. Mobile agents are helpful as they solve problems that are encountered in distributed systems. Network bandwidth is reduced due to the fact that the agent is moved to a new site where it performs tasks locally instead of passing information through the network. Also, unreliable network connections are not a problem because once an agent has been sent to a site, the operations are locally performed and the results can be sent when a connection is re-established. Mobile Agents can be applied in different applications. In this paper we consider an electronic commerce application: an auction site where products are auctioned. A customer of this auction site is interested in buying a specific product with certain specifications at a maximum price. To keep track of the new auctions being performed on the auction site the customer designs two mobile agents to take charge of the purchase. One of these agents is responsible for collecting information and the other agent is in charge of managing the purchase. The two agents have to collaborate with each other. The customer sends the agents to the auction site. The agents act for the customer. When the purchase is performed the agents return to their original location. 4.2.1 The PIM of the Case Study Specified in the AOADL of Ambient-PRISMA To allow the definition of PIMs, a language has to be used. The language can be a graphical language such as UML or a textual language. A graphical language, which is user friendly, is an easy way to allow users to develop their PIMs. However, in order to formalize the semantics of a PIM, it is necessary to have a formal language. In this section we focus on our formal AOADL to describe the distribution and mobility characteristics of the PIM of the case study presented in section 4.2.

Fig. 5. The Initial Configuration of the Software architecture of the Mobile Agent Case Study

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1641

In the case study, the customer designs the agents: the purchaser and the collector. As the purchaser and the Collector need to collaborate with each other, a connector called AgentCnctr coordinates them. The customer locates these architectural elements in a Non-Site ambient called AgentsNonSite. The Customer software component is connected with the AgentsNonSite by a connector called AgentCustCnct. Initially, the Customer and the AgentsNonSite are located in the ClientSite. Figure 5 shows the configuration of the software architecture before the AgentsNonSite ambient is moved to the AuctionSite. In the AuctionSite, there is a component that represents the Auction. The AuctionCnct is a connector that coordinates the Auction with other architectural elements. As the Auction component can communicate with distributed architectural elements, the AuctionCnct has an attachment with AuctionSite ambient. Distribution Aspect ANSDistribution using IMobility, ICapability Attributes location : loc; Services … … changeLocation(Name: String, NewLocation:loc) Valuations [changeLocation()] location:=NewLocation; getLocation( output Location:loc) Valuations [getLocation()] Location:=location; out exit (Name: String, Parent:loc ); out enter (self.Name: String, NewAmbient: loc); … … Transactions move(NewAmbient: loc) move::= out exit(self.Name, location)ÆMOVE1; MOVE1::= {exitOK} out enter(self.Name, NewAmbient)ÆMOVE2; Preconditions in changeLocation(Name, NewLocation) if {self.Name==Name}; … … … End_Distribution Aspect ANSDistribution

(a)

Ambient_NonSite type AgentNonSite Import Mobility Aspect Mobile; Import Coordination Aspect ACoordination; Import Distribution Aspect ANSDistribution; Ports ECapabilitiesPort: ICapability; EDistServicesPort: ICall; EMobilityPort: IMobility; InServicesPort: ICall; InCapabilitiesPort: ICapability; InMobilityPort: IMobility; End_Ports … … End Ambient_NonSite type AgentNonSite;

(b)

Fig. 6. Specification of the AgentNonSite ambient and its distribution aspect

The mobility of the AgentsNonSite is initiated when the Customer component requests it to move to the AuctionSite. Figure 6(b) shows the specification of the AgentNonSite in the AOADL. The AgentNonsite receives the mobility request through its port, called EMobitityPort. This causes the execution of move(NewAmbient:loc) of the ANSDistribution Distribution Aspect that the ambient imports. Figure 6(a) shows the specification of the ANSDistribution aspect. The move(NewAmbient:loc) specifies that the AgentNonSite has to exit its parent ambient and then enter another ambient. The enter and exit services are served by the parent ambient of the AgentNonSite. The AgentNonSite then requests the exit(AgentNonSite, ClientSite) from the ClientSite through the port ECapabilitiesPort (see Figure 6(b)). The ClientSite receives this petition through its port InCapabilitiesPort (see Figure 7(b)). As a consequence, the Mobile Mobility Aspect is executed. Figure 8 shows a segment of the Mobility Aspect specified in the AOADL, which all ambients must reuse. It shows that the exit is a transaction that consists of a set of services. First, the exit checks if the requested element (AgentNonSite) is one of its children (is one of its local elements). Since the AgentNonSite is its child, the

1642

N. Ali, C. Millán, and I. Ramos

Distribution Aspect SiteDistribution Attributes location : loc; Services … … getLocation( output Location:loc) Valuations [getLocation()] Location:=location; … End_Distribution Aspect SiteDistribution

(a)

Ambient_Site type ClientSite Import Mobility Aspect Mobile; Import Coordination Aspect ACoordination; Import Distribution Aspect SiteDistribution; Import Security Aspect ClientSecurity; Ports ECapabilitiesPort: ICapability; EDistServicesPort: ICall; InServicesPort: ICall; InCapabilitiesPort: ICapability; End_Ports Weavings SiteDistribution.getLocation(Location) before Mobile.getParent(Parent); ………… End Ambient_Site type ClientSite;

(b)

Fig. 7. Specification of the ClientSite ambient and its distribution aspect in the AOADL Mobility Aspect Mobile using ICapability …. …. TRANSACTIONS in exit(Requested: String, Ambient: loc): EXIT := out isChild(input Requested, output isChildOK)Æ EXIT1; EXIT1::= {isChildOK==true & self.Name==Ambient} getParent(output Parent)ÆEXIT2; EXIT2::= moving (Requested,Parent); TRANSACTIONS in enter(Requested: String, NewAmbient: loc): ENTER := out areChildren(input Requested, input Ambient, output areChildrenOK)ÆENTER1; ENTER1::= {areChildrenOK==true} moving(Requested, NewAmbient); TRANSACTIONS in moving(Requested: String, NewAmbient: loc): …….. TRANSACTIONS in accept(input NewAmbient:loc, input Caller: loc, input Child:String, input Type:String, input AttachmentsList[]:Attachments, output AcceptanceOK:boolean): ACCEPT::= out addChild(input Type, input Child, input AttachmentsList[], output AddedOK) {Acceptance==AddedOK}Æ ACCEPT1; ACCEPT1::=out changeLocation(Child, self.Name); Preconditions in accept(input NewAmbient, input Caller, input Child, input Type, input AttachmentsList[], output AcceptanceOK) if {self.Name==NewAmbient}; … … End_Mobility Aspect Mobile

Fig. 8. A segment of an Ambient Mobility Aspect specified in the AOADL

ClientSite executes the getParent service in order to know who its parent ambient is. This service, as shown in Figure 7(b), has a Weaving with the SiteDistribution aspect. The service getLocation of Figure 7(a) is executed to provide the value of location. Figure 5 shows the ClientSite has the Root ambient as its parent. This is a default parent ambient for all sites and is of type Gateway as it is a virtual ambient. When the parent value is achieved, the moving transaction in Figure 8 is executed. Briefly, the moving transaction is in charge of removing the mobile architectural element (AgentNonSite) from the ClientSite, modifying its local attachments and ensuring that

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1643

the receptor (the Root) receives and adds it as its child. The result of the configuration after the execution of the exit is shown in Figure 9. The AgentNonSite ambient then requests the enter(AgentNonSite, AuctionSite) to the Root ambient. The Root ambient also has the Mobile Mobility Aspect shown in Figure 8. The Root ambient checks if the AgentNonSite and the AuctionSite are both its children. If they are, then it executes the moving transaction. When the moving transaction is finalized, the AgentNonSite ambient becomes a child of AuctionSite as shown in Figure 10. It could happen that AgentNonSite does not request an enter from the Root. As explained in Section 4.1, that a Gateway ambient can only have Site ambients or other gateways. Therefore, if the AgentNonSite ambient does not request an enter to another Site, the Root would send it back to the ClientSite.

Fig. 9. The Software Architecture when the AgentNonSite executes the exit

Fig. 10. The AgentNonSite becomes a child of AuctionSite

1644

N. Ali, C. Millán, and I. Ramos

As Figure 10 shows, the Customer component can still send commands to the agents of the AgentNonSite in the AuctionSite. This is achieved because all the attachments between the AgentCustCnct and the AgentNonsite (see Figure 5) have been replaced by attachments between these elements and their ambients (see Figure 10). Thus, distributed communication is performed through ambients. When the purchase agent in Figure 10 performs the purchase that the customer desires, it invokes the move of the AgentNonSite through the InMobitityPort (see Figure 6(b)). The entire process is repeated until the AgentNonSite returns to ClientSite ( the architecture configuration returns to the configuration shown in Figure 5). From the above example, we have seen how the distribution and mobile characteristics of a PIM, in this case of the Mobile Agent field, have been specified using an AOADL based on a defined metamodel. 4.3 Platform-Specific Model in .Net The PRISMA metamodel is supported in .Net by the PRISMANET middleware [19]. The PRISMANET middleware provides an execution platform for PRISMA aspectoriented software architecture configurations. For example, it contains classes that map the concepts of aspects, ports and attachments. Each PRISMANET middleware of a host can collaborate with PRISMANET middlewares on other hosts in order to provide a distributed runtime environment (see Figure 11). The runtime environment has a distributed Domain Name Server (DNS) where all middlewares on hosts can access. PRISMANET must be extended in order to provide the mobility and distributed communication of architectural elements that Ambient-PRISMA provides. Therefore, in this section a PSM is proposed for supporting Ambient-PRISMA based on PRISMANET.

Fig. 11. Distributed Runtime Environment of PRISMANET

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1645

Ambient-PRISMANET extends the PRISMANET middleware in order to include the ambient architectural elements. Figure 12 shows the class ArchitecturalElement that includes the common functionality of all architectural elements. All architectural elements are composed of aspects, weavings, and ports. The classes Component, Connector and Ambient inherit from ArchitecturalElement. Using the PIM of the case study defined in section 4.2 the Collector, the Purchaser, the Customer, and the Auction are represented in C# as classes that inherit from the class Component. The AgentCustomerCnct, the AgentCnctr and the AuctionCnctr are classes that inherit from the class Connector. ArchitecturalElement name : string componentThread : Thread middlewareServer : MiddlewareSystem aspectList : ArrayList weavingList : WeavingsCollection inPorts : InPortsCollection outPorts : outPortsCollection Start() Stop() Abort() AddAspect() RemoveAspect() AddWeaving() RemoveWeaving()

Component

Connector

Ambient ComponentsList : ArrayList ConnectorsList : ArrayList AmbientsList : ArrayList AttachmentsList : ArrayList AddComponent() RemoveComponent() AddConnector() RemoveConnector() AddAmbient() RemoveAmbient() AddAttachment() RemoveAttachment() GetAttachments()

AmbientSite

AmbientNonSite

Fig. 12. The Ambient inherits from ArhitecturalElement class of PRISMANET

The class Ambient provides services for managing the information related to the architectural elements of an ambient. These services can change the state of an ambient by adding or removing either architectural elements or attachments. For example in the case study, when the AgentNonSite ambient requests to exit from the ClientSite ambient, the ClientSite has to replace the attachments between the AgentNonsite and the AgentCustCnctr with attachments between the AgentCustCnctr and the port of the ClientSite that provides distributed communication. Therefore, an ambient needs services that facilitate the dynamic generation of attachments depending on its state. In addition, all ambients must have a Mobility Aspect, a Coordination Aspect and a Distribution Aspect. The Mobility and Coordination Aspects of an ambient must be reused by all ambients. Thus, they are predefined and the designers do not have to modify. As these aspects have a predetermined definition, they are included as specific types of aspects that inherit from the class AspectBase (the class that represents a PRISMA aspect). Figure 13 shows the class MobileAspect that maps the Mobile Aspect and ACoordinationAspect that maps the ACoordination Aspect. They are marked with the C# sealed modifier in order to represent that they cannot be extended by the user. The class MobileAspect publishes its interface through its port in order to offer the mobility services to its architectural elements. The interface of the predefined Mobility Aspect is shown in Figure 14.

1646

N. Ali, C. Millán, and I. Ramos

AspectBase aspectName : string aspectThread : Thread link : ArchitecturalElement queueCallAspect : Queue subProcessesList : SubProcessCollection StartAspect() StopAspect() AbortAspect() EnqueueService() DequeueMethod()





ACoordinationAspect

MobileAspect

Call()

Enter() Exit() Open() Replicate() Accept()

DistributionAspect location : loc GetLocation() ChangeLocation()

Fig. 13. The Aspects of an ambient public interface ICapability { AsyncResult Enter(string AmbientName); AsyncResult Exit(string AmbientName); AsyncResult Open(string Ambient); AsyncResult Replicate(string Ambient); AsyncResult Accept(string grandparent, string parent, string type, string children, ArrayList attachmentsList, out bool acceptanceOK); }

Fig. 14. The interface ICapability of the Mobility Aspect in C#

On the other hand, the distribution aspect of an ambient can be extended by the user. As a result, a class DistributionAspect that also inherits from AspectBase has been created. The class DistributionAspect implements the minimum functionality of a distribution aspect. That is, it stores the reference of the ambient location and the services needed for managing it. For example, the ANSDistribution aspect of Figure 6(a) inherits from class DistributionAspect extending it with the mobility requests. Moreover, the classes AmbientSite and AmbientNonSite have been introduced by inheriting from class Ambient (see Figure 12) in order to represent Ambient-PRISMA Site and Non-Site ambients repectively. Each of these classes expresses the restrictions of the type of ambient they represent. For example, AgentsNonSite ambient must inherit from the class AmbientNonSite to be implemented. In the same way, ClientSite and AuctionSite ambients inherit from AmbientSite to be implemented. Another Ambient-PRISMA concept that has to be treated is the virtual Gateway Ambient. At implementation this ambient has been decided to be the set of middlewares that collaborate to form the borders of the distributed runtime environment. In this way, the Ambient-PRISMANET middleware has a layer called DistributionLayer that is in charge of the distributed communication among hosts and the mobility of architectural elements between hosts.

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1647

In the case study, when the ClientSite needs to execute the exit requested by the AgentsNonSite ambient, the ClientSite has to call the Root ambient in order to request it to accept the AgentsNonSite. This call is mapped to a request that the ClientSite performs to the DistributionLayer of the middleware at its host. As a result, the DistributionLayer stores the state of the AgentsNonSite ambient and its associated attachments. When, the AgentsNonSite exits the ClientSite, at implementation the AgentsNonSite is neither part of the ClientSite nor part of the AuctionSite. When the AgentsNonSite executes the enter to the AuctionSite, the DistributionLayer fetches in the distributed DNS to find out where the AuctionSite exists in order to create a proxy to the DistributionLayer of the middleware where the AuctionSite exists (the receptor). Then, the DistributionLayer of the middleware where the ClientSite exists (the sender) starts the serialization of the AgentsNonSite ambient and its contents. When the DistributionLayer of the receptor receives the serialized ambient, it calls the accept of the AuctionSite ambient. In this way, the DistributionLayer of the receptor acts as the local view of the parent of the AuctionSite (the Root Gateway ambient). The middleware establishes a timeout from the moment that the AgentsNonSite exits the ClientSite ambient. If the timeout expires, the mobility process is considered to be failed. This failure is due to the fact that a Non-Site ambient can only stay in this intermediate state for requesting an enter to a Site ambient. It is important to mention, that all the operations related to mobility are transactional. This implies that once a failure occurs at any point of the transaction, the operations performed must be undone in order to return to the state previous to the mobility process, i.e. returns the AgentsNonSite to the ClientSite.

5 Conclusions and Further Work In this paper, we have shown how ambient calculus can be used in software engineering to develop distributed and mobile applications. These applications, which are based on ambient calculus, can be developed using AOSD and CBSD techniques. The concepts of ambient calculus have been introduced into an aspect-oriented and component based metamodel (PRISMA) in order to achieve Ambient-PRISMA. Ambient-PRISMA provides the construction of distributed and mobile software systems by reusing and adapting specifications. Ambient-PRISMA has been able to specify the distributed and mobile characteristics of the software architecture of a mobile case study. This has been done in a platform-independent way through MDE. In order to execute distributed and mobile applications based on Ambient-PRISMA, a PSM has been proposed. This PSM supports the implementation of ambient calculus in C#, with the characteristic that it preserves the traceability of the concepts of Ambient-PRISMA. In the near future, we are going to take advantage of the ambient calculus primitives concerned with security. These primitives will be specified using our AOADL so that the case study presented in this paper could be extended to incorporate security properties. In addition, we are going to introduce the concepts presented in this paper into the PRISMA tool to be able to model and execute mobile distributed software architectures in an intuitive way. This will be done in three

1648

N. Ali, C. Millán, and I. Ramos

stages: first, a complete implementation of the concepts of Ambient-PRISMA will be introduced in the PRISMANET middleware [19] to execute these concepts; second, ambient graphical metaphor and code templates will be introduced in the modelling framework in order to automatically generate code from the graphical metaphor; third, the implementation will be validated by modelling and executing a complex, distributed, and mobile case study.

References [1] Schmidt, D.C. "Model-Driven Engineering". IEEE Computer 39 (2), February, 2006. [2] OMG, 2003. MDA Guide, http://www.omg.org/docs/omg/03-06-01.pdf [3] Szyperski, C., Component Software: Beyond Object Oriented programming, ACM Press and Addison Wesley, New York, USA, 2002. [4] Filman, R., Elrad, T., Clarke, S., Aksit, M. Aspect-Oriented Software Development, ISBN: 0321219767. [5] Perez, J., Ali, N., Carsí, J.A., Ramos, I. “Dynamic Evolution in Aspect-Oriented Architectural Models”, European Workshop on Software Architecture, Pisa, June 2005 © Springer LNCS vol n.3527. [6] Cardelli, L. “Abstractions for Mobile Computation.” In Vitek, J. and (Eds.), C. J., editors, Secure Internet Programming: Security Issues for Distributed and Mobile Objects, volume 1603 of LNCS, Springer Verlag, pp. 51-94. [7] Pérez, J., Ali, N., Carsí, J.A., Ramos, I. “Designing Software Architectures with an Aspect-Oriented Architecture Description Language”, 9th International Symposium on Component-Based Software Engineering (CBSE),Västerås , Stockholm, Sweden, LNCS, June 29th -1st July 2006 (accepted to appear) [8] Magee, J., Dulay, N., Eisenbach, S., Krammer, J. “Specifying Distributed Software Architectures”. 5th European Software Engineering Conference (ESEC 95), Sitges, Spain, 1995, pp 137-153. [9] Milner, R., Parrow, J., Walker, D. “A calculus of mobile processes”, Parts 1-2. Information and Computation, 100(1), 1992, pp. 1-77. [10] Magee, J., Tseng, A, Kramer, J. “Composing Distributed Objects in CORBA”, Third International Symposium on Autonomous Decentralized Systems, Berlin Germany, 1997, pp 257-263. [11] Virginia C. de Paula, G.R., Justo, Cunha, Ribeiro, P. R. F. “Specifying Dynamic Distributed Software Architectures”, XII Brazilian Symposium on Software Engineering, BCS Press, October, 1998. [12] Ciancarini, P., Mascolo, C. “Software Architecture and Mobility”, 3rd Int. Software Architecture Workshop (ISAW-3), November, 1998. [13] Mascolo, C. “MobiS: A Specification Language for Mobile Systems”. 3rd International Conference on Coordination Models and Languages, 1999. [14] Medvidovic, N., Rakic, M. “Exploiting Software Architecture Implementation Infrastructure in Facilitating Component Mobility”. Software Engineering and Mobility Workshop, Toronto, Canada, May 2001. [15] Lopes, A. Fiadeiro, J.L., Wermelinger, M. “Architectural Primitives for Distribution and Mobility”, 10th Symposium on Foundations of Software Engineering, SIGSOFT FSE 2002, pp. 41-50. [16] Cardelli, L. “ Mobile Ambient Synchronization” SRC Technical Note Report 1997-013, Digital SRC, 1997.

Developing Mobile Ambients Using an Aspect-Oriented Software Architectural Model

1649

[17] Vasudeva, E., Joshi, Rushikesh K. “A Scheme for Implementing Ambient Calculus over an ARC Framework”, Software Design and Architecture Workshop, Dec 2004, IIIT Bangalore (position paper). [18] Chess, D., Harrison, C., Kershenbaum, A. "Mobile Agents: Are They a Good Idea?" IBM Research Report RC. [19] Perez, J., Ali, N., Costa, C., Carsí, J.A., Ramos, I. “Executing Aspect-Oriented Component-Based Software Architectures on .NET Technology”,3rd International Conference on .NET Technologies, Pilsen, Czech Republic, May-June 2005 , 2005