AMSI: An Automatic Model-Driven Service Identification from Business Process Models Mokhtar Soltani1, Sidi Mohammed Benslimane2 1 Sciences and Technology Department, Ibn Khaldoun University, Tiaret, Algeria 2 Computer Sciences Department, Djillali Liabes University, Sidi Bel Abbes, Algeria m_soltani@mail.univ-tiaret.dz benslimane@Univ-sba.dz Abstract. The evolution of software engineering has passed through various paradigms; including structured programming, object oriented programming, component-based approaches and in recent years service-oriented computing. One of the key activities needed to develop a quality service oriented solution is the specification of service model. The majority of existing methods for service model specification are developed manually because they are based on the competence of the developers. The integration of Business Process Modeling (BPM) and Model-Driven Development (MDD) allows the automation of the SOA (Service-Oriented Architecture) services development. Three steps are used for developing an SOA solution: service identification, service specification and finally service realization. In this paper we propose a method called AMSI (Automatic Model-Driven Service Identification) that automatically identifies the architecturally significant elements from a high level business process model to specifying service model artifacts. The main goal of this work is to support the automation of the development process of service-oriented enterprise information system. Keywords: Business Process Modeling, Model-Driven Development, Service- Oriented Architecture, Service Identification. 1 Introduction Bridging the gap between Enterprise Modeling methods and Semantic Web services is an important yet challenging task. For organizations with business goals, the automation of business processes as Web services is increasingly important, especially with many business transactions taking place within the Web today [7]. Nowadays, the enterprises are organized in networks, in which various actors can be interacting. The competitiveness of these companies is deeply related to the capacity to structure, share and exchange knowledge with the participants in the collaborative network. This need to exchange knowledge obliges the companies to evolve their information systems and their applications in order to return them interoperable. The interoperability of enterprise applications allows ensuring the exchange of the 276 functionalities and the services in a transparent way. Each functionality, service, or data have a specific model. Several transformations of these models are essential to ensure interoperability between the various heterogeneous entities of the enterprise. So that these model transformations become an effective solution for establishing interoperability in a purely heterogeneous environment; it is necessary that they must be guided by a standard modeling framework. The MDA approach (Model-Driven Architecture) provides the bases to support the model-driven interoperability. The development of an enterprise application to large scale always starts with the highest level abstraction where they are the specification and the representation of the business in the form of business process models. These models must be projected gradually on an adapted architecture to the need for interoperability. Currently, the more adapted paradigm to the realization of the interoperable applications is the service-oriented paradigm because it brings a certain simplification and facilitates the establishment of a reconfigurable collaboration through the dynamic construction of software services. We try, in this paper, to answer the following question: How to ensure a permanent and flexible evolution of enterprise information system when business requirements change? For answer to this question, we proposed a method for deriving automatically a Service Oriented Architecture starting from a high level collaborative business process. The remainder of this paper is organized as follows. In section 2 we presented a basic concepts needed to understand our approach including Business Process Modeling and Service-Oriented Architecture. In section 3 we presented our approach called AMSI (Automatic Model-driven Service Identification). Section 4 concludes this paper. 2 Business Process Modeling and Service-Oriented Architecture Handshake Service identification is one of the core elements of the BPM and SOA handshake that reinforces the current mantra that “BPM should be service oriented, SOA should be business process focused, and SOA takes over where BPM leaves the enterprise in a path towards agility” [3]. 2.1 Business Process Modeling The process vision plays a significant role in the theories of the organizations as in the information system field where the process modeling is regarded as a key element of the representation of dynamics. The business process modeling is a prerequisite necessary to design an organizational information system. The business process definition reflects the functional needs implicitly. However, it is not sufficient to just conceive the business activities connected by control flows of the process. To represent the complete whole of the requirements, a process definition must explicitly indicate all the entities which take part in the process. These requirements should be 277 transformed, without loss of information, in semantic specifications of which different software components can be derived. 2.2 Service-Oriented Architecture (SOA) Service-Oriented Computing (SOC) is a new paradigm for distributed computing that uses services to support the development of interoperable, evolvable, and distributed applications. Services are autonomous, platform-independent entities that can be described, published, discovered, and loosely coupled by using standard protocols. Service-Oriented Architecture is the main architectural style for SOC. The main idea of Service-Oriented Architecture is the restructuring of enterprise information systems into loosely coupled, independent services. These services should allow the reuse of existing implemented functionality in order to minimize the time between design and implementation when business requirements change. The key challenges in developing the service oriented systems are the mapping of business processes models into service models. Service models play an important role during service-oriented analysis and design phases. According to the IBM SOMA [1], service-oriented modeling lifecycle has three main phases: Service identification. This phase is about identifying the architecturally significant elements of the target solution. The output artifact of this phase is analysis-level service model. Service specification. This phase is about describing a service: what it offers, what it requests and how it is exposed. It also describes dependencies with other services, service composition, and service messages. The main model related to this phase is the design-level service model. Service realization. This phase is about providing a solution for a particular service. We represent here, how a service is realized. The model related with this phase is the design model. This model has to be traced back to the service model, because it represents its realization. 3 Automatic model-driven service identification Service identification is one of the main activities in the modeling of a service- oriented solution, and therefore errors made during identification can flow down through detailed design and implementation activities that may necessitate multiple iterations, especially in building composite applications. According to [1], the initial activity in the development of a new SOA solution is the service identification. The result of the service identification is a set of candidate services. The first stage in the service identification process is the modeling of a high level business process that is represented as a CIM model. Metadata are added to the CIM model in the second stage. This operation is based on a whole of generic concepts stored in the process model ontology. The third stage allows the transformation, after the interrogation of the process model ontology, of the input business process model into an executable process model expressed as a PIM model. In the fourth stage, the service identification engine generates a whole of candidate’s services for 278 implementing the input process. These services are grouped in a set of clusters (composed services) by a multi-objective clustering algorithm (cf. Fig. 1.) Fig. 1. Automatic Model-Driven Service Identifier 3.1 Business Process annotation In this stage, complementary information is added to the business model elements such as the nature of the activities (manual, semi-automatic, automatic), the composition of the activities (decomposable, atomic activity), the goal of each activity etc. All knowledge’s about the initial business process are extracted and stored in the Process Model Ontology by business analyst and knowledge engineer. The PMO is based on two principles: to unify the different existing Business Process Metamodels, and to provide the necessary properties for deriving software services from a height level business processes. The PMO captures generic concepts associated with business processes and the relationships among them. To facilitate the extraction of the multiple views on a process model the PMO allows a business analyst and a knowledge engineer to mark the visibility of activities to different collaboration roles. Thus various views on the business process model can be extracted. The PMO will capture the notions of process models at the business level. This ontology defines concepts like Process, Activity, Event, Control Node, Message Flow, Sequence Flow, etc. and the relationships between them. It is regarded as a generic metamodel of business process that is used as a knowledge base for deriving software services from a height level business process model. Our proposition is that constructing the PMO through a careful analysis of existing reference metamodels, guarantees the representational width of the ontology, i.e. that 279 all existing business process models can be represented and all software services can be extracted from it. 3.2 Business Process transformation The first step for identifying SOA services is the business process modeling, and the business functionalities are understood, then the service identification step starts. We cannot directly transform a high level business model into SOA solution because it is independent of any computation specification and it comprises manual, semi- automatic and automatic activities. As well as the high level activities have a great granularity. The same business activity can be transformed into several SOA services. Thus it is necessary firstly to transform the high level business process into an intermediate process called executable process in order to identify the candidate services. The PMO is queried for transform the annotated business process model into an executable process. During this stage, the transformation engine executes the following operations: • Rename a business activity: In the simplest case, a small business process activity is mapped to exactly one SOA service • Split a business activity into several: Service-oriented system requires a strict distinction between activities with user interface (Human Activities) and Service Calls. One business activity can mapped into several activities in the executable process (Human Activities that need a user interface and automatic services) • Merge two business activities in only one: If small activities of a continuous sequence are always realized by the same person, it makes sense to merge them into one SOA service • Insert a new activity in the executable process: Additional activities, such as authentification service, are necessary for the normal execution of executable process • Remove an activity from the business process: A business process model often contains activities whose execution should not be controlled and monitored by a business process management system. Consequently these activities shall not be to be implemented as SOA services, but are important at business model level for calculating processing times and simulating process costs. 3.3 Service identification The identification engine queries the ontology and takes the executable process as input in order to generate automatically the candidate services. In this phase, a set of design metrics which satisfy business goals should be calculated from the PMO such as cohesion, coupling, granularity, maintainability, and reusability of activities, etc. that are considered as input parameters for classifying the candidate services in a groups (composite services). The identification of the services corresponding to the executables activities is possible via their names. The identification engine searches the name of the activity in the concepts taxonomy of the ontology and extracts the properties of the activity and its relations with the other concepts of ontology for 280 calculate design metrics. After this research phase, the identification engine generates a set of candidate services equivalents (implementing) to the activity in question. Thus their initial descriptions (name of the service, names of the interfaces, etc.). The service identification engine use relationships between individuals of the concepts Activity, Resource, and Participant for calculate different design metrics such as Service Cohesion, Service Coupling, Service Granularity, Service Maintainability, and Service Reusability. These design metrics are used as input parameters in the clustering algorithm that generates as output a set of optimal service clusters. We can formulate our identification algorithm as a multi-objective optimization problem that classifies candidate’s services according to optimal values of design metrics. 4 Conclusion and outlook In this paper we outlined some of our initial work in the development of AMSI, a method for identifying automatically candidate SOA services from a high level business process. The method defines how a high level business process should be transformed into an executable process in order to identifying SOA services. Our automatic service identifier uses a Process Model Ontology (PMO) to annotate the business process model. The annotated business process model is used as input of a transformation engine which transforms it, after the interrogation of ontology, into an executable process. Finally an identification engine querying the ontology and take the executable process as input in order to generate the candidates services automatically. Currently, our work is at formalization stage. Future work is mainly related to the implementation and evaluation of our approach. 5 References 1. Arsanjani: (SOMA) Service-Oriented Modeling and Architecture: How to identify, Specify, and Realize services for your SOA. IBM developer Works (2004) 2. Fareghzadeh N.: Service Identification Approach to SOA Development. In: Proceedings of World Academy of Science, Engineering and Technology, vol. 35, pp. 258–266 (2008) 3. Inaganti S. and Behara G. K.: Service Identification: BPM and SOA Handshake. BPTrends, March (2007) 4. Jamshidi P, Mansour S, Sedighiani K, Jamshidi S, Shams F.: An Automated Service Identification Method. Technical Report, Department of Electrical and Computer Engineering, Shahid Beheshti University, (2012) 5. Jamshidi P., Sharifi M., and Mansour S.: To Establish Enterprise Service Model from Enterprise Business Model. IEEE International Conference on Services Computing (2008) 6. Klose K., Knackstedt R., Beverungen D.: Identification of Services - A Stakeholder based Approach to SOA Development and its Application in the Area of Production Planning. In: ECIS 2007, pp. 1802–1814 (2007) 7. Nadarajan, G., and Chen-Burger, Y.-H.: Translating a Typical Business Process Modeling Language to Web Services Ontology through Lightweight Mapping. IET Software In: Formerly IEE Proceedings Software, Vol. 1, Issue 1, p.1-17, Feb (2007) 281