Date post: | 19-Aug-2015 |
Category: |
Software |
Upload: | brian-petrini |
View: | 32 times |
Download: | 0 times |
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
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
© 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
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
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
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 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
© 2008 IBM Corporation 14
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
© 2008 IBM Corporation
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
17
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
GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process
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 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
© 2008 IBM Corporation 24
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
© 2008 IBM Corporation
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
© 2008 IBM Corporation
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
© 2008 IBM Corporation 28 4/12/11 Integration Patterns
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
© 2008 IBM Corporation 29 4/12/11 Integration Patterns
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
© 2008 IBM Corporation 30 4/12/11 Integration Patterns
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
© 2008 IBM Corporation 31 4/12/11 Integration Patterns
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
© 2008 IBM Corporation
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
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
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
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
SRP
GUI
Business Process Model
LRP
Presentation Layer
Process and Composite Service Layer
Atomic Service Layer
minutes seconds minutes or days days days
HT
What types of errors could occur?
GUI Graphical User Interface HT Human Task SRP Short-running Process LRP Long-running Process
“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