Accepted at 4th International Conference on Information Technology, Gopalpur-on-sea, India, December 20-23, 2001
1
Model Based Web Applications Rakesh Agarwal, Giorgio Bruno, Marco Torchiano, Member, IEEE CS
Abstract-- The rapid evolution of the environment in which information systems are required to operate originated a new kind of systems: they are networked and process-driven applications. There is no well-defined widely accepted approach to such system. A model-based methodology is proposed for the development of this category of applications. Index Terms-- OOA, Operational Models, Enterprise Models, Workflow. I.
INTRODUCTION
T
HE recent evolution of enterprise information systems has been driven mainly by the rapid growth of the Internet. Such evolution can be seen in two main trends: • the adoption of the web-based paradigm; • the diffusion of process-driven systems. The mental model behind the web-based approach is very simple and successful therefore it has become the preferred paradigm to access every kind of system. Such trend poses several problem of integration between old legacy systems and such new presentation technology. Many solutions have been proposed to ease such integration, in particular the adoption of object-oriented technologies [6]. The success of e-commerce requires a complex interaction with information systems. In many cases the interaction patterns between the users and the system can be modeled to facilitate their modification and the maintenance of the information system. A new kind of applications has originated: the process-driven systems [7]. Such systems require a supporting workflow system, which can possibly interact with peer system on the Internet [8]. When considering those two main trends together a webapplication development approach that addresses the category of applications that we call process driven is required. Such approach is provided by the OPJ (OPerational Objecs) methodology, which is a generic object-oriented modeling methodology. The proposed approach is aimed at the development of model based prototypes and applications. The model-based paradigm uses models, not only during the design phase of the system life cycle, but also as the core component of the final system. The result are flexible and integrated applications. In a fairly complex web-based system a lot of architectural R. Agarwal is with Infosys Technologies Ltd., Near Planetarium, N.H.5, Bhubaneswar - 751013, India (e-mail:
[email protected]) G. Bruno is with Dip. Automatica e Informatica, Politecnico di Torino, C.so Duca degli Abuzzi, 24, I-10129 Torino, Italy (e-mail:
[email protected]) M. Torchiano is with Department of Computer and Information Science – NTNU, Sem Sælands vei 7-9, N-7491 Trondheim, Norway, (e-mail:
[email protected]).
components have to be settled in an appropriate framework. A model can be used as a unifying framework in which each architectural component can find its place. It is generally agreed that wherever possible, the adoption of model-based development enhances the maintainability and correctness of the system guaranteeing an automatic coherence between the model and the running system. In this paper we will present a model-based approach for building web-based information systems. The proposed approach permits the integration of different features of a complex information system thus providing a solution to the most common problems in the development of enterprise information systems. We begin presenting the OPJ model based approach, then we investigate the process-driven category of systems and present a sample model of such a system, finally we present the architecture of applications built using our approach. II. THE MODEL BASED APPROACH This paper will describe a specific methodology called OPJ. OPJ is an operational object-oriented methodology to develop model-based applications. OPJ is made up of two different parts: the OPJ modeling methodology and the OPJ supporting environment. The latter defines a set of features required to support the former. A. The OPJ methodology OPJ enriches common object-oriented models with a precise operational semantics. An operational model contains a possibly abstract description of the system, like any model, and in addition an operational part which serves as a set of constraints in the following phases of the modeling life cycle. An operational model can serve as the basis for a derived model, which is based upon and constrained by the original one. To make this possible, an operational model can define both what operations can be performed to build a derived model and what operations the derived model can perform. Building upon these fundamental capabilities of the operational models, the OPJ methodology it characterized by three main phases: • domain modeling, • system modeling, • model operation. Domain modeling aims at providing a collection of classes of building blocks intended to address all the potential systems belonging to the domain of interest. It abstracts the general properties from the actual problems under study and defines a common approach for a whole family of similar problems. The
Accepted at 4th International Conference on Information Technology, Gopalpur-on-sea, India, December 20-23, 2001 process of defining classes and relationships in object-oriented analysis is an example of domain modeling. System modeling applies the results of the previous phase, in that its purpose is to build the model of an actual system by means of a composition of building blocks. These phases can be performed by different roles. Therefore a modeling expert could analyze the problem together with problem experts and build a sort of modeling vocabulary, which will be used by problem experts to model an actual system. The OPJ methodology describes a system by means of two modeling artifacts: schemas and system models. A schema is a collection of class diagrams that describe the domain model of the system. It is based on the object-oriented paradigm and it is the evolution of a previous work by the authors, which included a graphical notation and its supporting tool. Both for historical reasons and the availability of a customizable tools that custom graphical notation is used to describe class diagrams, anyway it could be replaced by any enough powerful notation such as UML [5]. Thus the modeling phase of the methodology is quite equivalent to what can be carried on using the UML approach. A system model is a collection of diagrams and associated information that describe a real system. While a schema describes the common characteristics of a family of systems a system model describe a well-defined system. The final phase in the life cycle is model operation; this is a quite generic term that can assume different meanings depending on the kind of the model. In its simplest meaning, model operation consists in the use of a system model as documentation. For a business process it could mean enactment, for a software system it means both prototyping and application deployment and execution. Most object-oriented methodologies are class-centered: in fact they are structured around class-relationship diagrams. Different kinds of models are instance models: they are made up of objects. In widespread object-oriented modeling methodologies [5] instance models are used only to show examples of data structures or to describe the behavior in particular scenarios. OPJ, instead, makes a large use of instance models to describe systems in their details. B. OPJ Environment The OPJ methodology is based upon an integrated modeling environment, which supports all phases of the life cycle, as shown in Fig. 1. A generic domain-modeling tool, as an example a UML compliant CASE tool, can be used to develop a domain model. Such a model can be used to customize a suitable systemmodeling tool in order to offer a friendly modeling environment, which enables the construction of a system model. Once the system model have been developed it can serve as it is as documentation. In addition, if a suitable supporting architecture is provided, the system model can be the basis for a model-based system allowing both prototyping and execution of a full-fledged application.
2
Domain Model Operation Supporting Architecture
Domain Modeler
Execution Prototyping
Customizable Modeling Environment
Documentation System Model
Fig. 1. The OPJ environment.
The modeling environment is based on an object-oriented interface to the models: an object model [6]. The OPJ Object-Model provides the following advantages: • an integrated view of the models during all phases of the OPJ life cycle, • a simplified navigation through the models • a uniform view of both models and application data Models in an enterprise environment play a twofold role: on one side they can be used an analysis and management tool, on the other they represent the main design artifact used to develop software supporting the modeled features. The former use has been widely adopted by consulting firms, in order to conduct Business Process Reengineering activities and Quality Assurance projects. Recently such kind of models has been adopted by information technology expert as a powerful tool to perform ERP customization. Pushing the idea behind ERP customization to the limit gives model-based applications. In a fairly complex web-based system a lot of architectural components have to be settled in the appropriate framework. A model can be used as a unifying framework in which each architectural component can find its place. A model based application uses a model as a sort of very high level programming language, which is used to describe both the internal structure of the software system and the conceptual model that is presented to the user. The main advantages of using a model-based application are: • a model can be understood and created also by nonexperts, • to change the software system, only the model needs to be modified, • the model is always an up-to-date representation of the actual running system. III. PROCESS DRIVEN SYSTEMS The OPJ model based application development can be, successfully applied to a category of information systems that we call process driven. Virtual corporations and e-commerce are real and emphasized trends, the current economy is becoming more and more networked and process-driven [7]. Most efforts in information systems have been devoted, so far, to data. Recent trends change that data-oriented approach
Accepted at 4th International Conference on Information Technology, Gopalpur-on-sea, India, December 20-23, 2001 into a service oriented approach. Under such a new perspective operations performed on data become complex and can be described in terms of processes. Processes can be enacted by means of Workflow systems. Workflows are a key technology for such emerging category of process driven systems, in fact they are recently regaining interest from most IT operators [8]. The application of the OPJ methodology to the design and development of process driven systems can be divide into three phases: • define a modeling approach to describe such category of systems, that is define the domain model, the approach adopted in this paper is called PEIS and is described in section A; • model a specific system or part thereof, that is build a system model, an example is briefly described in section IV; • define an application architecture based on the OPJ environment, that is provide the technological details to perform the model operation, such details are described in section V. A. Processes and data The main problem in today’s information systems is the integration of the different features they need to manage. Conventional information systems (ERPs) had a strong focus on data, while processes have been added in a successive phase, resulting in a lack of flexibility. A last trend in ERP systems is to add a degree of freedom, usually by means of scripting languages. Unfortunately, their essentially monolithic structure represents a hurdle in the direction of the integration with workflow systems, requiring a heavy reengineering process. A different generation of enterprise information systems must be developed which treat processes an data in a more integrate way [2][3]. The authors proposed Process Enabled Information Systems (PEIS) [1] approach as one possible solution. Such kind of system may very well be developed using the operational model based approach represented by the OPJ methodology. The key concepts of PEIS are processes and business objects: a business-object is an aggregated data that can be manipulated by the information system. a process describes the life cycle of a business object The proposed approach integrates various aspects of an enterprise information system as shown in the simplified schema shown in Fig. 2. This is the domain model developed according to the OPJ methodology. The Process class represents business processes described by means of activities (Activity); a business process is linked to the BusinessObject class through the relationships Produces, meaning that a business object is produced as described by the process.
Process
3
BusinessObject Produces
PartOf
CanStart
Activity
WFRole
CanBePerformedBy
Login
Plays
Fig. 2. Simplified domain model for PEIS.
Process and business objects can serve for simple documentation purposes but they are effectively useful when they can form the basis for a model based information system. Thus the interaction with users, represented by class Login, is required. User capabilities are defined by the roles (WFRole) they play: a role can start a given set of processes and can be required to perform certain activities. IV. AN EXAMPLE We will present an example to explain how our approach works. The example is related to the automation of the procurement process in a medium sized enterprise. The steps required to purchase goods in a large enterprise can be very complex; many information are required to fulfill this task: the relative business objects are shown in Fig. 3. PurchaseRequisition Collects
RelatedTo SupplierDelivery
PurchaseOrder
Supplier
To
InReplyTo SupplierInvoice
Fig. 3. Purchasing business objects.
Usually an employee that needs some kind of goods has to fill-in a formal purchase requisition; periodically a purchase order can be produced, which collects a group or requisitions. Each business object has got its own life cycle, described by means of a process. The relationships among business objects are reflected into interactions among the related processes, as shown in Fig. 4. The PurchaseRequisition process describes the interaction of the employee with the homonymous business object. The PurchaseOrder process collects a number of requisitions and manages the interactions with the supplier with the help of a pair of other processes: SupplierInvoice and SupplierDelivery. When the supplier deliveries the requested goods the SupplierDelivery process notifies the PurchaseOrder process which on its turn dispatches the notification to each awaiting PurchaseRequisition process, which ask the employees to accept the goods. The PurchaseOrder process collects all the acceptances in order to accept the whole delivery.
Accepted at 4th International Conference on Information Technology, Gopalpur-on-sea, India, December 20-23, 2001
Purchase Requisition
parallel and autonomous paths are activated. The leftmost one manages the supplier invoices while the rightmost one handles the goods. Whenever an input event (InvoiceEntered) notifies the arrival of an invoice, a formal reception of the invoice is required (ReceiveInvoice) then the notification can be forwarded, by means of an output event (InvoiceReceived), to all related PurchaseRequisition processes, whose replies will be received through an input event (PaymentConfirmed) and collected (CollectConfirmations). A similar procedure is described in the other path, the rightmost one in Fig. 5, to deal with the goods.
GoodsAccepted
GoodsReceived SupplierInvoice InvoiceReceived
InvoiceEntered
PaymentConfirmed
PurchaseOrder
PaymentPrepared
GoodsChecked SupplierDelivery
Fig. 4. Procurement processes.
In a similar manner are handled the supplier invoices; they are received by the SupplierInvoice process which notifies the PurchaseOrder process, which dispatch the details to all the awaiting PurchaseRequisition processes, which on their turn require the employees to confirm the payment. The PurchaseOrder process collects all confirmations, then prepares the payment and forwards it to the SupplierInvoice process, which is in charge of performing the payment. The PurchaseOrder, shown in Fig. 5 describes the construction of a purchase order. When the process is started, the first activity, which is automatically carried out by the system, is the collection of similar requests that can be gathered together in a single purchase order. Then human intervention is needed to select the appropriate supplier, the resulting purchase order can then be sent to the supplier, as an example by means of some business-to-business electronic commerce system. After the order has been sent two Start
CollectRequests P
V. SYSTEM ARCHITECTURE After a brief overview of the conventional approach with the analysis of its main drawbacks the architecture for a modelbased system is presented. The proposed architecture is divided into two parts: back-end architecture and presentation related one. A. Conventional approach The conventional approach to a process driven system makes use of technologies and methodologies, which were not designed to interact with the web. The most common approach is to develop a web portal [7], which integrates the different features of the information system. The common overall architecture is depicted in Fig. 6. In a typical configuration, it is possible to identify three main back-end modules: the information system, the enterprise database and the workflow engine. These modules, in order to
SelectSupplier
P P
InvoiceEntered
GoodsChecked GoodsChecked
SendOrder
T
T P
InvoiceReceived
ReceiveInvoice
G
GoodsReceived
B1
P
ReceiveGoods P
GoodsReceived
G
P PaymentConfirmed
P CollectAcceptances
CollectConfirmations
T
T
J1 P
P P
End
PreparePayment P
4
G Fig. 5. Purchase order process.
PaymentPrepared
GoodsAccepted GoodsAccepted
Accepted at 4th International Conference on Information Technology, Gopalpur-on-sea, India, December 20-23, 2001 implement a web-centric approach, can be interfaced and integrated by a usually large set of server-side scripts. The workflow engine is basically what [4] calls a workflow enactment service. It should present a workflow interoperability interface, using one of the standards promoted by the WfMC, which enable e-business [8]. The information system is often a legacy system, which is made up of various, possibly very different, modules. In such a scenario the server-side scripts can play an integration role in cooperation with more specific Enterprise Application Integration (EAI) software. Such integration role of server-side scripts is very important; in particular considering that 40% of IT financial resources are devoted to system, application and data integration [7]. The presentation of both workflow work-lists and business data is the other major responsibility of the scripts. This structure allows a useful separation of concerns between data and presentation. The various parts of the back-end architecture described so far, usually have been designed in different phases, therefore each one is described by means of a different model.
Web Server
WF Engine
Information System
5
Aside the model, the system handles much operational information, which is stored in a set of operational databases. In order to make a model based system work it is necessary to decide what features of the system need to be modeled. A widely accepted approach [1] [2] is to subdivide an enterprise in different views, usually three: process view, organization view, and information view. In the case of a process driven system, the model encompasses the processes enacted by the workflow system, the business objects managed by the information system and the organization which people performing activities belong to. The model is stored in a model repository which can be accessed be the run-time system and modified by means of appropriate modeling tools. A schematic description of the process-drive system’s model is show in Fig. 7. The model repository hosts three integrated models that describe the workflow’s processes, the information system structure and the organization that interacts with the system. The workflow engine takes the process definitions [6] from the model repository and enacts them storing the run-time information in a custom database; in addition it interacts with the organization model (People).
Server-side scripts
Wf Engine Software modules
Model repository
Information System
feeds Processes
Database
describes
Data
describes
People Process Definitions
Business Model
Data Model
Models
WfRT
IS describes
Fig. 6. Conventional architecture.
The architecture of conventional applications which implement process-driven systems present several drawbacks: • there is no organization model, the organizational information is usually managed partly by the information system and partly by the workflow engine; • software modules are described by different and separate models, possibly developed with different paradigms, thus a single integrate view of the system is not available; • there is no model of the presentation: presentation issues are scattered through many scripts; • there is no widely accepted methodology to develop such kind of systems; • the maintenance of such system is very difficult due to the lack of an integrated vision of all the components. B. Back-end The model based approach results in a system, which operates according to the information contained in a model. During system operation, the model contains read-only information, which drive the behavior of the system itself.
Organization
Fig. 7. The coverage of models in an enterprise environment.
By means of OPJ methodology two different systems can be devised from a suitable model: • a prototypal system that works in a local environment (single machine). • a distributed application based on web protocols Both kind of system are based upon the same back-end architecture shown in Fig. 8. The OPJ Object Model performs the integration of the different data of the information system. It allows a uniform access to data stored in different places using different schemas.
Accepted at 4th International Conference on Information Technology, Gopalpur-on-sea, India, December 20-23, 2001 Wf Server
Organization Objects
maintain • the details of the presentation are integrated with the models of the rest of the system • permissions and visibility issues can be easily described in the model • any change to the model can be immediately reflected to the final system
Business Server
Process Model Objects
Wf Objects
Business Objects
OPJ Object Model
Model Repository
VI. CONCLUSIONS
Information System
WfRT
Fig. 8. Back-end architecture.
C. Presentation The presentation part of the proposed approach differs in two main points from the conventional approach: • a uniform user interface has been adopted for both prototypes and final applications; • presentation details are described in a unique model. The standard approach is to develop a set of server side scripts for each information entity, for example a purchase requisition or a workflow activity. These scripts are responsible for managing the presentation of related entity. The proposed approach makes use of suitable software module, which interprets the presentation model and manages every kind of entity. To support such an approach two different architectures have been devised, one for the full web-based application and one for the prototype. The presentation related application architecture is depicted in Fig. 9.
Web Server
6
The rapid evolution of the environment in which information systems are required to operate originated a new kind of systems. The rapid growth of the Internet requires a networked systems, web based application are a solution to such requirement but they need more complex interaction patterns. The new generation of web based system will be processdriven: the interaction between the enterprise information system and the users, both customers and business partners, has to be described by processes that can be enacted by workflow systems. The conventional approach integrates information systems, the web and workflow systems by means of scripts has several drawbacks. The operational model based approach provides a unified and integrated view of the enterprise system, solving many problems encountered with the conventional approach. The domain-modeling phase can be based on widespread methodologies such as UML, the model produced during this phase can be used to model a real system and use it as a basis to build a model based prototype or application. Finally, the adoption of browser based user interface enables seamless transition from the prototype to the final application. REFERENCES
Model repository Presentation Model
[1]
CGI protocol [2]
Visual Support Module [3] Wf Server
Business Server
Fig. 9. Web-based Application Presentation Architecture
Instead of using a large set of served side script, implemented either by ASP or by JSP technologies, a reduced number of scripts are used to make the web server interact with the Visual Support Module. Such module is in charge of interacting with the Workflow and Business servers and presenting the information according to a presentation model stored in the Model Repository. Thus the effective content is produced by the Visual Support Module and then passed to the web server. The main advantages of such an approach are: • there aren’t a lot of scripts which are difficult to
[4] [5] [6] [7] [8]
G. Bruno, M. Torchiano “Process Enabled Information Systems” in Proc. of 2nd International Conference on Enterprise Information Systems (ICEIS2000), Stafford, UK, July 5-7, 2000. G. Bruno, M. Torchiano “Making CIMOSA Operational: the experience with the PrimeObjects Tool” Computers in Industry 40(2-3), pages 279291, Elsevier Science, November 1999. R. Agarwal, G. Bruno and M. Torchiano. An Operational Approach to the Design of Workflow Systems. Information and Software Technology 42(8), pages 547-555, Elsevier Science, May 2000. Workflow Management Coalition, “The Workflow Reference Model”. WfMC- TC-1003, Version 1.1, Jan 1995. OMG, “Unified Modeling Language Specification”, Version 1.3, 1999. F. Manola “Technologies for a Web Object Model”, IEEE Internet Computing, 3(1), January-February, 1999. A.P. Sheth, W. van der Aalst, I.B. Arpinar, “Processes Driving the Networked Economy”, IEEE Concurrency, 7(3), July-September, 1999. J.G. Hayes, E. Peyrovian, S. Sarin, M. Schmidt, K.D. Swenson, R.Weber, “Workflow Interoperability Standards for the Internet”. IEEE Internet Computing, 4(2), May-June, 2000.
