Change Management in Semantic Web Services in Legal Domain using FSM & XXM

Introduction

With the new paradigm of Service Oriented Computing, many enterprises attempt to utilize services as fundamental elements for developing applications/solutions as an additive layer on top of existing components. The Web Service Controller Architecture (WSCA) for service-based, enterprise-scaled business solutions provides exactly this flexibility. The design, exposure and management of services can be accomplished through a Service Oriented Architecture (SOA) that supports the usage, composition and coordination of services in a loosely coupled manner. Web services appear to be particularly suitable for addressing these aspects of a SOA. Furthermore, composition languages such as BPEL add value by composing Web services and facilitating the implementation of business processes. As the SOA paradigm brings this big behavior change relying on loose coupling of services it raises new questions in the area of change management. Change management is a central aspect in any software design, but its complexity for Web services is increased by both composition languages and loose coupling. The resulting advantages like composability, autonomy, message-based communication, and the avoidance of combined compilation and binding prove to be deficiencies in this context.

In this paper we discuss these elementary challenges of change management in the area of Web services (Web Service Change Management, WSCM). Currently there are no sound mechanisms and engineering principles for changing Web services and their related entities. Through analysis of a suitable scenario, specifically looking at the details of the Web service provider and consumer roles, one can identify the various problems that exist in this domain. Therefore we will start our approach with the consideration of an application scenario from the business domain of application and change management, the addition of Web services in private legal sector.

An Overview of a WSCA

A WSCA consists of several autonomous outsourced Web services, but acts as a virtually coherent entity. Business entities, in the form of Web services, are often geographically distributed and organizationally independent. While WSCA has a potential to introduce new business opportunities through dynamic alliances, the challenges of fully realizing a WSCA lie in managing changes during its lifecycle through Extreme X Machines (XXM).

XXM:

In this paper we explore the design changes as made to software projects by the use of a formal model known as Extreme X-Machines (XXM) [5,6], which are based on the work of Eilenberg and Holcombe [7,8]. An XXM model describes the functionality of the software without defining exactly how this functionality is achieved. This perspective allows an analysis of functional change whilst excluding specific implementation or requirements issues.

XXM are a state based model, they are intended to be used by developers as a method to design their systems from at the top level but here, XXM are used as effectively to analyze and incorporate changes in, even addition of new web services. Each model typically consists of a set of states which correspond to screens in the final system and functions which link the screens together. The functions are typically labeled with an enabling action such as “click_ok” which corresponds to a user clicking the OK button.

Figure depicts the architecture of a WSCA. There are two key components and two supporting components in this architecture. The key components include a WSCA schema and a WSCA instance. The two supporting components include ontology providers and Web service providers.

• WSCA schema: A WSCA schema consists of a set of abstract services and the relationships among these services. An abstract service specifies one type of functionality provided by the Web services. They are not bounded to any concrete services. They are defined in terms of service concepts in a Web service ontology.

•WSCA instance: A WSCA instance is a composition of a set of concrete services, which instantiates a WSCA schema. It actually delivers the functionality and performance of a WSCA.

• Ontology providers: The ontology provider manages and maintains a set of ontologies that describe the semantics of Web services. A WSCA outsources semantics from an ontology provider to build up its schema.

• Web service providers: The Web service providers offer a set of Web services, which can be outsourced to form WSCA instances.

The lifecycle of a WSCA is a series of stages through which it passes from its inception to its termination. There are four phases in a WSCA lifecycle: initiation, composition, service-orchestration and termination. The initiation phase is the first stage, where the WSCA is described at a high level. It is initiated when the owner of the WSCA establishes a need for a business objective [53].

The composition phase deals with integrating the selected Web services [42]. After this, the selected Web services are orchestrated to provide the value-added service. The termination phase occurs when the owner of the WSCA decides that the execution of the WSCA is no longer required.

To materialize the concept of WSCA, the WSCA must automatically adapt to its dynamic environment, i.e., to deal with changes during its lifetime. Because of the dynamic nature of Web service infrastructure, changes should be considered as the rule and managed in a structured and systematic way [52]. Changes may be introduced by the occurrence of new market interests, new business regulation, or underlying service availability. Such changes require a corresponding modification of the WSCA structure with respect to the functionality it provides and the performance it delivers.

Once a change occurs, a WSCA must react in a reasonable time and realign itself to deal with the change. This alignment must be performed in an automatic manner considering the frequent occurrence of the changes to a WSCA. By doing this, the WSCA can not only deal with unanticipated changes to the underlying services and infrastructure, but also maximize its market value, optimize functionality outsourcing, and maintain competitiveness.

Problem Formulation

The problem with the existing system of legal decision making process is that:

• There is no universal coalition body to unite the various modules of law in private sector like:
• A Public Interface to query for a case
• Online allotment of Advocates to users
• Judgments
• Union of India (to export Central Acts and Amendments)
• State Acts (to export State Acts and Amendments)
• The whole system of legal enactment starting from user query, allotment of Advocate, and referring judgments is not under a single roof.
• Due to inadequacy of getting the latest and updated Acts or Amendments, sometimes old acts are cited which later cause problems when the case is taken up in courts. This is a cause of embarrassment to the lawyer.
• In the existing System there is no spontaneous notification to the legal bodies regarding a change in the Acts. They themselves have to search for it on internet or find them in the latest issues. The problem is that they are not notified about the change in Acts automatically.

Proposed Solution

The need is to have an automated Legal System in India, at least at the private level. And this automation should be done with the most contemporary and best suited group of technologies. The problem uncovers the major issue of incapability of notification of changed Acts or Amendments to the related bodies.

The proposed WSCA model namely LegalCosmos functions to provide a comprehensive Legal Solution that outsources the functionality from various service providers, such as WS_IndianUnionAmmendments, WS_StateActAmmendments, WS_PublicInterface, WS_AdvocateAssociation, WS_Judgments (depicted in Figure 1.2).

The user in need of a legal solution makes use of the web service WS_PublicInterface and submits his, here accused, details and the details of the FIR filed by the complainant and forwards the FIR details like Case Crime No, Name, crime, date etc., to the WSCA which allots a Lawyer for the case with the help of WS_AdvocatesAssociation. An interested user (may be lawyer or a normal user) can find the details of the judgments through the WS_Judgments service. When a judgment is made the WS_Judgment web service provides the user with the copy of the order of the judgment.

When these services are combined together as a WSCA, the WSCA will invoke the services on behalf of the user. There may potentially be some dependency relationship between them. These dependencies determine the composition of the services. In the case of the LegalCosmos WSCA,

users do not necessarily need to provide the information for each service. The input of some services can be derived from the dependency relationship. Like in WS_AdvocateAssociation selected advocate details are directly passed to the WS-Judgments.

Fig. Change Reaction for adding two new web services WS_UnionOfIndia, WS_StateActs

WSCA Schema using Finite State Machine

Definition: FSMis a mathematical model of computation used to design both computer programs and sequential logic circuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called atransition. A particular FSM is defined by a list of its states, and the triggering condition for each transition.

Fig. WSCA Schema (A simple XXM)

Change Management in LegalCosmos

The change management in the proposed LegalCosmos WSCA primarily deals with the change in Acts in the form of Amendments. This change origins from the addition of two web services provided by the “Union of India” that produces amendments at the central level and the “State Acts” that produces amendments at the State level. Since these changes are initiated by the outsourced service providers and incorporate an alteration in web service. They form the part of bottom up changes.

The bottom-up approach for managing changes is highly dependent on the services that compose the WSCA. Therefore, it is necessary to first define the changes that occur to Web services, and then map them onto the business level. These changes include Activation changes that occur at the service level and WSCA changes that are executed at the business level. Finally, we provide rules for mapping triggering changes to their respective reactive changes.

In our work, we assume that activation changes occur asynchronously. For instance, the WS_PublicInterface service may not change its data types while the activation change of unavailability is being managed. Another assumption we make is that the service is associated with a set of states. We associate each change with a transition between two states: precondition and postcondition.

For example, a precondition for PI’s unavailability is that it was previously available and the postcondition is that it has become unavailable. Activation changes and their respective preconditions and postconditions will later be used to model changes using FSM and XXM.

Fig. Activation Changes

Non-Functional Changes

Non-functional changes represent the dependability, usability, and trust associated with a member service. This information may be stored by a third party, the WSCA, or member services. We assume the information is stored as attributes that are maintained by an independent third party service provider. Changes to the trustworthiness of a Web service relate to the security, reputation, and privacy of a Web service. Changes in usability are dependent on the responsiveness and service cost. Finally, changes to dependability are associated with the availability and reliability of the Web service. Changes to service dependability are binary, because they represent two distinct states. For example, a service may either be available or unavailable. Alternatively, changes to service trust and usability are non-binary. For

instance, service cost may assume more than two values during a member service’s lifetime. Therefore, we assume that a threshold is set and maintained by the WSCA. This threshold declares the minimum and maximum intervals of a value accepted by the WSCA. For example, the WSCA has the threshold of minimum $5 and maximum $10 for any judgment service cost. Every time a change occurs to the cost of a member judgment service, it is compared with the threshold. Only if the change exceeds the threshold, we consider that a triggering change has occurred. Note that the changes we have defined, such as changes to availability, are applicable to member services only. Once a member service is replaced, it is no longer part of the change management mechanism. For example, the e-Acts member service EA1 may become unavailable, and prompt the WSCA LegalCosmos to select an alternate e-Acts service EA2. After some time, EA1 may become available. However, since it is no longer a part of the LegalCosmos LCS, the LegalCosmos WSCA does not manage the change in EA1. Table 6.1.1.1 summarizes the non-functional changes in Web services.

Non-Functional Changes

Fig. Non-Functional Changes

Functional Changes

Unlike non-functional changes, which are based on attributes, functional changes deal with changes to a service’s WSDL description [22]. We represent functional changes as a combined execution of a remove followed by an add. We further classify functional changes into structural and behavioral changes (Figure 6.1). Structural changes refer to the operational aspects of a Web service. For example, a structural change in a PI service can be caused by changing the operations offered to a user. Changes to the behavior of a Web service are indicated by changing its interaction with external entities. Functional changes to a member Web service occur when its WSDL description is modified. We assume these changes are initiated by the service provider.

Fig. Functional Changes

XXM for Existing LegalCosmos WSCA, when Functional Changes are not introduced (before the removal of e-Acts web service)

The key functional changes involved here are:

• Removal of e-Acts web service (E-Copy of acts) shown in dashed rectangle. It has to be removed as it gives only immutable acts and does not involve latest amendments done by the Bare Acts. This causes problems to the WSCA in maintaining latest updates of the amendments and sometimes leads to false application of acts.
• A new web service called WS_UnionOfIndia is added to the WSCA which supplies the latest acts and amendments to WSCA. The Union of India is responsible for making and amending acts on the Central level.

• A new web service called WS_StateActs is added to the WSCA which supplies the latest acts and amendments to WSCA. The State Acts is responsible for making and amending acts on the State level.

XXM for WSCA when Functional Changes are introduced (after the removal of e-Acts web service and addition of two new web services, WS_UnionOfIndia and WS_StateActs)

Fig.

The above figure shows the two newly added web services namely WS_UnionOfIndia and WS_StateActs.

WSCA Changes

Each activation change will initiate a WSCA change at the business layer. WSCA changes may occur at the composition and service orchestration levels of a WSCA. For instance, a Dt change in the PI service may trigger inconsistencies in the WSCA composition, such as incorrect parameter data types. Alternatively, a Da change may disrupt WSCA service orchestration. We divide the WSCA changes into composition and service orchestration.

Fig. WSCA Changes at business level

Mapping of Changes

A Mapping specifies how changes in one layer correspond to changes in another layer [86]. These mappings must remain consistent in the presence of frequent changes. When a change occurs at the service level, the business layer must react to manage the changes. Triggering changes have a reactive

impact on the business layer of the WSCA.

Our approach of mapping changes is based on mapping rules. These rules are based on the activation changes and their corresponding business level changes of WSCA. Some changes may have more than one rule associated with them. The rules are depicted in the matrix shown below:

Non-Functional Changes Functional Changes

Activation Changes ïƒ

Dp

Dr

Ds

Dc

Drs

Da

Dl

Dn-

Dn+

Dt-

Dt+

Dm-

Dm+

Do-

Do+

Dp-

Dp+

Db-

Db+

Dl-

Dl+

Business level Changes

Dm-

Dm+

Dp-

Dp+

Di-

Di+

Ds

Dsi

Do

Detection of Activation Services Changes

Algorithm 1 Change Detection Algorithm

1: ChangeDetection (Input: oldDesc, newDesc)

2: while newDesc do

3: Compare (oldDesc[Functional], newDesc[Functional])

4: if oldDesc[Functional]!= newDesc[Functional] then

5: GenerateXXM (FunctionalXXM)

6: end if

7: Compare (oldDesc[NonFunctional], newDesc[NonFunctional])

8: if oldDesc[NonFunctional] != newDesc[NonFunctional] then

9: Threshold = CheckThreshold (oldDesc, newDesc)

10: if Threshold then

11: GenerateFSM(NonFunctionalFSM)

12: end if

13: end if

14: end while

15: ChangeReaction (FunctionalXXM, NonFunctionalFSM)

Algorithm 2 Change Reaction Algorithm

1: ChangeReaction (Input: FunctionalXXM, NonFunctionalFSM)

2: WSCAXXM = φ

3: while FunctionalXXM do

4: WSCAXXM = Map (FunctionalXXM, WSCAXXM)

5: end while

6: while (NonFunctionalFSM) do

7: WSCAXXM = Map (NonFunctionalFSM, WSCAXXM)

8: end while

9: while (NonFunctionalFSM) do

10: if (WSCAXXM) then

11: Execute (WSCAXXM)

12: end if

13: end while

Algorithm 13 Change Management Algorithm

1: ChangeManagement (Input: executionTime, WSCA concrete service list)

2: time = executionTime

3: while time != 0 do

4: for all each Web Service WSi in WSCA concrete service list do

5: send alive message to WSi

6: if not alive then

7: remove WSi from WSCA concrete service list

8: call (serviceSelection (abstractService (WSi)))

9: break;

10: end if

11: globalDescription = WSi servicedescription from Registry

12: if serviceDescription (WSi) not equals globalDescription then

13: remove WSi from WSCA concre