Impact 2011 2667 - Developing effective services for use in critical business processes

1

Developing Effective Services for Use in Critical
Business Processes
Presenter: Brian M. Petrini, Senior IT Architect
Co-author: Kim Clark, Senior IT Specialist
IBM Software Services for WebSphere
Session Number: TBI-2667

Agenda
 Where have companies got to on their SOA journey?
 How does the service consumer effect the
characteristics?
 How do we technically characterise services?
 How would we expose services differently for BPM
consumers

IBM Software Group
© 2008 IBM Corporation
Silo Services
Composite
Services
Virtualized
Services
Dynamically
Re-Configurable
ServicesComponentizedIntegrated
Level 1 Level 4 Level 5 Level 6 Level 7Level 3Level 2
Applications
Methods
Organization
Infrastructure
Architecture
Business View
Modules Services
Process
Integration via
Services
Dynamic
Application
Assembly
ComponentsObjects
Structured
Analysis &
Design
Service
Oriented
Modeling
Service
Oriented
Modeling
Grammar
Oriented
Modeling
Component
Based
Development
Object
Oriented
Modeling
Ad hoc IT
Governance
Emerging SOA
Governance
SOA and IT
Governance
Alignment
SOA and IT
Governance
Alignment
Ad hoc IT
Governance
Ad hoc IT
Governance
SOA and IT
Governance
Alignment
Service
Oriented
Modeling
Process
Integration
via Services
Platform
Specific
Platform
Specific
Platform
Neutral
Dynamic
Sense &
Respond
Platform
Specific
Platform
Specific
Monolithic
Architecture
Emerging
SOA
Grid Enabled SOA
Dynamically Re-
Configurable
Architecture
Component
Architecture
Layered
Architecture
SOA
Platform
Specific
Function
Oriented
Service
Oriented
Service
Oriented
Service
Oriented
Function
Oriented
Function
Oriented
Service
Oriented
Service Integration Maturity Model (SIMM)
Where are we now?

IBM Software Group
4 4/12/11 Integration and the Enterprise
Service Bus
Zone: Enterprise Service Bus
<Consumer>
<Provider>
<Provider>
<Provider>
Connector
<Consumer>
<Consumer>
Evolving an integration architecture up to SIMM Level 4
Connector
Hub
ESBGateway
Integrated
Level 2
Services
Level 4
Service
Registry
<Provider>
<Consumer>
Connector
Connector
Connector
Connector
Componentized
Level 3

What type of architectural patterns are in play as SOA matures?
Silo Services
Composite
Services
Virtualized
Services
Dynamically
Re-Configurable
ServicesComponentizedIntegrated
Service
Exposure
Service
Composition
Process
Choreography
Workflow
Hub/Broker Based
Integration
Low-level
Connectivity
Process PatternsIntegration and ESB Patterns
Level 1 Level 4 Level 5 Level 6 Level 7Level 3Level 2
SIMM Level 5: The
focus of this
presentation
What do SOA solutions look like…
http://www.ibm.com/developerworks/websphere/library/techarticles/0904_clark/0904_clark.html

IBM Software Group
Short-running BPEL Long-running BPEL
Human Tasks
Async. Initiated
Transactional
Process
Briefly
Persisted
Process
Synchronous
Transactional
Process
Versioned Long-
lived Process
Task Based
Process
What s the difference between a Business Process and a Service Composition ?
  Appear to the business as a single step
  Do not include human interaction from the business.
Business
Processes
Service Composition
  Take long enough that the business need to be
aware of their intermediate in-progress states.
  Include human interaction, or interaction with slow
responding systems.
Process Implementation Types: Patterns based design for process based solutions
http://www.ibm.com/developerworks/websphere/library/techarticles/1004_clark/1004_clark.html

IBM Software Group
Who is the process controller ?
Who owns the flow of the composition/orchestration?
From the article series Process-oriented modeling for SOA
http://www.ibm.com/developerworks/architecture/library/ar-procmod1

IBM Software Group
Agenda
 Where have companies got to on their SOA
journey?
characteristics?
 How would we expose services differently for
BPM consumers

IBM Software Group
SRP
GUI
LRP
Presentation
Layer
Process and
Composite Service
Layer
Atomic
Service
Layer
How different are UIs and Processes as consumers?
GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process
Synchronous call Asynchronous call
waiting
How are business services called
by GUIs different from business
services called by processes?

1
0
Differences in consumers requirements between
users and automated processes
  Who’s in control
–  In traditional systems, humans (via
graphical interfaces) are requesters and
back end systems are providers.
–  BPM engines are the consumers.
Providers can either be back end systems
or humans. Humans are given tasks by
the BPM system.
–  Note however, that when working on the
task, the human may be working with UIs
that call services.
  Time/Resource Management
–  If users own the flow, bad at managing
their time. They usually wait for a
response.
–  Process is very efficient at managing
time. Has to be able to free up resources.
  Exception handling
–  Humans are good at retaining a dialog
despite unexpected situations. Great at
improvising and handling diverse
exception scenarios.
–  Processes are structured – only handle
the exception scenarios that are defined
in advance. Can’t think for themselves.
  Versioning
–  Humans can dynamically handle changes
in version that perhaps provide more or
less data, or place data in different places
or present it in an unstructured form.
–  Processes fail if core data structures
change.
  Difference in quality of output.
–  Humans work with data inconsistently and
are only (just!) bounded by the validation.
–  Processes provide a consistent
predictable behavior for a given set of
data. Important for automation of the next
step in line, for management information
and for process compliance.
  Context switching
–  Humans are bad at context switching and
can get confused and cause data leakage
errors.
–  Process engines switch context with
precision and therefore can manage high
throughput with multiple processes.

IBM Software Group
Using interface characteristics to analyse interactions
<Provider><Consumer>
<Consumer>
Interface Characteristics
(basic or first pass characteristics)
Interaction type
Transport
Protocols
Data formats
Principal data objects
Re-usability
Reliability
Availability
Volumes
Time windows
Response times
Service level agreements
Message size
Throughput
Batch or real-time
Data Ownership
Privacy
Integrity

IBM Software Group
1
3
4/12/11 Interface Characteristics
Solution Context Diagram with Integration Detail
Process
OrderBilling
System
Data
Warehouse
Credit
Checking
Shipping
Product
Catalogue Order
Management
Printing
Order
(JDBC)
Customer/Credit Rating
(Web Service/HTTP)
Order Confirmation
(Web service/JMS)
Order Summary
(JDBC)
Customer/Order
(Flat file, batch)
Customer/Order
(Flat file, XML)
Product Details
(RMI/IIOP)
Order Details
(WebSphere MQ)
Customer
Relationship
Managemen
t
Customer
Relationship
Management

IBM Software Group
1
4
4/12/11 Interface Characteristics
  Principal data objects
  Request/response objects
  Operation/function
  Validation
  Transactionality
  Statefullness
  Event Sequence
  Idempotence
  Data Ownership
  Privacy
  Mean time between failures
  Maintenance schedule
  Delivery assurance
  Synchronous or Asynchronous
  Request/Response or Fire/Forget
  Batch or real-time
  Response times
  Throughput
  Availability windows
  Volumes
  Message size
  Known exception conditions
  Error management capabilities
  Transport
  Protocols
  Data formats

IBM Software Group
Agenda
 Where have companies got to on their SOA
journey?
characteristics?
 How would we expose services differently for
BPM consumers

IBM Software Group
Exposing services for BPM
Functional definition

IBM Software Group
1
7
4/12/11 Process Implementation Types
SRP
GUI
LRP
Presentation
Layer
Process and
Composite Service
Layer
Atomic
Service
Layer
HT
Common pattern for complex services exposed to GUIs
Triggering long running work,
with acknowledgement response
waiting

IBM Software Group
Functional definition
  Human Consumer
– Operation/function
–  Synchronously exposed service may only have time to trigger work and provide acknowledgement.
– Request/response data
–  Need enough data for the human consumer and may retrieve all details in a single call to reduce latency.
  Automated Process Consumer
– Operation/function
–  Asynchronously exposed service may have time to complete it.
– Request/response data
–  Need only contain keys and primary metadata. Services has time to retrieve detail. Process may need to
retrieve latest data on response anyway. Etc.

IBM Software Group
Transport/Protocol

IBM Software Group
12-Apr-11
Synchronously Exposed Service
  Where will the error be surfaced if the service is unavailable? How will
it be managed?
  How transactional is the interface? Could duplicates occur?
Automated Process
Consumer
SOAP/HTTP
Synchronous
Service Exposure
Synchronous
Request
Synchronous
Integration
Human
Consumer
(GUI)
Back
end
System

IBM Software Group
Asynchronously exposed service
  What happens if the asynchronous request takes longer to
complete than the consumers are prepared to wait?
  How would a graphical user interface manage late
responses?
Automated Process
Consumer
MQ
Request/Response
Service Exposure
MQ
Request/response
Asynchronous
integration
Human
Consumer
(GUI)
Back
end
System

IBM Software Group
Transport/Protocol
– UIs prefer synchronous interaction
– Processes prefer asynchronous, especially for updates.
– Message based exposure will be preferred
–  WebSphere MQ
–  JMS
–  WS-ReliableMessaging?
Caution: Exposing over an asynchronous transport is only half the story. E.g.
–  Are the messages persistent?
–  Is the interaction pattern long lived, or does it have early timeouts?

IBM Software Group
Integrity/Transactionality

IBM Software Group
2
4
4/12/11 Transactionality and Locking
Strategies
Transactions within synchronous interactions
ProviderRequestor
What is the minimum number of transactions required to invoke synchronously?
What about when the interaction protocol does not provide transactionality?
Transaction
ProviderRequestor
Requestor Transaction
(waits whilst the
invocation takes place)
Provider Transaction
What happens if you loose the communication channel, or the
requestor box in the middle of processing the Provider Transaction?
What happens if you loose the communication
channel, or the requestor box, or the provider box,
in the middle of processing the Transaction?

IBM Software Group
Transactions within an asynchronous interaction
Provider
Queue
Requestor
Queue
What is the minimum number of transactions required to perform a
two way asynchronous interaction?
Who (requestor or provider) will perform those transactions?
Transaction 1
Transaction 2
Transaction 3

IBM Software Group
SOAP/HTTP interaction during failure – Thought exercise
  We re providing an enterprise service on an ESB using SOAP/HTTP over the
internet.
–  How many links in the HTTP chain are there between the consumer of the service and the WPS
server?
–  In what ways could they fail? How often?
  If the consumer receives an unexpected error from the service:
–  What is the state of the back end systems that the ESB is communicating with?
–  Has the request completed or not?
–  Can you even be sure if an HTTP request has started a synchronous transaction. What about if
it only got to the HTTP Service and not to the application because the application server was
busy.
  How can we find out the state of the back end system?
–  Is there a “read” type request available on the service?
–  How long should we wait before performing the read?
–  If we perform a read request to check the result after the backend’s transaction timeout is
complete, can we assume that we know the state of the back end system?
  What happens if we re-submit the request?
–  Are the back end systems idempotent (i.e. if you call it multiple times, it will only do it once)?
–  Can we make the enterprise service idempotent, even if the back end systems are not? How
would we do that?
–  Under what circumstances would it be impossible to make a service idempotent?

IBM Software Group
© 2008 IBM Corporation27
4/12/11 Integration Patterns
Retry
  Is it safe to retry?
– Is the request transactional?
– Do duplicates matter?
– Is the request idempotent?
  If failures occur, to what extent should they be logged?
– This is a new error handling scenario for customers moving into process
automation.
–  Previously either a user, or a failed event, or a stopped process would force investigation
into the cause of an error and re-submission would be automatic.
– Design questions:
–  If it ultimately works, do we care about occasional errors that happen along the way.
–  If it regularly fails, how do we know which alternate endpoint is failing, and how/who gets
alerted?

IBM Software Group
Idempotence
Definition and examples
  An idempotent request means that no matter how many times the request is
made, the result will be the same.
  Idempotence in low level transactions ( IT transactions)
–  Read-only requests are nearly always idempotent.
–  Updates are idempotent unless they retain some level of change history (e.g. auditing).
–  Deletes are idempotent from a data perspective (you can t delete something twice), but often
not behaviourally as deletion of a non-existent entity often results in an error.
–  Inserts are not naturally idempotent. If they have a unique key constraint then they may be
idempotent from a data perspective, but behaviourally are different on the second call due to the
unique constraint error.
  Idempotence in business transactions
–  Nearly all business transactions involve inserts – the most difficult to make idempotent – even if
they appear to be only performing a simple update or delete from a business perspective. This
is either because they involve the creation of a new data item (a money transaction, purchase
order etc.), or because they are audited in some way.
–  Most business transactions are therefore not naturally idempotent – unless you explicitly design
it in.
–  The only exception is reads , but these are often costly in CPU so double submissions would
be best avoided anyway.

IBM Software Group
Idempotence
Why is it so relevant to SOA
  Idempotence is not important, or required if the transaction boundary includes
the consumer and provider.
–  In this case you know definitively if the transaction occurred. This may cater for local service
calls and interactions, but what about enterprise service calls.
  Enterprise services are typically made available over an unreliable medium
such as an intranet or the internet.
–  On error, this can leave the caller in doubt as to whether the transaction has occurred.
  If the consumer can t be sure of the success/failure of the transaction, then
re-submission may occur, at the will of the consumer.
–  Therefore more than one attempt at a transaction is likely to occur relatively often, and
duplicates may occur.
  If duplicates matter, then the consumer must poll the enterprise service to
check for completion, but:
–  Did you design in a read operation to allow the poll? Is it accessible to all consumers of the
service?
–  How long should we poll for before we assume that the request was not received? How much
do we know about the providers error handling policy? Is it part of the SLA?
  An idempotent service resolve the concern over creation of duplicates on re-
tries
–  However, what if you exhaust all your re-tries, and you still haven t had a success?
–  Idempotence allows improved reliability over an unreliable medium, but not complete
reliability.

IBM Software Group
Idempotence
Techniques (patterns?) for designing idempotence into a service
  Always perform a read before performing an insert
– Requires that you have a unique key, but what if the service creates the key?
  Hold a log of the keys you have processed already, and don t process
them on re-submission
– Again, assumes there is a unique key.
  Soak up the duplicate keys exception and return success
– However, exceptions are typically significantly more costly in CPU, generating stack
traces etc.
  Make some assumptions about the likelyhood of similar data over time
– e.g. transactions for exactly the same amount to/from the same account within an
hour are probably duplicates
– Think carefully about how/whether you report conflicts.
  Idempotence always takes extra design and development effort, and
comes with disadvantages as well as advantages.

IBM Software Group
Event Sequencing
  If sequencing required, only 3 options
– Single threaded
– Sequencer-resequencer
–  Explicit (index) - pattern found in TCP (of TCP/IP) and WS-Reliable Messaging
–  Implicit (time)
– Selective Multi-threaded*
–  Supporting event sequencing based on specific key or primary metadata that is
correlated between subsequent events
  Sequencing in the ESB doesn’t solve the whole problem!
– If events are delivered in the wrong order, or are picked up by a system that
doesn’t preserve sequence, it doesn’t matter how smart we are with event
sequencing in the ESB.
– Ensure you check the source and target event sequencing capability.

IBM Software Group
Optimistic and Pessimistic locking
– More often uses Optimistic locking
– Requires the caller to retain a unique reference to the current instance of the
data. Essentially, the first updater wins, and the second must re-fresh from the
new data and start again.
– Consumers have no direct locking control over the backend system. More
appropriate level of encapsulation for enterprise services.
– Much harder to program as all clients must be aware of extra locking data, and
have a strategy to handle failed updates.
– Improved scalability as back end systems only perform locking at the point of
update.
– More often Pessimistic locking
– Requires that some form of ownership lock is placed on the back end data.
Transactions sometimes achieve this implicitly.
– Gives consumers ownership over locks, so often considered unacceptable for
enterprise service use, especially if other systems are involved in a transaction.
– Simpler to program as update conflicts can t occur, and may be able to take part
in global transactions.
– Doesn’t scale well due to the effort required by the backend to maintain the
locks. Locks may have to be escalated to other unrelated data, resulting in
unexpected deadlocks, and general performance meltdown.

IBM Software Group
Integrity/Transactionality
Human Consumer
–  User can improvise upon in-doubt transactions.
–  Transactionality often not available.
–  More often having an In-doubt transaction.
  Idempotence
–  Must consider idempotence for business transactions since the user can retry.
  Event Sequencing
–  Users unlikely to update the same data in the services so event sequencing not as critical.
  Validation
–  Data must not all be present since can return to the human consumer for further validation.
  Locking
–  Optimistic locking conflicts can be passed back to the human consumer.

IBM Software Group
Integrity/Transactionality continued
Automated System Consumer
–  Transactionality may will make coding of exception handling much simpler.
–  In-doubt transactions can be more effectively avoided by waiting longer periods for a response.
–  However, how often can transactional interaction be achieved with back end systems
  Idempotence
–  Coding for processes to manage the effects of duplicates create as a result of re-tries would be
extremely complex. Services must either be idempotent, or use a store/forward pattern so re-try
is not necessary.
  Event Sequencing
–  Exceptions resulting from out of sequence events are extremely difficult to code for. Event
sequencing may therefore be critical.
  Validation
–  All data must be present. No original requestor present from whom to request further data.
Validation should perhaps therefore be stronger to ensure invalid data situations don’t penetrate
the service.
  Locking
–  Pessimistic locking may actually be preferred, though there are scalability issues with this.

IBM Software Group
Security

IBM Software Group
Security
– Authorization
–  Service often acts on the identity of the human consumer.
– Data ownership and privacy
–  The data is often owned by the consumer.
  Process Automation Consumer
– Authorization
–  When the process performs work, under who s credentials will it act? The originator? Would they have
access to all the services called? How do we keep their session alive? Under a system id? If so where s the
audit trail. What happens if a support user has to re-submit a request – what id should we use then?
– Data ownership and privacy
–  What data can re-submitters of asynchronous events see? Does temporary storage of the
request data outside of the system of record pose a data protection act breach?

IBM Software Group
Availability

IBM Software Group
38
Store and Forward
  Description
– If downstream system is unavailable, store requests. Automatically process
(forward) the requests once the back end system becomes available.
  Store and forward is a non-trivial design problem
– How many messages is it reasonable to expect to be able to store? How long might
an outage be? What is the request rate? What is the message size?
– What will happen to requests that occur when the back end is in error, but before we
start storing?
– How will we check the availability of the back end? (see Health Check pattern)
– How will we switch on/off the storing mechanism?
– How will we automatically start the re-submissions?
– Do we need to apply flow control to the re-submissions so we don’t overload the
backend with the stored requests?
Due to the above complexities, store and forward requirements should
be addressed on a case-by-case basis.

IBM Software Group
39
Health Check
 Detecting the health of the downstream component
– A potential dependency for other error handling patterns such as
retry, flow control, store and forward.
 Complexity
– Simple – system is alive
– Complex – alive and how well it’s processing
 Prediction/reaction
– Proactive – nanny process (polling/listening)
– Reactive – based off of error response or lack thereof

IBM Software Group
Availability
– Availability windows
– Humans often only work part of the time. Service availability should match.
– Outages
– How do we tell human consumers about service outages?
– Availability windows
– Processes can work 24/7. Are the services they talk to available over same time
periods?
– Outages
– How do we tell processes to stop trying during outages?
Healthcheck and/or store/forward pattern required.
Caution: Don t assume that if an asynchronous transport is in place, that a sensible store/forward pattern is
implemented

IBM Software Group
Performance

4
2
Throughput vs. Response time
  Throughput based (Automated Process)
–  Designed to maximize throughput, so typically
asynchronous using messages
–  No user awaiting response
–  SLA Measured in events per time period (e.g.
processes 100,000 messages per hour)
–  Pace of an individual process irrelevant
–  Performance tuned for high CPU utilisation
–  Thread count should be minimised.
–  Concurrency only related to performance
tuning.
–  Errors must be handled/resolved
–  Servers handle retries
–  Typically stateful. Survives server restart.
  Response time based (Human)
–  Designed to minimize response time, so
typically synchronous
–  Typically a user awaits the response
–  SLA Measured in time taken for response to
arrive (e.g. user waits no more than 3
seconds)
–  Performance tuned to handle peaks
–  Queue depths should be minimised
–  Concurrency relates closely to the number of
expected clients.
–  Errors can often be thrown away
–  Clients handle re-tries
–  Largely stateless. Transaction doesn t
survive server restarts – although the session
might.
Throughput based applications are architected, designed, implemented,
optimised and managed differently to Response Time based applications

IBM Software Group
4
3
4/12/11 Performance
Anti-pattern: Slow synchronous invocations hogging asynchronous threads
Scenario
  Asynchronously initiated requests from a single pool of threads
  Requests call various back end systems synchronously
  Some of the systems are significantly slower than others OR one of the systems is
intermittently slow
What happens…?
  The slow requests hog all threads most of the time, and hence block the faster
calls from being processed. Requests that should have completed quickly are
throttled to the speed of the slowest calls.
The simplest thread blocking anti-pattern in the world!
Slow System
Th
Th
Th
Fast System
Thread Pool
Queue
Solution: Increase the number of threads, and/or assign a dedicated thread pool for the slow requests

IBM Software Group
Performance
–  Response times
–  Only faster response times can be tolerated.
–  Throughput/Volumes
–  Capacity has to be sufficient to handle peaks.
–  Batch or real-time
–  Humans work with real-time and not batch.
–  Message size
–  Messages should remain small to keep response times fast.

IBM Software Group
Performance continued
–  Response times
–  Slower synchronous response times can be accommodated since no user is waiting, but at the cost of threads.
–  If an asynchronous interaction pattern is used, very long response times can be accommodated.
–  Throughput/Volumes
–  Throughput can be managed more effectively since peaks and troughs present in user interaction can be levelled in
throughput based work.
–  Batch or real-time
–  Processes can take advantage of existing batch based processes to perform work.
–  Will bulk processing volumes affect existing online user response times. Need to consider how throughput flow control
is achieved.
–  Message size
–  Larger messages can be handled due to acceptance of slower response times, and potential to perform flow control.
However, usual concerns around memory etc. apply.

IBM Software Group
Error and exception management

IBM Software Group
SRP
GUI
Business
Process
Model
LRP
Presentation
Layer
Process and
Composite Service
Layer
Atomic
Service
Layer
minutes seconds minutes or daysdays days
HT
What types of errors could occur?
Customer not found
when searching to see if
customer has registered.
Escalation
period for task
expired
Task owner has left
the company or is
on vacation
Communication error talking
to back end system
Global transaction timeout due to large
aggregated response time
Graphical user interface timeout waiting
for response from service.
Back end unavailable due to
scheduled downtime
Out of memory error due to
unexpectedly large object
In-process data issue calling
back end system
NullPointerException in Java
snippet.
Queue not found for
asynchronous invocation
Address validation fails for an address
that is known to be valid

IBM Software Group
Error and exception management
–  Exception paths
–  Coding for exceptions relatively simple users.
–  Online error management
–  Exceptions can be returned to consumers for handling.
–  Diagnosis
–  Visibility is not as important since services respond quickly.
–  Exception paths
–  Coding for exceptions must be much more explicit than would be necessary with users.
–  Offline error management
–  Need to be able to manage exceptions offline. i.e. the original source of data and/or business domain expert may no
longer be available.
–  Diagnosis
–  Due to longer running nature of asynchronous interactions a greater degree of in-flight visibility will be required for
diagnosis of where s my message scenarios.

IBM Software Group
Why do we need two services when they provide the same
functionality?
  If services used by GUIs are different from those used by
processes/applications, then aren t we creating consumer
specific services? What about re-use!
  Specific to a category of consumer, not specific to a
consumer.
– We should always avoid creating services specific to a single consumer.
However, services specific to a category of consumers may be necessary.
– Two likely consumer categories might be GUIs, and processes.
– Differences relating to functional requirements may be easier to tease out
in the analysis. Differences in non-functional requirements might not be
clear unless sufficient analysis is done into the interface characteristics.

IBM Software Group
Key Message
  Consider the integration characteristics of existing
services to see how well suited they are for use in BPM
<Consumer>
Interaction type
Transport
Protocols
Data formats
Principal data objects
Re-usability
Reliability
Availability
Volumes
Time windows
Response times
Service level agreements
Message size
Throughput
Batch or real-time
Data Ownership
Privacy
Integrity

IBM Software Services Zone for WebSphere
ibm.com/websphere/serviceszone
  BPM-specific resources including proven,
prescribed, and repeatable assets and offerings to
accelerate BPM adoption
  Visibility across the worldwide skills & capabilities
that only IBM Software Services for WebSphere can
bring to your project
  Access to WebSphere practitioners insight on
project trends, best practices & emerging
technologies through personal videos, blogs, articles
& more
  Discover defined offerings to get your project started
quickly
What s New?
The destination for WebSphere services-related resources, offerings, & technical skills
to help you on your path to business agility
Visit us in the Solution Center!
• Ped SE2: IBM Software Services for WebSphere
• Ped BD1: IBM BPM & BRM Services

  InfoCenter:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp
  Support Sites:
http://www-01.ibm.com/software/integration/wps/support/
http://www-01.ibm.com/software/integration/wsesb/support/
  DeveloperWorks:
http://www.ibm.com/developerworks/websphere/zones/businessintegration/wesb.html
http://www.ibm.com/developerworks/websphere/zones/businessintegration/wps/wps.html
  WPS Public Knowledge Compendium (41 pages of links):
http://www-01.ibm.com/support/docview.wss?uid=swg21469876

5
3
We love your Feedback!
  Don’t forget to submit your Impact session and speaker
feedback! Your feedback is very important to us, we use it to
improve our conference for you next year.
  Go to impactsmartsite.com from your mobile device
  From the Impact 2011 Online Conference Guide;
–  Select Agenda
–  Navigate to the session you want to give feedback on
–  Select the session or speaker feedback links
–  Submit your feedback

5
4
© IBM Corporation 2011. All Rights Reserved.
IBM, the IBM logo, and ibm.com are trademarks or
registered trademarks of International Business Machines
Corp., registered in many jurisdictions worldwide. Other
product and service names might be trademarks of IBM or
other companies. A current list of IBM trademarks is
available on the Web at “Copyright and trademark
information” at www.ibm.com/legal/copytrade.shtml.
Copyright and Trademarks

Impact 2011 2667 - Developing effective services for use in critical business processes

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Impact 2011 2667 - Developing effective services for use in critical business processes

Similar to Impact 2011 2667 - Developing effective services for use in critical business processes (20)

Recently uploaded

Recently uploaded (20)

Impact 2011 2667 - Developing effective services for use in critical business processes