Creating Dynamic Business Processes Using Semantic Web Services and Business Rules Yiwei Gong
Marijn Janssen
Delft University of Technology Jaffalaan 5, 2628 BX Delft, The Netherlands +31 (0) 15 27 83287
Delft University of Technology Jaffalaan 5, 2628 BX Delft, The Netherlands +31 (0) 15 27 81140
[email protected]
[email protected] Business processes, Business Rule, SOA, Ontology, Semantic Web Services, Composition.
ABSTRACT Service Oriented Architecture (SOA) and Business Rules (BR) are used by organization to adapt to changes. The disadvantage of this approach is that processes need to be defined in advance often requiring labor-intensive and time-consuming modeling processes. Usually, only a limited number of variations in processes are supported which have to be defined in design time. Hence, a shift from static to dynamic business processes creation is required. Semantic Web Services (SWS) can be used as a technology to create dynamic processes. Although there has been extensive research in the field of SWS and BR, there is scant research on the combination of them. In this paper, we propose an architecture based on BR and SWS to create dynamic business processes. Using a pre-agreed domain ontology to ensure the compatibility between SWSs and BRs, a new process is created by selecting the decision services using BRs and composing decision services with necessary assistant services. An illustrative study is used to demonstrate and evaluate the architecture on its feasibility in dynamic process creation. In this way, SOA systems in government environment can create a process with their services dynamically without having to hardcode the process. This can help the organization to efficiently adapt to changes in policies and legislation.
1. INTRODUCTION To comply with frequently changed law and regulations against low costs, government organizations increasingly pay attention to the creation of business processes that can rapidly adapt to the changes in law. On a technical level, this has already resulted in a broad acceptance of Service Oriented Architecture (SOA). SOA is a framework to “address the requirements of loosely coupled, standards-based, and protocol-independent distributed computing, mapping enterprise information systems appropriately to the overall business process flow” [1 p. 389]. Web Services based on the SOA framework provide “a suitable technical foundation for making business processes accessible within enterprises and across enterprises” [2 p. 198]. It is a standardized way of connecting applications, regardless of the type of platform they are running on. In an SOA environment, a new process can be created by selecting the already available services and invoking them. Weske [3] characterized the limitations of state-of-art service oriented systems as static service matching and static service composition. The former means the services are manually discovered using service registry facilities and the invocation of services is hard wired. The latter means the composition of existing services to create processes is a manual task. Static matching and composition take place during design time when a process is planned. As such, process design has been limited to pre-defining processes based on languages like the Business Process Execution Language (BPEL) and Business Process Modeling Notation (BPMN). Yet, frequent changes in the environment require that processes do not need to be defined using labor-intensive and time-consuming processes in advance and can be created on the fly. In a dynamic process creation, a service is selected and composited at run time based on the enduser request and it goal. Such an approach allows creating a customized process for each client.
Categories and Subject Descriptors H.1.1. [General System Theory]: Models and Principles –Systems and Information Theory; J.1 [Administrative Data Processing]: Administrative Data Processing – Government; H.4 [Information Systems Applications]: Miscellaneous; J.1 [Administrative Data Processing]: Government
General Terms Algorithms, Design, Experimentation.
Keywords
To allow machine understandable service description and overcome the need for manual service composition, semantic description is introduced as an enhancement of Web Service technology. Semantic Web Service (SWS) “is an emerging approach for designing an architecture that would provide a flexible integration” and be more adaptable to changes in the processes [4 p. 10]. It adds the dynamic access to functionality of Web Service. The advantage of using SWSs is that semantically
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. ICEGOV2011, September 26–28, 2011, Tallinn, Estonia. Copyright 2011 ACM 978-1-4503-0746-8…$10.00.
249
described services in various forms (manual or electronic) can be composed into complex processes corresponding to the life events of request [5]. By using their semantic description, services can be automatically selected and composited. However, the SWS applied approaches for government service are still in experimental phase [6]. A systematic approach to use semantic technology for the creation of dynamic process creation is still lacking. Such an approach should clearly describe how SWS technologies are properly addressed in the organization’s system to enable dynamic process creation.
described using open standards like OWL-S and WSMO. Then, the composition can be achieved based on semantic description and BRs. Then the business process is created according to the schema generated in the composition. In this chapter, we discuss SWS description, and BR driven composition.
2.1 Semantic Web Service Description In literature, SWS description was often discussed as a preparation for service matching. Typical matching approaches including a computation of similarity between service request and service supply to identify the best matching among candidate services [10]. But what we focus on in this section is the description rather than the matching.
Some public organizations already utilize rule-based approaches to manage their business logic, in order to gain more flexibility to deal with rapid changes in the environment [7]. In these rulebased approaches, the logic of a process is represented by a set of rules, which are associated with business activities and specify the properties of the process, e.g., the preconditions of its execution. A Business Rule (BR) is a directive intended to influence or guide business behaviors [8]. BRs can be categorized into declarative rules which define what is the goal of an operation, and operative rules which describe how an operation is done [9]. Despite various BR solutions, BRs is usually only applied in decision making in an automation process. Weigand et al. [9] have pointed out that many Business Rule approaches are restricted as they concentrate on the application for decision-making and do not address the business process constraints that underlie service composition. In a SOA environment, this means the BR used in process creation is too rigid. For example, the widely used process language, BPEL, allows predefining processes using rules which usually are condition-action rules to steer the selection of services. This is a predefined but not dynamic process creation as services are manually composited into a process. Although BPEL is de facto standard for business process description, BPEL is not flexible [9]. Service composition in BPEL intermingles process logic with BRs. This results in higher complexity of maintaining and updating processes and BRs, which is often a labor-intensive job. Without an architecture allowing dynamic process creation using SWSs, the use of Semantic Web technology in a government environment is limited. Therefore this paper focuses on combining SWS and business rules to create dynamic business processes which can quickly adapt to changes in legislation against low costs.
Dietze et al. [11] claimed that “a SWS description is formally represented within a particular ontology that complies with a certain SWS reference model such as OWL-S or WSMO” (p. 248). Such a description is suitable for both service supply and request. In describing software components and their matching, Zaremski and Wing [12] provided widely-used formalization to specify the foundation of semantic matching between two logicbased software components, which can also be applied on SWS. In their formalization, component C is a signature, Csig, and a specification of its behavior, Cspec. The former describes the statically checkable information, and the latter describes the dynamic behavior of the component. Exact matching between two components C and C’ can be conceptualized as: Match {C,C’} = matchsig{Csig,C’sig}∩matchspec{Cspec,C’spec} Toch et al. [13] extended this formalization to describe a SWS or a SWS request and the different levels of their matching. They defined a tuple of concepts {C1,C2,…,Cn} to represent service query CQ, and another one {C’1,C’2,…,C’m} to represent candidate service CS. Moreover, four levels of matching can be identified:
To apply dynamic process creation in government organizations, BRs are necessary for steering the creation of business processes. As business rules are derived from policy and legislation, the consistent use of BRs can automatically ensure that processes are compliant with law. To achieve this, a combination of BRs and SWSs can be used. In this paper, we propose an architecture using a shared domain ontology to enable the communication between BRs and SWSs. In this way, it allows BRs to steer the composition of SWSs. We start with the discussion of SWS description and business rule driven composition. Thereafter, the architecture is presented. In the section thereafter, we demonstrate the approach using an illustrative example. The conclusion and future work of research is given in the final section.
•
Exact, or CQ≡CS, which means perfect match.
•
Subsumption, or CQ ⊂ CS, which means concepts of the query are fully contained in the properties of the candidate service.
•
Plugin, or CQ ⊃ CS, which means the properties of candidate service are fully contained in the concepts of the query.
•
Disjoint, or CQ∩CS= φ , which means none of concepts of the query can be related to any property of the candidate service.
Based on such formalization, the ontology of SWS can be designed. Ehrig and Sure [10] used a tuple including schema (static) and instance data (dynamic) to represent a SWS ontology. However, their purpose was to map ontologies used by SWSs instead of the SWSs themselves. Dietze et al. [11] extended this and suggested that a SWS ontology can be perceived as a conjunction of ontologies subsets, and it can be classified into sematic and data level. The semantic level refers to resolution of heterogeneities between semantic representation, e.g., using different ontologies. The data level relates to the Web service construction, e.g., the format of I/O messages. Compared with an interface based matching, distinguishing sematic level and data level provides an extra layer in the matching. The description as semantic level is usually simpler than the description of I/O
2. BACKGROUND AND RELATED WORK The essential of creating dynamic business process is to steer the sequence of steps in real-time and in each step selecting the appropriate services. In the effort of service composition, SWS is 250
messages. By doing the matching at semantic level, the search result of candidate services for matching at data level can be narrowed down, and therefore the matching can be more efficient. Furthermore, adding the semantic level allows an easy distinction between services that have the same I/O messages but provide different functions.
and being quicker in the response as process creation is automatic. In the current state of art in government service composition, users have to specify an abstract process of the required composite Web Services, and the control and data flow between these services. Moreover, neither the widely used language like WSDL and BPEL nor others workflow language such as YAWL allow automated composition [16].
Government services can be either provided by the organizations (internal) or external services. Internal services usually are based on a unified ontology defined by the organization. Typically, they all consistently use vocabulary from the unified ontology to ensure interoperability. In contrast external services can be based on any standard. The above approaches are only appropriate for external services matching, in case the matching result can be exact or subsumption. However, subsumption comes with an assumption that subset concepts are acceptable as substitutes of the parent concept. But it cannot always be correct [13]. In case of being plugin, the situation can refer to cross-organizational processes, where internal services are not adequate to satisfy the request from clients, and external services are required in the process creation. If different government organizations can adopt the same ontology, matching the external services can be the same as matching internal services.
Generally speaking, SWS composition is a state-based planning problem {Initial State, Services, Goal}, where the Initial State of world is given, and a sequence of Services are invoked to achieve a Goal. The task of composition is to find a proper sequence of services {SWS1,SWS2,…,SWSn} that can fulfill the goal. To make a process execution feasible, such a planning is necessary. If a client’s request was accepted without a planning of the process in advance, it can happen that the request processing might fail on the halfway and it is a waste of time and resource. Although a planned process can still fail, the chance of its failure is much less than an unplanned process. Current service compositions as used in many government BPM systems are static and predefined. In order to automate business processes using existing services, designers need to first understand entire requirements of processes and services, and then use modeling tools to create composition schemas, e.g., a BPEL schema with service invocation configuration (control flow and data flow etc.). In this approach, the designer is required to explicitly identify the services that compose business processes and specify the sequence of execution. This mode of composition requires all possible sequence of services to be defined a priori. It might lead to a huge number of execution paths to be defined in a design time. Such a problem implies the use of BRs in conducting service composition to replace the rigid and predefined composition schema (c.f. [17, 18]).
For the SWSs under a unify domain ontology, like internal services, matchmaking is normally based on the elements at data level. Consequently, matching a SWS supply and a SWS request uses their characteristics, such as input, output, precondition, and effects (IOPEs) [14]. Shin et al. [15] have pointed out that many Web Services are specified by I/O without precondition and effects, and only I/O information cannot sufficiently describe the functionality of a service. They suggested using functional semantics of a service to guarantee the correctness of matching. To simply and directly express what a service actually does, they defined service functionality as {action, object}. In additional, a domain ontology to define domain actions was suggested. In this way, functional semantics was added to the I/O information, and a Web Service was specified as {service functionality, input set, output set}. Separating the semantic level and data level, the matching at semantic level only considered the functionality of SWSs. The matching would continue at the data level if any candidate SWS was selected at semantic level. With a domain ontology to describe vocabulary, such a description takes both the functionality and I/O of a service into account, and moreover, remains relatively simple in the description construction and maintaining.
Using BRs in service composition is not a new idea. Orriëns et al. [19] have indicated that BRs can be used to determine how the composition should be structured and scheduled. D'Mello et al. [20] identified business rule driven composition as one of the eight categories of composition strategies. Yet, limited research of business rule driven composition can be found in literature. Some of them tried to interweave BRs into BPEL frame, e.g., [21]. The others intended to build novel framework without using BPEL, e.g., [17, 22]. However, in those approaches, BRs and Web Services were not compatible because they use different ontologies. Although they both can be semantic, they are not holding collective semantics foundation, as the same term/object can have different properties and different relationship with other terms in different ontologies. Without unified ontology, BRs for service composition had to know the exact interface of related services instead of their semantic description. Such a way makes the semantic level of Web Services meaningless. D'Mello et al. [20] also argued that business rule driven composition requires BRs to be documented in a unified ontology for successful composition.
2.2 Business Rule Driven Composition A service request from end-users is often difficult to standardize in advance, as it might have different requirement or even multiple related requirements to be satisfied. Those requirements can hardly be processed by just a single service. Typically, a SWS composition takes several SWSs and bundles them together into a process to meet the demand of a given client. The selection of SWSs is based on the semantic service description mentioned in the last section. Then, a schema of a process is generated as the result of service composition. From a client’s point of view, the composition of a process is invisible. The process has to be executable without any input other than those provided by the clients. Automating the composition can improve the flexibility of processes to deal with change in requirements. The benefit includes the capability to respond various requests from clients
Providing BRs with a semantic description in open standard and enable their interaction with Semantic Web resource is a new implementation recently. The development of BRs on Semantic Web domain has been focusing on a standard representation of BRs rules. Some standardized rule languages have been proposed by different organizations, e.g., the Semantics of Business Vocabulary and Business Rules (SBVR) from OMG and the Rule 251
Interchange Format (RIF) from W3C. Those standards are not specific for the application of BRs but their platform independence. An architecture allowing the use of SWSs and BRs to create dynamic processes under a unified semantics is still missing. Our starting point is that a unified domain ontology that provides vocabulary and taxonomy (or concept hierarchy) for both SWSs and BRs should be pre-agreed before developing the description of SWSs and BRs. That means they should share the same ontology and no conflict and misunderstanding of terms will happen in reasoning.
ontology. To perform prefect matching between a SWS and a service request, both the semantics at data level and function level should be described. As the discussion in the previous chapter, a SWS can be described as SWS = {service functionality, input set, output set}. A service request does not have input but only output. In addition, the initiator and its intension need to be described. Initiator is the semantic identifier of the service requester. This distinguishes the requester from other kind of requesters. Intension indicates the deliverable of process which is the goal of process creation. The description of a service request is given as SR = {initiator, intension, output set}.
3. PROCESS CREATION USING SEMANTIC BUSINESS RULES
Step 3: Describe BRs The final step is to describe BRs in ontology models. BRs can be briefly categorized into declarative rules and operational rules. Traditionally, operational rules are used in the decision making which is involved in the execution of services, such as conditionaction rules or event-condition-action rules [23]. In contrast, the BRs for service composition are declarative rules, which describe the goal rather than actions. The most important role of these BRs is to clarify the relationship between initiators and their desired services. Unlike the codified BRs in BPEL processes, where service compositions are pre-defined using interface, the relationship is described in a semantic way. As such, the detail of interface is hided from the BRs to reduce the complexity of their maintaining. Moreover, since the BRs are separated from processes, users do not have to indicate which BR is used at which certain point of a process. Appropriate BRs can be automatically discovered in their depository by using some inference technologies like backward chaining. This can reduce the complexity of using BRs.
The potential benefit of dynamic processes creation motivates the use of SWS in government. BRs are an important resource that can ensure the law compliance. In this section, we describe our approach of dynamic process creation using SWSs and BRs. The approach contains a preparation phase resulting in a semantic description of all the necessary resources and a dynamic process creation phase in which a composition architecture allows dynamic process creation.
3.1 Preparation: Semantic Description Before a dynamic business process can be created, the services and rules should be semantically described in such a way that they can be understandable by the system. To ensure the interoperability, the vocabulary used in their description should be unified. Hence, there are three steps in the preparation: first build a domain ontology, then describe the service, and finally describe the rules. Step 1: Build a domain ontology
In the use of declarative BRs, we distinguish between decision and assistant services. Taylor and Raden [24] used a term “decision service” to describe a self-contained callable component with a view of all conditions and actions that need to be considered in making an operational business decision. They simply called it a service that answers a business question for other services. Decision services refer to legislation, which implies that the use of these decision services is mandatory and they are the main services that can satisfy the service request with final decision making. Containing the law related decision making logic, it is an essential step of the process to comply with law enforcement but might not be able to satisfy the request on its own. In the execution of the decision services, assistant services might need to be composed with them. As assistant services are not directly impacted by law enforcement but depend on the design strategy of the organization, using BRs to steer the composition for assistant services is not necessary. In this case, we can perform service selection and composition just based on functional level and data level matching.
In the first step of preparation, a pre-agreed domain ontology is created to provide consistent semantics for both SWSs and BRs. A domain ontology shared by both the SWS description and BR description avoids conflict and mismatching on concepts, as in a well-defined and unified ontology, concepts are unified without overlap with each other. Unlike the Internet environment where multiple similar ontologies might exist, government services should be easier to adopt a unified domain ontology. Such a domain ontology needs to provide vocabulary and taxonomy that are used by the description of SWSs, service requests and BRs. It consists of concepts, their properties and relationship between concepts. What concepts should be involved is mainly depended on the context. Besides those context related concepts, some concepts of system behaviors might be common of all kinds of organizations. For example, the actions of information retrieval and recording can be found in many ontologies no matter what domain they are describing. In the following Step 2 and 3, SWSs, service requests and BRs are also need to be described in an ontological way. Although they can also be described in the domain ontology as concepts, it is better to separate their description from the domain ontology, because services and BRs are frequent changed, but the domain context is relatively stable.
Distinguishing decision and assistant services has two advantages: 1) decision logic and criteria are capsulized in a service. Since in a SOA environment services can be called from anywhere, locating BRs into such a clearly identified decision services allows high traceability of operative BRs. 2) Assistant services can be used as infrastructural services with high reusability. Services like information retrieval have purpose for information/data provision to decision making. They allow a single information source reusable to multiple decision services. Other assistant services may facilitate decision services by
Step 2: Describe SWSs The second step is to describe SWSs and service requests in ontology models using the vocabulary provided by the domain 252
providing user interface or report generation etc. They should be designed as much reusable as possible. We suggest making each data provision assistant service contain only one output. By doing so, we can apply a relevantly simpler service matching method and ensure the reusability at the same time. The relationship between decision services and assistant services can be conceptualized in the following figure.
general/specific classes, or retrieve individuals/tuples matching a given query. This mechanism allows a subclass being able to use the BRs defined for its parent class. Legislation is often improved by introducing exceptions on certain aspects for special situations. For example, foreigners who graduate in local universities are allowed to apply a lower incoming requirement in requesting a resident permit (see the case study in the next chapter). This implies that both the rule for regular applicant and the one for this exception situation are valid on a foreigner graduate. The inheritance in ontology model can address such a situation by defining foreigner graduate as a subclass of regular applicant. The inference engine can ensure the subclass object can retrieve the BRs for its parent class. In this way, the law compliance is maintained.
Domain Ontology
BR Models
SWS Ontology
Figure 1. Relationship between decision services and assistant services
3.2 Architecture for integrating BRs and SWSs
Inference Engine
After the semantic representations of domain knowledge, SWS and BRs are well prepared, an architecture for creating dynamic processes needs to be realized. Since the SWS and BR description is compatible when they are presented using ontology model and sharing the same domain vocabulary, an inference engine can be used to perform reasoning on the both. Each inference result provides service selection based on either BRs or service matching. The former provides selection of decision service, and the latter provides selection of assistant service. The compositor is therefore able to carry service composition based on the end-user request and the inference results. The elements that are required in a dynamic process creation and their relationship are shown in Figure 2.
Compositor
Services Execution
The process creation consists of two stages. The first one distinguishes the initiator situation and goal as the starting point, and then selects the related BR model to identify the decision services which can reach the goal. The latter one discovers necessary assistant services to satisfy all the required input of the decision service according to semantic description of the decision services and the given end-user request, and then builds a process out of them. When the existing services or their combinations can fulfill the request from the end-user, such a process can be built. Otherwise, new or adapted services might need to be introduced. Figure 2. Architecture for integrating BRs and SWSs
The first stage, named ‘rule based composition’, can be implemented using ontology inference. Its objective is to identify an appropriate decision service to respond the service request from an end-user. We consider the service composition in this phase as a goal-directed planning problem that takes two inputs: 1) a set of domain specific business rules models which have associated pre-conditions, or obligations, and 2) a description of requester and its business objective or goal. The BRs and business objective or goal must be presented using a consistent semantics which is described in previous sections. Ontology models allow querying over ontology classes and instances, e.g. find more
The second stage, named ‘logic-based composition’, uses backward chaining as reasoning mechanism. This phase is not guided by BR models and based on two inputs: 1) a description of requester and its output, and 2) a description of selected decision service and its input. If the request’s output RO perfectly matches the decision service’s input DI, namely RO ≡ DI, then the composition is finished and a single decision service can satisfy the service request. Otherwise, if the RO is a subset of DI, namely RO ⊂ DI, the following steps will be used for the service composition. 253
1)
Define R as complement set of RO, namely DI = RO ∪ R, and for each element or subset ri in R (r ∈ R), formulate a service request FSri.
2)
Perform service matching for FSri and list all the candidate services.
3)
If no candidate can perfect match FSri, in a plugin situation, for each candidate, repeat step 1), 2) and 3) until a perfect match is found. In case it is a subsumption situation, the matching might fail. Therefore, we suggest having only one output in each data provision assistant service in order to avoid subsumption situation in service matching.
4)
changed frequently in the recent years. In 2007, the annual income limitation on an applicant is at least 46,541 EUR or 34,130 EUR if the applicant is under 30. In 2008 there was a change in legislation in order to retain foreign intelligent graduates and encourage them to work in the Netherlands. The income limitation, for the foreign graduate that obtained a Bachelor or Master Degree at an accredited Dutch educational institution within one year before becoming employed, was changed to 25,000 EUR annually. In 2009 there was another change in legislation. Employees must have a gross annual income of at least 49,087 EUR, or 35,997 EUR if they are under the age of 30. There are two different situations to which the reduced wage criteria applies (in 2009 25,800 EUR gross a year). The first situation is aimed at graduates that obtained a Bachelor or Master Degree at an accredited Dutch educational institution, similar to the 2008 situation. The second situation concerns Master and PhD students who graduated in the Netherlands or at a university listed in the top 150 of two internationally recognized rankings.
Chain the found services and the decision service to provide a composition plan.
In case RO ∩ DI ≠ φ , define RO’ = RO ∩ DI, then replaced RO by RO’ and perform the algorithm mentioned above. Our proposal is different from traditional business rule techniques like BPEL4WS, in which the business rules are implicitly codified in the service selection and composition. By distinguishing decision services and assistant services, we use BRs as semantic description of relationship between process initiator and decision service to steer the mainstream of the process and ensure the law compliance. For the service composition between decision services and assistant services, we apply matching based on their semantic description. In this way, we reduce the maintaining effort for BRs as the complexity of BRs are reduced and fewer BRs are required. Using the semantic description of SWSs, BRs and domain ontology, the system is able to create a dynamic process based on the end-user’s request. The composition plan is generated automatically without human intervention for all possible combination of existing services and therefore, the flexibility is higher.
Over the last years, there were basically three types of changes that needed to implement to ensure compliance to the legislations. 1)
General income requirements: The general income requirements needed to be changed regularly. This occurs frequently as the wage criterion for HSM is indexed annually. 2) Additional check for educational institutions: A check for Bachelor and Master degrees at accredited Dutch educational institutions had to be added to the admission process. 3) Additional check for ranked institutions: A check for Master and Ph.D. degrees at certain ranked educational institutions had to be included to the admission process. Please be aware that the original HSM policy includes a much broader scope with more related concepts and legislation. The above introduction is a simplified description of the HSM program for practical reason.
4. AN ILLUSTRATIVE CASE STUDY
4.2 Building a Domain Ontology
The Immigration and Naturalization Service (Immigratie en Naturalisatie Dienst, or IND) is the organization that handles the admission of foreigners in the Netherlands. It is responsible for the execution of a complex set of regulations coming from different sources of law, including international law, national law, case decisions and policy directives. Moreover, the IND makes a large number of decisions, i.e. some 300,000 a year in the areas of asylum, standard objections to decisions, and naturalization. Under pressure from frequently changing law and regulations, the IND is one of the governmental organizations that desire a higher level of flexibility in their business processes. In this chapter, we illustrate the approach described in previous chapter to implement dynamic process creation for one of their business processes in an empirical way.
In our approach, the first step is to define a domain ontology to provide consistent understanding of concepts. In Figure 3 most concepts used in service description are involved and connect. For space reason, we didn’t include every concept as this figure is enough to demonstrate the structure of a domain ontology. As a typical case system, the domain ontology contains the identification of different clients under the Person class. Similar to the Object-Oriented programming, its subclasses inherit all its properties. We also defined an Action concept, and its several subclasses with different semantic meanings. Request indicates a service call from clients. It means a process initiation. In contrast, Return is the end of a process which a final result is returned to the client. Decide indicates a decision service for providing a decision-making. Check is for the provision functionality providing data by an assistant service. Resident Permit and its subclasses sound like services. But in this example, they are final deliverables of processes instead of services.
4.1 The Context A use case dealing with a Highly Skilled Migrant (HSM) program that provides residence permits for foreigners was selected to prove our concepts. One of the reasons for choosing this use case is that it is often subject to changes (initiated at the politician levels) and has a large number of applicants. The HSM admission legislation is introduced to enable qualified foreigners to work in the Netherlands. The policy with respect to HSM has been 254
HSM
HSM Dutch Graduate
Request
HSM Foreigner Graduate
Return
found it useful to only define decision services if they directly relate to law requirements, as this has its contribution to ensure the law compliance. The rest service (S7 and S8) are responsible for process initiation and finalization. They are employed for better client experience and security, i.e., providing user interface, or input checking. Although they are necessary in a process, they are not included in discussion of BRs for dynamic process creation, because all the processes involve these two services.
Decide Resident Permit
Table 1. The example of services in the HSM case
Action Check
Thing
Legend
Result
Decision
Person
ID
SWS S1
S2 Concept
Subclass relation Property
Date of Birth
Concept class
Applicant
S3
Income
Property Object property relation
S4
Institute
Foreigner Graduate
Dutch Graduate
Graduation date
{{Decide, HSM Dutch Graduate}, {ID, Income, Degree, Institute_Accreditment, Graduation date}, {ID, Decision}} {{Decide, HSM Foreigner Graduate}, {ID, Income Degree, Ranking, Graduation date}, {ID, Decision}} {{Check, Income}, {ID}, {Income}} {{Check, Institute_Accreditment}, {Institute}, {Result}}
S6
{{Check, Ranking}, {Institute}, {Result}}
S7*
{{Request, Resident Permit}, {ID, Date of Birth, Degree, Institute, Graduation date}, { ID, Date of Birth, Degree, Institute, Graduation date }}
Figure 3. Part of the domain ontology in the HSM case
4.3 Describing Semantic Services Using those concepts provided by the domain ontology model, we listed the designed services that used in HSM processes and their semantic representation in Table 1.
{{Decide, HSM}, {ID, Age, Income}, {Decision}}
S5
Graduate Degree
Specification
Description Decide whether the application satisfies regular HSM requirement Decide whether the Dutch graduate satisfies HSM requirement Decide whether the foreigner graduate satisfies HSM requirement Check the income information Check whether an institute is accredited Dutch educational institution Check whether an institute is listed in the top 150 of a certain ranking Intake submission from applicants and initiate a processes
Return the final result of decision to the applicant * The Service S7 has multiple forms of input and output, which allow empty value of certain parameters when they are not necessary. S8
Among the services in Table 1, S1, S2 and S3 are decision service, while S4, S5 and S6 are assistant services. Decision services use BRs that are directly derived from the HSM policy. Although the implementation of decision services can be various depending on the preference of the law execution organization, they are the services that directly reflect the requirement of law and regulation. Assistant services are not derived from legislation, but reflect the organization’s consideration in service system design and the design principle of SOA. In this case study, the use of assistant services is to make them reusable for other services and allow easier maintenance. Generally speaking, tow simpler services are easier in maintaining than an all-in-one service with equal functionality. For the IND, separating the check income service (S4) from the HSM service (S1) makes its maintaining easier than a monolithic HSM service including check income function. In case that the S4 need to be adapted, e.g., we can get the income information from an external Web Service provided by the tax administration, the change of S4 will not impact S1. We
{{Return, Decision},{ID, Decision},{ID Decision}}
4.4 Describing Business Rules A semantic BR can be presented in an ontology which provides instruction of process building. Typical BRs can strong relate to decision-making which is normally capsulized in a certain service. For example, the business logic of HSM based on income and age information is capsulized inside Service S1. A change of the income limitation can be easily adapted by changing BRs used in S1 without impacting other services. In this case study, we emphasize the BRs for process building, as the management approach for decision-making BRs is already mature and widely accepted in industry. We hereby list the process related BRs in SBVR format:
255
1.
“It is possible that an applicant requests resident permit as Regular HSM.”
services to assist the decision making of certain type of HSM resident permit, if it is necessary.
2.
“It is possible that a Dutch graduate requests resident permit as Regular HSM or HSM for Dutch Graduate.”
3.
“It is possible that a foreigner graduate requests resident permit as Regular HSM or HSM for Foreigner Graduate.”
In the first type of selection, the ontology model which derives from business rules describes the relationship between a process initiator and its goal, so that the related decision services can be identified. In Figure 4, the initiator, Applicant, Dutch Graduate or Foreigner Graduate and their individual goal of getting certain type of resident permit are connected. The model allows reasoning engine to perform inference to determine which decision service(s) should be involved, so that the compositor can be aware of the decision service(s) when a request is identified from a certain initiator. This also includes the identification of decision services according the inheritance relationship. In our example, S1, S2 and S3 can be individually identified as the decision service for Applicant, Dutch Graduate and Foreigner Graduate. Although BRs have indicated the selection of services, this is just on the semantic level. Matching on data level is still necessary to verify the selection. The verification should check whether the output set of service request is equal to or a subset of the input set of the decision service (RO ≡ DI or RO ⊂ DI).
Please note that the policy takes the situation for Dutch Graduate and Foreigner Graduation as exceptions of the Regular HSM. The policy does not deny their right to apply Regular HSM but allow them to applied easier criteria if the Regular HSM criteria cannot be met. The semantic representation of the above BRs:
In the second type of selection, services matchmaking is based on their functionality and interface. To be specific, the matching relies on the terms maintained in the domain ontology. For example, when income information is required, Service S4 can be found by S1 according to its functional description {Check, Income}. Such a key words based matching provides an easy way of service discovery, and no specific BR needs to be defined for this selection. Instead, the matching is based on an elegant domain ontology and correct and clear use of terms. Alternatively, the first type of selection can also be used to replace the second type of selection, if extra model to describe the relationship between a decision service and an assistant service can be built. In this case, an extra BR to guide the selection is needed. Which type of selection is used depends on the design of domain ontology or BR representation. It can be considered as a trade-off between the maintaining of BRs and the maintaining of SWS description, specially its functionality description. Based on the discussion above, the planning of HSM processes can be one of the following process alternatives:
Figure 4. Semantic representation of HSM process related BRs In this case, the BR applied on Class Applicant is also applied on Dutch Graduate and Foreigner Graduate, as they are the subclasses of Applicant. Therefore the logic in regular HSM process is not repeated in the process for HSM for Dutch graduate or HSM for foreigner graduate, and still these processes can satisfy the law compliance. Furthermore, unlike hard coded BRs, the BR model in this case does not need to involve the data flow and interface information. This reduces the maintaining of BR model.
4.5 Dynamic Process Creation To simplify the process and focus on the orchestration, we assume that the request from the client is complete and correct. That means, for example, the date of birth of the client is not later than the current date, and etc. Possible requests from clients can be {{Applicant}, {HSM}, {ID, Date of Birth}}, {{Dutch Graduate}, {HSM}, {ID, Degree, Institute, Graduation date}}, or {{Foreigner Graduate}, {HSM}, {ID, Degree, Institute, Graduation date}}. Their intention, HSM, indicates the purpose of application is for HSM resident permit, not other kinds of resident permit like family reunification or study.
•
{S7, S1, S4, S8} when initiator is an Applicant;
•
{S7, S2, S4, S5, S8} when initiator is a Dutch Graduate;
•
{S7,S3, S4, S6, S8} when initiator is a Foreigner Graduate.
Each alternative is a process that deals with requests from a certain kind of clients identified in the legislation. The alternatives of the HSM processes can be presented as Figure 5. By this case study, we briefly demonstrated our approach for dynamic processes creation. We defined necessary concepts in a domain ontology. At the same time, the SWSs and BRs were semantically presented. The homogeneous representation and the domain ontology allowed a common understand on SWSs and BRs. This resulted in the enablement of using a reasoning engine for computation of service matching and composition. Our focus was on the identification of general elements that are necessary for dynamic processes creation and their arrangement. Technology
There are two kinds of important service matching in the creating of residence permit application processes. The first one is the service matching which concerns the selection of a decision service responding to the decision making of certain type of HSM resident permit. The other one is the invocation of assistant 256
detail, like the selection of reasoning engine and reasoning algorithm were not included.
cost of maintaining pre-defined processes. We think that this depends on the frequency of changes in the legislation. The frequenter the change is, the higher the motivation to use this approach There are several limitations. First of all, it requires a lot of effort in defining and maintaining the domain ontology. More research in matching SWS and BRs without having a shared ontology is necessary. The second limitation is that a backward chaining service composition can result in several schemas and thus the need to apply optimization strategy to select the best one. The optimization has not been taken into account.
6. ACKNOWLEDGMENTS This work is supported by AGILE project (acronym for Advanced Governance of Information services through Legal Engineering, http://www.jacquard.nl/?m=426).
7. REFERENCES [1] Papazoglou, M.P. and van den Heuvel, W.-J. Service oriented architectures: Approaches, technologies and research issues. The International Journal on Very Large Data Bases (VLDB), 16 (3). 389-415. 2007. [2] Leymann, F., Roller, D. and Schmidt, M.-T. Web services and business process management. IBM Systems Journal 41 (2). 198-211. 2002. [3] Weske, M. Introduction. in Kuropka, D., Staab, S., Tröger, P. and Weske, M. eds. Semantic Service Provisioning, Springer, Belin Heidelberg, 2008. [4] Vitvar, T., Peristeras, V. and Tarabanis, K. Semantic Technologies for E-Government: An Overview in Vitvar, T., Peristeras, V. and Tarabanis, K. eds. Semantic Technologies for E-Government Springer, Heidelberg, 2010, 1-22. [5] Sabol, T., Furdík, K. and Mach, M. Employing Semantic Technologies for the Orchestration of Government Services. in Vitvar, T., Peristeras, V. and Tarabanis, K. eds. Semantic Technologies for E-Government, Springer, Heidelberg, 2010, 47-74. [6] Sourouni, A.-M., Kourlimpinis, G., Mouzakitis, S. and Askounis, D. Towards the government transformation: An ontology-based government knowledge repository. Computer Standards & Interfaces, 32 (1-2). 44-53. 2010. [7] Lu, R. and Sadiq, S. A Survey of Comparative Business Process Modeling Approaches. in Abramowicz, W. ed. Business Information Systems, Lecture Notes in Computer Science, 4439, Springer, Heidelberg, 2007, 82-94. [8] Ross, R.G. Principles of the Business Rule Approach. Addison-Wesley Professional, 2003. [9] Weigand, H., Van den Heuvel, W.-J. and Hiel, M. Business policy compliance in service-oriented systems. Information Systems, 36 (4). 791-807. 2011. [10] Ehrig, M. and Sure, Y. Ontology Mapping - An Integrated Approach. in Bussler, C., Davies, J., Fensel, D. and Studer, R. eds. The Semantic Web: Research and Applications, Lecture Notes in Computer Science, 3053, Springer, Heidelberg, 2004. [11] Dietze, S., Benn, N., Domingue, J., Conconi, A. and Cattaneo, F. Two-Fold Service Matchmaking – Applying Ontology Mapping for Semantic Web Service Discovery. in Gómez-Pérez, A., Yu, Y. and Ding, Y. eds. 4th Asian
Figure 5. HSM processes alternatives
5. CONCLUSION AND DISCUSSION In this paper, we introduced an approach for creating dynamic business processes using Semantic Web Services (SWSs) and Business Rules (BRs). The approach includes a pre-agreed domain ontology to provide consistent semantics for both SWSs and BRs descriptions. Furthermore, it involves an architecture for creating dynamic business processes in run time. We have used an illustrated case study to demonstrate the application of this approach. This architecture goes beyond existing process management techniques like BPEL and BPMN which are static in nature as they require the definition of the business processes in advance. There are several contributions in this research. SWSs and BRs are combined to allow dynamic process creation. We learned the SWS description methods for Internet applications and used them to present government services and their requests. In order to use BRs efficiently, we identify decision and assistant services in the design time. Separating these two kinds of services allows the use of BRs in steering the critical part of process creation. This ensures the compliance with law and higher flexibility in processes. In this way, BRs are not just used in decision making within the service, but also the process creation among services. A starting point was the requirements of having homogeneous representation of SWSs and BRs as a design strategy. As SWS and BR representation used to be heterogeneous, they were difficult to interoperate. In our approach, we used a pre-agreed domain ontology as the semantic foundation for both SWSs and BRs representation to make them compatible. We belief that this can simplify the service composition by reducing format translation components and allowing a single reasoning engine to perform inference on both SWSs and BRs. At the end, a case study provided insight of how government services can be arranged to achieve dynamic process creation and how law compliance can be ensured. This requires the organization to maintain a unified domain ontology. Organization will use the dynamic process creation approach only when the cost of building and maintaining a pre-agreed domain ontology is lower than the 257
[12]
[13]
[14]
[15]
[16]
[17]
[18] Zeng, L., Ngu, A.H.H., Benatallah, B., Podorozhny, R. and Lei, H. Dynamic composition and optimization of Web services. Distrib Parallel Databases, 24 (1-3). 45-72. 2008. [19] Orriëns, B., Yang, J. and Papazoglou, M.P. A Framework for Business Rule Driven Service Composition. in Benatallah, B. and Shan, M.-C. eds. Technologies for E-Services, Lecture Notes in Computer Science, 2819, Springer, Heidelberg, 2003, 14-27. [20] D'Mello, D.A., Ananthanarayana, V.S. and Salian, S. A Review of Dynamic Web Service Composition Techniques. in Meghanathan, N., Kaushik, B.K. and Nagamalai, D. eds. Advanced Computing, Communications in Computer and Information Science, 133, Springer, Heidelberg, 2011, 8597. [21] Charfi, A. and Mezini, M. AO4BPEL: An Aspect-oriented Extension to BPEL. World Wide Web, 10 (3). 309-344. 2007. [22] Yao, Y. and Chen, H. A Rule-based Web Service Composition Approach Sixth International Conference on Autonomic and Autonomous Systems, IEEE, 2010, 150-155. [23] Bailey, J., Poulovassilis, A. and Wood, P.T. Analysis and Optimisation of Event-condition-action Rules on XML. Computer Networks, 39 (3). 239-259. 2002. [24] Taylor, J. and Raden, N. Smart (Enough) Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions. Prentice Hall Press, 2007.
Semantic Web Conference (ASWC 2009) Proceedings, Lecture Notes in Computer Science, 5926, Springer, Heidelberg, 2009, 246-260. Zaremski, A.M. and Wing, J.M. Specification matching of software components. ACM Transactions on Software Engineering and Methodology, 6 (4). 333-369. 1997. Toch, E., Reinhartz-Berger, I. and Dori, D. Humans, semantic services and similarity: A user study of semantic Web services matching and composition. Web Semantics: Science, Services and Agents on the World Wide Web, 9 (1). 16-28. 2011. W3C. OWL-S: Semantic Markup for Web Services (W3C Member Submission 22 November 2004), 2004. http://www.w3.org/Submission/OWL-S/ Shin, D.-H., Lee, K.-H. and Suda, T. Automated generation of composite web services based on functional semantics. Web Semantics: Science, Services and Agents on the World Wide Web, 7 (4). 332-343. 2009. Klusch, M. Semantic Web Service Coordination. in Schumacher, M., Schuldt, H. and Helin, H. eds. CASCOM: Intelligent Service Coordination in the Semantic Web, Birkhäuser, Basel, 2008, 59-94. Weigand, H., Van den Heuvel, W.-J. and Hiel, M. RuleBased Service Composition and Service-Oriented Business Rule Management Regulations Modelling and Deployment (ReMoD'08), CEUR, 2008.
258
