Applying Ontology in Architecture-Based Self ... - CiteSeerX

Applying Ontology in Architecture-Based SelfManagement Applications Yu Zhou

Jian Pan

Xiaoxing Ma

Bin Luo

Xianping Tao

Jian Lu

State Key Laboratory for Novel Software Technology Nanjing University, China 210093, Nanjing, China

{zhouyu,panjian,xxm,luobin,txp,lj}@ics.nju.edu.cn an adequate context model also plays an important role in selfmanagement systems, because,

ABSTRACT Context-awareness is the premise of self-management applications. In this paper, a Middleware for Adaptive Coordination (MAC) architecture is proposed. It supports the cycle from modeling and reasoning about the context knowledge to planned architecture-based self-management actions. One of the key elements of our approach is the explicit modeling of context by Web Ontology Language based on which the logic reasoning is performed. Besides, an internal object-oriented architectural self-management mechanism is proposed. A prototype of MAC is also given followed by a case study with quantitative evaluations.

i) From a systematic point of view, an adequate context model will increase the representation ability and facilitate the following feedback process;. ii) An adequate context model may also help to avoid the communication problem among different systems due to the lack of common understanding. Software architecture [5-7] offers a coarse-grained view of the system at the level of interacting components and connectors. Architecture-based self-management is mapped to the reconfiguration of components and connectors. Thus architecturebased self-management systems have a better reusability and tractability, besides since components usually contain functional code while connectors contain coordination counterpart, this separation of concerns promises a vision of less difficult consistency control during reconfiguration. In the light of the above considerations, our self-management mechanism takes an architecture-based approach.

Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures; I.2.4 [Artificial Intelligence]: Knowledge Representation Formalisms and Methods; K.6.3 [Management of Computing and Information Systems]: Software Management

Keywords

The rest of the paper is organized into 6 sections. In Section 2, some necessary background of Ontology and OWL (Web Ontology Language) [8] is reviewed. In Section 3, our approach is explained in detail, comprising of context modeling, reasoning and reaction mechanism. In Section 4, the implementation issues are addressed. In Section 5, a case study with performance evaluation is demonstrated followed by related work and concluding remarks given in Section 6 and 7 separately.

Software architecture, self-management, context, ontology.

1. INTRODUCTION In recent years self-management systems have been proposed as a recipe to cope with the trend of more variable execution environments. In a certain abstraction level, this kind of systems generally consists of detecting and reacting steps. To designers, the question becomes when and how to change. In a more concrete level, designers have to consider the context modeling, context sensing, decision making and execution feedback which form a closed cycle. A considerable amount of current work on self-management systems emphasizes on how to change, among which the architecture-based approach [1, 2] is more active.

2. ONTOLOGY AND OWL In this section, we introduce some basic concepts about ontology and OWL for the convenience of later discussions.

Context-awareness is an active subject in pervasive computing research [3]. Various context models and reasoning mechanisms have been proposed in recent years [4]. We believe

Ontology is a concept in philosophy concerned with the nature of existence. For knowledge-based systems, the term means a specification of a representational vocabulary for a shared domain of discourse -- definitions of classes, relations, functions and other objects, as in software literatures, what “exists” is exactly that which can be represented [9].

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’07, March 11-15, 2007, Seoul, Korea. Copyright 2007 ACM 1-59593-480-4/07/0003…$5.00.

To support ontology, several requirements should be met, such as, a well-defined syntax as well as semantics, efficient reasoning support and sufficient expressive power etc [10]. Among those candidates, Web Ontology Language (OWL) is our choice for its generality. OWL is a semantic markup language for publishing and sharing ontology proposed by W3C’s Web Ontology Working Group. It is developed as a vocabulary extension of Resource Description Framework (RDF) and is

97

derived from the DAML+OIL [8]. OWL follows the XML syntax style and has the advantage of platform-independence. The following considerations motivate us to use OWLencoded ontology to model the context. From the perspective of knowledge engineering: i)

Uniform context concepts facilitate knowledge sharing. ii) Implicit context information can be logically reasoned. iii) Standard representation also facilitates knowledge reuse. iv) Formal methods can be employed. From the perspective of middleware design: i) ii) iii)

Figure 1. Two-layer context classification In Section 1, we have stated that our self-management mechanism is based on software architecture. To help modeling it, the concept of architectural style is employed. An architectural style defines a family of systems in terms of a pattern of structural organization [6], and a specific application architecture can be regarded as an instance of a particular architectural style. Some known styles are master/slave, client/server, pipe/filter etc. As the architectural style poses a set of general constraints on how the components and connectors can be combined, this property can help contribute to the consistency control over architectural reconfigurations.

Uniform framework facilitates application development. Available reasoning engines exist. Consistent representation helps interaction among different applications.

3. APPROACH Our initiative attempts to abstract the common facilities to form a reusable infrastructure for the development of selfmanagement systems. As stated above, in macro sense, we believe self-management systems have two elements to adapt itself, that is, monitoring and reaction. The former addresses when to change, while the latter emphasizes how to. In the following subparts, we will explain our approach in some detail.

Figure 2 gives a client/server architectural style ontology illustration. Ports, components, roles, connectors are all key elements of software architectures, while server, client, caller and callee are terms of a specific architectural style. The relationship and interactions between the entities are also described in this illustration. Top-level Ontology

3.1 Context Modeling and Reasoning 3.1.1 ‘Context’ in our context Context has rich meanings [11]. Generally speaking, context means the situation, events, or information that are related to something and that help you understand it. In pervasive computing [3], context mainly denotes location, identities of nearby people and objects. This is due to the characteristics of mobility and diversity of computing devices. However in our model, mobility and device diversity are not the main concern, we give a definition of context below according to our understanding.

description name

description name

String name description

hasPort

Component Connector

hasRole

attachTo

String name description

Role

Port

Style-level Ontology

attachBy

Context is the relevant information about the internal and external environment of the applications, the interactions between users and applications.

hasPort

Server

Client

respTime respTime SendReq hasPort

RecieveReq

Double attachBy attachTo attachBy attachTo

Caller Callee

Client-Server Style Other Styles

inherit

property

class

Figure 2. Client/server style ontology.

By internal and external environment, the context can denote performance, topology of the application architecture, the constraints and others such as bandwidth, response delay, etc; by interactions, it can denote user operational habits, preferences, etc.

The corresponding OWL-encoded description for the Component part of the above sample ontology is shown in Fig.3. Component description …… 1 …… … …

3.1.2 Modeling and reasoning We classified the context into two layers: the first is application layer, and the second is architectural or base layer. Fig.1 illustrates our classification. One of the benefits of this classification is it gives a clear view of the separation of concerns between infrastructure and upper applications. In this way, infrastructure designers can focus on the base layer, and just offer a general platform for the application layer, although upper context information may vary from applications to applications.

98

is not a static specification described by some ADL, but a reified object that plays a central role in system’s execution. In this way, the addition and removal of components and connectors are transformed to the corresponding class methods; the relationship between a concrete architecture and an architectural style is mapped to the relationship between an object and a class, and a specific architecture can be realized through object inheritance whose actions can be designed through polymorphism. This is different from conventional description way in which the control work is left to specific management module. A comparison is shown in the following table.

For application level context modeling, as different applications vary widely from each other, offering direct support would be a mission impractical. In middleware design, these are left up to application developers. In our approach, we categorized the application scenarios into domains, such as resource-limited domain, mobility domain, device identity domain, etc. The purpose is to distill the most elemental requirements of each domain and offer some direct support for these requirements. In this way, these fundamental elements can be reused by different applications, thus the work of reinventing the wheel is reduced. For instance, in mobility-intensive domains, the property of location, time, action and corresponding constraints can be offered to the developers as a pattern.

Table 1. Comparison between OO approach and external description approach

Context reasoning means inferring implicit information from explicit one. The purpose is to know the unknown from the known. In OWL [8], some class descriptions are offered to construct logical representations, such as subClassOf, subPropertyOf, inverseOf and so on. Together with RDF/RDFSbased rule, this logical schema can enhance expressiveness and reduce ambiguity. Besides, there are some available reasoning engines, for example, Jena [12], RACER [13], etc. In our approach, the logic mainly falls into two categories, owl-encoded model reasoning and rdf-encoded instance reasoning. This classification is similar to what is applied in SOCAM [14]. Model reasoning means constructing entities and their relationship from meta-axioms. For example, from (?P rdfs:subPropertyOf ?Q) and (?Q rdfs:subPropertyOf ?R), we can infer (?P rdfs:subPropertyOf ?R). When comes to rdf-encoded reasoning, it concerns more on concrete application scenarios, that’s why we name it after instance reasoning. For example, in trust computing area, when the trust value of a service node is lower than a 60 percent, this node will be considered unsafe. In this case, we can encode it in such a way:

Object-Oriented Approach

External Approach

Description

Architecture Style

Class

ADL (Architectural Description Language)

Specific Architecture

Inheritance

ADL (Architectural Description Language)

Runtime Structure

Object, Inheritance

Configuration Module

Management Action

Methods Invoking

Management Module

Evolution

Polymorphism/In heritance

Management Module

Static Struct ure

From the above comparison, we can find that, in external description language, although the external ADL can give a clear specification, the configuration and management module is difficult to design. While in object-oriented approach, the architecture is an internal entity and the causal connection between macro specification and concrete implementation is naturally established. The following sample code excerpt gives an illustration of master/slave architectural style class.

[r0:(?trust ns: trustValue ?value), lessThan(?value, '60' ^^xsd:double),(?trust ns:trustSrcNode ?srcNode), (?trust ns: trustDesNode ?desNode), (?srcNod ns:has Action ?action ->(?action ns:actName "unsafe"), (?action ns: actSrcNode ?srcNode), (?action ns:actDesNode ?desNode)]

public class MasterSlaveType extends RuntimeArchitecture { Component master; Vector slaves; Port drivenPort; …… public Command removeCommand(Component comp) throws ArchException{ Command command = null; if(comp.inType("Slave")) { command = removeSlaveCommand(comp); } else{ throw new ArchException ("Illegal Componet Type, only Slave Components are allowed!"); } return command; } public Command addCommand(Component comp, RuntimeArchitecture rArch)throws ArchException { … } ……}

Once the unsafe signal is alarmed, application can take the corresponding bound action. In our approach, the action usually denotes the reconfiguration of the software architecture.

3.2 Management Mechanism After gaining corresponding information and logical reasoning, the next question is how to change. In our approach, two interrelated elements are given to form the management mechanism, i.e. dynamic software architecture and action transformation, among which the first is the key.

3.2.1 Dynamic software architecture Dynamic architecture is an active area [15] in software architecture research. Here, dynamism denotes the characteristic of runtime modification [16]. Architecture-based selfmanagement means the adaptive action is done at the level of components and connectors [1]. Our approach is based on the past research into architecture support for online software evolution [17, 18]. The centerpiece is the object-oriented [19] treatment of software architecture. Concretely speaking, software architecture

3.2.2 Action mapping When a certain signal is derived from the engine, it will be reduced to a corresponding architectural configuration action. For example, when the trust value of a component is lower than 60 percent, the ‘unsafe’ signal will be derived. But it still has not mapped to actions. To bridge the gap, a monitor must be provided to proactively listen to potential signals and transform them to

99

handed to interpretation and reasoning engine. The latter part will interact with context database controller who manages the persistent and temporary context ontology items. The classification criterion is based on their degree of stability. When the reasoning result is delivered to Reaction layer, firstly, it will be mapped to corresponding actions according to the transformation configurations. Then the mapping module goes to retrieve the correct action from the repository. Sometimes, no action will be found, while in others, several are found. In these cases, the action schedule and control module decide which action has a higher priority or throw an exception. Last, it is execution module to activate the right action on the runtime architecture object. Through a transaction operation, the new architecture object is sent to the involving sites. Through this separation of layers, we believe a higher reusability can be achieved.

certain actions. In our approach, the transformation script is encoded in a triple: , in which signal means the possible result derived from the reasoning engine; action represents the corresponding architectural configuration methods; parameters denote the candidate architectural elements to be reconfigured. Since signal is uncertain during design, multiple triples may be present in one configuration file. We provide a priority-based control module to interpret this triple and manage the possible inconsistency.

3.3 MAC Architecture In this section, we shall present our architecture of Middleware for Adaptive Coordination (MAC). It is based upon the approach mentioned above and attempts to offer a reusable infrastructure for the development of architecture-based selfmanagement applications. MAC mainly consists of three conceptual layers as Fig. 3 illustrates. i)

ii)

iii)

i)

Utilizing the thought of component based software development and its affinity with software architecture will reduce the cost. ii) Context information varies widely, but through classification, some most usual kinds can be distilled out and generalized as common assets and can be reused. iii) Architectural reconfiguration actions mainly include addition and removal of components or connectors. Through a mapping facility, various special reasoning results can reuse these concrete architecture-level reactions. In this architecture, the three layers in fact form a closed cycle, which continually monitors and feeds back to the running system. The context modeling and logical reasoning absorb and digest the environmental data and produce useful information for possible architectural reconfigurations.

Application Layer. As the name hints, this layer offers the execution space for applications. In particular, these applications should follow some conventions. Context Layer. This layer facilitates for context information acquisition and it is also responsible for OWL interpreting and context reasoning. Reaction Layer. It maps the reasoning result to a concrete architectural method and initiates these actions on the application. Component

Application Layer

Style DB Architecture Controller Object Component Component

Architecture Style DB

Context Acquisition

4. PROTOTYPE IMPLEMENTATION

Context DB Controller

Context Layer

Persistent Context Action Repository

Reaction Layer

Temporar y Context Action DB Controller

Action Execution

We have developed a prototype system by integrating existing standards, techniques and new facilities for ontologybased modeling, reasoning and object-oriented runtime software architecture based self-management mechanisms.

Context Interpreting /Reasoning

Action Mapping

The system is written in Java and implemented as a plug-in in Eclipse. Users can publish, retrieve and bind services to components and connectors manually in a graphical way. It will generate the architecture object automatically from the architecture topology drawn by users. For distributed applications, different involving sites should all have a copy of this object, even though with different views since they play different roles. So, this architecture object is physically dispersed but logically centralized, 2-phase lock protocol is applied to ensure the consistency and atomicity of the transaction.

Schedule/Control

Figure 3. MAC conceptual architecture. Application layer offers space for applications in which they operate. We believe that an adequate component framework plays an important role in the development of architecture-based selfmanagement applications, for there is a natural affinity between software architecture and software component technology [20]. We have designed a component framework [21] for the ease of application development. The basic elements consist of description interpretation, composition support, interface decoupling utility, and so on. Developers will first select one particular architectural style as a blueprint from the style database, bind the corresponding services to components, check whether they are consistent or not, and create a concrete architecture object which will be dispatched to the involving hosts. Context layer is responsible for raw context-related data collection such as memory, CPU load, latency, etc and encoding them to unified RDF format. Then, this information will be

As argued above, different applications vary widely from each other. In consideration of the affinity between software architecture and component technology, we choose EJB model for our experiment and utilize Apache axis and Jboss AS to offer basic infrastructure for web services and EJB respectively. We use the broker design pattern [22] plugged in Jboss AS as a mbean service to parse the software architecture object and communications are done through RMI. A context modeling editor is integrated to provide OWL/RDF modeling support. The reasoning engine is partly based on Jena’s API[12] in which we extend to contain time dimension. And a real time visual monitor

100

is provided which we will see shortly in the following case study part.

mapped to a concrete architectural reconfiguration action. Here, it’s mapped to AddMaster action

5. CASE STUDY

5.3 Performance To simulate the concurrent multiple online request, we programmed the http request to the broker component in the code. First, it initiates 200 concurrent request threads. After a while, it adds 200 threads more, and then 200 threads more. The following two snapshots give some basic illustration.

5.1 Scenario Statement and Self-Management Requirement There are some single, independent ticket-booking web services scattering in the net offering different kinds of tickets, such as plane, train, bus, et al. If their interfaces are the same and open, then it’s possible to integrate them together. When requests come, they will be handled by a broker and dispatched to the candidate services. After process the results would be returned through the broker aforementioned. In this way, users will find an adequate travel plan more conveniently, as otherwise, they will have to browser those independent sites one by one. In busy hours, as the access increases rapidly, the intermediate broker component is likely to be the bottleneck thus affects the overall performance which is an important aspect of net users’ concern. A natural choice is to add an additional broker to take over part of requests automatically. The problem is when and how to add without causing system down.

5.2 Experiment Assumptions and Design

Figure 5. One master/three slave architecture.

Top-level Ontology

The experiment is done in a local area network isolated from outside, so the available bandwidth doesn’t fluctuate much. The latency between requests and responses can be regarded as an index of load. The application architecture belongs to Master/Slave style, as the broker acts as the master and delivers the work to its slave components. Fig. 4 shows the ontology model which is included in the prototype architectural families. S y s te m hasN

doA

ode d o A c tio n a c tS rc N o d e

N ode

c tio n

A c tio n

a c tD e s N o d e

Architecture-level Ontology

M S -S ty le

A d d M a ste rA c t

M a ste r a c tO b jA r g im e D o u b le im e g spT e jA r R b O act g r A a c tO b j

Re h a s S la v e

S la v e

sp T

A d d S la v e A c t

Figure6. Two master/three slave architecture. M o v e R e q u e s tA c t

(After self-management)

T h e M a s te r -S la v e A r c h ite c tu r e S ty le

Master node receives the requests and dispatches them to slave nodes. In our scenario, the slave nodes are for the selling of plane tickets, bus tickets and train tickets separately. The functional nodes are sat in different hosts in a local network environment. Latency information is collected at a certain frequency which is, in our example, 1 time per 2 seconds. The evaluation result is partly shown in Table 2.

T h e P ip le - F ilte r A rc h ite c tu r e S ty le

T h e im p le m e n ta tio n s p e c ific o n to lo g y in h e r it

p ro p e rty

c la ss

Figure 4. Master/slave style ontology design. The rule script is encoded as follows.

The table gives a view about the effect of self-management and the result shows the architecture-based self-management can improve application’s performance significantly. Besides, in the real-time monitor panel (Fig.6 shows), we can observe that, during reconfiguration, an additional time is required to adjust the new software architecture. The reason is the additional latency introduced by cache which preserved the requests during the adjustment and released them after.

@prefix ns: @prefix xsd: [r0:(?n ns:responseTime ?t), greaterThan (?t, '2500'^^xsd: double), (?n ns:hasAction ?action) -> (?action ns:actName "overload"),(?action ns:actSrcNode ?n),(?action ns: actDesNode ?n)] The script means, when the response time exceeds 2500 milliseconds, it sends an overload signal. And the signal will be

101

Table 2. Experiment result Time(τ)

1

2

3

4

5

6

7

Request (υ)

1

1

1

2

2

2

2

Reaction

N

N

N

N

N

N

N

Latency(ms)

1051

1093

1130

1820

2033

1952

20 84

Time(τ)

8

9

10

11

12

13

14

Request (υ)

3

3

3

3

3

3

3

Reaction

N

N

Y

Y

Y

Y

Y

Latency(ms)

2895

2786

2687

1628

1803

1932

17 59

7. CONCLUSIONS AND FUTURE RESEARCH

υ : Unit of request quantity which stands for 200 concurrent threads.

A considerable amount of work on self-management systems has been carried out on management mechanisms, while the premise of such systems: context modeling and reasoning are often dealt with in an ad hoc way. Our research aims to give a due attention to this aspect. Using Ontology defined in OWL to model the context and combining with the architecture-based selfmanagement mechanism, the expressiveness is enhanced and a uniform representation model is gained. These improvements especially make sense to the development of middleware for selfmanagement systems. The reason is that to build a specific application, designers are free to select from various mechanism candidates and even ad hoc ways but to build a middleware as an infrastructure for the development of such systems, decision should be carefully made.

N stands for No, and Y stands for Yes. Threshold here is 2500 milliseconds.

i) Performance, reusability, compatibility etc should be taken into consideration.

Note: τ: Unit of interval which is set to be 2 seconds here.

ii) Middleware should offer a general and uniform framework so that different applications have less difficulty in interactions.

6. RELATED WORK The vision of building self-managing systems attracts much attention both in industry and academia. IBM’s autonomic computing initiative [23] views autonomic systems in four aspects: self-configuration, self-optimization, self-healing and selfprotection. It regards these systems as collaborative collections of interacting autonomic components, but the coordination of such components will be a non-trivial task and several approaches have been proposed [24, 25]. Y.S. Dai [26] has also proposed a model driven autonomic management mechanism mainly from the perspective of software reliability.

Honestly speaking, building self-managing applications is rather a challenging work, since self-management has a wide spectrum and too many factors affecting the infrastructure design and implementation. We will continue our research on selfmanagement systems about employing aspect-oriented approach to separate fine-grained concerns and offering language-level support for self-management applications.

8. ACKNOWLEDGEMENTS

CMU’s Rainbow framework by Garlan et al [27] uses external adaptation mechanisms to explicitly specify the adaptation strategies for multiple system concerns. But Rainbow system does not address much about context modeling issues. Besides, the use of external architecture style specification requires an additional infrastructure to map across the abstraction gap from the system to the model. UCI’s ArchStudio [28] by Taylor et al is a tool suite for supporting the runtime modification of software architecture based on C2-style language. It mainly emphasizes on the architectural dynamism, while other aspects such as context modeling and reasoning has been paid less attention to. Its later research reviewed self-management systems and initiated a knowledge-based approach [29].

The work of this paper is funded by 973 Program of China (2002CB312002), 863 Program of China (2005AA113030), NSFC (60233010, 60403014), and NSFJ (BK2006712). Thanks

are given to the anonymous reviewers for their comments and valuable suggestions. We also thank Vaskar Raychoudhury for his assistance in improving the article.

9. REFERENCES [1] Oreizy, P., Gorlick MM, Taylor R. Heimbigner D, An

Architecture-Based Approach to Self-adaptive Software. IEEE Intelligent Systems, 1999. 14(3): p. 54. [2] Dashofy, E.M., Hoek, A., and Taylor, R. Towards

The Arch-Ware Project [30] funded by European Union has a good theoretical background. Its architectural modeling language is based on pi-calculus and is supporting the cycle from the initial description to the continuous evolution.

Architecture-based Self-Healing Systems. in Workshop on Self-healing Systems. 2002: ACM Press. [3] Satyanarayanan, M., Pervasive Computing: Vision and

Challenges. IEEE Personal Communications, 2001: p. 10-17.

Using ontology to model context is not unique to our approach. In context computing related area, a lot of research has been conducted, such as Maamar et al [31], Gu et al [14], Chen et al [32] and so on. The distinctions between our work and these mentioned are that we introduce explicit context modeling and reasoning techniques in architecture-based self-management applications and have offered a unified framework.

[4] Strang, T. and Linnhoff-Popien, C. A Context

Modeling Survey. in UbiComp 1st International Workshop on Advanced Context Modelling, Reasoning and Management. 2004. Nottingham. [5] Perry, D.E. and Wolf, A.L., Foundations for the Study

of Software Architecture. ACM SIGSOFT Software Engineering Notes, 1992. 17(4): p. 40-52.

102

[6] Shaw, M. and Garlan, D., Software Architecture:

[21] Zhou, Y., Ma, X.X., Tao, X.P., et al., Towards a

Perspective on an Emerging Discipline. 1996, New York: Prentice Hall.

Component Framework for self-Adaptive Applications. Journal of Wuhan University, 2006. 11(5).

[7] Shaw, M. and Clements, P., The Golden Age of

[22] Gamma, E., Helm, R., Johnson, R., et al., Design

Software Architecture. IEEE Software, 2006. 23(2): p. 31-39.

Patterns: Elements of Reusable Object-Oriented Software. 1995, Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.

[8] Bechhofer, S., Harmelen, F.V., Hendler, J., et al., OWL

[23] Kephart, J.O. and Chess, D.M., The Vision of

Web Ontology Language Reference. 2004.

Autonomic Computing. Computer, 2003. 36(1): p. 4150.

[9] Gruber, T.R., A translation approach to portable

ontology specifications, in Knowledge Acquisition. 1993. p. 199-220.

[24] White, S.R., Hanson, J.E., Whalley, I., et al. An

Architectural Approach to Autonomic Computing. In Proceedings of International Conference on Autonomic Computing, 2004.

[10] Antoniou, G. and Harmelen, F., Web Ontology

Language: OWL, in International Handbooks on Information Systems. 2004, Springer Verlag. p. 67-92.

[25] Cheng, S.W., Huang, A.C., and Garlan, D. An

[11] Dey, A.K. and Abowd, G.D., Towards a better

Architecture for Coordinating Multiple SelfManagement Systems. In Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture, 2004.

understanding of context and context-awareness. June 1999, Georgia Institute of Technology. [12] Reynolds, D., Jena 2 Inference Support. August, 2003. [13] Haarslev, R.M.V. and Moller, R. Description of the

[26] Dai, Y.S. Autonomic computing and reliability

RACER System and its Applications. In Proceedings Internaltional Workshop on Description Logics. 2001.

improvement. In Proceedings of the 8th IEEE International Symposium on Object-oriented Real-time Distributed Computing (ISORC 05). 2005. Seattle, Washington.

[14] Gu, T., Pung, H.K., and Zhang, D.Q., A Service-

oriented Middleware for Building Context-aware Services. Journal of Network and Computer Applications, 2005. 28(1): p. 1-18.

[27] Garlan, D., Cheng, S.W., and Huang, A.C., Rainbow:

Architecture-based Self-adaptation with Reusable Infrastructure. IEEE Computer, 2004. 37(10): p. 46-54.

[15] Andersson, J. Issues in Dynamic Software

Architectures. In Proceedings of the Fourth International Software Architecture Workshop. 2000.

[28] Oreizy, P. Architecture-Based Runtime Software

Evolution. in Proceedings of the International Conference on Software Engineering. 1998. Kyoto, Japan.

[16] Medvidovic, N. and Taylor, R., A Classification and

Comparison Framework for Software Architecture Description Language. IEEE Transactions on Software Engineering, 2000. 26(1): p. 70-93.

[29] Georgas, J.C. and Taylor, R. Towards a Knowledge-

Based Approach to Architectural Adaptation Management. in Proceedings of Workshop on Selfmanaged Systems. 2004: ACM Press.

[17] Ma XX, Y.P.T.X., Lu J., A Service-Oriented Dynamic

Coordination Architecture and Its Supporting System. Chinese Journal of Computers, 2005. 28(4): p. 467.

[30] Oquendo, F., Warboys, B., Morrison, R., et al.

Archware: Architecting Evolvable Software. in European Workshop on Software Architecture. 2004. St. Andrews, UK: Lecture Notes in Computer Science, Springer Verlag.

[18] Yu, P., Ma, X.X., and Lu, J. Dynamic Software

Architecture Oriented Service Composition and Evolution. In Proceedings of the Fifth International Conference on Computer and Information Technology. 2005. Shanghai, China.

[31] Maamar, Z., Narendra, N.C., and Sattanathan, S.,

Towards an ontology-based approach for specifying and securing Web services. Information & Software Technology, 2006. 48(7): p. 441-455.

[19] Meyer, B., Object-Oriented Software Construction.

1997, NJ, USA: Prentice Hall. [20] Wallnau, K., Stafford, J., Hissam, S., et al. On the

[32] Chen, H., Finin, T., and Joshi, A. Using OWL in a

Relationship of Software Architecture to Software component Technology. In 6th International Workshop on Component-Oriented Programming, in conjunction with the ECOOP. 2001. Budapest, Hungary.

Pervasive Computing Broker. In Proceedings of Workshop on Ontologies in Open Agent Systems. 2003.

103