- Since some years ago, an increased competition forces organizations to concentrate on core competencies and to collaborate closely with other organizations. The paper proposes a model-driven approach to design collaborative systems. This approach focuses on the collaborative business process modelling and the generation of the partner's private process models. To do so, we propose a framework with three layers: an organizational layer, that focuses on collaborative business, a conceptual layer, to define the business process, and a technology layer, aimed at process execution. To this aim, inter-organizational interactions (information exchanges) are modelled based on business processes and Web services. Finally, we validate our proposition with implementation of an e-ordering system.
Modern business process management
expands to cover the partner organizations’
business processes across organizational
boundaries [
Business-to-Business (B2B) interactions
are declined under different ways and using
different technologies, listed from old to recent
as follows: (1) exchanging data via traditional
means such as fax, phone, and mail; (2) using
Electronic Data Interchange or email for data
interchange; (3) utilizing private or public
exchanges to share business process
information; and (4) deploying Web services
and business process management (BPM)
tools to coordinate loosely coupled services
into integrated cross-organizational processes
with real-time data sharing [
In this work, we mainly focus on the use of business process modelling and Web services standards in support of B2B collaborations. So, we propose a design framework in a top-down manner, beginning with the collaborative (inter-enterprise) level as main business process template and after the private (intra-enterprise) level as their subprocesses.
The structure of this document is as follows. In section 2, we discuss the basic concepts of collaborative business process. Section 3 analyses the current literature on B2B collaboration design frameworks. Subsequently, section 4 is the main contribution of this paper, as it presents the details of our framework. Next, section 5 assesses the capabilities of proposed solution. Finally, section 6 draws some conclusions and outlines some further research activities. Seller ‘s Private Process Seller ‘s Public Process 2. COLLABORATIVE BUSINESS PROCESS Recently, CBP are turning to be an important issue of contemporary BPM. To explain specifics of CBP modelling, we will discuss their requirements. 2.1. Characteristics of Collaborative
Business Process
CBP comprise activities executed by different
organizations that are working together to
reach a common business objective. So, CBP
usually do not have a centralized control
instance or process owner [
In addition, the privacy and autonomy requirements are at the top priority of participant’s organizations. Having this concern in mind, each involved organization has to implement not only its private processes but also its external behavior, allowing better separation of the information density of different areas of concern. So, three different concepts are defined: Private (internal), Public (abstract or view) and Collaborative (cross- or inter-organizational) processes. In order to illustrate these different process categories, Figure 1 presents Business Process Modeling Notation (BPMN) activities of an ordering process where buyer and seller businesses collaborating together. 2.2. Collaborative Business Process
Modelling Languages
Although modeling CBP is a complex task,
many research efforts have been based on
approaches for distributed Workflow
management, e.g. [
Having these considerations in mind,
our approach provides an UML profile [
The recent years brought a vast number of
publications around the collaborative systems
topic. We will briefly refer to some of them
which are achieved in the field of
interorganizational Workflows or B2B
collaborations [
Legner et al. [
Another relevant contribution in this
area is the proposal made by Huemer et al.
[
The work of Touzi et al. [
The framework proposed by Ziemann et al.
[
Greiner et al.’s work [
Though significant research efforts, collaborative systems design is neither taken up broadly nor can it be considered a solved problem. Yet, while the proposed solutions strive to enable the operation of a CBP, no explicit consideration of generic business process requirements, as viewed by the different involved stakeholders (business analysts, process designers and IT specialists), is made to relate to generic collaborative scenarios by combining business process and Web services. To the best of our knowledge, generic business process modeling and execution as Web services in the realm of collaborative systems design as given in this paper have not been published before. 4. THE PROPOSED MDA-BASED
FRAMEWORK In order to establish B2B collaborations one may start “bottom-up” from the private processes or “top-down” from the CBP. In topdown design approach, we note that the business requirements drive the technology. It starts with a global view on the collaboration efforts. This requires that the agreed CBP was defined jointly, before, by the partners.
In this work, we follow the top-down
approach because it is more appropriate for
an e-Ordering system. Hence, our approach
helps to develop partner’s public processes
that are compliant to each other. This is
guaranteed by the fact that each partner
derives its public process consistently to a
commonly agreed CBP. It enables a
processbased collaborative systems development at
both business and technological levels, based
on a MDA (Model-Driven Architecture)
approach [
In addition, MDA approach is characterized
by a set of vertical transformations across
different phases (PIM to PSM and PSM to
Code) using model transformation languages
like ATL - Atlas Transformations Language [
Therefore, in Figure 2 we depict the
proposed framework which supports: the
design of CBP independent of particular
process model standard; and the automatic
generation of each partner’s side
specifications based on a process model
standard (in our case the generation of BPMN
and BPEL) from CBP models (using UML AD
profile). It is mainly based on the technique of
meta-model transformations [
The main benefits of our holistic framework are: increase of the abstraction level, since the focus is on the design of technologyindependent CBP; reduction of development costs and time and guarantee of alignment of a business solution with a technological solution, since process executions are generated automatically from process models. We present below in detail the different design phases composing our framework. 4.1. Collaborative Business Agreement
Definition Phase The collaborative business requirements phase at CIM level consists in analyzing the problem domain and identifying the collaborative business requirements. This is jointly carried out by the involved enterprises. CBP usually do not have a centralized control instance or process owner. Hence, it depicts the different roles involved in the collaboration and their specific responsibilities with regard to the collaboration scenario. So, it needs close coordination among networking partners which requires an agreement (common objective that partners agree on) on how to interact and exchange information, business documents and messages. 4.2. Collaborative Process Modelling
Phase
Modeling CBP follows an MDA approach,
proposing a set of models at different levels of
abstraction and model transformations to
connect them. At the PIM level, we model
CBP using an UML AD profile based on
extended process meta-model [
However, it is essential to enable partners to
make sure the correctness of the execution of
CBP. This formal verification task is concerned
to check the process model is free of logical
errors such as deadlocks, livelocks, etc. [
Business
level Process
level Technology level
Enterprise A: Seller 1-BPMN public process: public view, behaviour 2- BPMN private process: private activities, internal business logic 3- BPMN formal verification 1- SOA/WS-BPEL, WSDL: internal techno. Standards 2- BPEL formal verification 3- Internal code execution, 4- Seller’s web application
Transformation Rules
Derivation
Rules Message’s Exchange Invocation of services
Enterprise B: Buyer 1-BPMN public process: public view, behaviour 2- BPMN private process: private activities, internal business logic 3- BPMN formal verification
Transformation
Rules 1- SOA/WS-BPEL, WSDL: internal techno. Standards 2- BPEL formal verification 3- Internal code execution, 4- Buyer’s web application CIM: Collaborative business layer
PIM: Collaborative process layer PIM: Public & Private partner’s processes layer PSM: Partner’s internal code execution layer 4.3. Generation of Partner’s Public
Processes Phase As we are shown before, CBPs are not executable. Hence, CBP requires the definition of public and private processes each organization has to implement for executing collaborative process. A public process defines the public behavior of the role an organization performs in a CBP at PIM layer. It defines the externally visible behavior of a business partner in terms of the activities that support the receiving and sending of messages and business documents with each other. By deriving public process from the CBP, we ensure that the semantics of each CBP element (where UML AD model applies UML AD profile as depicted in Figure 3) is represented in terms of the elements and semantics provided by BPMN from one partner’s viewpoint (e.g. seller or buyer) as depicted before in Figure 2.
conforms-to
UML2 Activity Diagram Model
UML2 Activity
edit Eclipse UML2 Editor
ATL
Eclipse BPMN
BPEL & WSDL metamodels applies model-to-model transformation
UML2BPMN.atl
Eclipse BPMN Model
Seller.bpmn
Buyer.bpmn Intalio BPMN
Editor
BPMN2BPEL .atl
BPEL Model
WSDL Model Buyer & Seller.bpel Buyer & Seller.wsdl BPEL & WSDL
Editor edit conforms-to applies model-to-model transformation
For this purpose, we define automated process model transformation engine (see Figure 3). Henceforth, UML Activity Diagram and BPMN models have some elements share the same semantic meaning. These elements are transformed directly without considering about the element context or neighbourhood elements (one-to-one transformation rule). In addition, some UML Activity Diagram element types cannot be transferred directly to BPMN elements. To be able to remain the same semantic meaning, two or more elements in UML Activity Diagram will be translated to one BPMN element (many-to-one transformation rule). 4.4. Definition of Partner’s Private
Processes Phase The private executable process is derived from a public process at each partner’s side (see Figure 3). It adds the private logic of the enterprise required to achieve the role within a global CBP. The internal business logic includes the activities for producing and processing the exchanged information/ documents as well as data transformations and invocations to internal systems. Internal or private activities (see the seller’s private activities of Figure 1), which are required for generating the information to be sent and processing the information to be received from partners, have to be added to the public process to define the private process.
In our case, in order to realize the
BPMN-to-BPEL process model transformation,
we implement an algorithm inspired from
Ouyang et al. [
However, it is difficult to develop complete translation rules, so the result of the translation needs validation from process modeler. Consequently, we can use the transformation rules as a semi-automation translation method to reduce the time for him when translating the models manually.
Beside the model transformation engine, we consider the business processes as the key focal point of Web services design. Henceforth, each of the activities in the process model must be implemented with one or more services. Below we describe this task in two steps: Step1: Determine objectives and describe the business process structure and functions: The business process structure refers to the logical flow or progression of the business process. The functions of a business process are expressed in terms of the activities or the Internet
To this aim, we use an Eclipse-based integrated platform [11] to guarantee the interoperability of the different plug-ins, tools and ATL transformation languages. Thus, we develop an Eclipse-based ATL code for the building of process model transformations (e.g. from collaborative to specific BPMN). In this way, the derivation of the private process (e.g. seller) from the CBP ordering process is carried out with this ATL tool.
In this work, we implement the basic collaborative process scenario, where a buyer (University) makes an online order to a seller (Suppliers), who processes and fulfils the order, as shown in Figure 4. Hence, we implemented an e-Ordering application for each partner’s side, representing activities of executable business processes as Web services. So, interactions between seller and buyer are achieved as invocation of partner’s services.
Figure 5 shows the university’s ordering web application (buyer side) where we make an on line order by choosing the products from the seller’s catalogues.
In addition, we have developed in parallel a software tool implementing formal verification techniques which have to be applied to corresponding Petri Nets representation of business process. This tool is applied at the three framework levels (verification of UML AD, BPMN and BPEL business process models). Four verification properties (Deadlock, bounded, liveness and quasiliveness) are implemented as shown in the right side of Figure 6 of the process of the example depicted before in Figure 1.
e-Ordering system platform architecture University’s procurement dept. Suppliers Procurement
Agents services that need to be performed by a specific business process.
Step2: Describe business activity responsibilities (roles): Each activity within a business process is associated with a particular Web service provider who fulfils a defined role (responsibility) within the process. Each service provider is expected to properly fulfill the business responsibility of implementing the Web service, or set of Web services, which perform that activity within the process under the role that the provider is expected to undertake. 4.5. Code Execution and User Interfaces
Phase
CBP provides a global or public view on
participants collaborating in a peer-to-peer
fashion by offering distributed Web services in
order to achieve a common business goal.
This step deals with the user interface
applications development for the “seller” and
the “buyer” roles in an e-ordering system.
Furthermore, on the execution layer these
internal processes are used e. g. for the
orchestration of Web services [
To this aim, we have implemented a direct connection with the business applications of the buyer organization communicating directly with a seller's web application to send and receive information. After collaborating, both of the two partners’ applications progress independently. 5
In order to validate our approach, a tool support is essential. For this purpose, we have implemented an e-Ordering system. The main objective of the order fulfillment process that buyer expected is supplier can deliver qualified products to fulfill its orders at the right time and right place. So, buyer and supplier have to collaborate by sharing and exchanging business information. HTML
Solicitation Automation E-Procurement
Requests Responses
F I R E W A L L 6
In the frame of this work, we have proposed a MDA-based framework for designing collaborative systems. It combines the concepts of BPM and Web services technologies. We defined collaborative business process model. Thereafter, the specific partner’s processes are derived from the collaborative process. Moreover, the collaborative B2B interactions between partners are represented, using Web services technology, at executable level.
Finally, there are several open issues to address in the future. Thus, we plan to evaluate our framework through a scenario with three business partners (enterprise, supplier and shipper) in order to verify the completeness and generality of the proposed concepts and artifacts. Another aspect that requires further research is to investigate the explicit support of heterogeneity of data formats and messages using the ontology concepts.