1. Session 1162: Say Less and Communicate More with WebSphere
Process Server Designs Presenters: Kim Clark, Brian Petrini
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 IBM Software Group 2010 IBM Corporation 04/05/2010
Process Implementation Types Briefly Persisted Process
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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.