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

Services Componentized Integrated

Level 1 Level 4 Level 5 Level 6 Level 7 Level 3 Level 2

Applications

Methods

Organization

Infrastructure

Architecture

Business View

Modules Services Process

Integration via Services

Dynamic Application Assembly

Components Objects

Structured Analysis &

Design

Service Oriented Modeling


Grammar Oriented Modeling

Component Based

Development

Object Oriented Modeling

Ad hoc IT Governance

Emerging SOA Governance

SOA and IT Governance Alignment






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

© 2008 IBM Corporation 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

ESB G

ateway

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

Services Componentized Integrated

Service Exposure

Service Composition

Process Choreography

Workflow

Hub/Broker Based Integration

Low-level Connectivity

Process Patterns Integration and ESB Patterns

Level 1 Level 4 Level 5 Level 6 Level 7 Level 3 Level 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





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?

10 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

Agenda





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

© 2008 IBM Corporation 13

4/12/11 Interface Characteristics

Solution Context Diagram with Integration Detail

Process Order Billing

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

Interface Characteristics

IBM Software Group


4/12/11 Interface Characteristics

Interface Characteristics (basic or “first pass” 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





IBM Software Group

Exposing services for BPM Functional definition

IBM Software Group

17

4/12/11 Process Implementation Types

SRP

GUI

LRP

Presentation Layer



HT

Common pattern for complex services exposed to GUIs Triggering long running work, with acknowledgement response


waiting

IBM Software Group

Exposing services for BPM 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

Exposing services for BPM 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

Exposing services for BPM Transport/Protocol

 Human Consumer – UIs prefer synchronous interaction

 Automated Process Consumer – 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

Exposing services for BPM Integrity/Transactionality

IBM Software Group


4/12/11 Transactionality and Locking Strategies

Transactions within synchronous interactions

Provider Requestor

What is the minimum number of transactions required to invoke synchronously?

What about when the interaction protocol does not provide transactionality?

Transaction

Provider Requestor

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 Corporation 27 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

  Human Consumer – 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.

  Automated Process Consumer – 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

Exposing services for BPM Integrity/Transactionality

Human Consumer   Transactionality

– 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

Exposing services for BPM Integrity/Transactionality continued

Automated System Consumer   Transactionality

–  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

Exposing services for BPM Security

IBM Software Group

Exposing services for BPM Security

 Human Consumer – 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

Exposing services for BPM Availability

IBM Software Group

38 4/12/11 Integration Patterns

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 4/12/11 Integration Patterns

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

Exposing services for BPM Availability

  Human Consumer – Availability windows

– Humans often only work part of the time. Service availability should match.

– Outages

– How do we tell human consumers about service outages?

  Automated Process Consumer – 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

Exposing services for BPM Performance

42

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

43

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

Exposing services for BPM Performance

  Human Consumer –  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

Exposing services for BPM Performance continued

  Automated Process Consumer –  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

Exposing services for BPM Error and exception management

IBM Software Group

SRP

GUI

Business Process Model

LRP

Presentation Layer



minutes seconds minutes or days days 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 Exposing services for BPM Error and exception management

  Human Consumer –  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.

  Automated Process Consumer –  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> 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 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

53

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

54

© 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