=Paper=
{{Paper
|id=None
|storemode=property
|title=Context aware service discovery and service enabled workflow
|pdfUrl=https://ceur-ws.org/Vol-1054/paper-11.pdf
|volume=Vol-1054
|dblpUrl=https://dblp.org/rec/conf/csws/HussainM13
}}
==Context aware service discovery and service enabled workflow==
https://ceur-ws.org/Vol-1054/paper-11.pdf
CONTEXT AWARE SERVICE DISCOVERY AND
SERVICE ENABLED WORKFLOW
Altaf Hussain, Wendy MacCaull
Centre for Logic and Information, Dept. of Mathematics, Statistics, and Computer Science
St. Francis Xavier University
Antigonish, Nova Scotia, Canada
ahussain@stfx.ca, wmaccaul@stfx.ca
Abstract—We provide a conceptual model for context aware are empowered by the WS technology, which provides a
Semantic Web Service (SWS) discovery, which can utilize real- platform supporting independent communication and machine-
time legacy data from external systems and support user context- to-machine interaction framework. However, WS technologies
based service discovery and selection. This model offers need extensive human involvement for service discovery,
advantages over current SWS technology which cannot be easily composition, invocation, etc.
applied to different domains or be integrated with legacy systems.
Using this conceptualization we propose an intelligent decision In the recent years, a new paradigm has evolved, called the
support system, which offers Service Enabled Workflow. Semantic Web (SW), supporting machine-readability, and
automated trusted interaction between computers with minimal
Keywords—Semantic Web Service, Context Aware Service human intervention. The markup language of the SW is based
Discovery, Service Enabled Workflow, Service Metadata, Ontology on the Web Ontology Language (OWL), which can be used to
express logical relations among entities on the web, and leads
I. INTRODUCTION to a new class of WS called Semantic Web Service (SWS). A
Semantic Webservice is a standalone piece of functionality that
A service is an entity that offers an intended value to its is self-descriptive, machine-readable, and can be automatically
consumer; in today’s society, people are dependent on service
discovered and executed via the web. The SWS, inheriting the
paradigms. A service consumer may need to pay an exchange properties of the SW and the WS has achieved many desirable
value to consume a service but does not have to be concerned properties, namely: a) machine independent communication
with how the service is developed or delivered. The service
and machine readability b) easy and widely acceptable
model design, development, and delivery are the concern of, collaboration methodologies c) exploitation of SW and
and are handled by, the service providers: e.g., the Postal
reasoning techniques. Effort has been made in the areas of
Service. Web Service (WS) is the technology that makes SWS, for example: semantic description of WS, semantic
services available as consumable entities accessed and
reasoning based WS discovery and SWS delivery thorough
consumed through computers, via the Web: e.g., the Email ontology based concepts and frameworks e.g., Web Ontology
Service. WS technology, backed by Service Oriented
Language–Services (OWL-S) [1], and Web Service Modeling
Computing and Service Oriented Architecture (SOA) has Ontology (WSMO) [8].
gained attention and popularity in the commercial computing
sector as an enabling technology for the most enduring service As SWS becomes more popular, users expect it to be easier
planning, development, delivery and management to integrate with different domains and legacy systems.
methodology. As a result, a new spectrum of web applications Existing SWS approaches do not provide any easy
has emerged supporting Business-to-Business integration, e- methodology to integrate domain data (often housed in
commerce, and industry wide collaboration. These applications traditional databases) in the service discovery process to
Figure 1: Interconnection of legacy systems and SWS system
Copyright notice: Copyright is held by the authors
support context aware service discovery. However, users stating the real-time patient data properties and values, rules
frequently need to select services based on domain situations. stating the action required to be taken by the user based on the
To support automatic interoperation of the SWS discovery facts and services, and the queries. We can model Selection
process with traditional systems, SWS discovery should be Strategy 2 by the listed Fact 1, Rule 1 and Query 1.
able to utilize real-time data from external systems and
domains, providing automatic discovery and selection services In addition, the patient’s condition may also force the user
based on domain situations and conditions. See figure 1. to select several other services that should accompany the
selected service (the primary service). In such a case, the user
TABLE I. RELATED SERVICES AND THEIR DESCRIPTION
Service Name Service Quality Property: Cost, Relocation Duration Dependent Services Related Domain Data
Helicopter Service $2000, 1 hour Paramedic Service, Oxygen Supply Service, …
Ambulance Service $1000, 3 hours Paramedic Service, Oxygen Supply Service, … Patient Condition,
Patient Respiratory
Bus Service $100, 4 hours Paramedic Service … Status, …….
……… ………….. ……………..
We present a small example from healthcare describing must know which services can be provided to the patient along
problems users face to discover a service that depends on with a primary service. To support such features, the user has
domain context, and motivating features to be supported. to consider the services enabled by one service and with regard
Suppose a patient is in a hospital in Antigonish and a medical to patient’s medical service consumption history and current
professional determines that he should be relocated to Halifax condition. For example in Table 1, an Oxygen Supply Service
for care that is more specialized. The user submits Query 1 (see is enabled by the Helicopter Service which means, if a user
chooses Helicopter Service, he can also choose Oxygen Supply
Query 1:“Get a Relocation Service that can relocate Patient P from Service. However, for the Bus Service, he cannot choose the
Antigonish to Halifax.” Oxygen Supply Service. The user has to manually interface
Selection Strategy 1: If the Patient’s Condition is Normal, Select the different system components, namely: the patient data system,
Low Cost Service for relocating the Patient from Antigonish to Halifax.
Selection Strategy 2: If the Patient’s Condition is Critical, select the
the service dependability knowledge and SWS discovery
Fastest service for relocating a Patient from Antigonish to Halifax. engine. Hence, the user faces a great deal of difficulties while
Fact 1: The condition of the Patient P is Critical. trying to provide more than one service at a time to the patient.
Rule 1: If the patient’s condition is Critical, use fastest mode of
Relocation Service.
Step 1: Determine if the Patient’s Condition isCritical or not. If yes, then
Fact 2: The Patient P has a Respiratory Problem.
Step 2: Select the fastest service manually from the list of services
Rule 2: If the patient has a Respiratory Problems, there should be an
returned by the service discovery engine for Query 1.
Oxygen Sservice supplied while relocating.
Step 3: Find out if the Patient has a Respiratory Problem. If yes, then
Rule 3: If the Patient’s Condition is Critical, a Paramedic should
Query 2: “Get an Oxygen SupplySservice that can be provided while
accompany the Patient while relocating.
Patient is transferring using fastest Relocation Service selected by
IQ 1: “Get the fastest Relocation Service to relocate Patient P from
Query1.”
Antigonish to Halifax (uses Query 1, Fact 1, and Rule 1).”
Step 4: If there is an Oxygen Supply Service that can be provided with
IQ 2:“Get the fastest Relocation Service that supports Oxygen Supply
the selected Relocation Service then continue to the next fact. If there is
Service while relocating Patient P from Antigonish to Halifax (uses
no such Oxygen Supply Service selected from Query 1, go back, reissue
Query 1, Fact 1, Fact 2, Rule 1, and 2).”
Query 1, and select the next fastest service. Repeat until an Oxygen
IQ 3: “Get the fastest Relocation Service that can support Oxygen
Supply Service is found.
Supply Service and Paramedic Sservice while relocating Patient P from
Step 5: If the Patient’s Condition is Critical then,
Antigonish to Halifax (uses Query 1, Fact 1, Fact 2, Rule 1, 2 and 3).”
Query 3: “Get Paramedic Service that can be provided while the Patient
is relocating with the service selected by Query 1.”
Textbox 1: Examples of Queries, Facts and Rules Step 6: If there is a Paramedic Service returned by the service discovery
engine, the user could select that one. If there is no such service, the user
Textbox 1 below) to a SWS discovery engine, which will has to select next fastest service from Query 1.
match the query with a service repository and provide a list of
relocation services. However, this query does not incorporate Textbox 2: A scenerio of user interfacting different systems manually
other inputs such as patient condition, or patient disease history
and the user later may need to select a service depending on In addition, while the user tries to select services for a patient
such patient properties (examples of such selection strategies the user might need facts and rules in relation to selection
are Selection Strategy 1 and Selection Strategy 2). If none of strategies (e.g., facts and rules are Facts 1 and 2, Rules 1, 2
the discovered services fits patient properties, the user must and 3 in Textbox 1). This situation requires the user to check
initiate another discovery request and lose precious time. the database, and do additional steps. Also, based on the
Query 1 can be answered by state-of-the-art SWS service dependencies, the user may have to restart the process
approaches like OWL-S or WSMO. However, Selection from the beginning if the selected service cannot provide all of
Strategies 1 and 2 show how a user’s decision may change the required services. A typical scenario is given below.
based on patient properties. To support strategies representing The domain facts and rules lead the user to do several more
domain awareness, the user must inspect the patient medical queries (Query 2 and Query 3) (see Textbox 2) and manually
record and then make a decision based on the quality properties select services that are returned by traditional SWS discovery
of the list of services discovered. The selection strategies can processes. However, one can see that from Query 1, Facts 1
be articulated using domain object properties called facts and 2 and Rules 1, 2, and 3, we are really interested in getting
the results of the possible inferred queries IQ1, IQ2 or IQ3 (see also asserted in the domain ontology. At runtime, these rules
Textbox1), where IQ3 is the optimal query. For time critical will change the result of the discovery query to that of an
applications, taking such service dependencies into the inferred query due to a more refined search and discovery of
discovery process makes it more efficient and user friendly. services. Applying the facts and rules during discovery, the
answer to an inferred query can will obtained by applying
We describe a framework for intelligent SWS description, reasoning. This will reduce the need of user inspection and
discovery, and delivery that extends existing frameworks to: interaction to get a service that best suits the user’s need.
improve service discovery performance, facilitate integration of
domain-based information, and interface with legacy systems Service Metadata Based Reasoning and Discovery: The
such as workflow management systems. A workflow is a Inter-Service Dependency Relationships model can enable us
collection of interconnected Tasks with a specific control flow. to do on the fly service orchestration which can also save the
Each Task has a specification representing the action needed to number of queries required. The model expresses the
be carried out. We propose the notion of Service Enabled relationships between services in the service spectrum. A list of
Workflow (SEW) which will allow us to discover services interdependent services are provided in the service description
using the task specification as a query to the SWS discovery which then can be used in the discovery process and reasoning.
engine which will determine services that can carry out the E.g., in Table 1, if the user selected a Relocation Service like
action required by the task. SEW can provide desirable features BusService, the user cannot select OxygenSupplyService
such as: a) distributed workflow execution utilizing the because it is not supported but can select ParamedicService.
standalone nature of the services; b) service collaboration So, depending on the need of the patient and service
among various service providers as SEW can support the relationship, a service selection decision can be made.
choice and execution of services from different providers,
using them in a single workflow; c) decentralization of the Aggregation Query Support during Discovery: It is hard
workflow design, execution, and low coupling among to support some special queries like “Get the fastest relocation
workflow design and execution environment. service” using existing SWS discovery techniques. This
requires that we incorporate procedural programming
capability in a service discovery query. Procedural
II. PROPOSED MODEL AND ARCHITECTURE programming operation will be used along with DL based
Our framework focuses on the easy integration of SWS ontology query languages e.g. SPARQL Protocol and RDF
with a domain context and facilitates the interfacing with Query Language (SPARQL) [4] and Semantic Query-
systems developed using traditional approaches. The basic Enhanced Web Rule Language (SQWRL) [14]. This will allow
approach of service discovery traditionally contains a Service users to express complex aggregation and procedural
Discovery Engine, a Service Repository, and a Domain Service operations easily and intuitively in a discovery query.
Ontology; we add a data and context integration component Service Enabled Workflow: SEW imagines workflow as a
and a service metadata ontology. We can incorporate the data collection of tasks with control flows where tasks are carried
and context of legacy system by facts and rules that can be out as services. A workflow task has defined specifications,
utilized by SWS discovery for context and real-time data which can be imagined as a user query for the discovery of a
service discovery and selection. The model supports context service and the workflow engine can ask the service discovery
dependent service discovery using two ontologies which engine to discover services according to these task
provide the logic for a given service selection: 1) Service specifications. The workflow user may select a service to
Metadata Ontology which contains the service relationships execute from the discovered list of services. Continuing in this
with legacy system data and context; 2) Domain Facts and fashion, we can provide dynamic composition of services: the
Rules Ontology. The Service Metadata Ontology consists of a) overall result is SEW. SEW is a desirable feature that can
Service Domain Data Dependencies and b) Inter-Service easily provide workflow collaboration support with minimum
Dependencies. These ontologies allow us to do reasoning over efforts thorough service discovery and runtime composition.
service metadata, can be specified using OWL-2, and, can be
accommodated in both the OWL-S and in WSML-DL versions We propose a SOA based architecture shown in figure 2,
of WSMO approaches. We now discuss desirable features of a which supports integration of different domains; it consists of
hybrid SWS based decision support systems. the following components:
Domain Integration and Context Aware Service
Discovery: The “Relevant Domain Data” model articulates the
association of a service with the relevant domain data; in Table
1 it includes column 1 and column 4. Based on the relevant
domain data stated, we fetch data from the legacy system and
assert them as facts in the Domain Facts and Rule Ontology.
We can then use these facts asserted based on real-time data in
the SWS discovery process. Asserting a fact about a domain at
runtime, such as Fact 1, depends on the availability of the
Patient P’s property “Patient Condition” and the availability of
property value “Critical” which is gathered in real-time from a
database. Rules depending on the system’s situation and data
context that express the decision strategy related to a fact are Figure 2: System Architecture
Workflow Engine: works as a user query generator and language, T□, [13] which is used to write task specification
execution engine that enables Service Enabled Workflow. which include integration of data from a domain ontology. We
Service Discovery Engine: serves as a central plan to integrate our service discovery process to accept the
communication hub. It also carries out several decision- task specification. The discovery process then can provide the
making tasks about service dependency reasoning, and carries selected service to the Nova Workflow engine, which executes
out rules resulting in procedural steps. the service to accomplish the task.
Service Execution Environment: a server environment
providing service runtime requirements and run services. IV. REFERENCES
Patient Data Broker (Object Data Broker): works as a [1] Ankolekar, A. et al., 2002. “DAML-S: Web service description
broker to get data from external systems. for the semantic web.” In The Semantic Web—ISWC 2002,
Ontology Processor: is responsible for managing the Springer, p. 348–363.
ontologies and querying the ontologies. [2] Averbakh, A., et al., 2009. “Exploiting user feedback to improve
Service Repository: is responsible for holding information semantic web service discovery.” In The Semantic Web-ISWC
about services provided by the service providers. 2009, Springer, p. 33–48.
Domain and Data Context Plugin Manager: is [3] Davies, J. et al., 2006. Semantic Web technologies: trends and
responsible for the facts and rules related processing and research in ontology-based systems. Wiley.
domain based plugin management. [4] Garc’ia, J. et al., 2012. “Improving semantic web services
discovery using SPARQL-based repository filtering.” Web
III. RELATED WORK Semantics: Science, Services and Agents on the WWW.
The prominent conceptualizations of the SWS are OWL-S [5] Grossmann, Georg et al., 2011. “Conceptual modelling
[1][11] and WSMO [3][15]. OWL-S helps software agents to approaches for dynamic web service composition.” In The
discover web services that satisfy some specified quality evolution of conceptual modelling, Springer, p. 180–204.
constraints also provide a minimal set of composition [6] Grossmann, G. et al., 2008. “Modelling inter-process
templates. However, these abstract definitions can only be dependencies with high-level business process modelling
applied in a static service composition and can only be languages.” In Proceedings of the fifth Asia-Pacific conference on
arranged as a predefined combination of services in the Conceptual Modelling-Volume 79, p. 89–102. Austrian Computer
ontology. In [6], several types of inter-process dependencies Society, Inc.
are modeled using UML including Enabling, Cancelling, [7] Harold, M. 2008. “WSMX documentation.”
Triggering, and Disabling dependencies. WSMO also provides http://maczar.deri.ie/papers/wsmx-documentation.pdf.
a concept vocabulary to express service description in terms of [8] Keller, U. et al., 2004. “Wsmo web service discovery.” WSML
IOPEs but it currently only supports syntactical matching of a Draft, http://www.wsmo.org/2004/d5/d5.1/v0.1/20041112.
user’s goal against service descriptions. OWLS-MX [9] and [9] Klusch, M. et al., 2009. “OWLS-MX: A hybrid Semantic Web
WSMX [7] are the SWS execution and testing environments service matchmaker for OWL-S services.” Web Semantics:
for the SWS developed using OWL-S and WSMO approaches, Science, Services and Agents on the World Wide Web 7(2): 121–
respectively. OWLS-MX implemented the hybrid service 133.
discovery matchmaking using the OWL-2 reasoner Pellet. [10] W. MacCaull and F. Rabbi, “NOVA Workflow: A Workflow
OWLS-MX and WSMX both support SW query languages Management Tool Targeting Health Services Delivery,” in
SQWRL or SPARQL to perform semantic discovery of FHIES’11, ser. LNCS, vol. 7151. Berlin, Heidelberg: Springer-
services but do not use domain data dependent facts and rules Verlag, 2012, pp. 75–92.
to discover services. SADI [16] provides a design pattern for [11] Martin, D. et al., 2004. “OWL-S: Semantic mark-up for web
publication of services, interoperability with traditional WS, services.” W3C member submission 22: 2007–04.
and, semantic discovery and workflow generation based on [12] Merla, C. 2010. “Context-Aware Match-Making in Semantic
service input/output transition metadata. SADI does not Web Service Discovery.” Int’l Journal of Advanced Engineering
support domain data and context based service discovery and Sciences and Technologies 9(2): 243–247.
selction via integration and interoperation with legacy systems [13] F. Rabbi and W. MacCaull: "T-Square: A Domain Specific
and data. Presently, there are a variety of approaches to Language for Rapid Workflow Development," in ACM/IEEE
improve the accuracy of a service discovery process, including 15th Conf. on Model Driven Engineering Languages & Systems
collecting and integrating user feedback [2] and the addition of (MODELS 2012), Innsbruck, Austria (September, 2012). Proc,
contextual information by defining design time semantic based Lecture Notes in Computer Science, Volume 7590. pp. 36-52.
user context [12]. In our approach, the service description [14] Rodriguez, J. et al., 2010. “Improving Web Service descriptions
enables us to foresee the services dependencies and reason for effective service discovery.” Science of Computer
about them to discover services that best suit the system and Programming 75(11): 1001–1021.
context conditions based on described facts and rules. In [5] a [15] Wang, H. et al., 2012. “A formal model of the Semantic Web
conceptual model of task-based workflow is provided that Service Ontology (WSMO).” Information Systems 37(1): 33–60.
motivates our proposed Service Enabled Workflow. We extend [16] M. D. Wilkinson, et al., 2011. The semantic automated
the approach of [5] to support closer relationships with systems discovery and integration (sadi) web service design-pattern, api
and contexts, and improve the state-of-the-art of such and reference implementation. Journal of biomedical
workflow systems. The Nova Workflow Workbench [10] is a semantics, 2(1), 8.
task based workflow engine equipped with a high-level