Rapid Development of Adaptable Situation-Aware Service-based Systems

Introduction

Nowadays, heterogeneous networked systems involving sensors, actuators, access points, and control stations connected through wired/wireless networks are being widely used in many mission-critical applications, such as healthcare, military, automobile and space applications. These systems often need to satisfy various requirements simultaneously, such as real-time, fault-tolerance, and security, and may need to be run in resource-poor environments with bandwidth limitations and shortage of memory space and/or other critical resources. Such systems often need to monitor physical and/or computational contexts, which are any instantaneous, detectable, and relevant properties of the environment, the system, or the users (Yau, Karim, Y. Wang, B. Wang, & Gupta, 2002; Yau, Wang & Karim, 2002), and react to situation changes in an autonomous and distributed manner. A situation is a set of contexts in a system over a period of time that affects future system behavior for specific applications (Yau, Karim, Y. Wang, B. Wang, & Gupta, 2002; Yau, Wang & Karim, 2002). Components of these systems can migrate from one physical/logical location to another in runtime. Hence, it is of utmost importance that such systems are adaptable and situation-aware so that they can provide services to users reliably and intelligently in accordance with the user goals in harsh and rapidly-changing environments.

One of the most promising architectures for developing such adaptable situation-aware systems is the Service-Oriented Architecture (SOA) (W3C, 2004b) due to the major advantage of enabling rapid composition of distributed applications from available services, regardless of the programming languages and platforms used in developing and running the applications. The systems based on SOA are called service-based systems (SBS). In SBS, various capabilities are provided by different organizations as services, which are software/hardware entities with well-defined interfaces to provide certain functionality. These services can be used to compose higher-level functionality representing a certain workflow, which is a series of cooperating and coordinated activities achieving certain user goals. Hence, the development of an SBS can be viewed as a process involving the specification of user goals, the identification of suitable services, the composition of identified services into workflows satisfying the specified goals, and the implementation, testing and validation of the service composition.

A workflow can often be specified by a control flow graph (Hsu, 1993; Georgakopoulos, Hornick, & Sheth, 1995; WFMC, 1996), which is a common type of framework used in most workflow management systems for depicting the local execution dependencies among key activities in the workflow. A typical control flow graph specifies the initial and final activities in a workflow, the successor-activities for each activity in the graph, and branch selection or parallel execution of the successor-activities. However, dependencies among service invocations in a workflow in adaptable situation-aware SBS are often based on situation changes in highly dynamic environments, where users often have different requirements in various situations, or services cannot provide desirable QoS due to attacks, system failures or overload. Such dependencies can be effectively captured by situational constraints, which are the restrictions on what and how services should be invoked in various situations. Although it is possible to incorporate situational constraints in control flow graph specification, it is necessary to separate situational constraints from control flow graph specifications and specify situational constraints in a modular and reusable fashion so that a service composition system can discover appropriate services based on situations and users’ goals, use the discovered services to compose a workflow achieving users’ goals, and coordinate service execution adaptively based on situation changes. We consider such a process as situation-aware service composition. Since a large-scale SBS usually consists of thousands of services and may encounter many different situations in runtime, it is desirable that situation-aware service composition can be automated based on declaratively specified user goals.