Pervasive System with Workflow in u-Healthcare

2 Motivation

2.3 Pervasive System with Workflow

2.3.3 Pervasive System with Workflow in u-Healthcare

Figure 2-1: A Diagram of Pervasive Healthcare and Monitoring Application

The aging population is a growing problem throughout the global. The elderly people, suffering from the chronic diseases, require the medication and the regularly clinic visiting. Hence, an efficient pervasive healthcare and monitoring application is becoming crucial in recent years. However, an application of pervasive healthcare is involved of many challenges such as: (1) the context-aware monitoring of the patient, (2) The handling process when an emergency happens. The above Figure 2-1 illustrates the pervasive healthcare application.

One discussed scenario is about an aged patient suffering from hypertension is now rest at home. Wearable sensors equipped with the patient collects his signs of life such as heart beating, blood pressure etc. Video sensors are deployed in living room to capture his motions. The patient’s handheld monitors the information collecting by sensors. The handheld warns the care center through telephone when any emergency.

All the devices are connected by wireless network.

Suddenly, the patient feels discomfort due to headache. The wearable sensors detects the blood pressure of this patient is Diastolic = 155 mm hg & Systolic = 99mm hg. The video sensors capture the patient’s posture is falling. The handheld identifies the patient is on the morbidity of hypertension. As a consequence, a warning message with vibration of handheld is triggered, and intermediately transmits the physiological data from wearable sensors to care center. Through professional judgment, the care canter confirms the patient is under an emergency status. Hence, a sequence of activities is performed: (1) Inform the physician and transmit relevant medical history, (2) Inform care provider to send ambulance, and (3) Inform Hospital to prepare correspondent handling process…

In this scenario, pervasive healthcare including geriatrics care has highlighted the need of applying the workflow techniques into pervasive systems. Workflow technique is able to represent the pervasive healthcare monitoring process involving a sequence of activities associated with many participants. In Chapter 4, we will explain how to design a pervasive healthcare application based on our system architecture.

Chapter 3 A Pervasive Application Model and an Execution Framework

On account of the characteristics of pervasive computing discussed in Chapter 2, there are some challenges for the developers to build the pervasive applications. For example, a better expressive model reduces the efforts of recognition for the environment; an efficient approach describes the complex process/workflows performing a sequence of tasks, and a mechanism acquires/accesses ubiquitous services that the surrounding provides during run time. In order to reduce these difficulties, our observation indicates three fundamental components regarding to developing pervasive applications. A pervasive application model with necessary components and their detailed formats is presented in Section 3.1. And to separate the design issues from run time, a framework supporting the execution environment is proposed in Section 3.2. An activity diagram and collaboration diagram illustrating the operation of the execution framework is presented in Section 3.3.

3.1 The Necessary Components in Pervasive Applications

Figure 3-1 illustrates a conceptual overview of general pervasive applications based on the discussion in Chapter 2. Context-model is used to capture and perceive the environment. The application flow indicates the relationship among tasks during run time. The sub-flow(s) handles the context-changes in the surrounding. The required service description designates the necessary services of an application. In the

lower-part of Figure 3-1, services, distributed over a specific environment, dynamically support the executing tasks.

Figure 3-1: An Overview Concept Diagram of General Pervasive Applications.

According to the discussion in Chapter 2, we can conclude at least three necessary components in pervasive applications:

1. Context Model and Reasoning rules. Since the pervasive environment alters all the time, it is essential to use a context model to capture the change.

Moreover, the pre-defined rules are applied for reasoning the status of context entities. By means of the context model and context reasoning, the pervasive system can understand the environment and properly react to the changes. Thus, the context model with related reasoning rules is the first

necessary component to develop a pervasive application. Section 3.1.1 gives a detailed explanation of our context model approach.

2. Process Schema. In the design time, the developers specifiy the tasks, their execution order, and other control structures (e.g. if-then-else, loop, sequence, and so on) in an application. The above relationship among tasks is regarded as business processes (or processes) in an application. During run time, the pervasive system instantiates correspondent handling processes based on the current status of environment. Hence, the process schema is the second necessary component to develop a pervasive application. Section 3.1.2 gives a detailed explanation of our process schema approach.

3. Required Services. The service description details the interaction between a task and its required services, whereas the above process schema indicates the execution logic among all tasks. However, the developers might not anticipate all run-time available services, and therefore the developers describe required services in an abstraction manner. A platform-independent service description, thus, is the third necessary component to develop a pervasive application. Section 3.1.3 gives a detailed explanation of our required service description approach.

Figure 3-2: A General Model to Develop Pervasive Applications

With the three fundamental components, a general model to build pervasive applications is proposed as Figure 3-2. Based on the designing application, the developers build elements in the dashed rectangle in Figure 3-2 to construct pervasive applications among different domains.

3.1.1 Context Model and Context Reasoning

Two widely-accepted definitions of context, and context-aware systems given by A.K. Dey states [28]:

“Context is any information that can be used to characterize the situation of an entity.

An entity is a person, place or object that is considered relevant to the interaction

between a user and an application, including the user and the application themselves.”

“The systems that use context to provide relevant information and/or services to the user, where relevancy depends on user tasks”

Pervasive system is a kind of context-aware systems; therefore, a context model is utilized to recognize and capture the context that an application needs. This section explains our context model approach and how the developers design their domain-specific context models.

3.1.1.1 The Two-Level Hierarchical Approach

Our context model is a two-level hierarchical approach using ontology. The upper-level, representing for the generic context model, depicts the universal concepts throughout all pervasive application domains. The lower-level, representing the domain-specific context model, appropriately describes the features within an application domain. The upper-level context ontology is fixed and shared once defined, while the lower-level context ontologies are diverse along with domains.

The hierarchy of ontology classes categorizes the terms and specifies relationships associated with the context entities in the environment. The hierarchical structure emphasizes the machine-understandability of context information, supporting for the abstraction programming of capturing the environment in the development of pervasive applications.

Through Dey’s definition and the observation of pervasive application in Chapter 2, we conclude a skeleton of context model:

1. Basic Entities:

• Locations (indoor space or outdoor space)

• Individuals (persons or non-persons).

• Activity (scheduled activity or a deduced situation)

• Service (context providers, devices, network )

2. Properties/Relationships among the Above Entities:

• Individual, Activity, and Service must be located in a Location.

• In some location, Individual is engaged in some Activity utilizing Services that environment supports.

Hence, Figure 3-3 illustrates the generic ontology in our upper-level context model base on the above skeleton:

Figure 3-3: The Upper-Level Context Model of Class Hierarchy Diagram

With the above generic ontology serving as a generic context model, it provides the application developers or domain experts a coarse-grained backbone to design fine-grained context features suited for the application domain. The partition of different domains assists the application developers reduce the scale of context knowledge, and allow to reuse the domain-specific context models defined by third parties. In addition, by means of the context management system (CMS) in the framework (mentioned in Section 3.5), these domain-specific ontologies can be dynamically applied when the pervasive surrounding is altering.

Figure 3-4 shows that the ontologies of different domains derived from the generic context model.

Figure 3-4: The Two-Level Hierarchical Context Model

3.1.1.2 RDF Reification

The OWL ontology can be mapped into RDF graph that is a collection of RDF triples. Each RDF triple is a statement containing three parts: (1) subject, (2) object, and (3) predicate. The statement can be described and recorded by RDF reification using the RDF/XML syntax specification. According to W3C, RDF reification vocabulary consists of the type rdf:statement, and the properties rdf:subject, rdf:predicate, and rdf:object. The following example explains the RDF reification.

Figure 3-5: An Example of RDF Reification

Figure 3-5 shows the abridged part of our upper-level context model with respect to the context entity of “Person”, and a real instance in some application called

“Steven”. Person is the subclass of Context Entity. Person holds some Device. Person is engaged in some Activity. Person is located in some Location. Figure 3-6 shows the RDF/XML data serialization related to the context entity of a person.

<owl:Class rdf:about="#Person">

<rdfs:subClassOf rdf:resource="#Individual"/>

<rdfs:subClassOf>

<Location rdf:ID=”NCTULibrary”>

</LocatedIn>

Figure 3-6: The RDF/XML Data Serialization Example

3.1.1.3 Context Reasoning

Section 3.1.1.3.1 and Section 3.1.1.3.2 describes how context model captures and perceives the pervasive environment. The direct acquisition of context from the environment contains the raw data that only represents the low-level information (such as location, sound, video pictures and so on.) In order to identify the high level status of a context entity, a mechanism called context-reasoning is required to extract more useful information from these raw data of context.

The context-reasoning performs two major categories of tasks that are discussed in the following: (1) Ontology-reasoning employs description logic (2) Developer-defined rule reasoning utilizes first-order logic.

(1) Ontology Reasoning

Web Ontology Language (OWL) is W3C recommendation to makes use of web standards to represents information with RDF/XML schema. OWL is based on Description logic (DL) that specifies the hierarchy of terminologies by means of a restricted set of first-order formulas. Hence, the equivalence of OWL and Description logic (DL) supports the use of existing DL business segment for class consistency, instance checking, and concept satisfaction.

Table 1 shows the partial form of ontology reasoning rules based on description logic.

Rule

Transitive property (?p rdf:type owl:TransitiveProperty) ^ (?a ?p ?b) ^

(?b ?p ?c) Î (?a ?b ?c)

Symmetric property (?p rdf:type owl:SymmetricProperty) ^ (?a ?p ?b) ^ Î

(?b ?p ?a)

Inverse property (?p owl:inverseOf ?q) ^ (?a ?p ?b) Î (?b ?q ?a)

DisjointWith (?a owl: disjointWith ?b) ^ (?x rdf:type ?a) ^ (?y

rdf:type ?b) Î (?x owl:differentFrom ?y)

Table 1: The Ontology Reasoning Example

An example illustrates the ontology reasoning. If Steven’s location sensed is in the NCTU library, then the owl description is shown as:

<Person rdf:ID=”Steven”> …

</LocatedIn> …

By applying the defined context model of owl description about NCTU library and the transitive property as:

<LocatedIn>

</LocatedIn> …

<owl:ObjectProperty rdf:ID = “LocatedIn” >

<rdf:type=”…<URI>…TransitiveProperty”>

</owl:ObjectProperty>

Thus, the ontology reasoning gets the result:

<Person rdf:ID=”Steven”> …

<LocatedIn>

<Location rdf:ID=”NCTU Campus”>

</LocatedIn> …

(2) Developer-Defined Rule Reasoning

Developer-Defined Rule offers the more flexible approach for the designers to perform context-reasoning suitable for their applications. In the design phase of an application, the developers can define their reasoning rules in conformity with the format of first-order logic. During the running phase, exploiting these developer-defined rules, the CMS deduces the high-level status contexts from the raw data of contexts gathered by the sensors/context providers. The following examples illustrate the reasoning by developer-defined rules:

Status of user ?u Rules

Sleeping (?u locatedIn Bedroom) ^ (SmartBed PressureLevel High)

^ (Bedroom LightLevel Low)

Watching TV (?u locatedIn ?l) ^ (?TV locatedIn ?l) ^ (?TV Status On)

Cooking (?u locatedIn Kitchen) ^ (?SmatOven locatedIn Kitchen) ^

(?SmartOven Status On)

Table 2: The Defined Rule Reasoning Example

3.1.2 Process Schema and Required Service

3.1.2.1 Process

The process specification is used to navigate tasks that make up an application.

The execution of a process during run time is viewed as a workflow. The operational language we use to express the process is by BPMN [43]. The structured activities defined by BPMN, including sequence, flow, switch, while, and so on, can represent the relationship among tasks in the design time of an application.

The developers cannot anticipate all the run-time available services for the tasks in an application. Hence, the process specification needs the extra description to record the required services. The adopted method is by adding the semantic annotations associated to a process to mark up the used service during run time. The next section illustrates how to describe the required services and gives an example.

3.1.2.2 Required Service and Service ontology

Similar to context model, the service description needs a semantic but computer-interpretable language for the pervasive systems to control and administrate services. The service ontology, used to declare and describe the services, consists of a collection of classes and properties to provide the appropriate representation framework.

OWL-S [44], a web service ontology specified in OWL, is composed of three parts: the service profile, the service model, and the service grounding (see Figure 3-7 [44]). The service profile portrays the high level description of a service and its provider. The service model details the service behavior as step-by-step processes (atomic process, simple process, or composite process) under a set of control construct (e.g. Sequence, Split, Choice, If-Then-Else, Repeat-While and so on…). The service grounding specifies the necessary information (e.g. communication protocol, message format, port number etc…) to access a service. Note that the service profile and the service model deal with the abstraction representation of a service, while service grounding copes with the concrete level of specification of a service.

Figure 3-7: The Components of OWL-S [44]

The pervasive-service providers are suggested to use OWL-S to specify their advertised services. Additionally, user tasks in a pervasive application process also

specify the required service description in the format of OWL-S. The following Figure 3-8 illustrates the relationship between advertised services from service providers and requested services by user tasks. There are serveral OWL-S systems (such as [45], [46]) performing service discovery and matching. The further study of the semantic service by OWL-S is out scope of our study.

Figure 3-8: The Service Matching Using OWL-S during Rum Time

In Figure 3-8, the service management system (SMS) is designed to administrate the services that service providers advertize and the processes require during run time.

The service management system is one sub-system of our framework supporting the execution environment of pervasive applications (shown in Section 3.4).

The following example in Figure 3-9 shows how the developers specify a process and its required service descriptions. The upper-part of Figure 3-9 is an example of process. In this thesis, we use BPMN to model the processes in an application, and BPMN can translate into BPEL for execution. In the lower-part of , Process.bpel denotes the correspondent BPEL representation, and RequiredService.xml is associated to the process in order to mark up the used services during run time.

Figure 3-9

Figure 3-9: An Example of the Specification of a Process and Services

Since both the required service within a process and pervasive services in any kinds of environments conform to the format of OWL-S, the SMS can perform the service discovery, and service matching when a process is running.

3.2 A Framework supporting the execution environment

In the following Figure 3-10, a framework is designed to support the execution environment for pervasive applications. Hence, the designers can concentrate on constructing the required elements of an application. The goal of the framework assists the developers to focus on building the fundamental components in Section 3.1.

The framework consists of three major sub-systems corresponding to the three requirements in Section 3.1: (1) Context management system (CMS), (2) Workflow management system (WMS), and (3) Service management system (SMS).

In order to adapt the diverse environments, our framework adopts the concept of service-oriented architecture (SOA). The framework only preserves the necessary components. Taking the function of data-storage for example, it is often resource hungry but widely used by most components. As a result, our framework encapsulates the function of data-storage into the repository service that is provided according to environments. Since CMS and WMS require accessing the context model data, rules and process patterns frequently, the decoupling of data storage into service also minimizes the loading of the framework. Other encapsulated services, such as computation resources, reasoning modules, and devices, also follow the principle of

SOA and the other components in the framework can easily access these wrapped services provided from the third parties in the various pervasive surroundings.

s in our framework:

(1) Context Manageme

Figure 3-10: A Framework Supporting the Execution of Pervasive Applications

The following explains the three sub-system nt System (CMS):

The CMS comprises three major components: (1) Context capturer, (2) Context manager, and (3) Context repository. The context capturer captures the raw data of environment context and stores them into context repository.

The context manager is composed of a context handler and an event handler, thus processing the input context data. The context handler scratches context data from the context repository and utilizes domain-specific context model and developer-defined rules (stored in repository service) to reason the high-level status of context entities. The reasoning result represents the current situation in the environment. Once the reasoned situation matches some event, the event handler informs the workflow

(2) Wor

nts, performing tasks, and monitoring the execution of processes. Moreover, WfMS acquires available services by means of management system.

kflow Management System (WfMS):

After the CMS informs WfMs, the WfMS coordinates all participants within the workflow to perform a sequence of tasks. The process definition (stored in the process repository) provides the basic schema to execute the tasks required in the pervasive applications. The application developer defines the executing process patterns, whereas, WfMS is in charge of coordinating participa

requesting the SMS.

(3) Service Management System (SMS):

In conformity with the principle of SOA, the designed framework decomposes large elements into a set of wrapped services that may be provided by the third-party. Hence, the SMS has to furnish a mechanism to register and index these services. Besides, the pervasive service providers can also advertise their service by means of the SMS. Furthermore, The CMS and the WMS access the pervasive environment through the SMS so that they could easily locate and access the services. However, sometimes the requests from WfMS or CMS may not be achieved by a single service. The Service Proxy and Coordinator would comp

enting how to enable a BPEL workflow to dynamically invoke the service in the pervasive environment. The

the run-time rvices within a BPEL workflow.

3.3 T

ram with relevant to the execution framework presented in Chapter 3. Since three elements built must be running upon

ose several services into one temporary service composition to provide proper facilities.

The run time available services for the tasks of a workflow register their OWL-S service descriptions to the SMS. After the matching of the task and pervasive services, the SMS can specify the partnerLink of the selected service into the BPEL representation of a workflow and establish the communication channel. There are some systems [1],[47] pres

SMS in our framework can also use these systems to achieve invocation of se

he Communication Mechanism inside the Execution Framework

Figure 5-3 illustrates the activity diag

the execution framework, we use the activity diagram of execution framework to interpret the details of invocation and flows.

在文檔中一個發展普適應用的方法論 (頁 21-0)