View-based, Model-driven Approach for Process-driven SOAs

1. Introduction

In process-driven, service-oriented architectures (SOA), process activities invoke services to perform the various tasks of the process. As the number of elements involved in a business process architecture, such as processes, process activities, and services, grows, the complexity of process development also increases along with the number of the elements' relationships, interactions, and data exchanges – and quickly becomes hardly manageable. In addition, process-driven SOA models address different stakeholders, such as business experts and technical experts, who require different kinds of information for their work. Finally, process-driven SOA models must deal with constant changes – both at the business level (e.g. business concept changes) and the technical level (e.g. technologies and platform changes).

One of the successful approaches to manage complexity is separation of concerns. Process-driven SOAs use a specific realization of this principle, modularization : Services expose standard interfaces to processes and hide unnecessary details for using or reusing. This helps in reducing the complexity of process-driven SOA models, but from the modelers’ point of view this is often not enough to cope with the complexity challenges explained above, because modularization only exhibits a single perspective of the system focusing on its (de-)composition. Other – more problem-oriented – perspectives, such as a business-oriented perspective or a technical perspective (used as an example above), are not exhibited to the modeler. In the field of software architecture, architectural views have been proposed as a solution to this problem. An architectural view is a representation of a system from the perspective of a related set of concerns. The architectural view concept offers a separation of concerns that has the potential to resolve the complexity challenges in process-driven SOAs, because it offers more tailored perspectives on a system, but it has not yet been exploited in process modeling languages or tools.

Inspired by the concept of architectural views, we suggest a view-based approach to modeling of process-driven SOAs. Namely, perspectives on business process models and service interactions – as the most important concerns in process-driven SOA – are used as central views in our approach. The approach is extensible with all kinds of other views. In particular, our approach offers separated views, in which each of them represents a certain part of the processes and services, such as the collaboration view, the information view, the orchestration view, etc. These views can be viewed separately to get a better understanding of a specific concern, or they can be integrated to produce a richer view or a more thorough view of the processes and services.

Our concepts are realized in terms of a framework, namely, View-based Modeling Framework (VbMF), for process-driven SOAs using the model-driven software development paradigm. VbMF provides three major contributions: firstly, it captures different perspectives of a business process model in separate, (semi-)formalized views; secondly, it separates different abstraction levels in a business process architecture; thirdly, it is an extensible model-driven approach to integrate the different view models and abstraction levels. Moreover, VbMF automatically generates platform-specific descriptions and executable code of business processes in WSDL and BPEL.

2. View-based Model-driven Approach for Process-driven SOAs

The framework consists of modeling elements such as a meta-model, view models, and view instances (see Figure 1). A view model is a representation of a process from the perspective of related concerns. In VbMF, a view is specified using a relevant framework’s view model. Each view model is a (semi-)formalized representation of a particular business process concern. Therefore, the view model specifies entities and their relationships that can appear in the correspondent view instance. The view models, in turn, are defined on top of the meta-model which is the Eclipse Modeling Framework meta-model. VbMF defines a number of view models, one for each architectural view. A view model at a lower abstraction level is defined as an extension of the view models at higher levels. At the heart of VbMF is the Core view model from which each view meta-model is derived. Example view models that we have derived from the Core model include the following views: Collaboration, Control Flow, Information, Transaction, Human View, and so on.. Based on the view models, we derive particular view instances. For specific technologies, for instance, BPEL and WSDL, we provide extension meta-models which comprise additional details required to depict the specifics of these technologies. Figure 1 shows the relevant BPEL-specific view models of those aforementioned view models. Hence, we can use the distinction of Core view model, generic view models, and extension view models to handle different abstraction levels, including business-level concerns and technical concerns (see Figure 2).

VbMF provides stakeholders both top-down and bottom-up approaches. The top-down approach consists of a forward engineering tool-chain (see Figure 3) in which the stakeholders can develop process-driven view models, can generate process code from these views, or can extend the modeling framework with other process concerns by adding new view models or by enhancing existing view models. The bottom-up approach provides a reverse-engineering tool-chain for adapting legacy process descriptions and integrating various modeling representations. During the reverse engineering process, high-level, abstract and low-level, technology-specific views on the process descriptions are recovered from the existing code. These tailored view instances can be put into a common repository, and then be re-used in other processes or be manipulated to re-generate new schematic executable code, which corresponds to changes in the corresponding view instances. This way, the reverse engineering approach helps stakeholders to get involved in process re-development and maintenance at different abstractionlevels. Reverse engineering of business processes not only helps to adapt process models to stakeholder needs but also offers the ability to seamlessly integrate various process models into VbMF in order to enhance their interoperability.

3. Tool support

We realize the aforementioned tool-chain by facilitating the Eclipse Modeling Framework (EMF) and openArchitectureWare MDD Framework (see Figure 4). The most advantage of using Eclipse Modeling Framework is that we gain better integration and interoperability with existing development tools developed based on EMF Ecore, a MOF-compliant meta-model, and XMI, a standard for serializing models. The View-based Modeling Framework provides different editors for manipulating views, such as FlowView Editor, (Bpel)CollaborationView Editor, (Bpel)InformationView Editor, and so on. For the sake of demonstration, we mainly use the tree-based editors which are generated from our view models by the EMF generator. The template-based code generation rules are developed using the XPand language editor provided in openArchitectureWare. Using these rules, we can automatically generate process implementations including BPEL and WSDL descriptions.

People involved

• Schahram Dustdar
• Uwe Zdun
• Huy Tran
• Ta'id Holmes

For further information, please contact me at htran@infosys.tuwien.ac.at

Publications

• H. Tran, U. Zdun, and S. Dustdar. VbTrace: Using View-based and Model-driven Development to Support Traceability in Process-driven SOAs, Software & System Modeling, Springer, DOI: 10.1007/s10270-009-0137-0, 2009
• Huy Tran, Ta'id Holmes, Uwe Zdun, and Schahram Dustdar. Chapter II: Modeling Process-Driven SOAs – a View-Based Approach. In J. Cardoso, W. van der Aalst: Handbook of Research on Business Process Modeling, IGI Global, 2009.
• Ta'id Holmes, Huy Tran, Uwe Zdun, and Schahram Dustdar: Modeling Human Aspects of Business Processes – A View-Based, Model-Driven Approach, Fourth European Conference on Model Driven Architecture Foundations and Applications (ECMDA'08), Springer LNCS, June 2008
• H. Tran, U. Zdun and S. Dustdar. View-Based Reverse Engineering Approach for Enhancing Model Interoperability and Reusability in Process-Driven SOAs. 10th International Conference on Software Reuse (ICSR'08), 25 - 29 May, Beijing China, Springer LNCS, 2008
• H. Tran, U. Zdun, and S. Dustdar. View-based Integration of Process-driven SOA Models At Various Abstraction Levels. In R.-D. Kutsche and N. Milanovic, editors, Proceedings of First International Workshop on Model-Based Software and Data Integration MBSDI 2008, 1 - 2 April, Berlin, Germany, pages 55-66, CCIS 8, Springer, 2008
• H. Tran, U. Zdun and S. Dustdar. View-based and Model-driven Approach for Reducing the Development Complexity in Process-Driven SOA. In International Working Conference on Business Process and Services Computing (BPSC’07), volume 116 of Lecture Notes in Informatics, pages 105–124, 2007

Appendix: VbMF Developer Guide

1. Setup hosting environment (Eclipse 3.4 Ganymede, Eclipse EMF 2.4 and openArchitecture 4.3)

We have implemented VbMF using the Eclipse Modeling Framework (EMF) and openArchitectureWare (oAW), a model-driven development framework. The current version of VbMF can run smoothly with Eclipse 3.4, EMF 2.4, and oAW 4.3.1. For the sake of simplicity, we recommend
the bundle Eclipse Modeling Tools which includes many Eclispe modeling technologies such as EMF, GMF, MDT, M2M, M2T, and UML. These distributions are available for Windows, Linux, and Mac OS X. Then, you can use the Eclipse Update Manager to install oAW.

2. Import VbMF project into the active Eclipse workspace

The current version of VbMF is delivered as three Eclipse projects which can be easily imported by choosing menu File > Import, then choose Existing Projects into Workspace. In the next dialog, browse for the directory containing VbMF projects. Eclipse will recognizes and imports VbMF into the active workspace. VbMF includes the main projects, namely, viewbased, and two other projects, namely, viewbased.edit and viewbased editor, which comprise the view instance editor generated from the main project.

3. Try existing view-based modeling examples

We have developed a Shopping process as a small example of process-driven modeling using VbMF (Figure 4). This example is in the samples/shopping/ folder. There are a number of view instances which represent various concerns of the Shopping process including the control flow, collaborations with other services, data and message processing, transaction handling, etc. In order to generate schematic process code in terms of BPEL and WSDL, the workflow.oaw has to be run. Just right-click on the workflow.oaw inside the samples/shopping folder, then choose Run As > oAW Workflow (Figure 4)

       

Figure 5. Layout of the main VbMF project (left-hand side) and step-by-step to generate schematic code for the Shopping process (right-hand side)

In the Shopping process example, we have develop abstract view instances which are

• shopping.controlflow: an instance of the Control-Flow view model
• shopping.collaboration: an instance of the Collaboration view model
• shopping.information, an instance of the Information view model
• shopping.transaction, an instance of the Transaction view model

The following view instances refined from these abstract views represents technology-specific perspectives of the Shopping process.

• shopping.bpelcontrolflow: an instance of the BPEL Control-Flow view model refined from the Control-Flow view instance.
• shopping.bpelcollaboration: an instance of the BPEL Collaboration view model refined from the Collaboration view instance.
• shopping.bpelinformation, an instance of the BPEL Information view model refined from the Information view instance.

4. Develop process-driven models using VbMF

4.1 Develop view instances using VbMF View Editor

We also implemented a simple View Editor using EMF generator. The EMF generator takes the view models (i.e., .ecore files) as inputs and creates genmodel files. These genmodel files are used to generate schematic editor code for developing instances of the corresponding view models. The enclosed viewbased.edit and viewbased.editor, which are Eclipse plugins, are results of code generation using the EMF generator. The plugins can be installed in Eclipse in the same way as other Eclipse plugins. Currently, the VbMF editor is still in development phase. Therefore, it is greatly recommend to run the editor inside a second Eclipse instance. To do so, go to menu Run > Run As > Eclipse Application. Another Eclipse instance will be activated along with all development plugins, i.e., including the VbMF view editor. Inside the second Eclipse environment, go to File > New > Other. In the upcoming dialog, go to Example EMF Model Creation Wizards category, and choose the desired view model to create its new instance. A simple tree-based editor will be activated to support editing the selected view instance. To edit an existing view instance, simply double-click on the view instance to activate the corresponding editor (see Figure 5).

Figure 6. The VbMF view editor wizards (left-hand side) and the simple tree-based editor for an instance of the Control-Flow view model (right-hand side)

4.2. Develop view models using EMF Ecore editor

All view models in VbMF are realized as EMF Ecore models (i.e., .ecore file). At the moment, EMF supports editing of EMF Ecore models by using a simple Ecore editor. Just double-click on any .ecore file, for instance, the core.ecore which is the Core view model, to activate the EMF Ecore editor (see Figure 6)

Figure 7. Using EMF Ecore Editor to modify an existing view model or create new view models

4.3 Create oAW Xpand templates for additional code generation

Basically, the Xpand templates we defined in VbMF can handle all aforementioned view models and generate schematic process code in terms of BPEL and WSDL descriptions. If further snippets (for example, configurations for deploying processes onto a certain process-engine) are needed, additional templates should be developed. The best source of reference is the oAW's documentation of Xpand language.

4.4 Bring all-together using oAW workflow

An oAW workflow is an executable component in Eclipse which are often used to load the Ecore models, load and check the mode instances against the models, against some OCL-like constraints, load the templates and generate code according to the templates and models. In the Shopping process example, we also developed a workflow, which is mentioned in Section 3, to accomplish those steps except constraints checking. In this example workflow, we utilized XmiReader component to load the view instances and check if the instances conform to the view models, respectively. Then, the Generator component is used to combine the instances, the templates and generate schematic code. These resulting code are finally re-formatted using the XmlBeautifier. For further information on the oAW's workflow, please reference the documentation of oAW project.

---

Last updated: 12.11.2009