《电子商务 E-business》阅读文献：Model business processes for flexibility and re-use A component-oriented approach.pdf_大学文库

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

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

ibm. com/developerWorks developerWorks⑧ annotations beside each implementation document the condition(business rule)that triggers the selection of the corresponding implementation at execution time Some additional modeling considerations when using component-oriented process modeling are as follows Asynchronous processes. There is nothing special about how asynchronous processes are modeled using component-oriented process modeling Any process component can issue a"fire-and-forget request and any component (with the right interface to receive the response) may act as a"listener. there is however one small difference While standard"process components are invoked as a result of the evaluation of business rules, an asynchronous process component is triggered by the arrival of an event or message. It is therefore important to designate that a given component is a listener (an annotation may suffice)so that it is implemented accordingly Sharing context. Sometimes it is necessary to keep business object states across process component invocations. For example, if the complete Order object is not passed as an input parameter to all process components, it may be necessary to store it somewhere so that each component in the end-to-end order process may have access to it. That somewhere" may be a database, or it may be some sort of"process context(unless properly managed by the underlying software, the latter should be avoided because of the scalability implications ) How the process state is kept across process component invocations should not be a concern of business process modeling. However, the fact that the process is using (or producing output from) data that does not derive from its inputs should be recorded in the process model In Business Modeler a process and its(connected) sub-processes can share data through the use of a global repository, but with process components( that are not connected to the parent process) this is no longer possible. The solution that we propose is centred around the notion that context interactions are are represented by a service interface and should not be treated any ey dependencies that the process has on a"context service. As such, the differently than any other dependencies Process simulation implications Because business rules and policies for dynamic process assembly cannot be directly defined in Business Modeler, its simulation engine is not able to simulate processes that are composed of other decoupled processes Each process can be simulated individually but, if the intent is to improve the process through successive simulations, it is obvious that the optimisation of the parts may not result in the optimisation of the whole process. If this is the goal then interfaces have to be replaced by their respective process implementations as ub-processes Model business processes for flexibility and re-use: A component-oriented approach o Copyright IBM Corporation 2009. All rights reserved Page 7 of 11

annotations beside each implementation document the condition (business rule) that triggers the selection of the corresponding implementation at execution time. Some additional modeling considerations when using component-oriented process modeling are as follows: • Asynchronous processes. There is nothing special about how asynchronous processes are modeled using component-oriented process modeling. Any process component can issue a “fire-and-forget” request and any component (with the right interface to receive the response) may act as a “listener”. There is, however, one small difference. While “standard” process components are invoked as a result of the evaluation of business rules, an asynchronous process component is triggered by the arrival of an event or message. It is therefore important to designate that a given component is a listener (an annotation may suffice) so that it is implemented accordingly. • Sharing context. Sometimes it is necessary to keep business object states across process component invocations. For example, if the complete Order object is not passed as an input parameter to all process components, it may be necessary to store it somewhere so that each component in the end-to-end order process may have access to it. That “somewhere” may be a database, or it may be some sort of “process context” (unless properly managed by the underlying software, the latter should be avoided because of the scalability implications). How the process state is kept across process component invocations should not be a concern of business process modeling. However, the fact that the process is using (or producing output from) data that does not derive from its inputs should be recorded in the process model. In Business Modeler a process and its (connected) sub-processes can share data through the use of a global repository, but with process components (that are not connected to the parent process) this is no longer possible. The solution that we propose is centred around the notion that context interactions are dependencies that the process has on a “context service”. As such, they are represented by a service interface and should not be treated any differently than any other dependencies. • Process simulation implications. Because business rules and policies for dynamic process assembly cannot be directly defined in Business Modeler, its simulation engine is not able to simulate processes that are composed of other decoupled processes. Each process can be simulated individually but, if the intent is to improve the process through successive simulations, it is obvious that the optimisation of the parts may not result in the optimisation of the whole process. If this is the goal then interfaces have to be replaced by their respective process implementations as sub-processes. ibm.com/developerWorks developerWorks® Model business processes for flexibility and re-use: A component-oriented approach © Copyright IBM Corporation 2009. All rights reserved. Page 7 of 11

developerWorks⑧ ibm. com/developerWorks Implications for business process monitoring. In Business Modeler you can define business measures and key performance indicators(KPIs) that are specific to a particular process. A Web Sphere Business Monitor model may be generated from each Business Modeler process. With many decoupled process models forming part of a larger(parent) process, it is no longer possible to generate a single monitor model for the arent process and all its process components this is by no means a bad thing. In the same way that we now have decoupled business models and, as a by-product, a much more modular approach o or processes, we also end up with corresponding"decoupled " monit monitoring The attentive reader will at this point be thinking that this will work well if the intent is to monitor each process component independently It will not work so well if we wish to monitor the end-to-end process- for example, if we wish to establish metrics that cover the complete life span of an order. The solution is to use an approach that has already been proposed as a best practice for the creation of monitor models. The approach consists of the separation of monitor models into two separate monitoring levels: high-level monitor model and low-level monitor model. Low-level monitor models receive events from the running processes and in turn propagate (appropriate) events to the high-level monitor model. The original intent of this approach was to establish a certain degree of insulation between the running process and the higher-level monitoring artifacts, such as KPIs and business but in this case we have many low-level monitor models contributing events too% measures With decoupled component processes you can use the same approach single high-level monitor model that oversees the whole process(Figure 6) Figure 6. Low-level models contribute to a high-level model for end-to-end monitoring High level monitor mode Event Event Event Low level monitor Low level monitor Low level monitor model 1 model 2 model n Events Events Events Process 1 Process 2 Process n Business Modeler can already generate high-and low-level monitor models, but the Model business processes for flexibility and re-use: A component-oriented approach Page 8 of 11 Copyright IBM Corporation 2009. All rights reserved

• Implications for business process monitoring. In Business Modeler you can define business measures and key performance indicators (KPIs) that are specific to a particular process. A WebSphere Business Monitor model may be generated from each Business Modeler process. With many decoupled process models forming part of a larger (parent) process, it is no longer possible to generate a single monitor model for the parent process and all its process components. This is by no means a bad thing. In the same way that we now have decoupled business processes, we also end up with corresponding “decoupled” monitor models and, as a by-product, a much more modular approach to monitoring. The attentive reader will at this point be thinking that this will work well if the intent is to monitor each process component independently. It will not work so well if we wish to monitor the end-to-end process — for example, if we wish to establish metrics that cover the complete life span of an order. The solution is to use an approach that has already been proposed as a best practice for the creation of monitor models. The approach consists of the separation of monitor models into two separate monitoring levels: high-level monitor model and low-level monitor model. Low-level monitor models receive events from the running processes and in turn propagate (appropriate) events to the high-level monitor model. The original intent of this approach was to establish a certain degree of insulation between the running process and the higher-level monitoring artifacts, such as KPIs and business measures. With decoupled component processes you can use the same approach but in this case we have many low-level monitor models contributing events to a single high-level monitor model that oversees the whole process (Figure 6). Figure 6. Low-level models contribute to a high-level model for end-to-end monitoring Business Modeler can already generate high- and low-level monitor models, but the developerWorks® ibm.com/developerWorks Model business processes for flexibility and re-use: A component-oriented approach Page 8 of 11 © Copyright IBM Corporation 2009. All rights reserved

ibm. com/developerWorks developerWorks⑧ generation of multiple monitor models that contribute to a single high-level model not supported. This must be done in the Monitor Model Editor Component-oriented process modeling and SoA In most business environments, process models are created not only to describe new capabilities, but also to define how those capabilities interface to existing systems. In a growing number of cases the interfaces to existing legacy systems are implemented as web services that conform to Services Oriented Architecture(SOA) design principles. These services can be imported into Business Modeler as business services. Once in Business Modeler, business services may be referenced by one or more business processes This approach requires two types of analysis: top-down, to understand what the new business capabilities are and how they interact with each other and bottom-up, to understand what capabilities already exist and how they can be reused in the new asset re-use and better alignment of business processes and technology oal solution. Successive iterations of this analysis process result in the desired goals of In component-oriented business process modeling business services are no longer new or existing process components. Thus the component-oriented approach o just interfaces to external systems or services, but they can also be interfaces benefits from (but does not necessarily prescribe) increased rigor and discipline in the way that processes are modeled to ensure that they fully realize their re-use potential. Such reusable process components must then necessarily also become subject to the top-down or bottom-up Soa analysis process Summary This article addresses the issues of model size, re-use, modularity and flexibility in business process models by proposing a component-oriented approach to business process modeling. It defines a process component to be a cohesive business process that exposes its inputs and outputs as interfaces and declares all its dependencies as interfaces. It also maintains that such process components can be dynamically assembled into larger processes or process components Model business processes for flexibility and re-use: A component-oriented approach o Copyright IBM Corporation 2009. All rights reserved Page 9 of 11

generation of multiple monitor models that contribute to a single high-level model is not supported. This must be done in the Monitor Model Editor. Component-oriented process modeling and SOA In most business environments, process models are created not only to describe new capabilities, but also to define how those capabilities interface to existing systems. In a growing number of cases the interfaces to existing legacy systems are implemented as web services that conform to Services Oriented Architecture (SOA) design principles. These services can be imported into Business Modeler as business services. Once in Business Modeler, business services may be referenced by one or more business processes. This approach requires two types of analysis: top-down, to understand what the new business capabilities are and how they interact with each other and bottom-up, to understand what capabilities already exist and how they can be reused in the new solution. Successive iterations of this analysis process result in the desired goals of asset re-use and better alignment of business processes and technology. In component-oriented business process modeling, business services are no longer just interfaces to external systems or services, but they can also be interfaces to new or existing process components. Thus the component-oriented approach benefits from (but does not necessarily prescribe) increased rigor and discipline in the way that processes are modeled to ensure that they fully realize their re-use potential. Such reusable process components must then necessarily also become subject to the top-down or bottom-up SOA analysis process. Summary This article addresses the issues of model size, re-use, modularity and flexibility in business process models by proposing a component-oriented approach to business process modeling. It defines a process component to be a cohesive business process that exposes its inputs and outputs as interfaces and declares all its dependencies as interfaces. It also maintains that such process components can be dynamically assembled into larger processes or process components. ibm.com/developerWorks developerWorks® Model business processes for flexibility and re-use: A component-oriented approach © Copyright IBM Corporation 2009. All rights reserved. Page 9 of 11