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 11annotations 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