Moreover, sometimes the description of these business applications is highly tied to a ... conventional software methods did not consider while generating Web ... Section 6 introduces the transformation approaches used in this work. In ..... ManualTask2MainAIU(l,pc) are going to be applied on every task within a lane.
Building Business Process Driven Web Applications Victoria Torres and Vicente Pelechano Department of Information System and Computation Technical University of Valencia Camí de Vera s/n 46022 Valencia, Spain {vtorres, pele}@dsic.upv.es
Abstract. The Internet has turned to be one the most common platform for the development of applications. In addition, sometimes the specification of these applications is given to web developers in the form of Business Processes (BP), and from this specification they are asked to develop the corresponding Web Application. In this situation, Web Engineering Methods should provide a way in which these specifications could be taken and be transformed into a Web Application that gives support to the process execution. Furthermore, when we are talking about B2B applications, we have to take into account that these BP usually involve the use of distributed functionality where different partners collaborate to accomplish an agreed goal. Therefore, in this work we provide a method for the automatic generation of Web Applications that give support to BP specifications. For this purpose, we generate from a BP definition the Navigation (web pages) and the WS-BPEL executable description that implements the entire process.
1 Introduction The Internet has turned to be the most common platform for the development of business applications. This is due to the fact that many organizations and companies are already providing their functionality by means of Web Service technology. Moreover, sometimes the description of these business applications is highly tied to a Business Process (BP) definition, and hence the objective of these applications is not only information management but also process management. Therefore, in these situations it is more natural to describe these processes in the most appropriate way, which is by means of workflow charts, activity diagrams or a similar notation. Web Engineering Methods emerged to address some of the aspects that conventional software methods did not consider while generating Web applications. These aspects refer to Navigational and Presentation issues, and these became, within the Web Engineering methods, first-order citizens in the conceptual modelling step. Most well known Web Engineering Methods follow a Model Driven Development (MDD) approach in the sense that they are based on a set of models that cover those concerns that are necessary to specify a Web Application (structure, behaviour, navigation and presentation). In addition to this, when these models are unambiguously specified, with clear semantics, they can be (semi-)automatically
2
Victoria Torres and Vicente Pelechano
transformed in order to obtain the equivalent solution in terms of an implementation technology. Therefore, Web Engineering Methods should now be adapted to accept BP definitions and by means of a set of transformations generate the appropriate software solution. In addition, we should also take into account that real BPs do not only include automated activities and system participants, in fact, they can also include human participants (participants that require a user interface to interact with the process) and manual activities (activities that are not automated at all, for instance, “to make a phone call” or “to review a document”). Moreover, the kind of interaction that a human participant can have within a BP can range from simple decisions to the introduction of some required data through a user interface. Therefore, Web Engineering Methods should provide a mechanism that allows designers to define the necessary graphical interfaces (by means of their Navigational Model) that give support to the required interaction between human participants and the process. The challenge pursued in this work is to extract from a BP definition the required navigation (user interaction) to execute the process via a Web Application. We have focused on those cases where the interaction with the user is crucial for the process to be accomplished. The main contribution of this work is to provide a proposal for the automaticgeneration of Web Applications that give full support to the execution of BPs. To achieve this goal we generate from a BP definition (1) the required graphical user interface to launch and complete process activities, as well as (2) the equivalent executable definition of the process. This proposal allows us to obtain BP implementations that are totally integrated within the Web Application. This integration is achieved at three levels, which are data/content, functionality and graphical user interface. This proposal is based on the OOWS [7] approach (a Model Driven Web Development Method that is an extension to the object-oriented software production method OO-Method [15])-OOWS introduces the required expressivity to capture the navigational and presentational requirements of web applications. For this purpose we have defined an extension to the OOWS Navigational Model that allows us to model the graphical interfaces that are necessary to allow interaction between human participants and the business process. The rest of the paper is structured as follows. Section 2 makes an overview of the related work in both, the Web Engineering and the Business Process area. Section 3 provides an overview of the proposal presented in this work. In section 4 we introduce the example used to present the proposal. Section 5 presents the set of stereotypes added to the BPMN notation to allow us modelling the corresponding graphical user interfaces. Section 6 introduces the transformation approaches used in this work. In Section 7 we first provide an overview of the OOWS approach and then present the transformation rules for the generation of the OOWS Navigational Model that gives support to the BP execution. Section 8 provides an overview of the interaction schema followed to build the equivalent process defined in the Web Services Business Process Execution Language (WS-BPEL [4]). Finally, section 9 gives some conclusions and outlines some further work.
Building Business Process Driven Web Applications
3
2 Related Works Several Web Engineering methods have developed their own proposal for the systematic development of Web applications. Moreover, these methods have been extended to provide solutions to the new challenges that have come up in the Web application development. In particular, most of these proposals (UWE and OO-H [13], OOHDM [16], WebML [9] and WSDM [6]) have extended their methods in order to support the integration between Navigation and Business Processes. However, in some cases these extensions (1) do not consider the interaction of different business partners, (2) do not provide a process oriented user interface to guide the user for the accomplishment of their pending tasks or (3) do not take into account that real BPs entail sometimes the realization of manual tasks. On the other hand, the solutions provided in the area of business processes (Oracle BPEL Process Manager1, Active BPEL2, etc.) are more centred on the orchestration of Web Services more than in providing a suitable user interface that solves the interaction between the user and the business process. In fact, as stated in [2], the WSBPEL language does not consider people as a type of participant in a process definition. In this sense, the Oracle BPEL Process Manager has developed a solution to define this interaction. However, this solution is provided at the implementation level, what entails that Web Engineering Methodologies cannot take profit of these mechanisms at the modelling level.
3 Proposal Overview As we have stated previously, Web Engineering Methods should allow us to specify the application functional requirements by means of BP definitions. Moreover, the BPs that we want to model, range from those that include human interaction for the realization of some activities to those that include activities that are performed by external partners. For this reason, we have included within the OOWS method a model that allows us to define a BP. This model is the Business Process Model (BPM). Fig. 1 provides a graphical overview that includes just the models involved in the proposal as well as the relationships defined between them. The purpose of the BPM is to describe by means of a graphical notation a set of activities performed by different agents and sequenced by means of a control flow. These activities invoke operations that have been modeled either in the Class Diagram (CD) or in the Services Model (SM). The existing relationship between the BPM and the CD and the SM is depicted graphically in Fig. 1 by means of an arrow stereotyped with the keyword. The set of operations defined in the CD include the functionality that is provided within the boundaries of our system. On the other hand, the functionality that is “lent” from external partners is defined in the SM. The SM was introduced in a previous work [18] in order to define the set of services (and operations provided by these services) that are supplied by external partners. The 1 2
http://www.oracle.com/technology/products/ias/bpel/index.html http://www.activebpel.org/
4
Victoria Torres and Vicente Pelechano
major benefit of having external functionality at the modeling level is twofold, (1) it allows us to handle external functionality as if it was part of our system and (2) it facilitates the integration between external functionality and other models defined in our method.
SOLUTION SPACE
PROBLEM SPACE
OO-Method
OOWS
Structural Model (Class Diagram)
«uses»
Navigational Model
«generates» Model-to-Model transformation
Business Process Model
«generates» Model-to-Text transformation
WS-BPEL language
«uses»
Services Model
«generates» Model-to-Text transformation
Presentation tier (HTML, ASP, JSP, Servlets)
Fig. 1 Proposal Overview. Relationship between Models Some activities defined within the process definition require the existence of a user interface to be performed. These user interfaces are defined in the Navigational Model and allow the user to interact with the process by introducing some data, starting some activities or taking decisions over some displayed data. The relationship between the BPM and the Navigational Model is depicted in Fig. 1 as an arrow stereotyped with the “ Model-to-Model transformation” keyword. This means that from a BP definition we are going to obtain, after applying a set of transformation rules, an initial version of the navigational model that will give support to the process execution. Then, once the Navigational model is completely defined, again, by means of model-to-text transformations we generate the equivalent graphical interfaces represented in a specific technology. Finally, to execute the BP definition in a process engine, we transform the process definition into a target executable process language. This transformation is represented in Fig. 1 with an arrow stereotyped as “ Model-to-Text transformation”. Once we have the equivalent executable description we can execute the process in any engine capable of executing process definitions created in WSBPEL [4]. As can be seen in Fig. 1, the OOWS/OOMethod approach, in the same direction as the MDA proposal, is based on the use of models to achieve software development. In fact, its models characterize the system domain at the problem space, independently of any particular implementation technology.
Building Business Process Driven Web Applications
5
4 The e-Library Example To illustrate the proposal, we include in this work an example based on a real scenario that has been identified in the Department of Information Systems and Computation at the Technical University of Valencia. The department has developed a web application (www.dsic.upv.es) following the OOWS approach. This application provides the typical information and functionality that a web site like this usually offers (access to personal directories, information about subjects given at the department, enrollment to seminars and so on). Moreover, this application supports the realization of a set of Business Processes. However, the activities that make up the BPs are hidden through the navigation of the application, and users usually have the feeling that they are executing operations individually and not as a part of a whole process. This fact can finally imply that users involved in the process get lost when they have to perform an activity (normally when the process takes a long time to be completed) because they do not have the process in mind (which is quite normal if we think that people usually have multiple and disparate responsibilities). The BP that we have taken as the running example (Request Book Purchase Business Process) has as main goal to purchase a new book for the library of the department and to lend it to the purchase applicant after the book arrives to the department. This process involves the participation of different agents, which range from individuals (the secretary staff of the department, the department librarian, and the applicant member) to automated systems (the central library system and the department system). The graphical definition of the running example is shown and explained in the following section.
5 The Business Process Model. Defining the BP Example There are available several notations (such as UML Activity Diagrams, UML EDOC Business Processes, IDEF, ebXML BPSS or BPMN among others) that can be used to model BPs. As it is stated in [3], there is a gap between a BP definition and its equivalent process definition that has to be bridged. On the one hand, a BP definition focuses on providing a high level view of the activities performed by different agents to accomplish a specific goal. On the other hand, a process definition is more focused on technical aspects that define how these activities are accomplished. In this work, we have skipped the high level definition of a process and have directly defined BPs as process models. In particular, we are going to use the Business Process Modeling Notation (BPMN) [5] because it provides a mapping between the graphics of the notation to the underlying constructs of an execution language, in particular to the WS-BPEL language, what makes this notation a good candidate to be used. This notation is designed to cover a wide range of type of diagrams. However, as our goal is to obtain those software components that implement these BP definitions, we are going to use the notation for the design of “detailed private business processes with interactions to one or more external entities”. It is important to make this clear in order to obtain, after the application of the transformation rules, a correct Web Application solution.
6
Victoria Torres and Vicente Pelechano
SECRETARY «role-any» LIBRARIAN «role-any»
«user»
Request a Book Purchase
«send»
«user»
Validate the request
Approve?
Default (Yes)
Send Request
«receive»
Recv. Purch. Notification
«manual»
Pick Up Books
«service»
No
Loan Book Request [pending]
Request [validated] «service»
Notify Request Rejection
«service»
Load Book Details
+
«service»
Notify Book Purchase
CENTRAL LIBRARY
SYSTEM «entity»
DSIC
MEMBER «role-one»
As we have stated before, from a BPMN definition we want to obtain two different kinds of assets, one is the graphical interface that will allow the user to interact with the process, and the other one is the executable definition of the process. Fig. 2 depicts the BP definition of the running example. In this figure we can see how participants are organized first in pools (to represent the different organizations that take part in the process) and then in lanes (to organize different roles within the same organization). Moreover, to differentiate when human participants behave as individuals or as members of a group we have refined the participant type role (type that represents human participants) into role-one (to refer to individuals) and role-any (to refer to a group). In the running example (see Fig. 2) we have defined two Pools, one for the DSIC organization and another for the Central Library (external system). For instance, within the DSIC organization we have included four lanes to organize responsibilities; three of them refer to human roles (Librarian, Secretary and Member) and the last one refers to an automated system.
Fig. 2 Process Definition for the “Request Book Purchase” Business Process The lanes that refer to human beings are stereotyped with the keyword. On the other hand, automated participants are stereotyped with the keyword. Once Pools and Lanes are identified, we proceed to define the activities and the control flow that sequences them. We have stereotyped activities with the manual, user, service, send and receive keywords depending on the kind of activity that we want to represent. We want to note that the realization of a manual activity do not imply any change in the state of the automated system. For readability reasons, we have included a graphical definition that only displays the basic structure, control flow and data within the BP. However, this definition also includes a set of attributes that define completely each element of the process.
6 Transformation Techniques. Background Currently, the Model Driven Architecture (MDA) is the most well known approach to achieve the Model Driven Development (MDD) and advocates for the use of
Building Business Process Driven Web Applications
7
models in software development. These models are defined at different levels of abstraction, which are (1) system requirements modelled in a computation independent model (CIM), (2) system description defined in a platform independent model (PIM) where details of its use of its platform are not shown and (3) a detailed system specification that specify how to use a particular type of platform, the platform specific model (PSM). The act of converting one model into another from the same system is called a Model transformation. Fig. 3 and Fig. 4 depict graphically the approach proposed by the MDA to achieve transformations. However, model transformation does not always refer to transformations between models defined at different levels of abstractions (see Fig. 3). In fact, the same approach can be used to transform any model into another related model (see Fig. 4). subtypes of
PIM
Platform Independent Types
language used
Metamodel A
Model 1
source types
source language
Transformation Specification
Transformation Model
Transformation
Transformation target types
subtypes of
PSM
Platform Specific Types
Fig. 3 PIM to PSM transformation approach
target language language used
Model 2
Metamodel B
Fig. 4 Model to Model transformation approach
In particular, within the context of this work, we need to perform two different kinds of transformations, which are (1) model-to-model transformations (PIM-to-PIM transformations) to generate the Navigational Model from the BP definition and (2) model-to-text transformations (PIM-to-Code transformations) to generate an executable process definition in WS-BPEL.
7 Model-to-Model Transformations. From BPMN to OOWS This section is divided into four subsections. In the first one, after providing a brief overview of the OOWS approach, we present the primitives that have been added to this method and the reasons why they are necessary. In the second subsection we provide an overview of languages and tools to achieve model-to-text transformations. Next, we define intuitively (and using the graphical notation of the MOF QVT Relations language) the transformation rules that generate the corresponding OOWS Navigational model. Finally, we include some of the generated user interfaces obtained after applying the transformations. 7.1 New Navigational Primitives for Business Process Support The OOWS method extends OO-Method with three additional models (which are the User, Navigation and Presentation models) that allow us (1) to express what kind
8
Victoria Torres and Vicente Pelechano
of users can interact with the system as well as the inheritance relationships between them, (2) to define the visibility and the navigational semantics of the system for each user and (3) to specify the presentational requirements for the user interfaces. However, the current primitives defined by the OOWS approach do not fit well to represent the Navigation required by BP execution. For this reason, we have defined a set of new primitives in order to (1) organize the way pending activities are displayed to the user, (2) guide the user in order to complete his/her pending tasks, and (3) to improve the user experience while performing the activities assigned to him/her. This improvement is achieved by providing him/her with additional information that will help the user to finish the activity. The OOWS Navigational model allows us to define the navigational structure of a web application at the conceptual level. To do this, we associate a navigational map to each kind of user defined in the User model. A navigational map is represented by a directed graph whose nodes represent navigational contexts and whose arcs portray navigational links (see Fig. 5). On the one hand, a navigational context defines a view over the class diagram (see Fig. 6) that allows us to specify an object population retrieval that defines the information that users can access. On the other hand, a navigational link defines a reachability relationship among contexts. There are two kinds of navigational links: (1) Exploration links (targeted with dashed arrows and depicted with the “E” label in Fig. 5) that define a reachability relationship between every context of the navigational map and the target context. For instance, in Fig. 5 the Authors, Books and Members contexts can be accessed by the secretary user from any other navigational context. (2) Sequence link (targeted with solid arrows and depicted with the “S” label in Fig. 5). These navigational links define a reachability relationship between two specific contexts. For instance, in Fig. 5 the Loans context can only be accessed either from the Books or Members contexts. E «context» Books «AIU» Books
E SECRETARY
«context» Authors
Exploration Navigational Link
E E
«context» Books
Sequence Navigational Link
-title -isbn -editorial -num_edition -year_publication
«context» Members
S «context» Loans
«view» Book
Exploration Navigational Context
Sequence Navigational Context
«view» Copy -internal_id Internal_id -purchase_date [Loans] -state
«view» Author -name -nationality
ATTRIBUTE INDEX IDX_by_title ATTRIBUTE INDEX title,year_publication
Fig. 5 Navigational Map for the secretary user
«view» Loan
Fig. 6 Detailed view of the Books Navigational Context
INDEX
Building Business Process Driven Web Applications
9
Furthermore, this model includes mechanisms that facilitate users to access the information retrieved by the context (see bottom part of Fig. 6). We can define indexes to provide users with summarized information about the object population and search filters, which allow users to find specific objects. In its current state, the OOWS method allows users to decide which paths, from those already defined in the navigational map (via Exploration and Sequence links), they want to follow. However, within the execution of a process, the user does not decide which contents navigate through; in fact, it is the process which should drive the user to the next contents to accomplish the process target goal. For this purpose, we have included a set of primitives to model the navigation that define business processes. These new primitives are ProcessContext, ActivityContainer, Main-AIU, Complementary-AIU and Human-AIU and they are explained in the following paragraphs. Given a specific type of user, the ProcessContext primitive defines, in an abstract way, a process whose activities (or some of them) are assigned to this user. Each different activity is represented by means of the ActivityContainer primitive. An ActivityContainer is composed of a set of AIUs. An AIU (Abstract Information Unit) is an abstraction mechanism introduced to bring together a set of contents (class views) that are somehow related. Through the AIU primitive we can model contexts as an aggregation of contents, where no relationship between AIUs is expected at all. The proposed extension includes three different new kinds of AIUs: Main-AIU, Complementary-AIU and Human-AIU. An ActivityContainer is defined as a set of AIUs which can include either a Main-AIU or a Human-AIU and optionally several Complementary-AIU. The Main-AIU primitive presents the data and functionality needed in order to perform certain task. The Human-AIU primitive provides the user with a mechanism to inform the process that a manual activity has been completed. Moreover, the graphical interface that implements a Human-AIU includes the description of the manual task (for instance “Send the document via fax” o “Make a phone call”). On the contrary, Complementary-AIU provides information that complements the one given by the Main-AIU and Human-AIU. Although the contents provided by a Complementary-AIU are not vital to accomplish a task, they really help the user to complete the task. For instance, this primitive gathers some information kept in the system avoiding the user to navigate through the web application to acquire it. Regarding the Main-AIU, this abstraction mechanism provides the necessary data and functionality to perform the activity that it was designed for. On the other hand, a Complementary-AIU provides a mechanism to include a set of data that helps the user while performing an activity. Although the content supplied by a Complementary-AIU is not vital for the accomplishment of the activity (i.e. a list that provides the user with the necessary information to take a decision, avoiding the user to search for that information by navigating through the system) it helps the user in accomplishing it. Finally, a Human-AIU provides the user with a mechanism to notify the process that he/she has already finished a manual activity (an activity that is not automated at all). This mechanism, at the implementation level (see Fig. 7), could be represented as a button whose effect after pressing it is to make the process continue. This graphical interface also includes a description of the manual activity to perform (i.e. “Send a report via fax” or “Prepare the meeting and make the necessary arrangements”).
10
Victoria Torres and Vicente Pelechano
My TO-DO List – Pick up Books Task Description MEMBER CHANGE PROFILE HOME
Pick up Books
Please, pick up the book “Software Engineering” from the General Library and bring it to the porter’s office.
Department Directory Teaching
Task Name
Activates the Notification
Done
Fig. 7 Graphical Implementation of a Human-Activity Primitive
7.2 Model-to-Model Transformations Language/Tool Support There are different techniques that can be used to define transformations between models. Among the most used (or popular) languages/techniques we find MOF 2.0 QVT [10], MTF (an IBM implementation of a subset of QVT) [11], ATL [1] or AGG [17]. In particular we have chosen to use the QVT specification because it has been adopted by the OMG as the MDA standard to achieve model-to-model transformations. The QVT specification has a hybrid declarative/imperative nature. The declarative part is made of two languages (Relations and Core) that embody the same semantics at two different levels of abstraction. On the other hand, the imperative part is represented by the Operational language. In this work we have defined transformations using the Operacional Mappings imperative language. This language allows us to define unidirectional transformations between models, which are instances of MOF (Meta Object Facility) metamodels. We have used the Borland Together Architect 2006 for Eclipse that allows us to define transformations in this language and execute them over models defined by means of Ecore (a MOF Core implementation together). 7.3 Transformation Rules Definition To define the rules that generate the associated GUI, we only take into account the elements defined within the lanes marked as «role» in the BP definition (tasks that are performed by people). Therefore, we apply the following rules to the elements defined within these lanes: • Process Context Definition. For each lane defined in the process with its typed valued as «role» (human participant) we build a Process Context in the Navigational Map. We want to note that the roles used in the BP definition correspond to the type of users defined in the User Diagram modeled in the Navigational model. In the running example we build a Process Context called Request Book Purchase for the secretary user type (see Fig. 9). • Activity Container Definition. Each «user» and «manual» tasks within the boundaries of a «role» (human participant) Lane are transformed into Activity Containers. For instance, in the running example we include two Activity
Building Business Process Driven Web Applications
•
11
Containers within the Request Book Purchase Process Context previously built, one for the Validate Request activity and another for the Pick up Book activity (see Fig. 9). AIU Definition. o For the tasks that are defined as «user» tasks include a Main-AIU within the Activity Container. If the operation defined in the task refers to an operation modeled in the Class Diagram, then include a class view in the Main-AIU that references the class that contains the operation. If the operation defined in the task refers to an operation modeled in a Service (from the SM), then include a service view [18] in the Main-AIU that references the service that offers this operation. o For the tasks defined as «manual» tasks include a Human-AIU within the Activity Container. In Fig. 9 the Pick up Books Human-AIU has been created for the Pick_up_books activity container. Task2ActivityContainer «domain» t:Task
«domain» ac:ActivityContainer
name = n type=’user’ or ‘manual’
name = n oows
bpm C
E
pc:ProcessContext
l: Lane
when Lane2ProcessContext(l,pc) where UserTask2MainAIU(l,pc) or ManualTask2MainAIU(l,pc)
Fig. 8 QVT Transformation
As an example, and for readability reason, Fig. 8 depicts using the graphical notation of the QVT Relations language the second transformation rule presented above. This transformation rule builds activity containers for each user or manual task included within the role lanes of the BP definition. In the MOF QVT specification, transformations can be invoked for two purposes, either to check the consistency between models or to modify one model to enforce consistency. In particular, the transformation depicted in Fig. 8 has been defined to modify the OOWS model (target model) to enforce consistency with the BPMN model. The “E” label under the right limb of the relation symbol (depicted as a hexagon) specifies that the OOWS domain is enforced to be consistent with the BPMN model. The when clause specifies the conditions under which the relationship needs to hold, so the relation Task2ActivityContainer needs to hold only when the Lane2ProcessContext relation holds between the lane containing the task and the
12
Victoria Torres and Vicente Pelechano
process context containing the activity container. The where clause included in the above transformation specifies that the relations UserTask2MainAIU(l,pc) and ManualTask2MainAIU(l,pc) are going to be applied on every task within a lane. After applying the transformation rules defined above we obtain the basic navigational model required to execute the process (process contexts, their activity containers, their Main-AIUs and so on). Fig. 9 depicts the process context obtained for the secretary role. Moreover, this context also includes a set of complementary content that the web designer should add. These included elements refer to Complementary-AIUs. P «process context» Request book purchase «activity container» Validate_request «Main-AIU» Validate Requests «view» Request_book -title -authors -editorial -num_edition -year_publication -units_to_buy +resolve_request()
«Complementary-AIU» Last Purchases «view» Copy
«view» Member -name -surname
state == pending or rejected
Index Manually Generated
Complementary-AIU Manually Generated
INDEX IDX_byTitle ATTRIBUTES title, Member.name, Member.surname OPERATION validate_request() LINK ATTRIBUTE title
«view» Book -title
Purchase_date in last_month
«Complementary-AIU» Sanctioned Members «view» Member -name -surname is_sanctioned == true
Complementary-AIU Manually Generated
«activity container» Pick_up_books «Human-AIU» Pick Up Books
Fig. 9 Process Context for the Validate_request activity defined in the Request Book Purchase Process.
For the Process Context depicted in Fig. 9 we have included manually (1) an index associated to the Validate Request Main-AIU and (2) two Complementary-AIUs associated to the Validate_Request activity container. The generated user interface is depicted in Fig. 10. On the one hand, the index defined for the Validate Request Main-AIU provides an indexed access to the population of the Request_book class. This index retrieves a list (just including the data defined in the ATTRIBUTES section of the index, which are the title of the book and the name and surname of the requester) where the user can chose one item (object) from the list. This selection makes the selected object to become active in the AIU. On the other hand, the complementary-AIUs added to the activity container provide the user with two lists that gather, the sanctioned members and the last purchased books. These lists will help the secretary user to decide about the acceptance or rejection of each request. 7.4 Generated User Interface The implementation of the user interface of the web application is performed by the OOWS tool [19]. Given a Navigational Model, this tool generates the set of web
Building Business Process Driven Web Applications
13
pages that allow the user to interact with the application. Briefly, the procedure followed by the tool to obtain the implementation is the following: (1) It creates a web page for each activity container included in a Process Context. These generated web pages are dynamic and retrieve the information, which is generated by the ONME tool [14], and functionality that was defined in the corresponding AIUs. (2) When an AIU includes an index, the tool generates an additional web page that retrieves as a list the information modelled in the AIU. (See the Validate Requests section in Fig. 10). My TO-DO List – Validate Requests
Validate Requests SECRETARY CHANGE PROFILE HOME
Navigation Area
Link to the TO-DO List
Department Directory Teaching Research Intranet Intranet Links Intranet My TO-DO List Digital Library Department Library Material Purchases News Management
Applicant Member Juan García Pérez María Sánchez Ortiz María Sánchez Ortiz
Title
Validate
Reject
Software Engineering Software Engineering Web Ontologies
Navigated Path Area
Main-AIU Presented as an INDEX
Done
Complementary Data Sanctioned Members María Sánchez Ortiz Raúl Pérez Sanz Pedro Solaz Bueno Joaquín Bermúdez Gracia Rosa López Reina Juan A. Moreno Marques
Complementary AIU
Last Purchases Software Engineering Programming Java Programming Web Services in .NET Algorithms Quality on Software Engineering Datawarehouse and XML
Information Area Complementary AIU
Fig. 10 Web page generated for the Validate Requests Activity
The set of web pages generated are made up of two different areas (see Figure 8), which are the information and the navigation area. On the one hand, the information area is where the contents (lists, forms and so on) are shown to the user. In particular, Fig. 10 includes the Validate activity container shown in Fig. 9. This activity container includes a Main-AIU (Validate Requests) and two Complementary-AIUs (Sanctioned members and Last Purchases). On the other hand, the navigation area is what allows the user to navigate through the web application. Moreover, the navigation area includes a new link where the user can access his/her TO-DO list. This list includes the activities that the logged user has pending to complete. This list is obtained by querying the workflow engine the state of the started process for a specific user.
8 Model-to-Text Transformations. From BPMN to WS-BPEL This section is organized in two subsections. On the one hand, first subsection provides a brief overview about the language used to perform model-to-text transformations as well as the reasons that led us to take this decision. On the other hand, second subsection outlines the strategy followed to obtain the equivalent WSBPEL process definition.
14
Victoria Torres and Vicente Pelechano
8.1 Model-to-Text Transformation Language/Tool Support There are different alternatives to perform model-to-text transformations. Among the most well know techniques we find (1) XSLT [21], (2) Template Languages (as JET, Velocity [20] or FreeMarker [8]) or (3) MOFScript [12]. The MOFScript language is currently a candidate in the OMG RFP process on MOF Model to Text Transformation (http://www.omg.org/docs/ad/05-11-03.pdf). To achieve this kind of transformation we have chosen the MOFScript model-to-text transformation language because (1) it is a language specifically designed for the transformation of models into text files, (2) it deals directly with metamodel descriptions, (3) its transformations can be directly executed in a tool (in particular within the Eclipse environment) and (4) it provides a file constructor for the creation of the target text file. The tool that we have used to implement the transformations is the MOFScript tool included within the Generative Model Transformer (GMT) project of Eclipse. 8.2 Obtaining Executable BP Descriptions Model-to-text transformations have been organized in several modules. For instance, for each generated file (WSDL files and WS-BPEL) we have defined a specific transformation. The generated WSDL files define the interfaces of the functionality implemented within the boundaries of our system (defined in the CD) and that takes part in the process. On the other hand, the executable WS-BPEL description of the BP is obtained after applying the BPMN to WS-BPEL mappings outlined in [5]. Regarding the Web Services that take part in the process, we have organized them in three groups which are (1) services whose operations are implemented in our system, (2) services whose operations are provided by external partners and (3) services that simulate manual (non automated) activities. The reason why we build this third kind of service is that WS-BPEL does not provide support to human participation interaction. In fact, every participant included in the process must be a service. Therefore, we had to find a way in which human tasks could be “simulated” in order to generate executable definitions of the process. We need to define executable business processes that include activities that range from services provided via web services to activities that are not automated and that are performed by people. In order to do this, we propose to build a module (called the Task Manager) in charge of managing the Web services that simulate the interaction between the process and the people involved in it. Among the responsibilities of this module we distinguish the two following: Collect the messages produced by service invocations launched by the process engine. These services refer to user and manual tasks defined in the process; this is, to tasks that involve participation with users. Listen to the requests received by the application layer and returning, given a user in particular and his/her role, the list with his/her pending tasks as well as the contexts that allow performing these tasks.
Building Business Process Driven Web Applications Process Flow Activity1
...
Local Activity2 System (Web Service) Activityn
External Partner1
External Partner2
...
Activity1 Activity2
...
Task Manager
15
Activityn
External Partnern
Fig. 11 Web Service Interaction schema
We want to note that all the services exposed by the Task Manager should be defined as asynchronous. This is because the process has to wait until the person in charge of doing this task notifies the process that the activity has been completely finished. This notification is performed by means of the corresponding user interface. As a result, once this notification is done, it is the Task Manager module that gathers and returns to the process the results of the activity. On the other hand, to define the interaction between the local system and the process, we have also defined a web service (Local System Web Service, see Fig. 11) whose operations refer to the activities that are implemented by the operations defined in our system. The schema that has been designed to build the interaction between the participating actors is depicted in Fig. 11. In this figure we also can see that the interaction with external partners is performed via Web services. The definition of these Web services was imported to the SM at the modelling level.
9 Conclusions and Further Work In this work we have presented, based on a model transformation approach, a solution to generate Web Applications whose specification is highly tied to a BP description. In order to cover properly all kind of Web Applications, Web Engineering Methods should consider supporting BPs in an appropriate way, where not only automated participants are considered (in the form of Web Services) but also human participants. For this reason, we have tuned the OOWS approach in order to accept this kind of specifications and generate the appropriate Web solution. For this purpose, we have defined a set of transformations, Model-to-Model and Model-to-Text depending on the origin and target artifacts that take part in the transformation. In particular, to obtain the WS-BPEL definition of the process we had to decide how to perform this transformation, as a model-to-model or model-to-text transformation. In the end, we opted for the model-to-text transformation because this approach allows us to develop, in a very short time, the BPMN to WS-BPEL generator. This speediness is due mainly to the fact that it is not necessary to realize the construction of the WS-BPEL metamodel. As further work we have planned to integrate the solution presented in this work within the ONME tool [14]. This tool provides a conceptual modeling-based
16
Victoria Torres and Vicente Pelechano
environment where the model becomes the program, and the code generation process is fully automated following a MDA based approach. Moreover, we want to study the presentation patterns associated with the new primitives introduced to the Navigational model. In fact, the Presentation Model is strongly based on the navigational model and uses its navigational contexts to define the presentation properties.
References 1. Atlas Transformation Language (ATL). http://www.sciences.univ-nantes.fr/lina/atl/ 2. A Joint White Paper by IBM and SAP: WS-BPEL Extension for People – BPEL4People. July 2005 3. Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T., Johannesson, P.: A Declarative Foundation of Process Models. CAiSE 2005: 233-247 4. Business Process Execution Language for Web Services Specification, version 1.1 dated May 5, 2003 5. Business Process Modeling Notation (BPMN) Version 1.0 - May 3, 2004 6. De Troyer, O., Casteleyn, S.: Modeling Complex Processes for Web Applications using WSDM, In Proceedings of the Third International Workshop on Web-Oriented Software Technologies, IWWOST2003 7. Fons, J, Pelechano, V., Albert, M., Pastor, O.: Development of Web Applications from Web Enhanced Conceptual Schemas. In Workshop on Conceptual Modeling and the Web, ER'03, volume 2813 of Lecture Notes in Computer Science. Springer, 2003. 8. Freemarker. http://freemarker.sourceforge.net/ 9. Manolescu, I., Brambilla, M., Ceri, S., Comai, S., & Fraternali, P. (2005). Model-driven design and deployment of service-enabled web applications. ACM Trans. Inter. Tech. 5, 3, 439-479. 10. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification. Final Adopted Specification ptc/05-11-01. 11. Model Transformation Framework (http://www.alphaworks.ibm.com/tech/mtf) 12. MOFScript. http://www.eclipse.org/gmt/mofscript/ 13. N. Koch, A. Kraus, C. Cachero and S. Meliá, “Integration of Business Processes in Web Application Models”. Journal of Web Engineering. Vol. 3, No. 1 (2004) 14. OlivaNova Model Execution System. CARE Technologies (www.care-t.com). 15. Pastor, O., Gomez, J., Insfran, E., Pelechano, V. The OO-Method Approach for Information Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems 26, pp 507–534 (2001) 16. Schmid, H. A., Rossi, G.: Modeling and Designing Processes in E-Commerce Applications. IEEE Internet Computing 8(1): 19-27 (2004) 17. The Attributed Graph Grammar System v1.2.4. http://tfs.cs.tu-berlin.de/agg/. 2004 18. Torres, V., Pelechano, V., Ruiz, M., Valderas, P.: A Model Driven Approach for the Integration of External Functionality in Web Applications. The Travel Agency System. MDWE 2005. 19. Valderas, P., Fons, J., Pelechano, V: Transforming Web Requirements into Navigational Models: AN MDA Based Approach. ER 2005: 320-336 20. Velocity. http://jakarta.apache.org/velocity/ 21. XSL Transformations (XSLT) Version 1.0. http://www.w3.org/TR/xslt
