Solutions

We design U-CAF, Ubiquitous Context Adaptation Framework. Figure 7 illustrate this framework. It is revised from X-CAF [15]. Ubiquitous Context Adaptation Framework (U-CAF) contains software development kit and application programming interface, and service components. In this framework, we design context adaptation PUML/PGML translation, agent migration to approach our objectives.

SDKs and APIs:

We design mobile designer, which is a GUI-based UI authoring toolkit with the visualized fashioning functions using drag-and-drop and WYSIWYG (What You See Is What You Get) measures to accelerate the development of user interfaces of applications on mobile execution environments. Currently, we have designed APIs for the development of the front-end module (Figure 7) and the back-end module (Figure 7).

Context adaptation:

The use of the context profile to decide proper components [16][17] in application adaptation is a critical issue. In this paper, we aim to develop an attribute-based algorithm that decides components appropriately by using dynamic and static context information (CC/PP and WAP UAProf profiles ). These applied information will be explained in Chapter 2.

PUML/PGML transformation:

One is named Pervasive User interface Markup Language (PUML), which can describe user interfaces for applications on the small devices; the other is named Pervasive loGic Markup Language (PGML) to represent the computational logic of

applications.

Agent migration:

As a result, certain components of an application with heavy computing load can be enveloped into the back-end module and run at the server side. For follow-me, a personal agent [16][17], which can not only be anchored at a certain server to serve its owner, but also can carry back-end modules of applications as migrating among servers with its owner. This provides the flexibility for application developments.

Section 1.3 introduces the means of the objectives. The following table shows the relationship of objectives and solutions. To approach our objectives, we attempt the technologies introduced above. The following table shows the methods we design.

These techniques will be explained in the later sections.

Tab. 1 the relationship of solution and objective Solution

Rapid Development

Adaptability Flexibility Seamless-use System Easy-upgrade SDK and API GUI toolkit &

API Context

awareness W3C CC/PP

WAP UAProf W3C CC/PP

WAP UAProf

Adaptation Context

adaptation Context

adaptation

Transformation PUML/PGML PUML/PGML PUML/PGML

Transformation Stylesheet Agent

Migration

FAM, HAM,

LAM objective

Fig. 7 The solution we propose

This paper is organized as follows. After an overall introduction to the context adaptation and transformation framework, we show context adaptation in Chapter 2.

We will describe the essential aspects of PUML/PGML transformation in Chapter 3.

Chapter 4 presents a system implementation and then explains the software development kit. In Chapter 5, we introduce the development steps on our system.

Then, some related works are listed in Chapter 6. Finally, we discuss related work and conclusion.

Chapter 2 Context adaptation

In this chapter, we will explain the context awareness and adaptation process we attempt to use. We divide context information into to types. And to adapt applications, we structure an application, and use XML-based profile to describe it. Section 2.1 and 2.2 explain context awareness and the process for adaptation, respectively.

2.1 Context-awareness

To approach context adaptation, we collect two kinds of context information. The context information can be collected from many kinds of resources, such as http request with CC/PP and WAProf information, and the detected information from sensor devices, like, RFID. We divide them into two categories: Static and Dynamic, shown in Table 2.

Tab. 2 the types of context information

Semantic Media Format Static context

information

device capability

Description File Access /

Web Resources W3C CC/PP WAP UAProf Dynamic

context information

Context information detected at runtime

RFID

ZigBee internal format

The use of the context profile to decide proper components in application adaptation is a critical issue. In this paper, we aim to develop an attribute-based algorithm that decides components appropriately by using CC/PP and WAP UAProf profiles.

Nokia8310

Fig. 8. A segmentation of Nokia 8310’s WAP UAProf profile

Figure 8 illustrates a profile of WAP UAProf in RDF format. The Resource Description Framework (RDF) is a general-purpose language for representing information on the Web. This description covers six parts describing some characteristics of devices: Hardware Platform, Software Platform, Network Characteristics, BrowserUA, WAP Characteristics, and Push Characteristics. As in Figure 8, Hardware Platform specifies the hardware properties of devices. These properties include prf:Keyboard, prf:NumberOfSoftKeys, prf:ScreenSize, and prf:ScreenSizeChar, whose values can be PhoneKeypad, 2, 84x30, or 10x3 respectively. Listing 1 demonstrates the XML serialization form of the context profile in RDF.

Listing 1. The XML serialization form of the profile in Figure 8

1<?xml version="1.0"?>

2 <rdf:RDF ...>

3 <rdf:Description rdf:ID="Nokia8310">

4 <prf:component>

5 <rdf:Description rdf:ID="HardwarePlatform">

6 <rdf:type rdf:resource= "http://www.wapforum.org/profiles 7 /UAPROF/cppschema-20010430#HardwarePlatform"/>

8 <prf:Keyboard>PhoneKeypad</prf:Keyboard>

9 <prf:NumberOfSoftKeys>2</prf:NumberOfSoftKeys>

10 <prf:ScreenSize>84x30</prf:ScreenSize>

11 <prf:ScreenSizeChar>10x3</prf:ScreenSizeChar>

12 <prf:StandardFontProportional>

13 Yes

14 </prf:StandardFontProportional>

15 <prf:Vendor>Nokia</prf:Vendor>

16 <prf:Model>8310</prf:Model>

17 <prf:TextInputCapable>Yes</prf:TextInputCapable>

18 </rdf:Description>

19 </prf:component>

20 ...

21 </rdf:Description>

22 </rdf:RDF>

Figure 9 shows Gateway of Gateway (G²), a system we implemented. The left-hand side is the RFID subsystem. There are three components containing tags, locators, and a reader. A user takes a tag. A locator is placed in a location, like in a room. When a user carrying tag enters a room, a locator will trigger this tag to send the user’s ID information. Then the reader will receive this information.

Fig. 9 RFID application

2.2 Context adaptation process

2.2.1 Application structure

We divide the application into two parts: the front-end module and back-end module.

The front-end module contains two main constituents: an image display that can show images, and a requester that can send requests and receive the replied images. This module executes on the client device. The back-end module consists of four constituents: Image Transmitter, Cache, Image Retriever, Transcoder, and Data Access.

In this module, Image Transmitter is responsible for receiving clients’ requests and replying the required images. Image Retriever can obtain the requesting images from the biological multimedia information provider through Data Access. Next, it will pass the images to Transcoder for transforming images, such as image resizing, or to the cache for subsequent retrieving of images immediately. The following lists the possible procedures to retrieve the required images that the student wants to collect:

z 1→2→3→4→5→6→12→13: The procedure means that when Image Transmitter receives the user’s request, the required images are obtained from the information provider.

z 1→2→7→8→9→12→13: This process refers to obtaining the required image from Cache.

z 1→2→7→8→9→10→11→12→13: This indicates that passing the images to Transcoder for resizing the images after Image Receiver gets the images in the second bullet, and then transmitting the result to the requester.

Figure 11 shows an application, which is structured hierarchically. This application is composed of more than one function that could be implemented by at

least one component. The application structure exhibited in Figure 10 can also be expressed in the form of the two-level hierarchy demonstrated in Figure 11. As we can see in Figure 11, each function links to candidate components. The function Image Retriever, for example, links to three components, JPEG Retriever, GIF Retriever, or PNG Retriever. This indicates that the function Image Retriever can be implemented by the three components.

Image

2: request 3: retrieve

6: return

9: return 7: save

11: return 10: transform 12: return

Type 1 Component Type 2 Component Type 3 Component

Legend

Fig. 10. The back-end module of the application Image Gathering

Components, in our system, are classified into three categories: Type1, Type2, and Type3. Type 1 components have the characteristics inclusive of stateful, relative, and immoveable. The stateful property means that the component records some particular data. For instance, Image Cache for the cache function belongs to this category. In contrast, specifying the stateful property No means that the components do not keep track of any particular data. If we declare a component as relative, it is associated with certain resources, and these components have database or TCP/IP connections. For example, the components of the function Data Access need to be

declared as this type, since it connects to the database of the multimedia provider over the networks. Another moveable property is used to modify the components that fail to be carried in agent migration.

ImageCache Size

Tailor Resizer

Transcoder Cache

Image Retriever

HTTP Connector

Image Transmitter

MS Access

Data Access Image

Gathering

JPEG Retriever

GIF Retriever

PNG Retriever

Application

Function

Component

Fig. 11. The structure of the application ImageGathering

Type 1 components are the components connecting to certain resources. As demonstrated in Figure 10, candidate components of the function Data Access belong to this type. Type 2 components are those components which can be moved. The component Image Cache (in Listing 2) is declared as this type. Type 3 components are usually certain algorithms or pure computational logics, such as the XML transformation engine javax.xml.transform.Transformer. The following table arranges the three types of components.

Tab. 3 Three categories of components Type Stateful/

Stateless

Relative/

Irrelative

Movable/

Immovable Example Type 1 stateful Relative immoveable Database

Access Type 2 stateful Irrelative moveable Cache Type 3 stateless Irrelative moveable Transcoder

2.2.2 Attribute-based component decision algorithm

Take a profile Q for example. The profile Q includes a set of attributes, which can be expressed as {a_i | 1≤i≤n}, where a_i and n denote an attribute and the total number of the attributes in the profile individually. Let

} 1

1

| { )

(a_i av_i,k i n and k_i v_i

domain = _i ≤ ≤ ≤ ≤ indicate the domain of the attribute a_i, and ]value[a_i to be the value of the attribute, where v_i is the number of possible values of a_i. For instance, Listing xxx involves the attributeTextInputCapable, which has value[TextInputCapable]= yes and domain(TextInputCapable)={yes,no}.

An agent body contains a number of applications. An application comprises one or more functions fun₁, fun₂, ..., fun_m. Each of them can be implemented by at

least one component, ^{i i} _rⁱ

compi

comp

comp₁, ₂, ..., , where 1≤i≤n and r denotes _i the number of the user-defined components implementing fun . For example, _i fun₁ can be implemented by components comp₁¹ and comp¹₂ (illustrated in Figure 11).

Each component comp_y^x has a constraint set CS_x,y, which contains zero or more tuples (a_i, av_i,ki), where 1≤i≤n and 1≤k_i ≤|domain(a_i)|, annotated under each component shown in Figure 12. We can accomplish the testing of a component to see if it can be chosen to implement its corresponding function by using this constraint set. For a component comp^x_y, if for the given profile Q, comp^x_y can be

chosen, it must be true that each attribute value av_i,ki of (a_i, av_i,ki) in its CS_x,y is equal to the value of the same attribute a in _i Q. If so, we say that the component is satisfied. For example, assume that a certain profile and two components comp₁¹

and comp¹₂, and the function fun₁ are given. The component comp₁¹ has the constraint set {(ColorCapable, yes)} and comp¹₂ has {(ColorCapable, no)}. Because the value of the same attribute ColorCapab in this profile isle yes , comp₁¹

is satisfied. comp₁¹ can be chosen to implement fun₁ accordingly. A constraint set, in implementation, can be established by a <constraints> element in the ASCC description. As in Listing 2, Lines 9-10 describe two elements,

<prf:ImageCapable> and <prf:CcppAccept>. Therefore, the component

11

comp is declared suitable for processing JPEG files. As a result, the constraint set )}

/ ,

( ), ,

1 {(

,

1 ImageCapable yes CcppAccept image jpeg

CS = will be generated.

A component decision tree can be seen as a tree hierarchy. It comprises a number of attribute nodes, each of which has several branches linked to other attribute nodes as its child nodes. Let an_i,di indicate an attribute node, which is semantically equivalent to the attribute a with the same name in the given profile Q. Let _i av_i,ki denote a branch of an attribute node an_i,di , where 1≤k_i ≤|domain(a_i)|, d is _i between 1 and the component number at the same level in a tree, and 1≤i≤n.

Each attribute node an_i,di has a linked component set LC_i,dithat includes the components associated via dotted lines in the component decision tree, illustrated in Figure 12. As in the figure, the linked component sets of the attribute nodes an _3,1 and an_3,2 are }LC_3,1={comp_1,1, comp_2,1 and LC_3,2 ={comp_2,2} respectively.

. . .

Function Component Component Decision Tree

fun1

Fig. 12 A component decision tree and its linked components

To operate a component decision tree, there are a pointer cursor, and two operations, NEXT(an_i,di,an_i+1,di+1) capable of moving cursor from an attribute node an_i,di to its child node an_i+1,di+1, and VISIT(an_i+1,di+1) representing cursor visiting an attribute node an_i+1,di+1. Taking Figure 11 for example, the pointer cursor will point to the attribute an_3,1 since the operation NEXT(an_2,1,an_3,1) is applied.

Thereupon an is visited, denoted by _3,1 VISIT(an_3,1). Furthermore, let t denote a traverse from the root to a certain leaf node. A traverse t, a sequence of VISIT() and

()

VISIT >. In Figure 12, for instance, a traverse t starts from the attribute node

1

Accordingly, while a traverse t is built, the linked component set LC_i,di of each

attribute node an_i,di visited can be united to establish a proper component set

For example, suppose that there is a profile {ImageCapable, CCPPAccept, JavaPlatform, ...}, and their domains can be expressed domain(ImageCapable)={yes, no}, domain(CCPPAccept)={yes, no}, etc. Figure 13 demonstrates the structure of functions and components of an application. The function Image Retriever can be implemented by three components: JPEGRetriever, GIFRetriever, and PNGRetriever.

The constraint set of the first component is CS_1,1 ={(ColorCapable, yes), (CcppAccept, image/jpeg)}, and that of the second component is

2 ,

CS1 ={(ColorCapable, yes), (CcppAccept, image/gif)}. Moreover, in the component decision tree, each attribute node an_i,di has a number of branches and a linked component set LC_i,di. As in Figure 13, the attribute node ImageCapable has two branches, yes and no. The attribute node CCPPAccept has three branches encompassing image/jpeg, image/gif, and image/png. In addition, the attribute node

1 ,

an is JavaPlatform whose linked component set is 3 LC ={JPEGRetriever}, and _3,1 that of an_3,2 is LC_3,2 ={ImageRetriever}.

Let us assume that a traverse t is made by moving cursor from the root an _1,1

(ImageCapable) to the leaf node an (JavaPlatform). As a result, the sequence _3,1

SEQ(t)=<VISIT(ImageCapable), NEXT(ImageCapable, CCPPAccept), VISIT(CCPPAccept), NEXT(CCPPAccept, JavaPlatform), VISIT(JavaPlatform)> and

the proper component set of t, P(t)={JPEGRetriever} are established.

Function Component Component Decision Tree

Fig. 13 An instance of a component decision tree on the right-hand side, and the associated components of the application ImageGathering on the left-hand side

The problem of how to decide a proper component to implement each function f, if given an application p and each function f of the application p?; or of how to adapt an application p, can be solved through the attribute-based component decision algorithm. This is because SEQ(t) and P(t) will be generated after traversing from the root to a leaf node. In SEQ(t), NEXT(an_i,di,an_i+1,di+1) implies VISIT(an_i,di) and words, for a traverse t the proper component set P(t) contains the components, which are satisfied. Specifically speaking, given an application, if the suitable component exists for each function, this component can be chosen from P(t). Moreover, if there are two or more suitable components at the same time, the last-examined component will be chosen as default. This algorithm solves the problem and eliminates the need for traversing a tree from the root to a leaf node. Once sufficient components exist in the proper component set P(t), traversing a component decision tree can terminate at

some internal attribute node which is not a leaf node.

In implementation, instead of realizing this algorithm by using the data structure tree, we realize this algorithm by means of a linking list. The reason for this is that using the tree as the data structure consumes more memory space to choose proper components. For each attribute node an_i,di at the same level of a component decision tree, the information recorded for the nodes seems different, except for the linked component set LC_i,di . However, they are essentially identical. Take the previous profile Q and the tree in Figure 12 for example. At level 3, an , _3,1 an_3,2,

3 ,

an3 , andan_3,4 are semantically equivalent to the attribute a in the profile Q. ₃ Therefore, to implement the concept tree, we use a linking list. In this way, for each level in a tree, attribute nodes an_i,di, for all d , where _i 1≤i≤n and 1≤d_i ≤v_i, are regarded as one node in a linking list. Figure 14 represents a linking list that starts from the root attribute node connecting to its child attribute node in the tree as the next node, which also links to its child node as the next node, and so on. This hierarchy of the linking list equals that of the component decision tree. In this list, an attribute node an has two links: one connects to a child attribute node _i an_i+1; the other binds its linked component set (a hash table in practice). In Figure 14, for example, the linking list, kept by a table index, starts from the attribute node an₁ to the attribute an₄, each of which binds a linked component set. For instance, the attribute node an retains a link component set containing two components ₃ comp₁¹ and comp¹₂.

Fig. 14 The implementation (linking list) of a decision tree

Figure 15 illustrates the implementation of the component decision tree (Figure 12). Symmetrically, by traversing from the root node Image Capable to the node Java Platform, the proper component JPEG Retriever for the function Image Retriever can be decided.

Component Decision Tree

Table Index

Attribute Node

Linked Component Hash Table

Function

fun1

Component comp₁¹ comp¹₂ comp¹₃

an2 an₄

an1 an₃

Component Decision Tree

ColorCapab {(CcppAccept,image/fig)}

)}

Fig. 15. The linking list of the decision tree illustrated in Figure 13

In our system, we apply an attribute-based component decision algorithm to the application adaptation. Applications carried by the agent are adapted when the agent migrates to a new CAAS server. Implementing the component decision tree by a linking list simplifies the maintenance of attribute nodes. The space complexity is the

sum of linked component hash tables | _idi

di all

LC_,

∑

| for all i, where 1<i≤M . It is

less than n_m*M, where n is the number of attributes, and M is the size of the _m max linked component hash table. Besides, M is a constant. Therefore, the space complexity is O(n_m).

In terms of time complexity, the time complexity is constant for the attribute-based algorithm as the processing time does not depend on the number of components. By contrast, we can consider a simple algorithm that decides proper

y

CSx_, for each componentcomp_y^x. This costs O(n_c∗n_m) worst-case time, where n denotes the total number of components of an application, and c n =max(|_m CS_x,y|) indicates the total number of attributes. The cost of the attribute-based algorithm is merely affected by the length of the linking list (the height of the component decision tree). In addition, the link can be built from the attributes in CS_x,y for all

components comp^x_y in an application instead of generating from all attributes in a given profile. Therefore, its time complexity costs n =max(|_m CS_x,y|). This means that the time complexity is dominated by the size of the max constraint set. As it can be seen, using the attribute-based algorithm to support decisions about component selection, facilitates programming of adaptive applications. It can support a large scale

components comp^x_y in an application instead of generating from all attributes in a given profile. Therefore, its time complexity costs n =max(|_m CS_x,y|). This means that the time complexity is dominated by the size of the max constraint set. As it can be seen, using the attribute-based algorithm to support decisions about component selection, facilitates programming of adaptive applications. It can support a large scale

在文檔中 延伸性與可適性在行動執行環境的研究 (頁 25-0)