=Paper=
{{Paper
|id=None
|storemode=property
|title=AMSI: An Automatic Model-Driven Service Identification from Business
Process Models
|pdfUrl=https://ceur-ws.org/Vol-867/Paper29.pdf
|volume=Vol-867
|dblpUrl=https://dblp.org/rec/conf/icwit/SoltaniB12
}}
==AMSI: An Automatic Model-Driven Service Identification from Business
Process Models==
https://ceur-ws.org/Vol-867/Paper29.pdf
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