{Diplomarbeit} Diplomarbeit im Fach Informatik. vorgelegt von. {Ninh Nguyen Duy} angefertigt am

Transcription

1 {Diplomarbeit} Diplomarbeit im Fach Informatik vorgelegt von {Ninh Nguyen Duy} geb. { } in {Hanoi-Vietnam} angefertigt am Institut für Informatik Lehrstuhl für Informatik 2 Programmiersysteme Friedrich-Alexander-Universität Erlangen Nürnberg (Prof. Dr. M. Philippsen) Betreuer {Prof. Dr. M. Philippsen - Universität Erlangen Nürnberg} {Josef Adersberger - Universität Erlangen Nürnberg} {Wolfgang Frank - itemis GmbH} Beginn der Arbeit: { } Abgabe der Arbeit: { }

2 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der Diplomarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt. Erlangen, den { } {Ninh Nguyen Duy}

3 Diplomarbeit Thema: Das Architekturparadigma der serviceorientierten Architektur (SOA) basiert auf der Idee einer direkten Abbildung von Geschäftsprozessen auf IT-Systeme. Um die Eigenschaften dieser Abbildung besser untersuchen zu können, soll im Rahmen einer Diplomarbeit ein modellbasierter Ansatz entwickelt werden, der es ermöglicht, aus fachlichen Prozessbeschreibungen (Geschäftsprozessmodellen) einen umfassenden Anwendungsrahmen zu generieren. Dabei soll die bidirektionale Verfolgbarkeit zwischen Geschäftsprozessmodell und Elemente des Anwendungsrahmens möglich sein. Um die Generierung des Anwendungsrahmens zu vereinfachen, wird das Geschäftsprozessmodell dabei zunächst in ein Zwischenmodell transformiert, das aus der Untermenge an Modellierungskonstrukten des Geschäftsprozessmodells besteht, die direkt über gängige SOA Frameworks abbildbar ist. i

4

5 Abstract The emergence of new technology trends offers new capabilities to business management and the vision of seamless industry orchestration between disparate companies based on turnkey business process integration. Business executives and information technology executives within your company can leverage emerging capabilities to become a participant and innovator within the Business Web - a worldwide network of interconnected business services. Your business managers will have much greater control in the design and deployment of new online business services. For your IT managers, their success is measured by how seamlessly IT systems support your company s new service offerings. In this thesis a prototype is developed to demonstrate the integration of emerging technology trends considered as key technologies in the near future for business process management such as workflow technology, Service Oriented Architecture(SOA) and Model Driven Software Development. Business analysts can model their business process with various business process modeling languages or business process modeling notation, this business process model is then transformed to an intermediate model allowing software developers to enhance the model. With regards to SOA the intermediate model is designed so that developers can not only technically extend the model but also model web applications participating in the business process and its interactions with each other through web services provided by the participating web applications. Based on the extended intermediate model the business process is mapped to the IT-system, that means, a web application with an embedded workflow engine, an executable business process model, which will be deployed on the embedded workflow engine, and all other participating web applications are generated from the intermediate model. iii

6

7 Contents Contents 1 1 Chapter Background Workflow and BPM The Gap between Business and IT World Agility in the Face of Change The Business Value of Workflow SOA and BPM SOA and BPM together BPM and SOA need each other MDA Approach Recommendation MDSD and MDA Summary Chapter Workflow Technology Business Process Modeling Graph Oriented Programming Workflow Engine Chapter Case Study The Intermediate Model The Need of Intermediate Model The Metamodel of The Intermediate Model Transformations Traceability LOC Metric Conclusions

8 CONTENTS List of Figures 59 List of Tables 61 List of Acronyms 63 Bibliography 65 2

9 1 Chapter Background Today s market requirements are changing rapidly, new kinds of products have to come faster to the market with better quality and lower costs, products are required to be more flexible, more efficient but there is no universal integrating platform or paradigm, IT culture is slow to respond to change. The results are strain business-it relationship, poor integration and no reuse, not well-coordinated portfolios. New technology trends give us the hope that all of these problems will be resolved and the vision of seamless industry orchestration between disparate companies will be realized. Business Process Management(BPM) with Service Oriented Architecture(SOA) gives companies the flexibility and efficiency they need to thrive in a competitive market. SOA enables a standard, service-based integration approach to any and all applications and data sources. These discrete services are then dynamically packaged, modeled, combined, and resold through Business Service Providers. A Model Driven Architecture(MDA) approach helps your company to improve timeto-market and to reduce solutions lifecycle costs, which are the two most important competitive factors, furthermore, with Model Driven Software Development(MDSD) one can benefit from significantly improved solutions quality, improved overall business-it alignment and end-to-end traceability (requirements to deployment). Business process automation and workflow technologies are gaining importance for their ability to improve productivity, automate repetitive tasks, reduce human intervention wherever possible, assemble software services into end-to-end process flows, bridge the gap between the business and IT world and enable businesses be more agile. In the following sections we will see the key concepts of workflow technologies, SOA, MDA and their advantages of applying for BPM. 1.2 Workflow and BPM Workflow allows for a better alignment of IT with business because it allows the enterprise applications to be expressed in a way that makes sense to business users. We will also see that it helps businesses be more agile by allowing business people control of the 3

10 1 Chapter 1 business aspects of applications, while IT people retain control of the applications more technical aspects. If you ask 10 different vendors to define BPM or BPM suites, and you will likely get 10 variations of the definition, even though all vendors use the same basic terminology to explain it, therefore we should start first with a definition of a few basic terms to make sure that we are talking about the same things. Business Process: A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. Workflow: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. Process Definition: The representation of a business process in a form which supports automated manipulation, such as modeling or enactment by a workflow management system. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. Business Process Management(BPM): The practice of developing, running, performance measuring, and simulating Business Processes to effect the continued improvement of those processes. BPM is concerned with the lifecycle of the Process Definition. As office work has been traditionally supported through the use of paper documents and folders passed from function to function, many of the early workflow products focused on routing documents through a group of people. More recent systems offer not only documents, but structured information handling, complex event processing and the ability to exchange information with web services and other external information sources. These newer capabilities allow the workflow systems to integrate into the modern IT infrastructure. At the same time, the workflow systems have not forgotten the human aspect, which give workflow a unique capability to bridge the gap between the business world and the IT world.[14][13] The Gap between Business and IT World The first audience we call business users. These are the people in an organization who are doing the work that directly accomplishes the goals of the organization. The CEO, CFO and line of business manager are people, who is interested in how well their organization is running and might be interested in optimizing the way that people work. We now talk more about the Business Analyst role. People in this role specialize in the organization of tasks into processes. The Business Analyst is not normally technical but 4

11 1.2 Workflow and BPM Figure 1.1: The gap between business and IT world instead someone who understands the business and the goals of the business, as well as how to accomplish those goals with a team of people. The second audience we call Information Technology professionals. This side of the business is responsible for providing the information systems. Sometimes this means developing custom applications for the enterprise and in other cases it includes only installation and management of package applications. The reason for considering these as two distinct groups (see figure 1.1) is because they often look at the same problem with different goals and desires. The business side is concerned with business goals which are both manual and automatable, while the IT side is concerned with only those goals that can be translated into tested, reliable and secure systems. While the IT side is organized around system structure and values 7x24 operation and scalability issues, the business side is organized around social structures with the complexities of working hours, vacation schedules, skills training and changing positions. The purpose of workflow is to allow for the coordination of human work during the running of a process, but there is another key aspect of workflow which is critical to bridging the business IT gap (see figure 1.2). The business processes themselves must 5

12 1 Chapter 1 be able to be designed and modified by business people. Here are some comments that reflect this: The ultimate goal of workflow is to place in the hands of business professionals the ability to modify their processes, with no involvement from the IT organization. Michael Melenovsky, Gartner BPM Summit, process changes are made by business professionals who need only limited knowledge of IT systems. In a growing number of cases, changes such as work item routing, business rule overrides, and parametric changes to approval levels, are made in real time to executing process. Janelle Hill, Gartner BPM Summit, 2006 What these industry experts are saying is not that we want business people playing with the guts of the application developed along the lines of traditional programming but rather that applications must be structured in a specific way that isolates the business process from the programming logic. The more technical aspects of the application need to be wrapped up into reusable chunks. Those chunks need to be robust and not sensitive to erroneous input. They need to be more like plugging a power adapter into your cell phone and less like soldering a printed circuit board. The business processes need to be abstracted out of the application, and represented as a structure separate from the more technical aspects. The business process is simply used to sequence the chunks into an integrated whole in a way that is safe for a non-programer to edit.[13] Business side retains control of: Assignment of responsibility because this depends strongly on who is in the organization. Groups, Roles, and Skills because these change on a monthly, weekly or even daily basis Deadlines, Alerts, Reminders, and Escalations because they depend on the culture of the organizational unit Order of tasks and addition of new manual tasks because this is critical for agility to be able to respond to market and legislative changes. User Interface because this is effected by the level of training or experience of a particular organization IT retains control of: 6

13 1.2 Workflow and BPM Figure 1.2: The bridge between business and IT Computational logic and data representations because there is little or no dependency upon the culture of the organizations Scalability and performance because this requires significant specialized expertise in the working of information systems Interoperability because this requires extensive knowledge of the operating infrastructure Master data management because this is constrained by highly specialized requirements 7

14 1 Chapter 1 Figure 1.3: Processing a bank loan Agility in the Face of Change Both business and IT users need agility, the ability to respond to change. The following example application for processing bank loans shows how the application might be structured to enable rapid change of some aspects of the application without breaking it. Imagine that people come to the bank and fill out an application which is subsequently scanned and converted to text data and this is the event that starts the process. In this case the business analyst determines that two people need to be involved. First, a person needs to review the input data for completeness and as a check of the character recognition. Once that has been done, a bank manager needs to make a decision on whether to grant the loan or not. 8

15 1.2 Workflow and BPM This example is simplified so it can be discussed in this article, but it is important to note that the business analyst is dealing only with jobs that must be performed by humans within the organization. There is an implicit assumption that there will be a bunch of data processing associated with the process but that is not a concern at this level. For example, a bank will clearly want to perform a background check on the applicant, but that is not a human activity. Since that can be completely automated, there is no reason to have a person in your office who performs background checks. Instead, it is assumed that somewhere between the first and second human activity, a call will be made to retrieve information about the background of the applicant, and the bank manager has the results of that available in order to make the decision of whether to loan the money or not. At this point, the business analyst is concerned only with the activities that will be done by office workers. The diagram 1.3 is a conglomerate of notations. The circles, rounded rectangles and arrows between them depict the process using a standard called Business Process Modeling Notation(BPMN). The rounded rectangles are the standard way that you represent an activity, while the circles represent the start and end events. The trapezoid shapes are not part of the BPMN standard but instead are used here simply to represent that there will be a user interface of some sort associated with the activity. The boxes in the lower half of the diagram represent automated services of various forms. The smaller square boxes represent web service interfaces to these capabilities. The intent is not to imply that it is necessary to use web services but that is currently a popular approach to allow for flexibility. The human process design is provided to the programer who will add integration to the back end system. In this example, immediately after the first activity of reviewing the information for correctness (which must be done by a human) the system then should automatically call a service that can perform a background check of the applicant. The bank may have rules that it will not accept certain categories of applicants, and there is no reason to force the bank manager to check this manually. Business rules can be employed to classify applicants. In this example, an Enterprise Service Bus(ESB) is used to integrate the call to the background check service, and the call to the conformance rules into a single web service which is easy to connect to the workflow. This is not meant to imply that an ESB must be used, most workflow systems will allow for multiple calls to different services. This is offered here only as an example of how IT professionals might wish to structure the back end systems to give them flexibility. Consider what the bank will have to do to respond to this scenario: One day, it is reported that a small bank in one part of the country is successfully sued and has to pay a huge fine for having given a loan to a terrorist. This is a purely hypothetical example but the point is that legal precedence is set by court cases which can happen relatively suddenly without warning. If this was to happen, the precedence would be set and it 9

16 1 Chapter 1 Figure 1.4: New workflow against the risk of terrorism might be possible then for many other banks to be sued if they do the same thing. The bank has a huge risk, and can not afford to wait for a new terrorist identification solution to be developed by IT in order to check if the applicant is a terrorist. The bank must begin, the very next day, to behave under the new rule of not giving a loan to a terrorist. The first thing to happen is that a manual check must be added to the process (see figure 1.4). A team will be identified, and every bank loan must be reviewed by that team, to assure that the current loan is not going to a terrorist. The bank will also set in motion a project to automate this, but that will take weeks or months. The bank can not afford to stop giving out loans for that time. The manual review will be expensive, but less expensive than being sued if they make a mistake. 10

17 1.3 SOA and BPM The manual step can be immediately incorporated into the human process as a new step between the review and the approval. The huge advantage in being able to put this step directly into the process is that, at the end of the day, you are assured that every bank loan has been checked. Workflow systems keep a record of every activity that is completed, and it is easy to prove that every loan has been appropriately checked. The bank is able to prove compliance to the new rule (law) the very next day on every loan made, which greatly reduces risk of the bank. The manual step is temporary. A couple of months, or possibly weeks, later there will be an automated service that will be able to reliably categorize an applicant as a terrorist or not. This can be added as another automated call between the first and final steps of the process. When this is in place, and when the bank is confident that it works correctly, the manual step can be removed from the process and the bank can return to having two human steps in the loan process.[13] The Business Value of Workflow In the previous section we saw that workflow not only allows to improve productivity, reduce human intervention also help businesses be more agile and bridge the gap between the business and IT world. The fundamental benefit is business level agility, where applications are no longer monolithic blocks constructed out of third-generation languages. If an application is structured from the beginning to separate the human process from the technical manipulation of the data, then it is possible for business users to be able to modify the process part of the application in a safe way. The business analyst is in control of the human side of the application and can rearrange slices, add in manual steps quickly without having to do any programming. This yields a form of agility that is rapidly becoming a competitive differentiator in the industry. In the next chapter we will discuss the workflow technology from JBoss in more detail.[13] 1.3 SOA and BPM Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. In general, entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business. It is natural to think of one persons needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agents requirements being met by a computer agent belonging to a different owner. There is not necessarily a one-to-one correlation between needs and capabilities; the granularity of needs and capabilities vary from fundamental to complex, and any given 11

18 1 Chapter 1 need may require the combining of numerous capabilities while any single capability may address more than one need. The perceived value of SOA is that it provides a powerful framework for matching needs and capabilities and for combining capabilities to address those needs. The noun service is defined in dictionaries as The performance of work (a function) by one for another. However, service, as the term is generally understood, also combines the following related ideas: The capability to perform work for another The specification of the work offered for another The offer to perform work for another These concepts emphasize a distinction between a capability and the ability to bring that capability to bear. While both needs and capabilities exist independently of SOA, in SOA, services are the mechanism by which needs and capabilities are brought together. SOA is a means of organizing solutions that promotes reuse, growth and interoperability. It is not itself a solution to domain problems but rather an organizing and delivery paradigm that enables one to get more value from use both of capabilities which are locally owned and those under the control of others. It also enables one to express solutions in a way that makes it easier to modify or evolve the identified solution or to try alternate solutions.[10] SOA and BPM are nowadays the big names in the buzzword tag cloud. You can t attend a BPM conference or webcast without hearing how SOA provides the critical technology underpinnings of BPM software. One of the lessons learned in IT is that SOA helps to drive IT innovation and keep things flexible, while reducing risk and cutting costs. SOA Integration takes these lessons to the next level, to make better, more innovative use of your existing IT assets by transforming them into services that can then be shared and reused across the enterprise. SOA Integration really provides a flexible, standards-based framework for enabling services, data, events and connecting them to better align with business requirements. It supports key integration patterns that allow IT managers and IT architects to aggregate, orchestrate, and mediate these services. This can accelerate IT responsiveness to address or meet constant business changes. Companies have long sought to integrate existing systems in order to implement information technology support for business processes that cover all present and prospective systems requirements needed to run the business end-to-end. SOA offers a prospective architecture, it unifies business processes by structuring large applications as an ad hoc 12

19 1.3 SOA and BPM collection of smaller modules called services. Different groups of people both inside and outside an organization can use these applications, and new applications built from a mix of services from the global pool exhibit greater flexibility and uniformity. SOA has gained ground as a mechanism for defining business services[7] and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures[12]. Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business in some way and must be traceable back to the business architecture SOA and BPM together SOA can exist without BPM and BPM has flourished without firm understanding of SOA. The combination of SOA and BPM is more powerful than either is in itself. Services are joined together to arrive at a composite business process. SOA minimizes the gap between business analysis and IT development work. Business Processes and data may be considered and designed simultaneously due to access to applications and databases. As shown in Figure 1.5, business services are aligned to a particular business domain, reusable technical services that can be shared across multiple business domains, which allows services to be defined and utilized in a manner that is independent of the underlying application and technology platforms.[3] The services layer provides the ideal platform for the business process layer for the following reasons: A line of business services provides coarse-grain business functionality that maps to the business tasks in a business process. Business process is not responsible for knowing any details of the underlying application and technology platforms, as Service contracts for the line of business services provide well-defined and unambiguous interfaces for accessing the services. Service registry and service discovery facilities provided by the service layer ensure that the business process layer can dynamically locate and access services. 13

20 1 Chapter 1 Figure 1.5: Layered SOA Architecture A service-level data model is defined based on the business domain and is independent of the data model used by any particular application. A service-level security model provides single sign-on and role-based access control to ensure that process tasks are authorized to use services. The major point of implementing an SOA is to provide a loosely coupled integration platform that allows application instance to change and evolve without affecting the core integration technology. Similarly, the process modifications that require different applications to communicate with each other should not alter the core integration technology as well as application instance. This process and service independence helps to establish the relationship between business process modeling and application implementation. Figure 1.6 depicts the relationship between BPM and SOA. As shown in the diagram, BPM does the modeling, simulation, and redesign of processes. SOA infrastructure orchestrates business processes and mediates service providers. Services are exposed, to be used in various processes. Service changes should not impact processes. Process changes reuse various services as 14

21 1.3 SOA and BPM Figure 1.6: Relation between BPM and SOA needed. The process changes will be implemented more rapidly at the enterprise level, because SOA decouples processes from the application implementation, and the communication between process and application happens only through SOA integration. This SOA integration minimizes the gap between process modeling and application implementation.[4] Enhancing Process Design using SOA: SOA creates modular business components that encapsulate business logic and data with interfaces. The modules created are used to execute process flow steps. All the process steps in a business process may or may not be tied to the SOA service. SOA is a tool for designing business processes. Services can be joined to deliver composite business functions or business processes. A single service can be reused in the context of multiple business processes. Therefore, SOA is a set of design principles that can be applied to the design of both computing and process assets. SOA helps business owners in designing IT systems that enable business processes. This improves the adaptability of process change, increases reuse, and improves process con- 15

22 1 Chapter 1 sistency. The SOA approach affects the overall efficiency of IT operations, in particular, application development in the form of reuse of common, shared business services in multiple processes and systems. For large organizations, the business processes, business rules, and policies are inconsistent and are redefined for each new application and process. SOA helps in reducing the inconsistencies in the form of creation of well defined and managed business services that are shared across multiple systems, irrespective of underlying technology implementation.[4] Influencing SOA through Process Management: By using BPM, SOA is tied to the process services to develop composite business flows. BPM adds additional runtime power for service composition and the ability to modify a flow in exchange for more runtime complexity. BPM can also provide the assurance that long-running processes are performed and run any necessary compensating transactions in the case of failure. BPM leverages and extends SOAs power by adding a flexible, agile runtime layer to the services exposed by SOA.[4] BPM and SOA need each other BPM and SOA provide a perfect combination for enterprise computing. BPM provides the higherlevel abstraction for defining businesses processes, as well as other important capabilities of monitoring and managing those processes. Services provide the functions that support those processes. SOA provides the capabilities for services to be combined and to support and create an agile, flexible enterprise. BPM without SOA is useful for building applications, but difficult to extend to the enterprise. SOA without BPM is useful for creating reusable and consistent services, but lacks the ability to turn those services into an agile, competitive enterprise. SOA provides the ideal level of abstraction for defining reusable business functionality, completely encapsulating underlying applications and technology platforms from the BPM system. SOA is the crucial foundation for BPM, supporting rapid assembly and orchestration of process services into larger, end-to-end processes.[4] 1.4 MDA Approach In the previous section, the BPM and SOA convergence was discussed, its combination sounds like the new holy grail, but it seems to lack something. The combination of 16

23 1.4 MDA Approach SOA, BPM and MDA could be adequate for a software development that can start on business processes to create a Computationally Independent Model(CIM) and then transform it to a Platform Independent Model(PIM) based on software services that do not depend on technologies (see figure 1.7). In this section is described a particular vision that combines MDSD, BPM, SOA to show how is possible to improve the development software process starting on business aspects. Figure 1.7: Model Driven Architecture Approach 17

24 1 Chapter 1 Model Driven Architecture(MDA) is a MDSD initiative launched by the Object Management Group. By combining BPM with MDA, BPM is applied to analyze and to model the CIM level including the main elements of the business processes, like people, resources, tasks and information. Starting on this type of business model it will be easier to connect the business elements to different software components, configured as software services. This will help to develop software that will satisfy the business goals and requirements. Using SOA as a basic foundation we want to integrate strategic processes to be able to respond, in a flexible and fast way, to any change in customers demand or new business opportunities. The combination of BPM, MDA and SOA allows us not only improve the business-it alignment, enable a much more agile enterprise but also separate business logic from technology platforms, as a result we gain multiple viewpoints, multi-level reuse(see figure 1.8) and full traceability[6]. A consistent modeling approach from the highest to the lowest level with manual, semi-automated or fully-automated transformation. Figure 1.8: Multi-Level Reuse 18

25 1.4 MDA Approach Recommendation In this section is described briefly how is possible to improve the software development process starting on business aspects by applying all the concepts discussed above. Defining a development environment based on MDA and SOA: In this step each company must define its own development environment, according to the restrictions of the MDA specification and SOA architecture. The main activities of this step are exposed in the figure 1.9. In the first place it must be defined the specific content of CIM, PIM and PSM(Platform Specific Model) models and the languages associated to them. Figure 1.9: Define a development environment based on MDA and SOA After this activity, it will be necessary to define the specific software architecture used to develop and execute the enterprise software. This architecture must be supported on SOA and the selected CIM, PIM and PSM models. Each company can determine in which way they want to organize these types of models according to its MDA interpretation. Additionally the company must define the adequate transformations between MDA models and the rules and restrictions to convert the elements of one type of model to another.[9] 19

26 1 Chapter 1 Business process modeling and specification (CIM Level): In this stage must be defined many details of the business process. The workflow diagram with the main activities of this step is included in the figure 1.10 Figure 1.10: Business Process Modeling and Specification(CIM Level) In the first activity is crucial to identify the key elements of the business process: people, tasks, documents, data and applications. In a parallel activity the company must analyze when the tasks of the business process will require total software automation, when they need software with human intervention and when they are completely manual. In addition, it is very important to determine the integration level in this business process with another enterprise processes. For this reason the company should start developing simple business processes and then integrate them with others more complicated. With the information obtained will be possible to create a business process model, considered CIM in MDA, and to include on it the specification of its main characteristics. 20

27 1.4 MDA Approach Besides, is necessary to define the business rules associated to the process and identify the expected behavior of the process in normal and special conditions. In the last activity and using a specialized simulation tool, it will be possible to make a virtual execution of the business process modeled before. In order to make a good analysis, the process must be simulated in different scenarios and conditions and the results obtained compared with its expected behavior. This type of CIM makes possible to represent the knowledge of the business in a comprehensible format that will be easy to use for the software specialist to define the PIM models, as we can see in the next step.[9] Figure 1.11: Software analysis related to the business process(pim Level) Software analysis related to the business process (PIM Level): In this case the main objective is to define the software requirements and to identify the software services that 21

28 1 Chapter 1 must be developed to support the business process modeled in the previous step. In the figure 1.11 are represented the main activities of this step. In the first action, a CIM to PIM transformation is executed using the descriptions of CIM and PIM elements. The model obtained after the first CIM to PIM transformation will be very simple because it will not have any detail about software requirements. For this reason, this first PIM should be extended and detailed with this information about the software to use in the business process defined in the CIM. When this PIM is completed, it must be performed the software analysis activity and the identification of software services that are necessary to execute the process. This action is very important because it realizes the connection between the software requirements with the software elements that can perform these requirements. Also in this case, each company will have decided what type of constructions employ to represent the software elements and the services, but in every case the model obtained must be platform independent. After this action, the resulting PIM will be very different with respect to first obtained after the CIM transformation. In the last activity of this step, business managers and IT specialist must evaluate and review this PIM model. In this way, if the model is considered correct, developers will have a business validation in a early phase. Therefore, this activity can reduce the number of typical errors produced in context with no good connection between business and IT. If the model is not validated there will be another activity to review the CIM model and its relationship with the final PIM. It will be necessary if business managers detect any problem with the software proposed or the software specialists propose to change some parts of the business process to improve the connection between business and software. After this, all the actions of this step would be repeated until the PIM is validated.[9] Software design, implementation and deploy: The first objective of this step is to obtain the design models related to real platforms and technologies starting on the PIM model. In order to reach this goal it will be necessary to apply one or more PIM to PSM transformations. This number will depend on the architecture defined in the first step of this recommendation, in which are defined the characteristics and the content type of each PSM. Once created and detailed the PSM models, they must be transformed into code that finally should be completed and deployed. We will not mention more details about the activities in this step because this article is focused on the PIM to PSM connection.[9] 22

29 1.5 Summary MDSD and MDA Model Driven Software Development(MDSD) is a software development methodology which focuses on creating models, or abstractions, more close to some particular domain concepts rather than computing (or algorithmic) concepts. It is meant to increase productivity by maximizing compatibility between systems, simplifying the process of design, and promoting communication between individuals and teams working on the system. As you see above, the whole MDA approach is very complex and the recommendation just shows a general solution. In this thesis we don t follow all the steps in MDA, you will see later, we don t have a PIM level, what we really do here is rather a general MDSD approach. 1.5 Summary In this first chapter we have seen the vision of combining BPM, SOA and MDSD concepts, that holds out the promise of creating agile enterprises, which operate efficiently and respond rapidly to changing business needs. Through the separation of concepts we have multiple point of view, that improves the business-it alignment and enables multi-level reuse through the different levels of abstraction. The combined MDSD/SOA benefits allow a faster, cheaper approach for both portfolio management and application development, since it allows to accelerate all aspects of application development and the automatic translation of business models into applications. Enterprises are in the continual maintenance and upkeep of the systems with a solution based on MDSD and SOA. The business need for process management is clear. Streamlined, automated business processes can help deliver huge gains in organizational and cost productivity. Workflow technology is one of the most important BPM technologies, at the heart of workflow technology is an engine that automates and manages processes for the end-user. In the next chapter we will focus on workflow technology with Graph Oriented Programming and The Process Virtual Machine. 23

30

31 2 Chapter Workflow Technology Twenty years ago, the commercial catch phrase was Please allow 6 to 8 weeks for delivery. Today, we do a few quick clicks of the mouse, indicate 3 to 6 days and actually get the package in 2 days. How did this happen? A large part of the answer is Workflow. By focusing on the coordination and automation of work, a workflow system achieves many benefits, helps businesses be more agile and bridges the gap between the business and IT world. Workflow products will constantly be developing new ways to design and administer business technology systems. This isn t just about putting together a workflow design or assigning user rights. This is about the simulation and monitoring of enterprise scale systems in real time. Workflow development is the ultimate integration project. Workflow software doesn t actually do the work but coordinates, triggers, tracks and manages tools and people who do the work. That means that workflow solutions need to be able to talk to and listen to everything from mainframe databases and terminal emulators to web clients and web services. Future architectures won t have to be redesigned every time a new technology emerges. Architectures should allow administrators to quickly and easily integrate Workflow with that new tool.[5] Business Process Modeling Business process modeling in systems engineering and software engineering is the activity of representing processes of an enterprise, so that the current ( as is ) process may be analyzed and improved in future ( to be ). BPM is typically performed by business analysts and managers who are seeking to improve process efficiency and quality. The process improvements identified by BPM may or may not require Information Technology involvement, although that is a common driver for the need to model a business process, by creating a process master. The classic business process modeling methodologies such as the flow chart, functional flow block diagram, data flow diagram, control flow diagram, Gantt chart, PERT diagram, and IDEF have emerged all over the 20th century: The Gantt chart around 1900, the flow charts in the 1920s, Functional Flow Block Diagram and PERT in the 1950s, 25

32 2 Chapter 2 Data Flow Diagrams and IDEF in the 1970s. IDEF0 is probably the most common technique of traditional business process modeling. These represent just a fraction of the methodologies used over the years to document business processes. Methods from the new millennium here are Unified Modeling Language and BPMN [15]. The term business process modeling itself was coined in the 1960s in the field of systems engineering. S. Williams in 1967 published the article Business Process Modeling Improves Administrative Control. His idea was that techniques for obtaining a better understanding of physical control systems could be used in a similar way for business processes. In the 1990s the term process became a new productivity paradigm. Companies were encouraged to think in processes instead of functions and procedures. Process thinking looks horizontally through the company for inducing improvement and measurement. Traditional function modeling methods failed to measure and support improvement in cross-function activities, and their tools can depict the complexity and dependency. As complexity grows these cross-functional activities had increased in number and importance. The focus on processes has been described as business process redesign, business process innovation apart from several nicknames, all aiming at improving processes across the traditional functions that comprise a company.[11] Around the same time (early 1990s) in the field of software engineering the term business process modeling was coined as opposed to software process modeling, much more oriented towards the state of the practice [16]. Earlier and new modeling techniques to capture business processes were now called business process modeling languages. In the Object Oriented approach, it was considered to be an essential step in the specification of Business Application Systems. Business process modeling became the base of new methodologies, that for example also supported data collection, data flow analysis, process flow diagrams and reporting facilities. Around 1995 the first visually oriented tool for business process modeling and implementation were being presented. Business Process: A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. There are three main types of business processes: Management processes, the processes that govern the operation of a system. Typical management processes include Corporate Governance and Strategic Management. Operational processes, processes that constitute the core business and create the primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales. Examples include Ac- Supporting processes, which support the core processes. counting, Recruitment, Technical support. 26

33 2.1 Workflow Technology A business process can be decomposed into several sub-processes, which have their own attributes, but also contribute to achieving the goal of the super-process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level. A business process model is a model of one or more business processes, and defines the ways in which operations are carried out to accomplish the intended objectives of an organization. Such a model remains an abstraction and depends on the intended use of the model. It can describe the workflow or the integration between business processes. It can be constructed in multiple levels. Business Process Modeling Languages There are several modeling languages and notations used to describe business processes, textual as well as graphical representation, e.g. BPMN, UML, jpdl(jbpm Process Definition Language), BPEL(Business Process Execution Language),... one can more mention, unfortunately more is not always better, since we still don t have a common standard for all Business Modeling Languages and Notations. This is the source of many problems [8]. If we could agree on a common standard we will get much benefit from the value of the standard such as: Business: Commoditization of technology and services. Portability between modeling tools. Reduces ambiguity of process models. Business-IT Alignment: Unbroken, bidirectional modeling-interchange-execution chain. Reduces translation errors between business and IT. Less time spent by business analysts teaching IT about business processes. IT time spent just cleaning up processes and hooking them up to the process engine. 27

34 2 Chapter 2 Collaboration: Choreograph processes with partners Share business models in community Outsource business processes (e.g. process modeling and execution may be done by different organizations or runtime statistics feed back for process visibility and optimization against original models). There are currently three important competing organizations, each of which provides its own standard. OMG : Object Management Group is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling (programs, systems and business processes) and model-based standards. OMG manages a number of standards for business modeling, including BPMN, the Business Motivation Model (BMM) and the Semantics of Business Vocabulary and Business Rules (SBVR) specification. BPMN was originally developed by Business Process Management Initiative (BPMI) and is currently maintained by the Object Management Group since the two organizations merged in In 2006 OMG adopted the BPMN language specification as a standard by OMG. A standard BPMN will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations. This will ensure that businesses will understand themselves and participants in their business and will enable organizations to adjust to new internal and B2B business circumstances quickly. WfMC : Founded in 1993, the Workflow Management Coalition is a global organization of adopters, developers, consultants, analysts, as well as university and research groups engaged in workflow and BPM. The WfMC creates and contributes to process related standards, educates the market on related issues, and is the only standards organization that concentrates purely on process. The WfMC created Wf-XML and XPDL, the leading process definition used today in over 80 known solutions to store and exchange process models. XPDL is not an executable programming language but a process design format for storing the visual diagram and process syntax of business process models, as well as extended product attributes. XPDL is the Serialization Format for BPMN. The BPMN standard defines only the 28

35 2.1 Workflow Technology look of how the process definition is displayed on the screen. How you store and interchange those process definitions is outside the scope of the standard, and this is where XPDL comes in. XPDL provides a file format that supports every aspect of the BPMN process definition notation including graphical descriptions of the diagram, as well as executable properties used at run time. With XPDL, a product can write out a process definition with full fidelity, and another product can read it in and reproduce the same diagram that was sent. OASIS : Organization for the Advancement of Structured Information Standards is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards than any other organization along with standards for security, e- business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries. In April 2003, BEA Systems, IBM, Microsoft, SAP and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web Services BPEL Technical Committee. Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OA- SIS WS-BPEL technical committee voted on 14 September 2004 to name their spec WS-BPEL 2.0. This change in name was done to align BPEL with other Web Service standard naming conventions which start with WS- and accounts for the significant enhancements between BPEL4WS 1.1 and WS-BPEL 2.0. If not discussing a specific version, the moniker BPEL is commonly used. In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People and WS-HumanTask specifications, which describe how human interaction in BPEL processes can be implemented. There is no standard graphical notation for WS-BPEL, as the OASIS technical committee decided this was out of scope. Some vendors have invented their own notations. These notations take advantage of the fact that most constructs in BPEL are blockstructured (e.g. sequence, while, pick, scope, etc.) This feature enables a direct visual representation of BPEL process descriptions in the form of structograms, in a style reminiscent of a Nassi-Shneiderman diagram. Others have proposed to use a substantially different business process modeling language, namely BPMN, as a graphical front-end to capture BPEL process descriptions. As an illustration of the feasibility of this approach, the BPMN specification includes an informal and partial mapping from BPMN to BPEL 1.1. A more detailed mapping of BPMN to BPEL has been implemented in a number of tools, including an open-source tool known as BPMN2BPEL. However, the development of these tools has exposed fundamental differences between BPMN and BPEL, which make it very difficult, and in some cases impossible, to generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-to-BPEL 29

36 2 Chapter 2 round-trip engineering: generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated BPEL code synchronized, in the sense that any modification to one is propagated to the other. Besides BPMN, BPEL, XPDL, which are developed by the popular organizations and widely used there are many other notable languages to model business processes e.g. jpdl, an executable process language with excellent modeling capabilities. jpdl supports the collaboration between business analysts and developers. First of all, jpdl is graph based, which allows for more freedom then blockstructured (aka composite) process languages. Secondly, event listeners (aka actions) allow for developers to associate technical details hidden from the business analysts diagram without changing the diagram. That way, the translation from an analysis model to an executable process model becomes easier. And furthermore, the diagram part of the executable process will still be understood by the business analyst. In the next section we will see jpdl again in a brief introduction to Graph Oriented Programming Graph Oriented Programming There are numerous graph based process languages. There are big differences in the environment and focus. For instance, BPEL is intended as an XML based service orchestation component on top of an ESB architecture. And a pageflow process language might define how the pages of a webapplication can be navigated. These are two completely different environments. Despite all these differences, there are two features that you ll find in almost every process language: support for wait states and a graphical represenation. This is no coincidence because it s exactly those two features that are not sufficiently supported in plain Object Oriented(OO) programming languages like Java. Graph Oriented Programming is a technique to implement these two features in an OO programming language. The dependency of Graph Oriented Programming on OO programming implies that all concrete process languages, implemented on top of Graph Oriented Programming, will have to be developed in OOP. But this does not mean that the process languages themselves expose any of this OOP nature. E.g. BPEL doesn t have any relation to OO programming and it can be implemented on top of Graph Oriented Programming. In other words Graph Oriented Programming is the foundation for all domain specific languages that are based on executing a graph.[1] Wait States An imperative programming language like Java are used to express a sequence of instructions to be executed by one system. There is no wait instruction. An imperative 30

37 2.1 Workflow Technology Figure 2.1: Graph Oriented Programming as a foundation for graph based languages language is perfect for describing e.g. one request response cycle in a server. The system is continuously executing the sequence of instructions till the request is handled and the response is complete. But one such request is typically part of a bigger scenario. E.g. a client submits a purchase order, this purchase order is to be validated by a purchase order manager. After approval, the information must be entered in the ERP system. Many requests to the server are part of the same bigger scenario. Process languages are languages to describe the bigger scenario. A very important distinction we must make here is scenarios that are executable on one system (orchestration) and scenarios that describe the protocol between multiple systems (choreography). The Graph Oriented Programming implementation technique is only targets process languages that are executable on one machine (orchestration). An orchestration process describes the overall scenario in terms of one system. For example: A process is started when a client submits an order. The next step in the process is the order manager s approval. So the system must add an entry in the task list of the order manager and the wait till the order manager provides the required input. When the input is received, the process continues execution. Now a message is sent to the ERP system and again this system will wait until the response comes back. To describe the overall scenario for one system, we need a mechanism to cope with wait states. In most of the application domains, the execution must be persisted during the wait states. That is why blocking threads is not sufficient. Clever Java programers might think about the Object.wait() and Object.notify() methods. Those could be used to simulate wait states but the problem is that threads are not persistable. An important aspect of the support for wait states is that executions need to be persistable. Different application domains might have different requirements for persisting such an execution. 31

38 2 Chapter 2 For most workflow, BPM and orchestration applications, the execution needs to be persisted in a relational database. Typically, a state transition in the process execution will correspond with one transaction in the database.[1] Graphical Representation Some aspects of software development can benefit very well from a graph based approach. BPM is one of the most obvious application domains of graph based languages. In that example, the communication between a business analyst and the developer is improved using the graph based diagram of the business process as the common language. The graphical representation can be seen as a missing feature in OO programming. There is no sensible way in which the execution of an OO program can be represented graphically. So there is no direct relation between an OO program and the graphical view. In Graph Oriented Programming, the description of the graph is central and it is a real software artifact like e.g. an XML file that describes the process graph. Since the graphical view is an intrinsic part of the software, it is always in sync. There is no need for a manual translation from the graphical requirements into a software design. The software is structured around the graph.[1] An Execution A process definition represents a formal specification of a business process and is based on a directed graph. The graph is composed of nodes and transitions. Every node in the graph is of a specific type. The type of the node defines the runtime behavior. A process definition has exactly one start state. A token is the runtime concept that maintains a pointer to a node in the graph, in other words a token represents one path of execution. A process instance is one execution of a process definition. When a process instance is created, a token is created for the main path of execution. This token is called the root token of the process instance and it is positioned in the start state of the process definition. 32

39 2.1 Workflow Technology Figure 2.2: Websale Process Definition with jpdl Language A signal instructs a token to continue graph execution. When receiving an unnamed signal, the token will leave its current node over the default leaving transition. When a transition-name is specified in the signal, the token will leave its node over the specified transition. A signal given to the process instance is delegated to the root token. The figure 2.2 is a process definition modeled with jpdl Language, the red token is the root token created when a process instance is created for the Websale process definition. First, the root token points to the start state named create new web sale order of the process definition. If the process instance or the root token receives a signal, the root token will leave the start state and move to evaluate web order. There are two other tokens, one is blue and another is green and both don t appear in the start state, 33

40 2 Chapter 2 that s because when the root token arrived in the fork node it will create a child token for each transition that leaves the fork node. A join node will end every token that enters the join. Then it will examine the parentchild relation of the token that enters the join. When all sibling tokens have arrived in the join, the parent token will be propagated over the (unique!) leaving transition. When there are still sibling tokens active, the join will behave as a wait state. You can see the two child tokens are ended in the join node, only the root token arrives in the end node and the root token don t move through the nodes between the fork and the join.[1] Node types A process graph is made up of nodes and transitions, each node has a specific type. The node type determines what will happen when an execution arrives in the node at runtime. In jpdl each node has two main responsibilities: First, it can execute plain java code. Typically the plain java code relates to the function of the node. E.g. sending a notification, updating a database,... Secondly, a node is responsible for propagating the process execution. Basically, each node has the following options for propagating the process execution: Not propagate the execution. In that case the node behaves as a wait state. Propagate the execution over one of the leaving transitions of the node. This means that the token that originally arrived in the node is passed over one of the leaving transitions. The node will now act as an automatic node in the sense it can execute some custom programming logic and then continue process execution automatically without waiting. Create new paths of execution. A node can decide to create new tokens. Each new token represents a new path of execution and each new token can be launched over the node s leaving transitions. A good example of this kind of behavior is the fork node. End paths of execution. A node can decide to end a path of execution. That means that the token is ended and the path of execution is finished. More general, a node can modify the whole runtime structure of the process instance. The runtime structure is a process instance that contains a tree of tokens. Each token represents a path of execution. A node can create and end tokens, put each token in a node of the graph and launch tokens over transitions. We won t discuss each node type in more detail, scince it s indended that just an overview and the concept of Graph Oriented Programming are given to you but you can find out everything else in jpdl documents. 34

41 2.1 Workflow Technology Persistence The main purpose of persistence is to store process executions during wait states. If a token is not in a wait state it will be passed automatic to the next node till it reachs a new wait state. During wait states, the token can be persisted in the database, that means the overall change between two wait states of the token are persisted. The ORM solution can calculate the difference between the original database state and the updated all changes. Both process definition information (like Node, Transition and Action) and execution information (like Execution) can be stored in a relational database. A process definition can be represented in 3 different forms : as xml, as java objects and as records in a database. Runtime information and logging information can be represented in 2 forms : as java objects and as records in a database.[1] Figure 2.3: The transformations and different forms in jbpm Action In some application domains there must be a way to include the execution of programming logic without introducing a node for it. In BPM for example this is a very important aspect. The business analyst is in charge of the graphical representation and the developer is responsible for making it executable. It is not acceptable if the developer must change the graphical diagram to include a technical detail in which the business analyst is not interested. Actions are a mechanism to bind your custom java code into a process. Actions can 35

42 2 Chapter 2 be associated with its own nodes (if they are relevant in the graphical representation of the process). Or actions can be placed on events like e.g. taking a transition, leaving a node or entering a node. In that case, the actions are not part of the graphical representation, but they are executed when execution fires the events in a runtime process execution. In jbpm it s quite easy to embed your custom actions into the process, in order to implement this you should implement the ActionHandler. The implementation can execute any business logic, but also has the responsibility to propagate the graph execution (in case the action is a part of the graphical representation). Let s look at an example that will update an ERP-system. We ll read an amout from the ERP-system, add an amount that is stored in the process variables and store the result back in the ERP-system. Based on the size of the amount, we have to leave the node via the small amounts or the large amounts transition.[1] Figure 2.4: A custom Action to update an ERP-System Workflow Engine Workflow engines are the heart of the workflow technology. Basically, a workflow engine facilitates the flow of information, tasks and events. There are a lot of workflow engines, open source as well as commercial products implemented with different workflow patterns e.g. control-flow perspective, data perspective, resource perspective or exception handling perspective.[2] You may have heard the word jbpm in the last section, it is a platform for executable process languages ranging from BPM over workflow to service orchestration. jbpm supports three different process languages. Each one is targeted towards a specific function and environment. jbpm builds all these process languages natively on top of a single technology: the Process Virtual Machine(PVM). The PVM is a simple Java library for building and executing process graphs. This serves as a basis for all kinds of workflow, BPM and orchestration process languages. 36

43 2.1 Workflow Technology Figure 2.5: jbpm Overview We have chosen jbpm in this thesis to implement a prototype because of its embeddability and extensibility that we consider two most important aspects of a workflow engine. Workflow and BPM engines are known as monolithic engines. There is typically an API offered to developers to connect to the engine. In some cases, this is desirable, but in most use cases, the business processes and workflows are part of a larger application. In that case, it is crucial that the deployment of the process engine can be embedded straight into the client application. This can greatly simplify testability and maneability. Extensibility because the PVM is the basis for multiple process languages. Native support for any process language can be build on top of the Process Virtual Machine. The runtime behavior of each activity in the process graph is delegated to a Java interface. Process languages are a set of activity types. An activity implements the runtime behaviour and corresponds to one activity type. So building a process language on the PVM is as easy as creating a set of activity implementations. Through the same mechanism, languages like jpdl are very easily extensible. If you compare the figure 2.5 and the figure 2.1 you can see that the PVM is an implementation of Graph Oriented Programming. In the next chapter you will see that jbpm and its modeling language jpdl are used to implement a prototype, which demonstrates a solution combining all concepts discussed in chapter one. 37