1. 1. Session 1162: Say Less and Communicate More with WebSphere Process Server Designs Presenters: Kim Clark, Brian Petrini
2. 2. 2 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Contents Why do we need Process Implementation Types? What are the primary Process Implementation Types? Complications: Could we implement some of these types using mediation flow components rather than BPEL? How do we make the broader implementation choices? How does all this help us to communicate solution designs?
3. 3. 3 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Basic Characteristics for Processes Time-span Granularity Human interaction Principal objects Application integration Complexity Monitoring Flow ownership Dynamicity Performance Volumes Business value State management Security Infrastructure Given the amount of variation in these characteristics, we could have an infinite number of different possible implementation types for processes. In reality however, thankfully, we see only a small number of common types. If both solution designers, and Implementors can agree to use a common set of types (a pattern vocabulary), communication of designs will become more succinct, and accurate.
4. 4. 4 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Process Implementation Types in WebSphere Process Server This presentation provides a "pattern language" of process types that can be used by high level designers to communicate requirements with WPS specialists. Each process type encapsulates a common design pattern which specifically prescribes the technical capabilities of a process to a detailed designer. This presentation is based on the following DeveloperWorks article Part 3: Process Implementation Types: Patterns based design for process based solutions http://www.ibm.com/developerworks/websphere/library/techarticles/1004_clark/1004_clark.html
5. 5. 5 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Contents Why do we need Process Implementation Types? What are the primary Process Implementation Types? Complications: Could we implement some of these types using mediation flow components rather than BPEL? How do we make the broader implementation choices? How does all this help us to communicate solution designs?
6. 6. 6 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Common process implementation types Human Tasks Short-running BPEL Long-running BPEL Async. Initiated Transactional Process Briefly Persisted Process Synchronous Transactional Process GUI Intensive Process Versioned Long-lived Process Task Based Process Response Time Based Throughput Based
7. 7. 7 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Process flow that may not belong in WPS Human Tasks Short-running BPEL Long-running BPEL Versioned Long-lived Process Task Based Process Response Time Based Throughput Based Async. Initiated Transactional Process Synchronous Transactional Process Briefly Persisted Process GUI Intensive Process
8. 8. 8 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types GUI Intensive Process Graphical User Interface Exposed Service (Sync or Async) Sync. Transactional Process Briefly Persisted Process (Triggering of) Versioned Long-Lived Process Navigational flow and data aggregation at the glass rather than in a BPEL process in WPS Typically single user flow, though collaborative GUIs may transfer flow. WPS not involved in process navigation, but may used to provide swiftly responding synchronous services Transaction boundary One way invocation Request/response invocation True transactional initiation from the GUI, or even from the presentation layer may be hard to achieve if the services are truly decoupled.
9. 9. 9 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Non-versioned process implementation types Human Tasks Short-running BPEL Long-running BPEL GUI Intensive Process Versioned Long-lived Process Task Based Process Response Time Based Throughput Based Async. Initiated Transactional Process Synchronous Transactional Process Briefly Persisted Process
10. 10. 10 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Synchronous Transactional Process Typical use of short running BPEL processes Often used for real-time responses to graphical user interfaces, or for transactional sub- processes. Transactional, and therefore must complete within the global timeout. No state is persisted by the process Errors are typically translated for clarity, then passed back to the caller Exposed Service (Sync or Async) Sync. Transactional Process Briefly Persisted Process (Triggering of) Versioned Long-Lived Process Consumer (GUI, process) Synchronous Transactional Process (BPEL) Transaction boundary One way invocation Request/response invocation True transactional initiation from the GUI is hard to achieve. See Transactionality lecture
11. 11. 11 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Synchronous Transactional Process Non-transactional back-end system Transactional back end systems Transactional Boundaries Note that the green transaction highlighting on the diagram is created by right clicking on a component in the assembly diagram and choosing Show Transaction from Here
12. 12. 12 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Synchronous Transactional Process Whilst we can use constructs such as For Each to good effect, we should remember that this is a short running process running on a single thread, so we will gain no benefit it we use it to process items in parallel. We have a synchronous request, so the caller expects a populated response. Since short running processes can be replaced relatively easily, business logic may be coded directly into the process. For the longer running processes described later it might be wise to separate it out into business rules or sub processes. Invocations to transactional systems will by default be performed in the same transaction as the process. Should you need to alter this behaviour adjust the transaction related SCA qualifiers How many times will the invoke be called inside the loop? If we only find out at runtime, how can we be sure that the total aggregated time isnt longer than the globally set transaction time for WPS of 120 seconds? We need to consider these important edge cases in our design. If we have to make updates to a non-transactional system, it is best to do that last. At least then if we have any problems during the transactional updates, they can all be rolled back without having to worry about how to compensate the non-transactional system.
13. 13. 13 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Asynchronously Initiated Transactional Process Callers transaction is minimal, and just makes a request, but does not wait for a response. Process is assured to occur at a later time in a separate transaction. The caller seeks feedback via an a route external to this process. e.g. user periodically check status, or is sent an email. Error handling more complex than a simple Synchronous Transactional Process, since the caller is no longer present to take action. Useful for making relatively slow services appear fast! Exposed Service (Sync or Async) Sync. Transactional Process Briefly Persisted Process (Triggering of) Versioned Long-Lived Process Consumer (GUI, process) Synchronous Transactional Process (BPEL) Transaction boundary One way invocation Request/response invocation Message queue provides asynchronous initiation
14. 14. 14 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Asynchronously Initiated Transactional Process Transactional Boundaries Non-transactional back-end system Transactional back end systems Asynchronous binding such as MQ or JMS with one-way interface
15. 15. 15 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Asynchronously Initiated Transactional Process Note that due to the typical use of a one way interface for initiation, this process type does do not usually have a Reply activity in the BPEL. Since the caller is not waiting synchronously for a response it is acceptable for the aggregate time of all invocations in the process to be higher than would be acceptable for a synchronous transactional process. However, we are still performing everything within one transaction, so we must ensure the process completes well within the transaction timeout of the server (typically 120 seconds). Asynchronously Initiated Processes are typically used to perform background work, and as such are often initiate with a one way interface. If an error occurs, there is no caller to pass the message back to. In fact, errors end up in the WPS failed event manager and resolved by an operations team. We must ensure that only system errors such as connectivity problems, end up there. Business errors should be passed to an exception handling mechanism that is visible to the business. This could be a separate process containing human tasks, or could just be an exception report viewed by the business.
16. 16. 16 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Briefly Persisted Process Briefly Persisted Process Exposed Service (Sync or Async) Sync. Transactional Process Briefly Persisted Process (Triggering of) Versioned of Long-Lived Process A special use of a long running process where the process completes relatively swiftly Process lifespan deliberately short (seconds, maybe minutes), such that process versioning issues can be avoided. The process must be designed to complete in a timely fashion, so no Human Tasks are allowed and error handling actions should be passed pushed out of the process May not receive in-process events Allows parallel processing, so good for aggregation. This is one of the most common motivations for this usage type. Careful through must be put to the the error handling implications of this multi- transactional scenario. A Synchronous Transactional Process is always preferable if at all possible. For Briefly Persisted Processes, persistence adds a significant overhead and the error handling is much more complex. Consumer (GUI, process) Transaction boundary One way invocation Request/response invocation There is significant subtlety in how a fundamentally synchronous consumer interacts with an asynchronous provider.
17. 17. 17 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Briefly Persisted Process Transactional Boundaries Asynchronous request Asynchronous response Synchronous request and response Synchronous request only (one way interface)
18. 18. 18 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Briefly Persisted Process
19. 19. 19 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Briefly Persisted Process Example Where possible, invocations should have expirations set. Note that only asynchronous invocations can have expirations. Expirations on synchronous requests generally have to be done at the transport binding transport level. Processing on timeout should be minimal so as not to hold up the process. Compensation actions should be handed off via one-way asynchronous calls such that this process can continue immediately to completion. Ideally callers of a Briefly Persisted Process should not be dependent on real-time responses due to the throughput based performance characteristics of long running processes. As such, the process is often initiated via a one-way interface, and no Reply activity is present. For Each, and Parallel scopes are available to us in Briefly Persisted Processes allowing activities to occur alongside one another. This is one of their key benefits over short running processes
20. 20. 20 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Variations on Briefly Persisted Processes Short-running BPEL Long-running BPEL Async. Initiated Transactional Process Synchronous Transactional Process GUI Intensive Process Versioned Long-lived Process Response Time Based Throughput Based Human Tasks Task Based Process Asynchronous Briefly Persisted Process Realtime Briefly Persisted Process
21. 21. 21 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Versioned process implementation types Human Tasks Short-running BPEL Long-running BPEL GUI Intensive Process Response Time Based Throughput Based Async. Initiated Transactional Process Synchronous Transactional Process Briefly Persisted Process Versioned Long-lived Process Task Based Process
22. 22. 22 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Versioned Long-lived Process Versioned Long-lived Process Exposed Service (Sync or Async) Sync. Transactional Process (Triggering of) Versioned Long-Lived Process A true long running process that will last a relatively long time (days, weeks, etc). Process instances will always be present in the systems such that the complex issues of process versioning must be taken into account. Can contain human tasks, and complex error handling such as compensation. May receive in-process events which need to contain sufficient information to be correlated with the existing process instance. Invocation typically does not provide a response, and late-binding techniques need to be well understood. Activities can be set to wait for manual intervention on error. See infocentre detail on Continue on error checkbox. Consumer (GUI, process) Human Task Receipt of in-process event late binding Transaction boundary One way invocation Request/response invocation
23. 23. 23 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Versioned Long Lived Process Complex compensation can be embedded in the process In-process Receives, and Wait activities can be used Human Tasks may be present, but typically for exception paths. i.e. most flows do not create tasks, and the main objective of the process is straight through processing. Contrast this with task based processes described next in the article The process may live long enough that event handlers may be useful. Activities will by default run in separate transactions, but can be configured to try to group together (participate) in the same transaction for performance. However, to ensure they run as a single transaction they must be separated out into a short running process. Invoke expirations must have timeout handling.
24. 24. 24 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Proxy pattern for versioned long running processes The red lines added to the solution diagram show the path of the hidden late binding as a result of configuring the Process Template name of VersionedLongLivedProcess1 on the reference partner ProxyProcess1. Notice that no Imports or Exports are required to make the late binding happen. When this further template is introduced with the same name of VersionedLongLivedProcess1, requests from ProxyProcess1 will automatically be directed to the new template based on the its valid from date. All short lived components related to the long running process, such as rules, sub- processes, and mediation flows are housed in a separate module to the long running process such that they can be updated independently, and such that they are available to any new versions of the process template that might be introduced. .
25. 25. 25 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Task Based Process Task Based Process (BPEL) Exposed Service (Sync or Async) Sync. Transactional Process Briefly Persisted Process Long-Lived Process Used to balance multiple tasks between a number of different users, possibly in different teams/departments Necessitates long-lived processes, and hence must consider process versioning issues. Allows progressive automation of tasks. This is a very broad category still, and can be broken into 4 sub-types Structured Workflow Case Handling User Modeled Pageflow Human Task Human Task Human Task Human Task Transaction boundary One way invocation Request/response invocation
26. 26. 26 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Task Based Process Generalised flows and collaboration scopes allow more flexible navigation, splits, joins, forks, merges, back links, user driven navigation such as skip and redo, and user added sub tasks and follow on tasks. Enabling well coordinated parallelism between human activities is often key to business process improvements Task based processes of course still aim to automate as many actions as possible with system invocations. Tasks can be automated further over time with little or no change to the core process. Loops can be used with tasks too, allowing us to efficiently spread items of work out in parallel. Processes can break waiting for an event, or for some period of time to pass. However, we should carefully consider whether we should split the process here to lessen our versioning complications.
27. 27. 27 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Decision tree for basic Process Implementation Types Async. Initiated Transactional Process Briefly Persisted Process Synchronous Transactional Process GUI Intensive Process Versioned Long-lived Process Task Based Process User or GUI performs process navigation? Short response time required AND/OR Single transaction Updating multiple systems that cannot join in the same transaction. AND/OR Process will often take longer than the transaction timeout? (>120 seconds) AND/OR Parallel processing required Process instance can be flushed through to enable simple maintenance. (typical process time minutes/hours) Process predominantly contains human tasks Caller only requires acknowledgement Caller requires back end data in response Instances of processes present during maintenance (typical process time of days/weeks) Process predominantly contains system interactions Start here
28. 28. 28 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Contents Why do we need Process Implementation Types? What are the primary Process Implementation Types? Complications: Could we implement some of these types using mediation flow components rather than BPEL? How do we make the broader implementation choices? How does all this help us to communicate solution designs?
29. 29. 29 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Should we use BPEL, or Mediation Flow Components for non-versioned process implementation types? Product decision points (see next two slides) Architectural/Design differences in usage of BPEL and MFC Functional/technical differences between BPEL and MFC Environment specific decision points How strongly separated are the process and integration layers. Logically separated, or physically? Consider performance implications for example. What else is in the environment (WebSphere Message Broker, WebSphere DataPower, etc.) What are the current skill sets?
30. 30. 30 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Architectural/Design differences in usage of BPEL and MFC MFC Primary capabilities Integration Used to improve infrastructural robustness such as re- try and alternate routing logic Works primarily with protocol and transport headers avoiding coupling and performance overhead of parsing message body Enables enriching of messages based on additional data sources Messaging integration patterns such as content and/or header based routing. Service Exposition Makes systems that use awkward protocols more accessible on standard protocols and transports Implements broad brush policies such as logging, auditing, monitoring, security, for the services exposed. Provides translation from application specific data models, to enterprise or industry standard ones. MFC Secondary capabilities Composite services Basic aggregation capabilities. Basic parallelism Basic decision logic Short Running BPEL Composite services Complex choreography of sequences of requests to relatively maturely exposed services* performed within the time period of a single transaction. Long Running BPEL Automated business processes Choreography of chains of system interactions that are independent transactions spread over a period of time. Task based business processes Choreography of processes involving several human based business tasks. Includes management of the task assignment, and workload distribution. * Maturely exposed services, are ones that can be consumed over common protocols, with no additional integration. If functions are not exposed in this way, an MFC should be used to mature the service such that it can be more appropriately called by the BPEL. This ensures that BPEL processes do not get polluted with integration logic.
31. 31. 31 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Functional differences between BPEL and MFC Meditation Flow Component (MFC) Simple access to the protocol headers via the service message object (SMO) Simple access to the user context via the SMO Support for data handlers as a primitive in the flow Configurable re-try and alternate endpoint routing Lazy parsing of the XML message, for performance optimisation XML maps work directly on unparsed XML providing high speed transformation XML maps provide group, merge and foreach capabilities Dynamic endpoint routing and cached endpoint lookup to WSRR WSRR policy lookup and mapping to promoted properties of the mediation. Database lookup primitive Customisable logging primitive Single transaction unless asynchronous. Parallelism done using fan out/in Only faster than BPEL if message body not parsed. Where message body parsed, synchronous throughput comparable to short running BPEL, asynchronous/parallel throughput comparable to long running BPEL. Short Running BPEL Looping constructs such as foreach, while, repeat until, are much easier to do in BPEL A process has a concept of variables that are easily accessible throughout the processes life, one of which is the request message. Much more intuitive than MFC contexts. Error handling can be performed for whole scopes. In an MFC, handling is must be done on each primitives terminals individually. Single transaction, so relatively high performance. Long Running BPEL Tools are provided to view processes that are in-progress. Parallel processing, especially where multiple different pieces of work need to be done, is trivially easy to code in BPEL. In MFC, the Fan out/in only works on homogeneous arrays. Compensational steps can be stored up to help undo when errors occur in multi-transactional logic. In-process events can be easily correlated with a running process using Receives, Event Handlers etc. Processes can pass decisions to a fully functional workflow subsystem (human tasks). Late binding takes into account both the valid date of the process template, and correlation. True concept of timeout, rather then the act on late message style of the MFC Multiple transaction, with persistence in between steps, so slower performance than short running BPEL
32. 32. 32 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Contents Why do we need Process Implementation Types? What are the primary Process Implementation Types? Complications: Could we implement some of these types using mediation flow components rather than BPEL? How do we make the broader implementation choices? How does all this help us to communicate solution designs?
33. 33. 33 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Mapping requirements to the many possible implementation options Atomic Request Routed Request Broadcast Aggregation Enrichment State-free orchestration Stateful orchestration Publish Subscribe Parallel Processing Mediation Flow Component (Fan Out/In) Patterns Short Running BPEL Process Long Running BPEL Process (Briefly Persisted) Mediation Flow Component (Sequential flow with Service Invokes) Mediation Flow Component (Callout only) Long Running BPEL Process (Versioned) Long Running BPEL Process (Task Based) Transport only (e.g. HTTP, JMS, MQ) Most attempts at decision trees for implementation choices fail because they try to cover the many-to-many mapping from all possible requirements to all possible implementations. This would be an impossibly hard decision tree to draw, and inconceivably complex to navigate. Implementation Options Parallel Initiation Requirements
34. 34. 34 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Many patterns, many possible implementation options Atomic Request Routed Request Broadcast Aggregation Enrichment State-free orchestration Stateful orchestration Publish Subscribe Parallel Processing Mediation Flow Component (Fan Out/In) Patterns Short Running BPEL Process Long Running BPEL Process (Briefly Persisted) Mediation Flow Component (Sequential flow with Service Invokes) Mediation Flow Component (Callout only) Long Running BPEL Process (Versioned) Long Running BPEL Process (Task Based) Transport only (e.g. HTTP, JMS, MQ) If we break down the requirements into a discrete set of patterns we see that there is only a limited number of options from each pattern. Some options stand out as primary choices, others as special cases. Implementation Types Parallel Initiation
35. 35. 35 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Narrowing the complexity using a two stage decision tree Patterns Implementation Types Based on a specific pattern, what are the relevant implementation choices?
36. 36. 36 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Contents Why do we need Process Implementation Types? What are the primary Process Implementation Types? Complications: Could we implement some of these types using mediation flow components rather than BPEL? How do we make the broader implementation choices? How does all this help us to communicate solution designs?
37. 37. 37 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Business Process Model Presentation Layer Process and Composite Service Layer Atomic Service Layer minutes seconds minutes or daysdays days Comparing the logical business process model to the implemented physical process Note: Please note that the below is not a formal diagramming style. It simply allows us to compare the possible constituent parts of a solution with the business model from which it might have originated. The business process model may begin before any technology is even involved. A single step in the business process may be several screens/pages of data capture within the actual GUI A single step in the business process may relate to a whole BPEL process in the implementation. The end to end business process may last days, weeks, or months, but that doesnt necessarily mean it is logical for there to be a BPEL process present for that length of time. The Human Task could occur on every process instance, or only on 1 in every 1000. We would design the underlying implementation completely differently for each case.
38. 38. 38 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Common solutions, using Process Implementation Types Over the next few slides we take a high level view of some common solutions, and assess what process implementation type(s) would best satisfy the requirement. By drawing boundaries to show where the types are applied we can turn a design full of unknowns, into a set of known design patterns. Common Solutions Summaries Online User Interface Predominantly single user driven scenario where the navigation is performed by the user, and the GUI makes calls to existing and new services. Online Application Automation Initial data capture by a single user, often including calls to services for quotations etc. Followed by a submission step that involves an automated process with some task based human interaction. Straight Through Processing Streamlined automated process, designed for performance and high volume. Errors are designed to be rare, and are handled outside of the main process. Data Item Review Task based process such as an approval process involving multiple people in a structured review cycle.
39. 39. 39 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types SRP GUI Business Process Model LRP Presentation Layer Process and Composite Service Layer Atomic Service Layer minutes seconds minutesdays Common solution: Online User Interface GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process Complex graphical user interface, utilises services, implicit or user navigation Synchronous call Asynchronous call Usage Type: GUI Intensive Process Usage Type: Sync. Transactional Process Usage Type: Briefly Persisted Process waiting
40. 40. 40 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types SRP GUI Business Process Model LRP Presentation Layer Process and Composite Service Layer Atomic Service Layer minutes seconds minutes or daysdays days HT Common solution: Online Application Automation GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process Data capture, submission and processing Usage Type: GUI Intensive Process Usage Type: Versioned Long- lived ProcessUsage Type: Sync. Transactional Process waiting
41. 41. 41 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types SRP Business Process Model LRP Process and Composite Service Layer Atomic Service Layer Events Source milli-seconds per event hrs secondsdaily per batch HT Common solution: Straight Through Processing GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process Presentation Layer HT Event receipt, validation, processing, rare error handling by re-submission hrs LRP LRP Usage Type: Async. Init. Transactional Process Usage Type: Versioned Long Lived Process Usage Type: Versioned Long Lived Process Usage Type: Briefly Persisted Process Special cases (1% of happy path) Happy Path - 99.9% of cases, goes straight through the SRP without need to touch the HT Rare, error handling paths (~1 in a thousand)
42. 42. 42 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types SRP Business Process Model LRP Process and Composite Service Layer Atomic Service Layer seconds days/weeks days Common solution: Data Item Review GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process Presentation Layer HT Item creation, validation, submission, review cycle GUI Usage Type: GUI Intensive Process Usage Type: Sync. Transactional Process Usage Type: Task Based Process waiting
43. 43. 43 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Documenting a solution showing patterns, solutions and services Enterprise Information System Enterprise Information System Usage Type: Briefly Persisted Process Usage Type: Versioned Long- lived Process Usage Type: Transactional Short-lived Process Usage Type: Async. Init. Short-lived Process Enterprise Information System Enterprise Information System Usage Type: Synchronously Exposed Service Usage Type: Asynchronously Exposed Service Usage Type: Transactional Short-lived Service
44. 44. 44 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Process not implemented in WPS Process implemented in WPS Short-running BPEL Long-running BPEL Human Tasks Async. Initiated Transactional Process Briefly Persisted Process Synchronous Transactional Process GUI Intensive Process Versioned Long-lived Process Task Based Process Throughput Based Response Time Based Process Implementation Types
45. 45. 45 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Key messages It is not enough to simply define a process as short or long running What about transactionality, duration, parallelism, error handling. All of these things have a significant impact on the low level design Solution designers shouldnt need to be WPS specialists, to be able to include it in their designs Patterns provide solution designers with a high level vocabulary that translates to a very specific implementation style with known characteristics. Define a set of patterns such as the process implementation types improves communication from solution designers to implementers improves clarity of the design drives consistency in the implementation
46. 46. 46 IBM Software Group 2010 IBM Corporation 04/05/2010 Process Implementation Types Developerworks article series on WPS Solution Design Part 1: What do solutions look like in WebSphere Process Server http://www.ibm.com/developerworks/websphere/library/techarticles/0904_c lark/0904_clark.html Part 2: Designing an ESB Gateway in WebSphere Process Server and WebSphere ESB http://www.ibm.com/developerworks/websphere/library/techarticles/0908_c lark/0908_clark.html Part 3: Process Implementation Types: Patterns based design for process based solutions http://www.ibm.com/developerworks/websphere/library/techarticles/1004_c lark/1004_clark.html
47. 47. 47 We Value Your Feedback ! Please complete the session survey for this session by: Accessing the SmartSite on your smart phone or computer at: http://imp2010.confnav.com Surveys / My Session Evaluations Visiting any onsite event kiosk Surveys / My Session Evaluations Each completed survey increases your chance to win an Apple iPod Touch with daily drawing sponsored by Alliance Tech
48. 48. 48 Copyright and Trademarks IBM Corporation 2009. All rights reserved. IBM, the IBM logo, ibm.com and the globe design are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml. Other company, product, or service names may be trademarks or service marks of others.