Policy-based model-driven engineering of pervasive services and the ...

Policy-based model-driven engineering of pervasive services and the associated OSS K Yang, S Ou, M Azmoodeh and N Georgalas

This paper presents our work towards a fully functioning platform for pervasive service engineering in an operational support services (OSS) context for an ICT service provider. The focus of the paper lies in a proof-of-concept for a novel means to develop and execute pervasive services, with simplicity and maintainability as prime drivers. The essence of this approach is the novel integration of the policy-based management (PBM) techniques and the model-driven architecture (MDA) techniques for specifying pervasive services and their behaviour, together with auto-generation of middleware implementation and policy enablement. The presence of policies provides pervasive services with the high flexibility and adaptability needed for dealing with changing environments and resource availabilities, while the introduction of MDA for defining pervasive service information models fundamentally solves the information modelling puzzle of current policybased approaches. Additionally, MDA’s middleware-neutral feature benefits the smooth evolution of pervasive services as a piece of software artefact in the face of heterogeneous devices and platforms. A preliminary case study has demonstrated the practical feasibility and benefits of this approach. The case study revolves around an ICT service called TEANU — transparent enterprise access for nomadic user. The service provides a means for nomadic users to maintain a secure access to their enterprise network in the presence of multiple access network providers with different service level guarantees.

1.

Introduction

Following the mainframe age and the desktop computing era, we are now entering the age of pervasive (or ubiquitous) computing [1]. Driven by the increasing pervasiveness of networks and networked devices, telecommunications industries have already begun to shift part of their attention from traditional core network support services to pervasive services that are targeted more on the individual end users where numerous potential revenues lie. A pervasive service (PS) can be a simple service such as helping a user on a mobile device (such as a PDA or a smart-phone) to find their favourite restaurant in a vicinity according to their current location or simply find a nearby printer to print out their presentation slides — or it is a combination of the above-mentioned small services (called component services). For example, a virtual office environment (VOE) service could enable a user on a PDA to continue their normal office work such as dealing with e-mails, and editing the presentation slides left on office desktop machines even while waiting for boarding at Heathrow airport. Because of the constrained resources of a PDA, this service may need to find a surrogate computer nearby to store the slides if the presentation is too big, or even request the surrogate (which is usually wire162

BT Technology Journal • Vol 23 No 3 • July 2005

connected to the Internet and as such has much higher bandwidth than the wireless mobile devices) to download the slides on their behalf after successful authorisation. If an important e-mail contains a video clip whose decoder is not available on their PDA, then the VOE service will automatically search for such a decoder and install it. If the VOE service is smart enough, it might convert the e-mail text into voice if the user is moving in a queue (i.e. unable to read the text) with earphones on. The procedure of composition, delivery and management of such a pervasive service is termed as pervasive service engineering. This exemplar pervasive service demonstrates the highly dynamic nature of pervasive services, which is mainly caused by the increasing diversities of customers, the types of device, their usage and their requirements (with variability based on time, location, etc). Pervasive services should have the potential to run at any time, anywhere, and on any device without (or with little) user attention. As users move from one place to another, they will expect their tasks to logically ‘follow’ them around. Such mobility requires a shift of software engineering from large, monolithic applications with a fixed user interface mode and task logic

Policy-based model-driven engineering of pervasive services and the associated OSS

to composing services from collections of loosely coupled small components. In a pervasive environment, it is highly likely that the hardware and software resources available to a mobile user in a certain environment will change as resources and users move in and out of that environment. A pervasive service should be able to adapt itself to these changes so as to take advantage of the new situation. For instance, if a visitor from Spain has just arrived whose mobile device has an English-Spanish e-translator, then another tourist from Mexico who is located within one-hop wireless transmission of this Spanish visitor may well use this translation software to translate English text into Spanish. Service adaptability is an important characteristic of pervasive services. These two important features of pervasive services, namely mobility and resource availability, are usually highly coupled, as the need for service adaptability is often due to mobility. One way of providing service adaptability, as widely employed in the current literature, is to build up a powerful middleware infrastructure and deploy it into the environment where the pervasive service will possibly execute. The MIT Oxygen project [2], which emphasises the environment enhancement technologies, and Portolano Project [3] at the University of Washington, among others, are typical of this approach. However, due to the heterogeneity of environments in which a pervasive service is about to operate, this deployment sometimes can be difficult. An opposing trend to tackle this problem, is to miniaturise this middleware. Then the classical trade-off problem between size and functionality arises. A recent publication is dedicated to the emerging PS supporting middleware [4]. While we appreciate the necessity of the presence of a middleware infrastructure, we attempt to tackle the mobility and adaptability requirements of PS from another angle, i.e. the inner logic of pervasive service itself, which is largely neglected in the related research work. To this end, firstly a flexible means of describing the logic of a pervasive service needs to be specified, a means that can inherently grant adaptability to pervasive services while considering the code mobility at the same time. This self-contained adaptability cannot be achieved at the source code level because, at the time of coding a pervasive service, there is no way to know exactly when, where and how a potential user will use this service. We propose to utilise policies to describe the PS logic at a higher level. The notion of policy employed here is a concept borrowed from policybased management (PBM) [5], a successful technique widely researched for IP network management [6].

We utilise a policy (a rule) to define a choice in the behaviour of a pervasive service. The policies whose conditions satisfy the particular environment will be activated automatically by an event-driven policy decision engine. In this context, the internal logic of a pervasive service is in the form of a bundle of policies with no particular order — and the pervasive service itself is a collection of these policies, plus a policy decision engine that reasons over these policies. Underpinning this policy decision engine is a pervasive service information model (PSIM) that provides the object-level implementation of these policies (i.e. the behaviours of the service). PSIM could be extremely complex and difficult to manage or update if it were to consider the many diverse user requirements, devices, etc, and most importantly the diversity of software tools and platforms. To tackle the complexity of this problem, a hierarchical PSIM is proposed in this paper which makes use of model concept (in the sense of OMG (object management group) model-driven architecture (MDA) [7]) to separate the system design part of the PSIM from its real implementation part (classes, code). Furthermore, with the continued development of MDA itself, there is a significant potential to automate the whole procedure of pervasive service composition. To our knowledge, the work presented in this paper is the first attempt to utilise MDA for policy information modelling. By using policies to define the task logic of pervasive services, and various high-level models to specify the design and implementation views of the pervasive services, which is aided by dynamic service discovery mechanism (not covered in this paper), a systematic and simpler way of engineering pervasive services is created. Such an approach provides an inherent improvement for adaptability of pervasive services. Furthermore, this improvement is not at the cost of a complex middleware infrastructure. As will be demonstrated later in the paper, we are targeting a minimised supporting environment, ideally requiring only a standard Java Virtual Machine (JVM) plus some necessary service discovery software. Although the methodology (i.e. the combination of PBM and MDA) has been presented from the PS engineering’s perspective, the same approach can be equally applied to the operational support systems (OSS) engineering. At the same time, pervasive services developed by traditional telcos and network operators such as BT will take advantage of their existing OSS and associated services (such as billing, trouble ticketing, etc) to enable the practical provisioning of these pervasive services. The remainder of the paper is structured as follows. Section 2 discusses the background and rationale BT Technology Journal • Vol 23 No 3 • July 2005

163

Policy-based model-driven engineering of pervasive services and the associated OSS

behind our approach for pervasive service engineering with both policy-based and model-based capabilities. The following sections describe how this approach is practically implemented. Section 3 provides an analysis of a pervasive service and its most important feature, i.e. context-awareness. A typical pervasive service example called TEANU is used for this purpose. The section finishes with a meta-model for pervasive services in general. The entities summarised in the section also help guide the design of the policy-based pervasive service description language — PoPSiDL, which is described in section 4. Using TEANU as an exemplar, section 5 presents the complete procedure for composing a pervasive service using both policies and MDA. Some related works are discussed in section 6 and conclusions and future work are presented in section 7. The Appendix gives the TEANU service description in the PoPSiDL language.

2.

Background and rationale

This paper utilises policies (in the form of rule: IF THEN ) to describe the choice of pervasive service behaviours under different conditions, and this description is kept separate from implementation. The rich flexibility inherent in policy-based management technique matches very well with the high dynamic nature of pervasive services. In this way, adaptability applies to the service itself rather than the supporting environment. One of the most important parts of a PBM system is its policy information model which bridges the highlevel declarative policies and real operations on devices [6, 8]. In order to have an operational policy-based PS, a PSIM needs to be developed. This is in the form of a policy information model, that provides a complete implementation for the operations described by the policies. Currently, the dominant work on policy information models is being carried out by the IETF Policy Working Group [8], in close collaboration with DMTF (Distributed Management Task Force). IETF has defined the PCIM (Policy Core Information Model) [8] and its extension as an overall guidance for any further domain-specific policy information model, such as IP VPN, DiffServ, etc. As such, one straightforward way to build PSIM would be to extend the IETF PCIM to make it support pervasive service features. However, this approach has not proved possible for the following reasons. IETF PCIM was originated for network management purposes and as such it lacks serviceoriented features, making it neither easy nor appropriate to extend its structure to facilitate service features. At the same time, the class hierarchy of PCIM, while loose in the sense that there is no clear semantics associated with it, is also rigid in terms of the way the classes are organised. Another barrier to extending PCIM to pervasive service modelling lies in the way 164

BT Technology Journal • Vol 23 No 3 • July 2005

PCIM defines commonly used facts/information. Facts/ information in PCIM are usually defined as attributes with classes operating on them. This leads to significant data redundancy in a policy repository, which inevitably reduces the efficiency of the whole PBM system. Since attributes are confined within the specific classes, it is difficult to share attributes that express common information among different classes. It is especially a problem in pervasive services where there is enormous common contextual information available for use by any authorised user. Clearly, there is a need to separate these public attributes from the classes using them. Furthermore, the current PCIM and its extensions have no policy definition language support at the top. All these indications point to a need to exploit a new policy information model for pervasive services. To provide this independence from middleware platforms, this paper employs the MDA approach to express PSIM.

2.1

MDA for pervasive service information model

MDA [7, 9] is an approach to IT system development fostered by the OMG. Its essence is the concept of separation between the specification of a system’s essential functions as a platform-independent model (PIM) and the realisation of the system using a more specific and detailed platform — a platform-specific model (PSM). Its promising platform-, language- and middleware-neutral features will affect the current methods and techniques applied to manage the software development process. This paper explores how the MDA approach can be used to specify PSIM. As depicted in Fig 1, by employing MDA for PSIM, a layered and more flexible PSIM can be achieved. For instance, any change made internally to the implementationindependent part of the PSIM (iiPSIM) will not affect the implementation. Similarly, any change to the implementation-dependent part of the PSIM (idPSIM) (e.g. change to a new implementing technique or language) will be kept transparent to iiPSIM. The OMG MDA defines the components for constructing model-driven applications; however, it does not specify concrete techniques for each component. In order to make MDA useful in practice (e.g. using it for real pervasive service provision), specific techniques need to be provided for each MDA component. The techniques employed in this paper are shown at the bottom of Fig 1 (in italic). A newly developed pervasive service description language called PoPSiDL (detail in Section 4) is used to describe a pervasive service and this description corresponds to a PIM. Among a number of MDA tools currently available, the XMF tool-kit from Xactium Ltd [10] was used to help build up meta-models and

Policy-based model-driven engineering of pervasive services and the associated OSS model-to-code transformation

model-to-model transformation MDA components

platform independent model

platform specific model

PSIM

implement independent PS information model

implement dependent PS information model

proposed techniques

PoPSiDL

Fig 1

XMF MicroJava meta-model

Pervasive service analysis and modelling

Before embarking on the pervasive service description language and pervasive service meta-model study, an analysis of features common to most pervasive services is needed. This is carried out via a typical pervasive service scenario study. This scenario is deliberately made with more network orientation, which reflects our intention to show a gradual evolution, to pervasive services, of traditional telecommunications services that are more core-network related.

3.1

code

Java

MDA components for PSIM.

models. XMF is a generic meta-programming environment that aims to support a wide variety of MDA development scenarios [8]. It already implements a MicroJava meta-model as a PSM (platform-specific model) language and its transformation to the corresponding Java source code. A PIM conformant to XMF PIM format can also be mapped to MicroJava PSM by XMF. The adoption of this MDA tool significantly simplifies our PSIM modelling work and is able to make us focus on PoPSiDL and its transformation to XMFcompliant PIM. We assume all the functions of a pervasive service described via PoPSiDL could be implemented by Java. Given the fact there are plenty of Java-based reference implementations for ICT OSS and other functions, this is a reasonable assumption. Part of our future work will be to look into utilising techniques more oriented towards pervasive services (such as OSGi [11]), or specialising in telecommunications operations (such as OSS/J [12]), etc. So far, the generation of PSIM has been turned into a matter of transforming PoPSiDLbased service description into a PIM in XMF.

3.

code

Scenario description

Here an imaginary future ICT service called TEANU (Transparent Enterprise Access for Nomadic User) is described. The service provides a means for nomadic

users to maintain secure access to their enterprise network transparently after they have subscribed to the pervasive service from a service provider, such as BT. Consider Julie, a medical professor in a famous university, always with a busy schedule for medical consultation around Europe. Julie works from home several days a week, using her broadband home network that is connected to the consulting hospital’s network to transfer materials including large-sized scan pictures. One day, when she was working on an important medical case that had to be sent out by 4:30 pm that day, she received an emergency call from her university and had to go there immediately. On the way to the university, she luckily finished the last part of the case analysis and needed to submit her analysis result together with a large number of images to the consulting company. Immediately she used her laptop and an embedded GPRS modem to set up a network connection. Unfortunately, the bandwidth of the GPRS network was insufficient, and transferring these large files would take several hours, far passing the deadline. However, luckily enough, she had subscribed to the new TEANU service that detected the bandwidth problem and tried to find a resolution. In the scenario the TEANU service found out that there was an appropriate WLAN access point in the university, and as such it dynamically switched the network connection to the faster wireless LAN when Julie arrived at the university. At the same time, a secure tunnel was established automatically between her university and the consulting company. Julie was then connected to the local network in order to deliver the file more quickly. She noticed happily that the significantly increased file transfer speed enabled her important BT Technology Journal • Vol 23 No 3 • July 2005

165

Policy-based model-driven engineering of pervasive services and the associated OSS

what we mean by context in our work, and how to classify it, are explained below.

medical analysis to be submitted successfully before the deadline — this possibly could save a life. The whole scenario is depicted in Fig 2.

3.2

The term context is overloaded with a wide variety of meanings [13]. The concept given by Dey [12], which constrains the context to those existing only between a user and an application (indicating the origination of context-awareness research — human-computer interface (HCI)) is extended in this paper to include networks, so as to cover all the entities involved in a pervasive service. Actually, all the entities appearing in the policy pre-conditions of a PS are regarded as the contextual information to this particular PS. As such, the context used in a PS is any information, obtained either explicitly or implicitly, that can be used to characterise a certain aspect of an entity that is involved in a specific application or network service. An entity can be a physical object such as a person, a place, a router, a GPRS network gateway, a physical link, or a virtual object such as IPsec tunnel, or a simple network management protocol (SNMP) agent.

Analysis of pervasive service and context

Describing it in an abstract way, this PS scenario typically involves a user (Julie) using her user device to access a function (file uploading) provided by a certain provider through her access network (GPRS or WLAN) and the core network. We assume the functions made available by such providers are part of the core network (it makes sense from the user’s point of view) and hence there is a separate network for the function provider. A function can be of any type (and consequently different function providers being involved), for instance, videostreaming where a content provider is involved, language translation where a third party service provider is involved, or a tourism information retrieval where an information service provider is involved, or a secure IPsec tunnel set-up where a network infrastructure provider is involved. Furthermore, one individual function can be provided by multiple providers.

The context also needs to be classified so as to guide the design and implementation of context classes in PSIM. A proper classification of context types will help application designers decide the most likely pieces of context that will be useful in their applications. The above-mentioned definition of context germinates our development of context classification at a high level. Schilit et al [14] list the important aspects of context as where you are, who you are with and what resources are nearby. This list does not consider time a major critical factor. Ryan et al suggest context types of location,

There may be other ways of extracting these features. This paper adopts a practical means that considers the final implementation of pervasive services. Namely, entities are taken into consideration that play different roles and are located within different physical and administrative domains. The adaptability of a pervasive service comes from its context-awareness [1]. Before working on the pervasive service modelling itself, an investigation into

xDSL ISP

home

Internet

l ne

RS

er id

IPs ec

tun

GP

ov pr

university

WLAN AP

Fig 2

166

BT Technology Journal • Vol 23 No 3 • July 2005

A pervasive service — TEANU.

consulting company

Policy-based model-driven engineering of pervasive services and the associated OSS

environment, identity and time [15]. Dey thinks that there are certain types of contexts that are, in practice, more important than others, and these are location, identity, activity and time [16]. Sharing the same idea as proposed by Dey, we utilise location, identity, time, and activity as basic context types for characterising the situation of a particular context entity, as depicted in Fig 3. identity

location located at

identified by entity at time time

Fig 3

involved in activity

Please note that some of the context types also act as indices into other sources of context information. For example, given a person’s identity, we can acquire many pieces of related information such as telephone numbers, addresses, e-mail addresses, list of friends, relationships to other people in the environment, or even the emotion of this person. Such items of information are related to the basic context and called derived context (e.g. the e-mail address) for that entity. Items of context information can be related to one another. For example, with an entity’s location, we can determine what other devices or people are near the entity and what activity is occurring near the entity.

3.3

Classification of context in terms of entity.

This context classification clearly answers the questions of who (identity), where (location), when (time), and what (activity) for a specific context entity. This contributes to one dimension of context information classification — we call it horizontal because it describes the features common to most of the context entities. The vertical classification of context information is about context entity itself, which can be categorised using the entities worked out above

Fig 4

to describe the role of an entity involved in a typical pervasive service, i.e. user, user device, function, function provider, access network, and core network.

Meta-modelling pervasive services as a domain-specific language

In summary, the following six entities are usually involved in a typical PS — user, user device, function, function provider, access network, and core network, each having, apart from their own attributes, four extra attributes, namely, identity, time, location and activity. These artefacts constitute the meta-model for PIMs of a specific domain — PervasiveService, as depicted by XMF in Fig 4. In MDA terminology, this meta-model is a kind of domain-specific language. At the highest level, this PS

Pervasive service meta-model.

BT Technology Journal • Vol 23 No 3 • July 2005

167

Policy-based model-driven engineering of pervasive services and the associated OSS

modelling language consists of the following constructs, each representing a corresponding class of the XMF XCore package that already has a well-defined executable semantics defined in the XMF tool.

•

Entity Entity represents one of the above-mentioned six types of context information in a PS. It extends the class Root::XCore::Class so that it contains attributes, operations and constraints, and can be instantiated.

•

EntitySpec EntitySpec represents the configuration of entities, mainly in terms of constraints, such as range of values or preconfigured settings on features of the entity. Correspondingly, the API specification defines six subtypes of EntitySpec, each representing specification for one of the six entities respectively. EntitySpec specialises XCore:Constraint and is owned by an Entity and contains an OCL (Object Constraint Language) expression that can be evaluated.

•

EnvironmentSpec EnvironmentSpec in the same way as EntitySpec, represents the configuration of four special EntityAttributes, namely, time, location, identity and activity. Correspondingly, the API specification defines four subtypes of EnvironmentSpec, each representing specification for one of the four attributes respectively. EnvironmentSpec also specialises XCore:Constraint and contains an OCL expression that can be evaluated.

•

EntityAttribute EntityAttribute represents relationships between entity types and the four extra items of context information associated to each entity, namely, time, location, identity and activity. It inherits the class XCore::Attribute and is used to associate different entity types.

A number of constraints, expressed in OCL, apply to the above PS modelling language. As an example, the following OCL constraint states that if an entity a extends another entity b then a has to be of the same type as the parent entity, that is: context Entity @Constraint SameSuperClassType superClass->select(s | s.isKindOf(Entities::Entity))>forAll(s | s.of() = self.of()) end 168

BT Technology Journal • Vol 23 No 3 • July 2005

s.of( ) is an XOCL (executable OCL) operation that returns the super-class of an entity.

4.

Policy-based pervasive service description language (PoPSiDL)

A policy-based pervasive service description language (PoPSiDL) is proposed here which can be used by a PS provider or developer to specify/update the possible behaviours (actions) of this PS under different circumstances (conditions) in the form of policies. As suggested by the IETF Policy Framework Working Group, which has been investigating policies as a means for managing IP-based networks for many years, policies take the following rule-based format: IF {condition(s)} THEN {action(s)}.

It means action(s) is/are taken if the corresponding condition(s) is/are true. Policy condition can be in both disjunctive normal form (DNF, an ORed set of AND conditions) or conjunctive normal form (CNF, an ANDed set of OR conditions). To consider the potential policy conflict and its resolution and to deal with uncertainty, this IETF policy format is further extended in this paper to the following format: IF THEN

denotes the level of priority of a policy in comparison with other policies and it is to be used for policy conflict resolution. denotes the overall uncertainty of the policy, and it is an indicator as to how much this PS (namely, the PS composer or the PS subscriber) trusts this piece of policy. Both and can also have an uncertainty factor associated with them. The presence of an uncertainty factor in a policy provides a means to describe (and as such to tolerate) the vagueness or uncertainty of a piece of information (represented by policy conditions), or intended action (denoted by policy actions), or a whole strategy (policy itself), aiming to increase PS’s ability to cope with more complex circumstances. For the sake of description simplicity, the remainder of the paper utilises the default value (‘1’) to these two parameters, meaning ‘same priority’ and ‘100% certain’ respectively. By using this format, as many as necessary policies can be defined to describe the behaviour of a pervasive service. For example, the TEANU service mentioned above can be described by PoPSiDL as shown in the Appendix. Due to the space limitation, the formal the syntax description (using extended BNF) of PoPSiDL and

Policy-based model-driven engineering of pervasive services and the associated OSS

the policy decision engine that reasons over PoPSiDL policies are not included in this paper. Please refer to the Web site [17] for details. The example shows that the policies are divided into different groups called modules. A module is a specific set of policies that aims to fulfil a particular network or service task. Grouping policies into a number of modules makes the logical structure of the PS description clearer to the service developer, and reduces the searching space when performing policy reasoning (i.e. decision making). Parallel operation of independent modules can improve the performance of pervasive services. Different modules may co-operate with one another. For instance, some input of one module may come from the output of another module. As an example, the securityLevel variable of a Common Service module in the TEANU service comes from the UserInfoModule. Each pervasive service corresponds to such a PoPSiDL description file (.psd). The policies specified in this file, maybe in collaboration with some network-specific policies imposed by the network administrator for example, are analysed by a policy decision engine (or policy decision point — PDP in PBM terms) to guide the operation of this pervasive service. In PoPSiDL, policies serve as the containers of context information. All the information used in policy conditions is regarded as context information. These can change frequently and dynamically, such as user

Fig 5

location, user device type (such as its screen size), most of the network information, e.g. queue length, available bandwidth, are registered to the corresponding monitoring daemons so as to be monitored instantly. A sufficient change of such context (e.g. beyond a certain threshold) will generate an event, which will then be captured by the policy decision engine to make a proper decision.

5.

Pervasive service TEANU composition — a case study

5.1

Creation of TEANU PIM

After the PS modelling language and PS description language have been defined, as described in the previous two sections respectively, it is time to transform policies into PIM (PIM is part of PSIM — refer to Fig 1). However, before this, a PIM specific to this TEANU service needs to be created with guidance from the PS meta-model. Fig 5 illustrates the PIM of this TEANU service. This TEANU PIM also indicates that all the building blocks in this diagram (including the relationships between two blocks) are sub-classes of the classes defined in the general PS modelling diagram in Fig 4. For instance, Laptop1 is an instance of meta-class UserDevice, whereas BT is an instance of meta-class 1

The italic font in this paragraph is specifically used to denote these blocks appearing in the TEANU PIM diagram (Fig 5).

PIM of the pervasive service TEANU.

BT Technology Journal • Vol 23 No 3 • July 2005

169

Policy-based model-driven engineering of pervasive services and the associated OSS

FunctionProvider. As such, this model is an instance of the pervasive service meta-model. For the sake of simplicity, this diagram only illustrates the highest-level entities and some of their specifications comprising the service. In this TEANU service, the customer makes use of four different types of networks: GPRS, WLAN, the Internet and their consulting company’s enterprise network (EnterpriseNetwork), via their laptop (or handheld) in order to do file Transmission. An IPsec tunnel may be set up by calling EstablishIPsec function between the WLAN gateway in the WLAN access network and the ingress router of the EnterpriseNetwork depending on the customer’s security level. In TEANU, both EstablishIPsec and Transmission functions are provided by one function provider, BT. Individual features of the entities are defined in the accompanying xxxSpec constraints, e.g. Laptop by LaptopSpec, Internet by InternetSpec, Transmission by TransmissionSpec, and BT by BTSpec, etc. Particularly, BTSpec defines the specifications and constraints imposed by the BT OSS system. Since all model entities of Fig 5 are instances of PS meta-classes that inherit Entity, which, in turn, extends class Root::XCore::Class, they inherit the ability to have constraints, attributes and operations (and their associated specialisations, namely, EntitySpec and EntityAttribute). As an example, the LaptopSpec, associated with Laptop, has the following OCL body which defines the protocols that could be used by this user device. self.Laptop.protocol = "FTP" or self.Laptop.protocol = "HTTP") and self.Laptop.protocol "RTP"

However, more constraints that are specific to a type of pervasive service, such as TEANU, must be specified to confine the service’s behaviours. This is how the policies, which are employed to describe the service’s behaviours, come into the MDA models, particularly the platform-independent model.

5.2

Constraining TEANU PIM with TEANU policies

Again using the TEANU service example, the following piece of policy extracted from TEANU’s PoPSiDL description (refer to TEANU.psd in Appendix 1) describes the condition to establish an IPsec tunnel: CS001: IF UserDevice.protocol == "ftp" AND transmission.destIPaddress == ConsultCompanyAddress and securityLevel >= 5 THEN EstablishIPsec ,

This piece of policy is translated into the following XOCL in TEANU PIM: 170

BT Technology Journal • Vol 23 No 3 • July 2005

context TEANU @Operation WLANIPsecOp(SrcIP:NetworkSpec, DestIP:NetworkSpec, User:String, Password:String) ...... if self.User.securityLevel >= THRESHOLD_IPsec and self.UserDevice.protocol = PROTOCOL.ftp and DestIP = self.ConsultCompany.IPAddress then EstablishIPsec(SrcIP, DestIP, User, Password) end

The following policy in TEANU’s PoPSiDL description exemplifies how OSS services could be connected to the pervasive service composition and, furthermore, to be managed and engineered by policies and MDA. Billing is a typical OSS service and the example policy shown below states: ‘... if the TEANU customer is using IPsec then the bill will be increased by 20%’. Georgalas and Bagley [18] complement this by describing a comprehensive solution to this issue: CS003: IF IPsecOn == TRUE THEN billingTariff.increaseBy(20) ;

Its corresponding XOCL format in TEANU PIM is as follows: context TEANU @Operation BillingOp() ...... if self.IPsecOn then billingTarrif.increaseBy(20) end

Currently this procedure is carried out manually. With the research work going on, this procedure will be (semi-)automated in our future work. After all the policies in TEANU.psd are translated to the constraints of TEANU PIM, a complete TEANU PIM is ready for the next step — being transformed to PSM and Java source code.

5.3

Transformation of TEANU PIM to PSM/Java

A MicroJava PSM and its corresponding transformation to MicroJava (a micro version of Java programming language) have been implemented in XMF. And each element in the PS meta-model, and in turn each element in TEANU PIM, is a sub-class of XCore::Class. As every element in the XCore package has a mapping to a corresponding element in the MicroJava PSM (i.e. the Java meta-model), then the mapping from TEANU

Policy-based model-driven engineering of pervasive services and the associated OSS

PIM to MicroJava PSM is straightforward and supported by XMF.

PDA physical address, different role in the enterprise network).

One of the mechanisms provided by the XMF tool to transform PIM to PSM/MicroJava is XMap. The model illustrated in Fig 6 shows how XMap was used to provide this transformation by means of mappings. A mapping consists of a sequence of clauses describing pattern matches which take an object with a specific structure and matches it with another object of another structure. In the diagram, a mapping is represented by an arrow from source objects (the domain) to target objects (the range), and it contains pattern matches between their values. An example of a simple pattern match is described by the following XMap code:

TEANU’s execution is event-based and usually follows the following procedure: the change of the context information (and in turn the conditions of TEANU policies) generates a certain event which triggers the reasoning of the policy decision point (also the service execution engine) over all TEANU policies; then certain action(s), or no action, if none of the conditions of the policies is satisfied, will be taken. A policy decision engine based on forward reasoning has been implemented, which also facilitates the uncertainty processing.

context Entity2Java @Clause AccessNetwork_Clause0 PervasiveService::AccessNetwork [name = A,attribute = B] do Languages::MicroJava::Class [name = A, body = O] where O = B->collect(t | AccessNetwork2JavaClass()(t)) End

The source code for TEANU service has now been generated. After the compilation and deployment stages, the TEANU service is fully created and is ready to be subscribed to by customers. Every subscription of the TEANU service creates an instance of TEANU service with personalised information (e.g. different laptop or

Fig 6

6.

Related work

As far as the policy-based management (PBM) is concerned, our work is not just to apply existing PBM techniques to the network aspect of pervasive services nor to concentrate on the building-up or extending of the standard-based information model as most do (e.g. Policy Core Information Model (PCIM) by IETF, Core Information Model (CIM) by DMTF, Parlay policy management APIs). While being aware of the importance of these two sides of PBM research, this paper gives specific emphasis on the policy-based description of pervasive service, and a practically functioning pervasive service information model. The fact that there is not any reference implementation for IETF PCIM or DMTF CIM makes PBM hard to put into practice. Most importantly, our work endeavours to introduce PBM into the new field of ‘pervasive service’

Transformation of TEANU PIM to Java.

BT Technology Journal • Vol 23 No 3 • July 2005

171

Policy-based model-driven engineering of pervasive services and the associated OSS

engineering and in a practical manner. There have been activities of employing PBM for service engineering, a typical example of which is OSA/Parlay [19]. However OSA/Parlay is dedicated to providing a set of open and standard policy management APIs and its current focus is more on the provisioning of traditional telecommunications/network services with little emphasis on mobile (wireless) services. Furthermore, there is no policy language mentioned. It follows more or less an ‘information model’ path. Ponder [20], from Imperial College London, provides an impressive policy specification language but with particular interest on security issues. Finin et al of University of Maryland Baltimore [21] recently introduced a policy language for a pervasive computing environment, but their policies were more like a Prolog statement and their focus was not on service engineering in particular. In our work presented in this paper, the policy language is actually a pervasive service description language. This paper also investigates the potential of employing OMG MDA for expressing PSIM in a hierarchical way and automated generation of code (including the skeleton of code) to be used by a pervasive service. Similar work has not been found in the current literature. Though the adoption of MDA as a means to describe and express a policy information model is mainly driven by the insufficiency of current policy information models, MDA’s middleware-neutral feature also benefits the smooth evolution of a pervasive service as a software artefact. Because the MDA is platform-independent at its core, adding new middleware platforms, such as OSGi which is specific for building pervasive systems, will be straightforward as long as the corresponding OSGi PSM is provided. Actually OMG members are currently trying to incorporate more middleware into the MDA as different mappings, and this makes MDA a more promising technique for future software engineering (and, in particular, pervasive service engineering).

7.

Conclusions and future work

This paper presents a novel method for engineering pervasive services by making use of a combination of PBM and MDA techniques. The use of policies improves the flexibility in describing the service logic and provides service developers with an easy way to describe services. MDA provides a well-defined path from abstract pervasive service descriptions (using PoPSiDL) to the executable source code of a general network language (Java), while keeping the separation of system design from system implementation. The successful composition of a typical pervasive service called TEANU has demonstrated that this is a promising path. An ICT service cannot operate properly without the support from OSS. This paper also illustrated how OSS could be 172

BT Technology Journal • Vol 23 No 3 • July 2005

used for supporting the TEANU pervasive service and how policies were used to express OSS-related components (e.g. billing). However, this paper only presents a first step of our work towards a pervasive service engineering platform which is policy-based, model-driven and has full integration with OSS systems. As part of the future work, a user-friendly interface is to be developed to ease the creation of the PoPSiDL descriptions, and to make it precise by validating these descriptions against the PS meta-model. While providing useful modelling support, the XMF tool used in our current work also limits in some way our freedom of making use of software platforms other than MicroJava. A framework that integrates the PoPSiDL parser, context registration, and MDA modelling and mapping functions is to be developed, specifically for pervasive service development, deployment, execution and maintenance. The automation of model-to-model and model-to-code transformation is the long-term research target. Another facet of our future work is to apply the approach (i.e. the combination of policies and MDA) to OSS capabilities as integral components on pervasive services.

Appendix TEANU service description in PoPSiDL (TEANU.psd) PS TEANU # Control Information MODULE UserInfoModule BEGIN_M UI001: IF User.role == manager THEN securityLevel=10 ; UI002: IF User.role == consultant THEN securityLevel=5 ; UI003: IF User.role == employee THEN securityLevel=3 ; UI004: IF User.role == non-employee THEN securityLevel=0 ; UI009: IF User.contactAllowedAttribute == TRUE THEN UserDevice.setAvailability (TRUE) ; ...... END_M MODULE PersonActivityModule ... MODULE TransmissionActivityModule ... MODULE GPRSModule BEGIN_M GPRS001: IF gPRSConnected == FALSE AND networkAccess == TRUE THEN UserDevice.establishGPRSConnection(); GPRS002: IF tearDownGPRSConnection == TRUE THEN UserDevice.closeGPRSConnection(); ... ... END_M

Policy-based model-driven engineering of pervasive services and the associated OSS

MODULE WLANModule ... # other modules MODULE CommonService BEGIN_M CS001: IF UserDevice.protocol == "ftp" and transmission.destIPaddress == ConsultCompanyAddress and securityLevel >=5 THEN EstablishIPsec ; CS002: IF wLANdeviceAvailable == TRUE AND UserDevice.protocol == "ftp" THEN UserDevice.handOverToWLAN() ; CS003: IF IPsecOn == TRUE THEN billingTariff.increaseBy(20) ; ... END_M ENDPS

14 Schilit B and Theimer M: ‘Disseminating Active Map Information to Mobile Hosts’, IEEE Network, 8, No 5, pp 22—32 (1994).

15 Ryan N S et al: ‘Issues in developing context-aware computing’, in Gellersen H-W (Ed): ‘Handheld and Ubiquitous Computing’, LNCS-1707, pp 208—221, Springer-Verlag (September 1999).

16 Dey A K: ‘Providing Architectural Support for Building ContextAware Applications’, PhD thesis, Georgia Institute of Technology (November 2000).

17 PoPSiDL grammar — http://privatewww.essex.ac.uk/~kunyang/ PoPSiDL/PoPSiDL-BNF.doc

18 Georgalas N and Bagley C: ‘Using policies in highly configurable component-based NGOSS’, BT Technol J, 23, No 3, pp 149—161 (July 2005).

References 1 Satyanarayanan M: ‘Pervasive computing: vision and challenges’, IEEE Personal Communications Journal, 8, Issue 4, pp 10—17 (August 2001). 2 Decasper D, Dittia Z, Parulkar B and Plattner B: ‘Router plugins: a software architecture for next-generation routers’, IEEE/ACM Transactions on Networking, 8, Issue 1, pp 2—15 (February 2000). 3 Esler M, Hightower J, Anderson T and Borriello G: ‘Next Century Challenges: Data-Centric Networking for Invisible Computing — The Portolano Project at the University of Washington’, Proc of the Fifth ACM/IEEE International Conference on Mobile Networking and Computing, pp 256—262 (August 1999). 4 ‘PS Supporting Middleware’, Special Issue, IEEE Journal of Pervasive Computing, 3, No 3 (2004). 5 Sloman M: ‘Policy Driven Management For Distributed Systems’, Journal of Network and System Management, 2, No 4, pp 333— 60 (December 1994). 6 Yang K, Galis A, Mota T and Gouveris S: ‘Automated Management of IP Networks through Policy and Mobile agents’, Proc of Fourth International Workshop on Mobile Agents for Telecommunication Applications (MATA2002): LNCS-2521, Springer, Barcelona, Spain, pp 249—258 (October 2002). 7 Model Driven Architecture — http://www.omg.org/mda/ 8 IETF Policy Framework Working Group — http://www.ietf.org/ html.charters/policy-charter.html 9 Georgalas N, Azmoodeh M, Clark T, Evans A, Sammut P and Willans J: ‘MDA-Driven Development of standard-compliant OSS components: the OSS/J inventory case-study’, Proceedings of the Second European Workshop on Model Driven Architecture with emphasis on Methodologies and Transformations (EWMDA 2004), Canterbury, UK (September 2004). 10 Xactium — http://www.xactium.com/ 11 OSGi Alliance — http://www.osgi.org/ 12 OSS through Java Initiative — http://www.ossj.org/ 13 Dey A K and Abowd G D: ‘Towards a better understanding of context and context awareness’, Proceedings of CHI2000 Workshop on the What, Who, Where, When and How of ContextAwareness, The Hague (April 2000).

19 Stretch R M: ‘The Parlay API — allowing third party application providers safe and secure access to network capabilities’, BT Technol J, 21, No 3, pp 141—159 (July 2003).

20 Dulay N, Lupu E, Sloman M and Damianou N: ‘A Policy Deployment Model for the Ponder Language’, Proc IEEE/IFIP International Symposium on Integrated Network Management (IM’2001), IEEE Press, Seattle (May 2001).

21 Kagal L, Finin T and Joshi A: ‘A Policy Language for a Pervasive Computing Environment’, Proc IEEE 4th International Workshop on Policies for Distributed Systems and Networks, Lake Como, Italy (June 2003).

Kun Yang is on the academic staff of the Department of Electronic Systems Engineering, University of Essex, UK. Before that he worked at E&EE-UCL on several EU IST projects. His main research interests include pervasive service, mobile ad hoc and sensor networks, and Grid computing. He has published about 15 journal papers and books. He is an organiser or TPC member of several international conferences.

Shumao Ou is currently a PhD student in the Department of Electronic Systems Engineering, University of Essex. He obtained an MSc with distinction from the same department and a BEng from the National Technical University of Defence, China. His research interests include pervasive computing, context-aware computing, policy-based services, distributed systems, operation support systems, model-driven development, and software engineering.

BT Technology Journal • Vol 23 No 3 • July 2005

173

Policy-based model-driven engineering of pervasive services and the associated OSS

Dr Manooch Azmoodeh, after 5 years lecturing at Essex University and researching intelligent database models and graphical query languages, moved to BT. Since then he has been active in various aspects of research into designing management systems for broadband networks and services, and lately researching technologies to build the next generation of OSS. He leads a team looking into technologies such as model-driven development, policy-based management, and autonomic computing to automate much of the OSS integration of BT systems across all ICT infrastructure and services.

174

BT Technology Journal • Vol 23 No 3 • July 2005

Nektarios Georgalas holds a Diploma in Electrical and Computer Engineering from University of Patras, Greece, an MPhil in Computer Science from UMIST, Manchester UK and is currently completing his PhD in Computer Science at the University of London. He joined BT in 1998. He has since been actively involved in, and managed, numerous collaborative and internal research projects in areas such as active networks, market-driven data management systems, policy-based management, distributed information systems and Web Services. He currently leads the NGOSS/ MDA Catalyst project in TMF, manages the MDA aspects of the CelticMADEIRA project, technically directs the Model-driven Process-based OSS/J Component Integration project and looks into opportunities to downstream results of the MDA work into the LoBs through a number of case studies. He holds 5 patents and has authored more than 18 papers.