重真 developerWorks Model business processes for flexibility and re-use A component-oriented approach Skill Level: Intermediate JoseADeFreitas(freitas@uk.ibm.com) Advisory Software Engineer 22Apr2009 This article describes a component-oriented approach to business process modeling that allows you to capture process variability and ensure that your model is reusable It describes modeling patterns and practices in Web Spheree Business Modeler that will help you achieve this goal ntroduction Today's business dynamics are mandating that business processes be increasingly responsive to change. This makes it critical that business process models be modular and flexible, not only for increased modeling agility but also for the greater robustness and flexibility of executing processes. A traditional approach to business process modeling frequently results in large models that are difficult to change and maintain. Because of their size these models are not very flexible. They are also not conducive to dynamic process selection - that is, parts of the process model cannot be easily replaced at execution time a good example of a scenario where dynamic process selection is justified is the case where different exception handling processes may be invoked depending on the type of error that is encountered. The traditional way to solve this problem is to use a multiple-choice decision. This is illustrated in the trivial process order example shown in Figure 1. If the order is not valid, one of three paths is chosen depending on the outcome of the decision Figure 1. Hard-wired choices limit flexibility and increase process size Model business processes for flexibility and re-use: A component-oriented approach o Copyright IBM Corporation 2009. All rights reserved Page 1 of 11
Model business processes for flexibility and re-use: A component-oriented approach Skill Level: Intermediate Jose A. De Freitas (dfreitas@uk.ibm.com) Advisory Software Engineer IBM 22 Apr 2009 This article describes a component-oriented approach to business process modeling that allows you to capture process variability and ensure that your model is reusable. It describes modeling patterns and practices in WebSphere® Business Modeler that will help you achieve this goal. Introduction Today's business dynamics are mandating that business processes be increasingly responsive to change. This makes it critical that business process models be modular and flexible, not only for increased modeling agility but also for the greater robustness and flexibility of executing processes. A traditional approach to business process modeling frequently results in large models that are difficult to change and maintain. Because of their size, these models are not very flexible. They are also not conducive to dynamic process selection — that is, parts of the process model cannot be easily replaced at execution time. A good example of a scenario where dynamic process selection is justified is the case where different exception handling processes may be invoked depending on the type of error that is encountered. The traditional way to solve this problem is to use a multiple-choice decision. This is illustrated in the trivial process order example shown in Figure 1. If the order is not valid, one of three paths is chosen depending on the outcome of the decision. Figure 1. Hard-wired choices limit flexibility and increase process size Model business processes for flexibility and re-use: A component-oriented approach © Copyright IBM Corporation 2009. All rights reserved. Page 1 of 11
orks③ ibm. com/developerWorks 回 Fuf Order s00N Yes Cers 30N Amend order Aumonzabon 409, otoo Cancel order An obvious limitation of this approach is that for each new error handling process a new decision branch must be created. Therefore, the process needs to be changed and all the related documentation, deployment, and testing must be repeated It also means that you could end up with a very large process Business processes as components An alternative, more modular approach to solving the problem described above is one where a business service interface "stands in"for one of many compatible processes(compatible, meaning that they have the same interfaces). A single process can then be dynamically selected at execution time. See Figure 2 Figure 2. An interface"stands in"for one of many possible process implementations Model business processes for flexibility and re-use: A component-oriented approach Page 2 of 11 Copyright IBM Corporation 2009. All rights reserved
An obvious limitation of this approach is that for each new error handling process a new decision branch must be created. Therefore, the process needs to be changed and all the related documentation, deployment, and testing must be repeated. It also means that you could end up with a very large process. Business processes as components An alternative, more modular approach to solving the problem described above is one where a business service interface "stands in" for one of many compatible processes (compatible, meaning that they have the same interfaces). A single process can then be dynamically selected at execution time. See Figure 2. Figure 2. An interface “stands in” for one of many possible process implementations developerWorks® ibm.com/developerWorks Model business processes for flexibility and re-use: A component-oriented approach Page 2 of 11 © Copyright IBM Corporation 2009. All rights reserved
ibm. com/developerWorks developerWorks⑧ 9 Peeet Tree 23 团出 Pf Orde rate Orde whH △ Lodate ode hand Cpoe 9 assess servce otects Authorizaton, Caned od, et At first glance this may appear to be only a subtle change in modeling style, but the consequences are far-reaching First, the process interfaces are clearly defined through their inputs and outputs(Figure 3). But most importantly, the process dependencies are also clearly exposed through interfaces(business services in Business Modeler). This effectively means that a process modeled in this way is a component in the sense that it embodies the most fundamental property of components: a component declares the services it provides and those that it depends on Cohesion is another property that is typically associated with software components and that is also highly desirable in the context of business process modeling. While the idea behind component cohesion may be simple( keep related functionality together), it does require good analysis skills to achieve. The number and comple of process dependencies may provide a measure of process cohesiveness; the exity lower the number of dependencies and the lower the dependency complexity, the more cohesive a process tends to be If we agree that business processes are components if they(1)are cohesive and(2) expose services and dependencies, then "component-oriented business process modeling" is an adequate term to describe the activity of creating such process models. This notion of business processes as components is not one that is exclusive to the technical or implementation domain. A component view of a business is also sary for greater business agility. Thus if your goal is to better align business with technology, and to easily respond to changing business requirements, then the use of components in one domain necessarily implies a component view in the other Figure 3. a process component exposes its services and its dependencies Model business processes for flexibility and re-use: A component-oriented approach o Copyright IBM Corporation 2009. All rights reserved Page 3 of 11
At first glance this may appear to be only a subtle change in modeling style, but the consequences are far-reaching. First, the process interfaces are clearly defined through their inputs and outputs (Figure 3). But most importantly, the process dependencies are also clearly exposed through interfaces (business services in Business Modeler). This effectively means that a process modeled in this way is a component in the sense that it embodies the most fundamental property of components: a component declares the services it provides and those that it depends on. Cohesion is another property that is typically associated with software components and that is also highly desirable in the context of business process modeling. While the idea behind component cohesion may be simple (keep related functionality together), it does require good analysis skills to achieve. The number and complexity of process dependencies may provide a measure of process cohesiveness; the lower the number of dependencies and the lower the dependency complexity, the more cohesive a process tends to be. If we agree that business processes are components if they (1) are cohesive and (2) expose services and dependencies, then "component-oriented business process modeling" is an adequate term to describe the activity of creating such process models. This notion of business processes as components is not one that is exclusive to the technical or implementation domain. A component view of a business is also necessary for greater business agility. Thus if your goal is to better align business with technology, and to easily respond to changing business requirements, then the use of components in one domain necessarily implies a component view in the other. Figure 3. A process component exposes its services and its dependencies ibm.com/developerWorks developerWorks® Model business processes for flexibility and re-use: A component-oriented approach © Copyright IBM Corporation 2009. All rights reserved. Page 3 of 11
developerWorks⑧ ibm. com/developerWorks roject Tree 2 soder orderCOBPM 5 Amend Oder x 5 Amend orde With Authorizebion5oCa e靠 ② Busness items Se Abstact Process order E G Ta Process Component ce order MAness Ruies Task 5o processorder soder.COepM wale Loop Dependencies represented by Service(Interface date Ocer witHT △ Update order ODo-whie Lodd Resources GFer Loop I G Ogareabons Lodate Order Process input represented by the Exception Handler intertace It is trivially true that components may be composed of other components, but the way in which they are composed may differ For greater flexibility we propose that a business process component not be statically bound to its constituent components Instead dependencies should be injected at run time based on the outcome of the execution of business rules. The use of the term injected is used here to draw an nalogy to the more technical notion of"dependency injection"(used in the popular Spring framework and the Service Component Architecture(SCA) that has delivered increased reuse potential, robustness and flexibility to solutions built using this approach). See Resources for details on Spring and SCA Component-oriented process modeling using Web Sphere Business modeler The terms service and interface are used interchangeably because, in Business Modeler, a service typically represents an interface to some external service implementation. Business Modeler distinguishes between those services that are defined in Business Modeler(sometimes called global services)and those that are imported into Business Modeler as Web Services Definition Language(WSDL) services. Both types of services can be used as interfaces in the component-oriented approach, the former in a top-down modeling approach and the latter in a bottom-up approach(please refer to Component-oriented process modeling and SOA). Web services definitions can be imported from the file system from Web Sphere Services Registry and Repository, or from Rational@ Asset Manager With component-oriented process modeling, components are represented as Model business processes for flexibility and re-use: A component-oriented approach Page 4 of 11 Copyright IBM Corporation 2009. All rights reserved
It is trivially true that components may be composed of other components, but the way in which they are composed may differ. For greater flexibility, we propose that a business process component not be statically bound to its constituent components. Instead dependencies should be injected at run time based on the outcome of the execution of business rules. The use of the term injected is used here to draw an analogy to the more technical notion of "dependency injection" (used in the popular Spring framework and the Service Component Architecture (SCA) that has delivered increased reuse potential, robustness and flexibility to solutions built using this approach). See Resources for details on Spring and SCA. Component-oriented process modeling using WebSphere Business Modeler The terms service and interface are used interchangeably because, in Business Modeler, a service typically represents an interface to some external service implementation. Business Modeler distinguishes between those services that are defined in Business Modeler (sometimes called global services) and those that are imported into Business Modeler as Web Services Definition Language (WSDL) services. Both types of services can be used as interfaces in the component-oriented approach, the former in a top-down modeling approach and the latter in a bottom-up approach (please refer to Component-oriented process modeling and SOA). Web services definitions can be imported from the file system, from WebSphere Services Registry and Repository, or from Rational® Asset Manager. With component-oriented process modeling, components are represented as developerWorks® ibm.com/developerWorks Model business processes for flexibility and re-use: A component-oriented approach Page 4 of 11 © Copyright IBM Corporation 2009. All rights reserved
ibm. com/developerWorks developerWorks⑧ disjointed global processes in Business Modeler. It is therefore necessary to 1. Define the "glue" that holds them together in a containing business process 2. Define a modeling pattern that enables an end-to-end view of this process These two steps are outlined in the following sections Business rules serve as the" glue The most flexible way to govern the dynamic composition of processes and services is through the use of business rules. In a typical implementation, business rules are used to inspect the data that flows through a particular node or point in the process flow(known as a point of variability) and to make a decision that determines the next path in the flow. In our example a simple rule could be "if the outcome of the validation is an error code of 999 then the corresponding amendment to the order must be authorised by the supervisor". The phrase "must be authorised by the supervisor simply means that the process that implements this capability(Amen Order With Authorization, in the example)is dynamically invoked. WebSphere Business Services Fabric(hereafter referred to as Business Services Fabric)is ideally suited for defining, managing and executing such rules. In Business Modeler, you can designate a service interface to be a Dynamic Assembler(Figure 4)to indicate that it is a Business Services Fabric point of variability Then, you can define rules and policies for the component within Business Services Fabric. Refer to Resources for details on points of variability igure 4 Point of variability identified as a Business services Fabric Dynamic Assembler B%%andeExcepton x 田) Technical Specification +bUsness items V Component Attributes - specfication f Abstract Process Order E2EM Defne the comoonent nformation thatrepresents the target roemer t Amend Order Amend Order wath Authorizes onent splay na te Cance Order to processorder t processorder_CoePM t Update Orde withT e Update order LA Casters 以 Quenes 么 会 ExceoborHender nterface s② Excestortande Define the implementation informaton hand eExceoton Model business processes for flexibility and re-use: A component-oriented approach o Copyright IBM Corporation 2009. All rights reserved Page 5 of 11
disjointed global processes in Business Modeler. It is therefore necessary to: 1. Define the “glue” that holds them together in a containing business process 2. Define a modeling pattern that enables an end-to-end view of this process These two steps are outlined in the following sections. Business rules serve as the “glue” The most flexible way to govern the dynamic composition of processes and services is through the use of business rules. In a typical implementation, business rules are used to inspect the data that flows through a particular node or point in the process flow (known as a point of variability) and to make a decision that determines the next path in the flow. In our example, a simple rule could be “if the outcome of the validation is an error code of ‘999’ then the corresponding amendment to the order must be authorised by the supervisor”. The phrase “must be authorised by the supervisor” simply means that the process that implements this capability (Amend Order With Authorization, in the example) is dynamically invoked. WebSphere Business Services Fabric (hereafter referred to as Business Services Fabric) is ideally suited for defining, managing and executing such rules. In Business Modeler, you can designate a service interface to be a Dynamic Assembler (Figure 4) to indicate that it is a Business Services Fabric point of variability. Then, you can define rules and policies for the component within Business Services Fabric. Refer to Resources for details on points of variability. Figure 4. Point of variability identified as a Business Services Fabric Dynamic Assembler ibm.com/developerWorks developerWorks® Model business processes for flexibility and re-use: A component-oriented approach © Copyright IBM Corporation 2009. All rights reserved. Page 5 of 11