1. ERA (Excellence in Research for Australia) CORE Ranking Feb 2010
2. Cristina Vicente-Chicote's list of Software Engineering Journals & Magazines
3. Jeff Offutt's list of journals
4. Periodicals on Software Engineering
5. Steven C.H. Hoi's reference list
6. Tao Xie's Software Engineering Conferences
7. Daniel Lemire's list of journals

In process-driven, service-oriented architectures (SOA), process activities invoke services to perform the various tasks of the business 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. technology 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 flow 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 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.

Our approach provides a number of foundational 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).

Figure 1. Fundamental concepts of the view-based, model-driven approach

Figure 2. Layered architecture of the view-based, model-driven approach

Figure 3. Top-down and bottom-up approach for process-driven SOAs in VbMF.

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 abstraction levels. 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.

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.

Figure 4. The proof-of-concept of the view-based, model-driven approach for process-driven SOAs: (1) FlowView Editor, (2) (Bpel)InformationView Editor, (3) (Bpel)CollaborationView Editor, (4) Code generation template rules, and (5) Generated process code

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

We provide simple high-level and low-level tree-based view editors such as Flow View, Collaboration View, Information View editors, by using EMF generator. Go to File > New > Other, or simply press Ctrl+N. In the upcoming dialog, go to View-based Modeling Framwork category, and choose the desired one to create its new instance (see Fig. 5). Otherwise, users can choose the VbMF HelloWorld Project to start with a HelloWorld process including some predefined views. A simple tree-based editor will be activated to support editing the selected view. In case you want to manipulate an existing view, just double-click on the view to activate the corresponding editor.

Figure 5. Creating new view with VbMF wizards

Beside view manipulations, users can also quickly generate process implementation in BPEL and WSDL descriptions of the process under development. Just right-click on the Core Model of the process, then choose "Generating Process Code (WSBPEL/WSDL)" in the drop-down menu (or so-called the context menu) (see Fig. 6). A new folder "generate-code" will be created to store the generated code.

Figure 6. Generating process implemetation

5.4 Extract views from process implementation Starting from scratch is an expensive option in software development. Therefore, we devise a view-based reverse engineering approach that can support users to extract views from existing process implementation in BPEL/WSDL.

To facilitate the view-based reverse engineering, users just right-click on the BPEL file and choose "Extract View" in the drop-down menu. A new folder "generate-view" will be created to store the views extracted from the corresponding process implementation (see Fig.7).

Figure 7. Extracting views from process implementation

Note: we assume that there is a WSDL file delacring Web service interfaces for a BPEL process. The BPEL and WSDL files have the same name but different extensions. For instance, the HelloWorld project contains a process specification in Hello.bpel and Web service interfaces of that process in Hello.wsdl.

VbMF has been implemented using the Eclipse Modeling Framework (EMF) and openArchitectureWare (oAW), a model-driven software development tool. The current version of VbMF runs inside Eclipse development environment with appropriate plugins.

VbMF source code is available here or by our internal SVN (for DSG members only). VbMF is an open source software. You can find a MIT/BSD-like license attached.

The current version of VbMF is delivered as 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, at.ac.tuwien.vitalab.vb, and other projects, namely, at.ac.tuwien.vitalab.vb.edit, at.ac.tuwien.vitalab.vb.editor, at.ac.tuwien.vitalab.vb that offer the user interface and view editors generated from the main project (see Fig. 8).

Figure 8. VbMF source code organized as Eclipse plugin projects

            Copyright (c) 2007-2010 Vienna University of Technology, Austria. All rights reserved.

            Developed by: Distributed Systems Group,
                          Information Systems Institute,
                          Vienna University of Technology, Austria.
                          http://www.infosys.tuwien.ac.at

            Permission is hereby granted, free of charge, to any person obtaining a copy
            of this software and associated documentation files (the "Software"), to
            deal with the Software without restriction, including without limitation the
            rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
            sell copies of the Software, and to permit persons to whom the Software is
            furnished to do so, subject to the following conditions:

              1. Redistributions of source code must retain the above copyright notice,
                 this list of conditions and the following disclaimers.
              2. Redistributions in binary form must reproduce the above copyright
                 notice, this list of conditions and the following disclaimers in the
                 documentation and/or other materials provided with the distribution.
              3. Neither the names of Distributed Systems Group, Information Systems
                 Institute, Vienna University of Technology, Austria, nor the names
                 of its contributors may be used to endorse or promote products derived
                 from this Software without specific prior written permission.

            The Software is provided "as is", without warranty of any kind, express or
            implied, including but not limited to the warranties of merchantability,
            fitness for a particular purpose and noninfringement.  in no event shall the
            contributors or copyright holders be liable for any claim, damages or other
            liability, whether in an action of contract, tort or otherwise, arising
            from, out of or in connection with the Software or the use or other dealings
            with the Software.