MISS: A Metamodel of Information System Service

Nicolas Arni-Bloch and Jolita Ralyté

University of Geneva, CUI, 24 rue General Dufour, CH-1204 Geneva, Switzerland1

{Nicolas.Arni-Bloch, Jolita.Ralyte}@cui.unige.ch

Abstract. Integration of different components that compose enterprise information systems (IS) represents a big challenge in the IS development. However, this integration is indispensable in order to avoid IS fragmentation and redundancy between different IS applications. In this work we apply service-oriented development principles to information systems. We define the concept of Information System Service (ISS) and propose a Metamodel of ISS (MISS). We claim that it is not sufficient to consider an ISS as a black box and it is essential to include in the ISS specification the information about service structure, processes and rules shared with other services and thus to make the service transparent. Therefore we define the MISS using three informational spaces (static, dynamic and rule).

1 Introduction

Enterprise Information Systems (IS) are generally composed of applications and data that represent enterprise legacy. Due to constant changes and evolution that an enterprise undergoes, like organisation restructuring or merging with a group of partners, business process reengineering and innovation, as well as evolution of information technologies, the enterprise legacy became heterogeneous and specialised by trade, department, service etc. Besides, new applications are constantly added to the legacy ones. This situation leads to fragmented IS and therefore to the redundancy between different IS parts which introduces the need for a permanent validation of data, process and rules consistency. The common part of different IS components represents the interoperability area of the enterprise IS. If no integration is done between these IS components, the interoperability challenge is left to the human using this IS, i.e. the human have to validate “by hand” the consistency between different IS components. Such a human intervention generates extra cost and leads to a poor data

1 This work was partially supported by the Swiss National Science Foundation. N°

200021-103826

2

quality. In this work we confront the problems of IS fragmentation and interoperability of different IS components and, in general, the challenge of sustainable IS development from the method engineering perspective. We aim to define a method supporting IS components construction and integration. For this purpose, we consider the main principles of the SOA (Service Oriented Architecture) [6, 8] approach that are the modularity and autonomy, reusability and evolution [4, 5]:

• Modularity and autonomy: SOA is based on the notion of service that represents a system functionality encapsulated into a more or less autonomous system component. In this work we consider that an IS is composed of a collection of interrelated and autonomous components – services – that allow to avoid chaotic IS fragmentation. Therefore, we define the notion of a specific service that we call Information System Service (ISS).

• Reusability: The reuse of a service can be considered from two perspectives: composition and integration. The SOA approach is based on service composition – the capabilities of a service are reused by other services. The interaction between the consumer of a capability and the provider of a service is governed by the notion of contract [7] which defines, among other things, the information to be provided as input and the information to be obtained as output. To be composed, a service has to be published in the registry of services. In case of IS development, an ISS has to be deployed in the IS. We name the process of ISS publication – the integration of ISS into the IS. Indeed, by integrating a new ISS into an IS we extend the IS with new capabilities, i.e. the domain of the IS is extended. When an ISS is developed from scratch, the integration process is relatively simple because the new service is designed by considering the existing services. In the contrary, when an ISS is developed independently, the integration process demands to take into account the overlap that this service could have with other services of the IS. Handling this overlap is not a simple task and can lead to several situations. In [2] we propose a situation-driven process model supporting new ISS integration into a legacy IS.

• Evolution: In SOA a service can be easily replaced by a new one. In the IS development this principle allows to extend legacy IS with new services. Integration of a new ISS implies evolution of the ISS itself as well as evolution of the existing IS. This evolution has to be mastered and the integration process has to guarantee the autonomy of services and to limit the coupling between services.

In this work we define the concept of Information System Service (ISS) that adapts traditional service definition to the service-oriented IS engineering and we propose a Metamodel of ISS (MISS) which aims to support ISS engineering and integration. From the integration perspective, we claim that it is not sufficient to consider an ISS as a black box with only interface part available for its integration and we argue that it is essential to include in the ISS specification the information about service structure, processes and rules shared with other services and thus to make the service transparent. Therefore, the MISS extends service description with its informational knowledge:

1. service data structure and semantics,

3

2. service behaviour in terms of actions that can be executed by the service, and 3. rules (data integrity and process rules) to be respected when realising the service.

The paper is organised as follows: in section 2 we defines the notion of ISS and present the MISS. Section 3 illustrates MISS with two services while section 4 discusses the modularity and autonomy of ISS and proposes rules validating ISS completeness. Finally, section 5 concludes the paper.

2 Information System Service

Traditional object-oriented methods propose two categories of models, static and dynamic, to specify software and information systems. Static models deal with data structure and system architecture definition while dynamic models define system functionalities, activities, states and behaviour. In our opinion, these two modelling perspectives are not sufficient to completely specify an IS. We agree with Turki and Leonard [9] that there is a need for a third perspective, specific to the IS engineering, allowing to specify the rules governing the IS and ensuring the integrity of its data. Therefore, from the conceptual point of view the specification of an IS is a triplet <static space, dynamic space, rules space> [10]. The static space represents the structure of the information, the dynamic space captures the manipulations that the information can undergo and finally the rules space represents the constraints that the static space must satisfy.

Following the same reasoning, we define an Information System Service (ISS) as an autonomous coherent and interoperable component of an information system. Therefore, an ISS is also considered through the same three spaces: static, dynamic and rules. Fig. 1 represents the Metamodel of Information System Service (MISS), more exactly the informational part of a service.

Similarly, Andrikopoulos et al. [1] propose an Abstract Service Definition Model based on three layers – structural, behavioural and regulatory – to deal with web service evolution. In our work, MISS is mainly dedicated to the ISS integration. In the following we use the word “service” as a synonym to “ISS”.

An ISS is a component of an information system that offers capabilities and owns resources to realize these capabilities. These resources can be technical (hardware or software), informational (classes, actions and rules as defined in the metamodel Fig. 1) and organizational (actors). Formally, at the informational level an ISS ς is a set of objects: ς** = {o1,…,on} because in the MISS model everything is an object. In fact, in MISS a class is a clabject [3], i.e. a class and object. An ISS is express by a triplet <sSs, sDs, sRs> where:

• sSs is the static space of the ISS, i.e. the set of classes of the ISS; • sDs is the dynamic space of the ISS; it is composed of a set of actions (sDsaction)

and a set of effects (sDseffect) that the ISS actions are allowed to produce; • sRs is the rule space of the ISS, i.e. the set of rules of the ISS.

4

Fig. 1. Metamodel of the informational part of an ISS

An information system if build of a collection of services: ξ represents the set of all services of the IS: ξ = {ς1,…, ςn}. ξ** represents the objects of the IS: the union of the objects of all services. ξ** = ς**1∪…∪ς**n.

2.1 Static Space

The static space of the MISS represents the data structure of an ISS. This structure is expressed with an object oriented model called Binex [10]. The particularity of the Binex model is that classes are linked only via existential dependencies. An existential dependency is materialized via an attribute with mandatory and permanent constraints. The use of only existential dependencies simplifies the ISS static model and therefore the integration process. To better represent the domain of a service, we use the notion of hyperclass [9] that allows to put together a set of classes and in this way to represent more complex concepts.

An object is a concretisation of a concept in a service. It belongs to a context - the service defining the conditions of its execution and its persistence. An object is defined by a tuple o = <oid, cxt> where cxt is the context of the object, i.e. the service which owns the object, and oid is the object identifier, witch is unique within the IS. An object belongs to one or several classes and represents an instance of these classes; it takes values for its attributes defined in these classes.

The context allows to define the notion of redundancy. An object (or class) is redundant if there are two objects with the same oid in the ISS. An object o is redundant if ∃ o', oid(o)=oid(o') and cxt(o)≠cxt(o') with o, o' ∈ ξ**.

5

A class is an object that defines the common informational structure of a set of other objects. This informational structure is based on the static part (attributes and their types), behaviour part (methods) and rules part (invariants). Dependencies between classes are specified through their attributes.

As a class is also an object it belongs to a context. The notion of hyperclass was first introduced by Turki et al. in [9] to better

represent the domain of information systems and to support their evolution and integration. “A Hyperclass is a large class, composed of a subset of conceptual classes of the IS schema, forming a unit with a precise semantic” [9]. It represents the structure of complex objects composed of several classes. These complex objects, called hyperobjects, are particularly adapted to represent responsibility area and parameters of complex actions. The notion of hyperclass allows to represent the semantic area of a class. This area is represented as a set of classes (sCl) needed for the structural representation (attributes), behaviour definition (method) and rules validation (invariant).

An attribute is a property that defines static structure of a class. It has origin, i.e. the hyperclass to witch it belongs, and defines the type of its value. We distinguish two kinds of attributes: Hyperattribute and RefAttribute. A RefAttribute is a class attribute that offers a storage or memory space for a value and defines reference between objects. A Hyperattribute is a calculated property of a hyperclass.

2.2 Dynamic Space

There are several ways to express the dynamic specifications of an ISS. For example, it can be done with state-diagrams, object life-cycles described with state-charts (UML), Petri nets or bipartite nets. We use a bipartite net where one type of nodes represents classes and the other type represents actions [10]. We adapt it for representing the context of a service and we extend it with the notion of effect. The main concepts of the dynamic space are: action and effect.

An action is an object that defines a behaviour having an effect on other objects. An action is defined by the following set <name, {parameter}, {precondition}, {action}, {effect}, process, {postcondition} >. Parameters denote objects to be given to the action for its execution. An action can use other actions during its execution. These actions can be either method calls on objects passed through parameters, or action instantiations during the process. An action is described by a process to be executed and produces one or more effects that specify the type of its result. The process can be executable (Function), i.e. expressed as an algorithm, or enactable, i.e. realized trough interactions with IS actors. An action with an executable process can be atomic, also called a primitive action, or composed. A transaction is an action with transactional properties. A method is an action that is linked to a class. Finally, the execution/enactment of an action is constrained by a set of preconditions and a set of postconditions.

6

An effect is a tuple <nameEffect, primitive, target, visibility> where primitive defines the kind of effect (Table 1) and target is a class, a class and a set of attributes or a action in the case of the call primitive. The set of attributes is used with the update and read primitive to refine the attributes that are updated or read. If no attribute are defined, it is assumed that all attributes of the class are concerned with the effect. The visibility (public or private) of the effect defines if it is visible outside the service or not. It is used in a composition perspective to define the effects that are part of the action interface.

Table. The six types of primitives that describe effects of an action

Primitive Description create The create primitive characterizes creation of a new object in a class. ⏐cl**

before⏐ = ⏐cl** after⏐-1 and ⏐ς** before⏐ = ⏐ς**after⏐-1 where cl** represents the set of objects of cl.

enter The enter primitive characterizes the addition of existing object to a class. ⏐cl**

before⏐ = ⏐cl** after⏐-1 and ⏐ς** before⏐ = ⏐ς**after⏐ exit The exit primitive characterizes the deletion of an object from a class. ⏐cl**

before⏐ = ⏐cl** after⏐+1 and ⏐ς** before⏐ = ⏐ς**after⏐. Note that if cl = Object then the object will exit the root class; it is equivalent to the delete effect. In this case ⏐ς** before⏐ = ⏐ς**after⏐+1

list The list primitive characterizes the access to the set or subset of objects of a class.

return The return primitive characterizes an action that sends back a result. The return primitive is always a public effect.

update The update primitive characterizes the change of the values of class attributes. read The read primitive characterizes the access to the attributes of an object. call The call primitive characterizes the sending of a message to an action.

Therefore the use of a capability, i.e. the public effects of the called action.

2.3 Rule Space

The objective of this space is to preserve the coherence, correctness and consistency of an ISS during its exploitation. The main type of rules to be considered here is the integrity rules [7], the role of which is to ensure the integrity of the ISS data.

A rule is an expression/algorithm that returns a Boolean value when evaluated. The rule is valid if the evaluation result is true and it is invalid if the result is false. The classes and attributes that participate in the validation of the rule define its validation context. Rules are used as a basis for the specification of integrity constraints and conditions. An integrity constraint (IC) is a rule that has to be verified in each state of the services or at each modification of it. An IC has a scope witch represents the effects that could transgress the rule. This effect is called a risk of the IC. Thanks to the context of IC, we can identify invariants of a class as integrity

7

constraints that have to be validated. The matching between action effects and IC risk identifies the actions that can transgress the IC.

A condition is a rule that has to be valid at some point of process execution. In particular, it can be a precondition to be validated before the execution of a process or a postcondition to be validated at the end of the process.

The last type of rule is the authorization. An authorization links an organizational role to an effect and defines the information that can be accessed, modified or deleted and the action that can be called by this role. An organizational role is an element of an organization to which management level are associate, and that has responsibilities in achieving activities to reach a common objective of the organization.

3 Examples of ISS

In order to illustrate the MISS we propose the following example: the IS of a University (simplified version) providing a service for diploma management DiplomaManagementService (DMS) has to be extended with a new service supporting on-line registration of students to the university URegistrationService (URS).

The DMS is a legacy service (Fig. 2) that offers capabilities to manage several diplomas of the University. It allows to create the curriculum of each diploma by defining courses and linking them to their teachers. It also supports the management of students that follow different diplomas, by providing actions for their inscription to the courses as well as their examination.

Fig. 2. Partial specification of the DiplomaManagementService (DMS)

8

The new service URS offers capabilities for students’ on-line registration to the University. It is composed of a set of classes and actions defined in Fig. 3. This service publishes two actions as public methods: OnlineRegistration and RegisterToUniversity. The first action allows to create a UniversityRegistration-Request on the web. It is a complex process (not detailed here) that builds the registration including different required documents, according to the integrity constraints defined on the UniversityRegistrationRequest.

Fig. 3. Partial specification of the URegistrationService (URS)

This example illustrates several overlap situations between the two services, the legacy one and the new one. In fact, we can see that there is a static overlap between classes Person, Student, Diploma and FollowedDiploma as well as a dynamic overlap between actions registerStudentToDiploma. As mentioned before, if an object, class or action belongs to several services that has to be integrated in the same IS, this introduces information redundancy that has to be managed. Moreover, it is not only a question of redundancy; it is also a question of responsibility: “Which service is responsible for the common objects, classes and actions?” The integration of services consists in defining if the responsibility is shared or delegate to one of the services. In the case where a new service is integrated into a legacy IS, all responsibilities have to be delegated to the legacy ISS in order to preserve the integrity of existing data and processes.

For example, as the class Student already exists in the IS the creation of a new student must be the responsibility of the DMS. Therefore, the URS delegates the management of the student information and its persistence to the DMS. The same

9

reasoning can be applied for the delegation of the registerStudentToDiploma action by the URS. Other integration strategies can be defined but will require the evolution of the IS witch is a costly process. To help the engineer in identifying overlap situations, analysing integration choices and integrating services, a specific methodological support is necessary. The process model for ISS integration is introduced in [2].

4 Modularity and Autonomy of ISS

The definition of an ISS is based on the principal of modularity which offers a way to group a set of elements together in order to crate a semantic unit. In this way capabilities are grouped to form a service. This grouping can be defined explicitly or constrained by the coherence rules. The explicit definition of service boundaries can be reached by analysing the application domain in which this service is relevant. However, some rules have to be validated to guarantee the autonomy of the service. This autonomy aims to guarantee that the service owns the required resources to support its capabilities. In this work we focus our attention on the informational resources (required data, processes and rules), and we define the following completeness rules in order to reach the autonomy of a service:

Class completeness:∀cl ∈ sSs(ς ),sCl(cl) ⊂ sSs(ς ) where sCl(cl) is a set of classes necessary for the structural representation (attributes), behaviour definition (method) and rules validation (invariant) of the class cl. The class completeness ensures that an ISS is defined on the static space (sSs) that offers all the information needed by its classes. For example, the class UniversityRegistrationRequest (Fig. 3) is existentially dependant on the classes Diploma and Applicant. In addition, it is associated to the class Document that represents the exam reports and others files needed during the registration process. Therefore, sCl(UniversityRegistrationRequest) is equal to {Diploma, Applicant, Document, RegistrationRequestDiploma} and the service that includes this class has to be build on the static space that also includes sCl(UniversityRegistrationRequest).

Action completeness: ∀act ∈ sDs(ς),sCl(act) ⊂ sSs(ς) where sCl(act) is a set of classes needed for the realization of the process of the action act and for the validation of its condition. It includes the type of action parameters, the classes concerned by its effect and the context of its conditions. The action completeness ensures that an ISS is defined on the static space (sSs) that offers all the information required by its actions. For example, the action RegisterStudentToDiploma (Fig. 2) requires as parameters the classes Student and Diploma and has an effect to create a FollowedDiploma. Therefore, sCl(RegisterStudentToDiploma) includes these three classes. The action completeness rule requires that the static space of the service includes also these classes.

10

Rule completeness: ∀rule ∈ sRs(ς ),sCl(rule) ⊂ sSs(ς ) where sCl(rule) is a set of classes needed for the evaluation of the rule, i.e. the context of the rule (sCl(rule)=context(rule)). The rule completeness ensures that the ISS is defined on the static space (sSs) that offers all the information needed by its rules. For example, the IC02 constraint (Fig. 3) needs the Diploma and UniversityRegistrationRequest classes for its validation. As a consequence, these classes are in the context of the rule and in sCl(IC02). Therefore, a service that includes this integrity constraint will have to include these two classes, in order to be able to validate the rule.

Process completeness: ∀act ∈ sDs(ς),sCl+(actions(act)) ⊂ sSs(ς) where sCl+ represents a set of classes needed for the realization of the public part of the ISS process. It includes the type of the action parameter, the classes concerned by its public effect and the context of its conditions. The process completeness ensures that the service includes at least the classes needed for the interaction with the subactions.2 This rule is used in a composition perspective. If a service uses an action from other services in one of its processes, only classes from the public effects of this action have to be included in the static space of the service. In the case of the action RegisterToUniversity, only the classes UniversityRegistrationRequest, Student and Applicant are part of sCl+. If other services reuse this action, they have to include only these three classes and not all the other classes (i.e. classes needed for the Dossier lifecycle).

Responsibility coherence: ∀act ∈ sDsaction (ς ),effects (act ) ⊂ sDseffect (ς ) The responsibility coherence ensures that the actions of a service produce effect included in the service responsibility space, i.e. the service has the right to produce this effect.

5 Positioning and Future Work

According to several reference models for SOA [8, 4, 5], SOA aims to provide support for the reuse of system engineering principles with the help of the service description concept. Indeed, the concept of service description is used to define the reuse context of a service as well as the contracts between services. A service description includes two models: the information model representing its structure and semantics and the behaviour model describing its actions and processes. These two models constitute service interface which defines the possible ways to interact with services and to compose them. This interaction is generally realized using the concept of message that plays a key role in allowing communication between services. However, the specification of service interface only provides required and returned

2 In fact, from the composition point of view, sCl+ represents the static part of the

contract.

11

information and does not include information on the effect that the service will produce, and on the data manipulated during the realization of service capabilities (its actions). Viewing services as black boxes is key from the composition point of view, but it is problematic from the integration point of view. In this second perspective, it is crucial to have the opportunity to identify common data and process between different services. Without this knowledge, it is difficult to guarantee the coherence and consistency of the IS.

MISS offers a way to express the knowledge necessary for service composition but also for service integration. This integration is fundamental if we do not want to leave the validation of the data and process to the actors of the IS. However, this is a complex task that can lead to several situations and requires methods and tools to help in the integration process. Due to the diversity of integration situations, the corresponding method should be flexible and modular. In [2] we have presented the process model for integrating a new ISS into an existing IS following chunk-driven situational method engineering approach [6] and based on MISS. This process mainly consists in resolving the information overlap situations between the ISS and the legacy IS. To make our method operational we need to define various method chunks supporting different process activities. First, we need to define a set of service evolution and integration operations. Second, we have to specify the rules to be satisfied during the integration process; we already defined some of them, e.g. the completeness rules. Finally, we have to elaborate metrics allowing to evaluate the impact of the integration on the informational coupling, the level of complexity and the involved service capabilities.

6 Conclusion

In this paper we look at IS development from the perspective of sustainability and evolution and we propose to consider principles of the SOA approach in order to develop service-oriented IS and to avoid chaotic IS fragmentation and problems of IS interoperability.

Before publishing an information system service to be reused in some composition, the validation of the data consistency, rule soundness and process compatibility has to be guaranteed. This is a complex task that needs models representing different information spaces of service definition and methods to help engineers for taking the right choices during the integration process. In this perspective we see the following contributions of this paper:

• We define the notion of information system service (ISS) and propose a metamodel of ISS (MISS) representing the static, dynamic and rule space of a service. The notions action effect, rule context and risk provide a ground for identifying the overlap between different ISS during their integration process.

• Thanks to the notion of effect visibility, the overlap between services can be analysed in the public part but also in the private part of the service. This allows to

12

consider services as white boxes and offers a way to improve the coherence and consistency of an IS made of services.

• Finally, we specify a ser of completeness rules to ensure the autonomy of ISS at the end of their integration process. These rules allows us to ensure the quality of the integration.

Currently, we focus our effort on identifying and evaluating other situations that can occur in the ISS integration process, defining method chunks satisfying these situations and evaluating them with a set of metrics. A tool support is also under development to help in the integration process.

References

1. Andrikopoulos, V., Benbernou, S. and Papazoglou, M.P. (2008) managing the evolution of Service Specifications. In the proceedings of the 20th International Conference on Advanced Information Systems Engineering (CAiSE’08), LNCS, Springer.

2. Arni-Bloch, N. and Ralyté, J. (2008) Service-oriented information systems engineering: A situation-driven approach for service integration. In the proceedings of the 20th International Conference on Advanced Information Systems Engineering (CAiSE’08), LNCS, Springer.

3. Atkinson, C. and Kühne, T. (2000) Meta-level independent modeling. In Int. Workshop on Model Engineering (in conjunction with ECOOP’2000). Cannes, France, June 2000.

4. Erl, T. Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Prentice Hall PTR, 2005.

5. Krafzig, D., Banke, K. and Slama, D. (2004) Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall PTR.

6. Mirbel, I. and Ralyté, J. (2006) Situational Method Engineering: Combining Assembly-Based and Roadmap-Driven Approaches. Requirements Engineering, 11(1), pp. 58–78.

7. OASIS (2006) Reference model for service oriented architecture 1.0. Technical report. 8. Papazoglou, M.P., et al. (2006) Service-Oriented Computing Research Roadmap.

ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/st-ds/services-research-roadmap_en.pdf 9. Turki, S. Léonard, M. (2002) Hyperclasses: towards a new kind of independence of the methods

from the schema. Proc. of ICEIS'2002, Vol.2, pp. 788-794, ISBN: 972-98050-6-7. 10. Turki, S., Léonard, M. and Arni-Bloch, N. (2003) From Hyperclasses to IS Components. Proc. of

the 10th Int. Conference on Concurrent Engineering (CE'2003), Madeira, Portugal. R. Jardim-Goncalves, H. Cha, A. Steiger-Garcao (eds.), Balkema Publishers. pp. 235-242.