Web Services Best Practices 072604.ppt

IBM Software Services for WebSphere
© 2003, 2004I BM Corporation
Web Services Best Practices
Rachel Reinitz, Sr. Certified IT Specialist., ISSW
Co-Author
Kyle Brown, Senior Technical Staff Member, ISSW
Contributions from
Tony Cowan, Sr. Web Services Architect, ISSW
Andre Tost, Sr. Certified IBM Technical Specialist
Yaroslav Dunchych, Sr. Consultant, ISSW
Rick Robinson, ISSW EMEA
Stan Cox, WAS Performance
Harvey Gunther, Performance
Web Services Development and Emerging Technology teams
March 15, 2004

Web Services Best Practices © 2003, 2004 IBM Corporation
Key Questions this Talk Addresses
 Are web services ready to be used for production
applications?
 Where should web services be used?
 What do I need to understand about web services and
where the technologies are today to architect them into
my architecture – multiple protocols, security,
performance?
 What is the right granularity for services?
 How to I get started today and architect for the future?
 How do Web Services, Service Oriented Architecture,
and On Demand relate to each other?

Web Services Best Practices References
 “Web Services Architecture and Design Best Practices” by Kyle Brown
and Rachel Reinitz
WebSphere Technical Developers Journal October, 2003
http://www-
106.ibm.com/developerworks/websphere/techjournal/0310_brown/brown.html
 "Performance Best Practices for Using WAS Web Services“, by Harvey
Gunther
WebSphere Developers Journal October, 2003
http://www.sys-con.com/websphere/article.cfm?id=394
 Best Practices for Web Services Versioning by Kyle Brown & Michael
Ellis
IBM developerWorks, Jan. 2004
http://www-106.ibm.com/developerworks/webservices/library/ws-version/
 Enterprise Integration Patterns: Designing, Building, and Deploying
Messaging Solutions by Gregor Hohpe and Bobby Woolf, Addison-
Wesley 2003, ISBN 0321200683

Recommended Book on WebSphere includes Web
Services
Enterprise Java
Programming
with IBM Websphere,
2nd Edition
Kyle Brown et al,
Addison-Wesley,
ISBN: 032118579X

Distributed Systems Challenges
 Performance/scalability
 Management
 Accomplishing loose coupling
 Defining Granularity of interactions
 Maintaining context across systems
Transaction, security, session state
 Protocol conversions
 Versioning
 Firewall and other security challenges
 Network bandwidth
 Failover
 Problem determination/Root cause analysis
 Development/integration/test cost
Web Services are a set of technologies to enable
applications to communicate with each other

IBM’s View of Web Services
 A Web Services is described by WSDL
not limited to SOAP
multiple protocols
both synchronous and asynchronous
both RPC and document oriented
 Evolutionary
add web services to your existing designs
does not require a radical redesign
Web Services will not supplant other distributed
technologies. They will supplement them.
 You have to start with good distributed design
principles
Proper layer design and layer placement is critical to
success
 Enabling technology for Service Oriented
Architectures and On demand systems
 Standards, Standards, Standards
Interoperability is key
Use open source and commercial tools wisely and adhere
to standards
Connection
Enterprise
Security
Interoperability
Discovery
Management
Business Processes
Reliability
Publication
Description
Messaging
Transactions
Security
User Experience

Web Services Anti-Patterns

Domain
Objects
IIS
Session
EJB
(app
control
logic)
ASP
SOAP
over
HTTP
WebSphere Application Server
Web
Service
Definition
&Engine
Model
Managers
Data XML
XSLT Conversion
to Domain XML format
Convert Result Set
into XML
Data
Access Objects
DB
Domain
XML
Good: WS for
Interoperability
Bad: XML/WS
between application
layers within a single
J2EE server with no
external access
required
Scenario: Do NOT use XML or SOAP over HTTP between
Layers of an Application
Convert XML into
Domain Objects

SOAP Engine
Generated SOAP
stub
EJB
(controller/model)
Swing
(view/controller)
Java Application
SOAP
over
HTTP
WebSphere
Application Server
Presentation
Layer
Business
Layer
SOAP Engine
Web Service
Do NOT Fine-Grained calls Across Distributed Systems
Example calls
getFirstName
getLastName
getOfficePhone
…
Bad: Using WS
between WAS
application
servers (no
firewall issues,
fine grained
interaction)

Web Services Scenarios

Delivering Business Value
 The key consideration in architecting and designing the use of web
services is the business needs you are meeting
Incorporating considerations with respect to current systems
QoS requirements
Enterprise architecture directions
Cost
 The most common business need being addressed by Web
Services is need to integrate disparate applications deployed on
heterogeneous systems

Packaged
Applications
(Siebel, Oracle
Financials
B2B
(Amazon,
Google, UPS)
Other
Systems
(Perl, C++,
Cobol)
.NET
Client
J2EE
Client
J2EE
Applications
SOAP/HTTP
Interoperability between Heterogeneous Systems
Messaging
Hub
(uses Enterprise
Service Bus
Functionality)

B2B Message Exchange
 Simple B2B scenario
 Replace costly EDI infrastructure with Web Service
 Peer-to-Peer topology
 Focus on security
Inventory
Service
Railroad
Application
Security:
•Authentication
•Privacy
•Integrity
•Non-Repudiation
Web
Service
Web
Service
Integration
•J2EE and .Net
•Existing Applications
Messages
•XML vs EDI
•Message compression
Railroad Railroad
Internet

Need for an Enterprise Services Bus – Existing
Architecture
CICS
CICS
CICS
Gateway
Gateway
Translator
(x 10's)
App Server
App Server
App Server
(x 100's)
custom
protocol
SNA
 Motivating Factor: Eliminate a layer of translator servers between the Web
Application Servers and the Mainframe data
 Lots of critical business logic in Mainframe CICS transactions and DB2 Stored
procedures
 Presentation layer is implemented through high-performance, complex Web
front ends that change very often
 The bottleneck became the middle tier translation
 Translation was done through a layer of custom translator servers that exposed
a common Java API (pre-JCA) to the mainframe functionality
 Custom load-balancing, failover strategy and security

Solution: Enterprise Services Bus using WAS WS Gateway
 Eliminate the middle tier of custom built translation servers by allowing
application servers to communicate with the backend using standard
protocols
 HTTP and JMS (MQ Series)
 Move the data translation from the middle tier to the mainframe
 Use WebSphere Studio to wrap transactions and stored procedures as
Web Services
 Need for protocol translation (for async), standard security, metering, and
load-balancing between the App Servers and Mainframe
 Reduced hardware costs, reduced development time
Gateway
Gateway
SOAP
Engine
CICS
App Server
App Server
App Server
(SOAP
client) SOAP
over
HTTP
Gateway
Gateway
WS Gateway
(WAS 5.x
ND)
SOAP
over JMS
SOAP
over
HTTP
Or JMS
protocol
translation
routing/load
security
metering

Enable content and application providers to
create Interactive services that plug and
play with portals via the Internet rather than
only through the local portlets
Uses Web services
concepts
WPS
Local
Portlet
WSRP
Service
Local
Portlet
Local
Portlet
Local
Portlet
WSRP
Service
WSRP
Service
WSRP
Service
WSRP
Service
WPS
Local
Portlet
WSRP
Service
Local
Portlet
Local
Portlet
Local
Portlet
WSRP
Service
WSRP
Service
WSRP
Service
WSRP
Service
Remote
Local
Portal
Server
Web Services for Remote Portlets (WSRP)

Choosing the Granularity in SOA
 Unified Logical View
An extension of the Facade pattern -- encapsulation of technology-
specific details
 Exposing Common Legacy Interfaces
Provide new protocol access and/or interface to legacy systems
 Composable component
So that you can create business process with the elements (BPEL4WS)
 Replaceable component
Isolating requestors from change in the implementation
Most important consideration – what services are needed to
enable delivering business value

IBM Software Group | WebSphere software
"Service" Interfaces vs. "API" Interfaces ...
Think of the difference between applying for a mortgage over the phone
or by post ...
By post:
1. Client requests application form
2. Provider sends it
3. Client fills it in and returns it
4. Provider says "yes" or "no"
By phone:
1. Client calls provider
2. Provider says "Hello, how can we
help"
3. "I'd like a mortgage please"
4. "What's your name"
5. "John Smith"
6. "What's the property address"
7. "27 ..."
8. etc.
9. etc.
10. etc.
11. etc.
12. etc.
13. "... OK, your mortgage
agreement number is 12345, I'll
post the rest of the details"
Service-like - the
interaction is not
dependent on the
*identify* of the service
provider - i.e. the
completed application
form can be returned
to a different branch
than the one that
provided it.
API-like - the
interaction is
dependent on the
specific
representative of the
estate agent - i.e. the
*identity* of the
service provider
IBM Software Group | WebSphere software
"Service" Interfaces vs. "API" Interfaces ...
Think of the difference between applying for a mortgage over the phone
or by post ...
By post:
1. Client requests application form
2. Provider sends it
3. Client fills it in and returns it
4. Provider says "yes" or "no"
By phone:
1. Client calls provider
2. Provider says "Hello, how can we
help"
3. "I'd like a mortgage please"
4. "What's your name"
5. "John Smith"
6. "What's the property address"
7. "27 ..."
8. etc.
9. etc.
10. etc.
11. etc.
12. etc.
13. "... OK, your mortgage
agreement number is 12345, I'll
post the rest of the details"
Service-like - the
interaction is not
dependent on the
*identify* of the service
provider - i.e. the
completed application
form can be returned
to a different branch
than the one that
provided it.
API-like - the
interaction is
dependent on the
specific
representative of the
estate agent - i.e. the
*identity* of the
service provider

WebSphere Application Server (WAS)
DB2
DB2
Mainframe
CICS and
CICS Java
Gateway
Employee Service Implementation
JCA
CICS
mapper
JDBC
JDBC
mapper
3rd
party
system
custom code
Business
logic
(decides which
backends to call
and merges data)
Empl.
Service
Session
EJB
JAX-
RPC
Empl
SEI
SOAP
Engine
Facade
Unified Logical View – Hide the implementation details.
Do not expose existing legacy interfaces/transactions – provide new abstraction (Façade Pattern)

Adapting Common Legacy Interfaces to New Protocols
Existing interface at good level of granularity for the business service (Adapter Pattern)
SOAP/HTTP(S)
WebSphere
Channels
Everyday
Banking
CICS systems
Branch
.Net Client
Customer
Information
Loans and
Mortgages
Term
Investments
Mutual
Funds
Internet
WebSphere
(Linux)
EXCI,
3270,
2980
Call Center
.Net Client
Adapter Service
Adapter Service
Adapter Service
Adapter Service
Adapter Service
Middle Tier
Product
Systems

Web Services Process - “Choreography"
 Business Process Execution Language for Web Services (BPEL4WS)
 Define flow as abstract series of activities
 Each activity is implemented by a WSDL interface
 Provides means for handling shared state, compensations, faults etc.
 Expose a process as a web service
Web
Service
Choreography
Activity 1
Shared
state and
context
Public
Private
Web
Service
Web
Service
WSDL
Interface
WSDL
Interface
WSDL
Interface
Activity 2 Activity 3
Individual
application
transactions

Business Process
Function Service
Member Requests an Rx
Refill (Call Center IVR or
Online)
Request
Denied
Rx Dept
Processes
Refill
PC Physician
Approves or
Denies Request
(WS or Email)
Member Informed that
Refill is Ready
Validate
Member is
Authorized to
Make Request
Determine Member’s Coverages
and Primary Care Physician
Send Request
Notification to
pharmacy
Send Request
Notification to Notes
Patient
Records
Business Transaction
Member Informed that
Request has been Denied
Request
Approved
WS Enabled
Not WS
Enabled
Credit
Verification
Office
Scheduling
Email
System
Authorization Service
Email Service
Outpatient Service
Masters Service
HR
- long running
- one or more persons interacting
- multiple valid BP states
- alternative workflows for non-normal conds
- short term, non-interactive
- one change of business state or STP
- consumes one or more enterprise service
-targeted level of service reuse
- loose coupling very important
- may require compensating transactions
- collaborations to implement a single WS
- collaborating apps encapsulated via WS(s)
- performance more important than loose
coupling
Composable Web Services – Request Prescription Refill

Insurer A
Adapter
Insurer B
Adapter
Insurer C
Adapter
Broker
getQuote Insurer A
Insurer B
Insurer C
Insurer X
Adapter
Quote WSDL
Private
UDDI
Registry
Replaceable Component
 In one insurance application, the broker obtains policy quotes from
several different systems
 Think of this as a large-scale application of the Strategy pattern

Where to Use Web Services
 Implementing a Service Oriented Architectures with an Enterprise
Service Bus
 Interoperability between heterogeneous systems
 B2B
 Adding flexibility to business
Delivering information via services, ex. WSRP
Replaceable component
 Deployability
Ability to get through firewalls, handle content based routing and filtering
 Enable reuse by exposing legacy applications over new protocols
 To expose a common, language neutral interface and hide
implementation details
 Unified view and business logic
 Loose coupling
Defer the choice of transport and supporting multiple protocols
 Minimize impact of changes in one system effecting other systems

Web Services Relationship to
Service Oriented Architecture and
On Demand

 An approach for building distributed systems
that deliver application functionality as services
to either end-user applications or other services
 It defines :
An architecture that leverages open standards to
represent software assets as services.
Provides a standard way of representing and
interacting with software assets
Individual software assets become building blocks
that can be reused in developing other
applications
Shifts focus to application assembly rather than
implementation details
Used internally to create new applications out of
existing components
Used externally to integrate with applications outside
of the enterprise
What is a Service Oriented Architecture?

SOA
Web services
Build Deploy
Consume
Manage Secure
SOA and Web Services

Flexible Business Models
Transformation
Business Process Outsourcing
Mergers, Acquisitions & Divestitures
Increased financial pressures require greater
flexibility from business models and supporting IT
architecture
Composable
Processes
Flexible IT Architecture
On demand Operating Environment
Requires
Composable
Services
Software
Developme
nt Integration
Infrastructure
Management
Service Oriented Architecture (SOA)
Developm
ent
Infrastruct
ure
Managem
ent

Web Services – Multiple Protocols

Sync Async Broadcast Queued
(Latency)
Reliable
Delivery
Open
Standard
Message
Queue
X X X X * (JMS –
Java only)
HTTP X X
SMTP X X X X
RMI-IIOP X X X*
Choose the Protocol based on the Requirements

Remote EJB IF
JAX-RPC Service
Endpoint Interface (SEI)
MDB
Local EJB IF
EJB Impl
Java clients, Servlets/EJBs
in other JVMs
Non-Java clients JMS-enabled clients
Servlets, EJBs
in the same JVM
RMI-IIOP
SOAP/HTTP XML/JMS
Java
Balancing J2EE protocols
 If the application server may have Java as a service requester, may
want that Java client to make an RMI/IIOP call to an EJB instead of
using SOAP over HTTP.
 Support both RMI/IIOP and web services interfaces
 Support SOAP over JMS for reliable messaging

Between Java Application Servers – SOAP/HTTP vs.
RMI/IIOP (WebSphere 5.1)
 Performance
SOAP/HTTP approaching RMI/IIOP for complex types
Do not eliminate SOAP/HTTP due to performance without testing it
For best performing, use RMI/IIOP (for now)
 Security
Security context maintained with little cost over RMI/IIOP
HTTP/S gets through firewalls much more easily then IIOP
HTTP/S works well for single hops, but not across multiple hops needs
WS-Security
WS-Security bridges from SOAP to EJB, but at significant performance
cost and interoperability is still being worked out
 Transactional Context
RMI/IIOP maintains transactional context
WS-Transaction is not yet available

JMS or HTTP for Synchronous Web Services Interactions
 The only reason to use JMS for Sync SOAP service is if it is the
existing protocol choice for the application exposing web services
 Whether using HTTP or JMS, client code needs to handle timeout
situation
 When using HTTP if service is unavailable, fault returned immediately
 When using JMS if service is unavailable, must wait for timeout to
occur
 Use of persistent queues (guarenteed delivery) does not provide any
additional QoS for sync and will degrade performance

Location Transparency and
Invocation Frameworks

Location Transparency and Invocation frameworks
 Want web service requestors to be unaware of the service
endpoint
Preferably also unaware of binding/protocol information
 Read endpoint from startup configuration or lookup dynamically
Register implementation WSDL with endpoint in UDDI
Cache the endpoint in the requestor for efficiency
 Want binding/protocol to be part of the configuration or
deployment of the requestor, not in the requestor code
 Would like containers or intermediaries to apply ‘policies’ to
determine correct binding and endpoint choice

Describing Multiple Protocols in WSDL
Java
EJB
Java
JCA
CICS
IMS
MQ
A
B
C
D
E
F
Reserve
Cancel
Reserve
Cancel
Reserve
Cancel
Charge
Refund
Java code
SAP
etc
WSDL
Legacy/EAI
Adapters
JMS/MQ
RMI/IIOP
RMI/IIOP
BPEL
JMS
RMI
IIOP
Operational definition:
A service is an
application function
exposed with any
protocol that can be
described in WSDL
not necessarily with
SOAP!
This is why WSDL is more
important to SOA than SOAP.
SOAP is still the best way to
interoperate with a different
organization

Client
DelegateFactory
RemoteEJBDelegate
LocalEJBDelegate
WebServiceDelegate
RemoteEJBInterface
LocalEJBInterface
ServiceEndpointInterface
SessionEJBImpl
RMI -IIOP
Java call
SOAP/HTTP
DelegateService
<<interface>>
Delegate design pattern as an Invocation Framework
 A Stateless Session EJB is a preferred web service implementation
 Want to hide the protocol used to call the EJB functionality
 Consider using the adaptation of the Business Delegate Pattern (from
Crupi’s J2EE Patterns)
 Client is written to interact with the Delegate interface and use the
DelegateFactory to get the actual Delegate implementation

Service Invocation Choices
Java
EJB
Java
JCA
CICS
IMS
MQ
A
B
C
D
E
F
Reserve
Cancel
Reserve
Cancel
Reserve
Cancel
Charge
Refund
Java code
SAP
etc
WSDL
Legacy/EAI
Adapters
JMS/MQ
RMI/IIOP
RMI/IIOP
BPEL
JMS
RMI
IIOP
WSAD
Proxy
WSIF
deprecated!
App
JAX
RPC
...

Separating Application Data/Logic from Quality of Service
( QoS)
 Key is use of headers to provide data about the processing of
the message
Not application data
 Separate the processing of the headers from the application
logic
Express processing rules declaratively in configuration files
Application server containers are starting to provide processing of
headers (ex. WS-Security)
Write your own configurable components to process headers
 Supported by standards
SOAP header
WSDL description of header
WS-XX standards mostly target adding information to message
header
WS-Policy framework

SOAP Headers
 SOAP Headers are an important feature of SOAP (maybe the most
important feature)
Separate application processing, QoS information from the application data
 So we want containers and custom code to be able access SOAP
headers
 Containers are adding support to directly process headers
Example: In WAS 5.0.2 supported WS-Security headers are specified as part of
deployment. WAS will process the header and propagate security context from the
web service message to J2EE security context
<SOAP-ENV:Envelope ….">
<SOAP-ENV:Header>
<wsse:SecurityToken>
<wsse:TokenType>wsse:X509v3</wsse:TokenType>
</wsse:SecurityToken>
</SOAP-ENV:Header>
<SOAP-ENV:Body> ….
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Enterprise Service Bus (ESB)
 The “enterprise service bus” concept is often used to describe the mechanism by which services
interact with requestors and each other i.e. it provides the communication infrastructure
 The “enterprise service bus” should provide:
A consistent, location-transparent and protocol-independent means to address services.
A consistent and location-transparent means to mediate/route between service requests and
responses based on that address.
This means that service endpoints need only to be concerned with connecting to some local
communication protocol (i.e. able to open an HTTP socket or place a message on /
retrieve a message from a local queue).
Communicate service requests / responses through whatever mixture of protocols (HTTP,
messaging etc.) that provide connectivity between any set of end-points.
Ability to deploy mediations for a specific service or group of service
Enterprise Service Bus
Local JAX-
RPC
Requestor
Mediations(s)
SOAP
Requestor
Local
Service
Remote
Service
MQ
Requestor

Enterprise applications Enterprise data
Data Access Services
Application Access Services
IBM Software Offerings
Monitoring Services
Business Integration Reference Architecture
Model, design, development, test tools
Common Runtime Infrastructure
WebSphere BI Modeler
WebSphere BI Monitor
Web Services Gateway WebSphere BI Event/Message Broker
WebSphere MQ
WebSphere BI Adapters DB2 Information Integrator Classic
WebSphere Studio
DB2 Information
Integrator
WebSphere
Business
Integration
Server
WebSphere
Business
Integration
Connect
WebSphere
Application Server
Process
Services
Community
Integration
Services
Application
Services
Information
Services
WebSphere
Portal Server
User Interaction
Services

WS-Policy
 Policies describe the capabilities and requirements of service providers and
consumers, e.g.
Encryption required
Digital Signature required
 WS-Policy is a domain-neutral framework for defining policies
 Policies are associated with services or requestors
Communicate the service or requestor what QoS are expected
Can be attached to particular WSDL
 Matchmaking Vision:
Matchmaking engine will find Service Providers with required business function,
and matching policy
Could be part of Enterprise Service Bus
Selection will become more complex
Combination of multiple requirements
Eg only use secure service if amount > $10
Matchmaking is an emerging technology; early versions are available in the
Emerging Technology Toolkit (ETTK) on Alphaworks

Example of WS-Policy
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsp:ExactlyOne>
<wsse:SecurityToken wsp:Usage="wsp:Required“
wsp:Preference="100">
<wsse:TokenType>wsse:Kerberosv5TGT
<wsse:TokenType>
<wsse:SecurityToken wsp:Usage="wsp:Required"
wsp:Preference="1">
<wsse:TokenType>wsse:X509v3</wsse:TokenType>
</wsp:ExactlyOne>
</wsp:Policy>

Web Services Performance
Best Practices
Work by Harvey Gunther and Stan Cox – WebSphere
Web Services Performance experts

Summary of WS Performance Best Practices
 Best web services call is no web services call
Really no distributed system call
 Be smart about designing your DISTRIBUTED application
Create a prototype and test it under load
 Test performance before assuming you have a performance issue
Time spent in Web Service processing maybe small % of your overall
processing time.
You can use Tivoli Performance Monitoring to measure the time required to
process Web services requests.
 SOAP over HTTP (in WAS 5.1) approaches comparable performance
to RMI/IIOP
Particularly for complex types, within 20 – 40%
 XML, Java, and Web Service engines are getting faster quickly
Use the fastest engines you are comfortable with

Summary of WS Performance Best Practices (cont.)
 Designing Messages
Medium granularity web services perform best
Avoid fine-grained calls
Large payloads may result in network delays
Simpler schemas perform better
Avoid Deep Nesting of Objects
Choose RPC/literal or document/literal wrapped over SOAP Encoding
 Use Application Server caching capabilities
WebSphere has declarative based caching of SOAP requests.
Web service specific components used to construct a cache-id
 Use EJB “pass by reference”
Avoid Overhead of “Pass By Value” Marshalling
So set WebSphere to use ‘no local copies’
 Beware of WS-Security performance

Avoid Fine Grained Messages
 The next slide shows the performance implications of fine-grained
messaging. Assume you have a 50K object that has 50 properties,
each 1K long. You can retrieve this object:
– in one Web service request of 50K;
– in 50 requests for 1K each;
– in some other combination, such as 10 requests for 5K each.
 Transferring the 50K in one single Web services request is the
best-performing alternative. Transferring 1K, 50 times is the worst-
performing alternative. The overhead cost of latency is the major
factor.

Performance Comparison of sending 50K length
Retrieving 50K * 1, 5K * 10, 1K * 50
156
44
11
173
300
900
0
20
40
60
80
100
120
140
160
180
50K * 1 5K * 10 1K * 50
Payload Size
Requests
Per
Second
0
100
200
300
400
500
600
700
800
900
1000
Response
Time
ms
Avoid Fine Grained Messages
From Harvey Gunther

A brief look at the past….
214
502
680
125
210
410
16
33 91
0
100
200
300
400
500
600
700
Requests
per
second
1K / 10 10K / 100 100K / 1000
Input Payload Size and Complexity
WebSphere 4.0 SOAP WebSphere 5.0 Tech Preview WebSphere 5.0.2 WS
Analysis
 WAS 5.02 Web Services engine is IBM
technology
 Performance improving architectural
changes
IBM XML Parsing technology, SAX based
processing, Custom serializers
Standards based programming model
(JAX/RPC), etc.
Numerous algorithm/code enhancements
 WAS 5.02 Web services performance
improves ~2-3x across a set of primitive
workloads as compared to Apache and
WAS 5.0 Tech preview

Web Services Product Information

WebSphere 5.0.2/5.1 Web Services support
 Base WebSphere AppServer
Enhanced performance (SAX Based)
JSR 101 (JAX-RPC) 1.0 and SAAJ 1.1
JSR 109 1.0
WS-I Basic Profile 1.0
WS-Security
ASTK support
SOAP/JMS support
JSR 109 performance monitoring support
Enhanced Command line tools
WSIF (additional providers for WAS 5.02 engine)
Web Services Caching
UDDI4J version 2.0
Apache SOAP
 Network Deployment (ND) WebSphere AppServer
Web Services Gateway – JAX-RPC handlers, performance improvements, WAS HTTP and JMS channels
UDDI Registry – Custom taxonomy support
 Enterprise Edition WebSphere AppServer
Web services Gateway filter programming model
Web Services Choreography

WebSphere Studio Application Developer
5.1/5.1.1 Web Services Support
 Eclipse 2.1
 JDK 1.4 (5.1.1)
 WAS 5.1, 5.02, 5.0, 4.0, Apache AXIS 1.0 runtimes supported
 Web Services wizards enhanced to support features of WAS 5.02
Support for document literal and RPC SOAP-encoded
Support for SOAP over JMS for EJB web services
Default WS-Security options
 WS-I
produce and consume WS-I compliant WSDL
Validation of WSDL and of SOAP Messages
 WSDL Editor and validator
 Deployment descriptor editors
 Command line tools
 Web Services Explorer expanded
UDDI custom taxonomy definition
Dynamic testing of web services defined by a WSDL file
 Web Services discovery dialog as part of Java Server Faces tooling (5.1.1)
 Expanded preferences, cheat sheets

WebSphere 5.1 WS Gateway Functionality
 Configurable runtime component
HTML web admin GUI
 Maps WSDL documents
Target service maps to Gateway service
Target bindings replaced by gateway bindings
Target service/port replaced by Gateway service/port
Handles UDDI lookup/publication
 Service proxy capability
 Processes requests
WS-Security support
Handles authorization
Forwards requests to target service
Sends responses back to originator
 Protocol conversion
Using JAX-RPC or WSIF support
 Support Intermediation
Pluggable protocol independent request/response filters (WSIF)
JAX-RPC Handler chains
Selective Parsing (only headers) for high performance

Additional Web Services Design
Best Practices – will NOT Be
Talked about in Presentation

Client cache
Business
Delegate Web Services
Proxy
Load
Balancer
Stateless
Web Service
Stateless
Web Service
Stateless
Web Service
Design Best Practices
 Web Services should be coarse-grained interfaces
 Web Services should be stateless
Even though it's possible to use transport state mechanisms they
should be avoided
 The best web service call is NO web service call
 Design your web services (data being exchanged) to meet
business needs and for performance
 Consider asynchronous messaging instead of synchronous RPC-
style interaction
asynchronous is a more loosely coupled interaction model

WS-I Basic Profile
 HTTP V1.1
specific on HTTP errors and response codes
must not require cookie support
 XML 1.0 and XML Schema 1.0
may use any construct from Schema 1.0
 SOAP V1.1
Use of SOAP encoding disallowed
specific on structure of fault and when to generate faults
“Trailers” (element content after soap-env:Body) disallowed
Use of SOAPAction, soap-env:actor clarified
 WSDL V1.1 with SOAP use="literal"
Exclude use of wsdl:import for XSD files
Numerous spec clarifications
only one element in the Body of the element
 UDDI V2.0
Established category to identify WS-I conformant entities
tmodels must use WSDL as descriptive language

Use WAS 5.02 or later for Web Services
 Earlier versions of WAS use Apache SOAP web services engine
 Apache SOAP does not support WS-I
Only support RPC SOAP-encoded style of web services
Very limited interoperability capability
Performance is not very good
 Java Web Services Standard APIs
JAX-RPC and JSR109
Handler support
 Full WS-I support
 WS-Security support
 JMS support
 JMX MBean for monitoring web services
 Latest version of WAS is consistently much faster than previous version
 UDDI Private Registry (additional features)
 Web Services Gateway
extensive features added
improved performance

But if Customer is on WAS 5.01 or earlier – seriously
consider using Apache AXIS (open source) instead of
Apache SOAP versus AXIS/JAX-RPC
AXIS
 Open source
 Supported by WSAD 5.1 +
 Implements JAX-RPC
programming APIs
 Document/Literal and
RPC/SOAP encoded
supported
 WS-I compliant
 Better performance than
Apache SOAP
 Runs inside of WebSphere
 Easy migration to WAS 5.02 +
 Adds proprietary features
beyond JAX-RPC
 Proprietary deployment model
WAS Apache SOAP
 IBM Product support
 Runs inside of WebSphere
 Supported by WSAD 4.0 +
 Proprietary programming APIs
and features
 RPC/SOAP encoded only (not
WS-I compliant)
 Proprietary deployment model

Summary of the Security Road Map
SSL/TLS offers several security features including authentication, data integrity
and data confidentiality but only for individual hops.
What is needed in a comprehensive Web service security architecture is a
mechanism that provides end-to-end security and greater functionality.

Summary of the Security Road Map (cont)
A Web service can require that an incoming message prove a set of claims
(e.g., name, key, permission, capability, etc..)
A requester can send messages with proof of the required claims by
associating security tokens with the messages.
When a requester does not have the required claims, the requester or someone
on its behalf can try to obtain the necessary claims by contacting a security
token service (also a web service).

WS-Security for Web Services
 WS-Security spec describes a SOAP header
that may contain information to secure the
SOAP message and the process of
incorporating security mechanisms (like XML
Digital Signature and Encryption) into a SOAP
message.
Security token propagation
UsernameToken, X.509, Kerberos, SAML, etc
Can be used for identity assertion
Message Integrity
XML Digital Signatures
Message Confidentiality
XML Encryption
Note that you could continue to just use SSL for
integrity and confidentiality but you would lose
the benefits of message based security.
WS-Security for Web Services
SOAP Header
SOAP Envelope
SOAP Body
WS-Security Header
Message content

There are two particular parts of the WSDL Binding to examine
ƒ The binding style (Document or RPC)
ƒ The encoding use (literal or encoded)
Document RPC
Literal Default for MS
tools
MS does not
support
‘SOAP’
Encoded
Should never
occur
Earlier
Standard choice
for Java tools
 First generation of Java tools supported RPC Encoded (often exclusively)
 MS always supported Document literal
 WAS 5.02+ supports RPC Literal, Document Literal, and RPC SOAP
encoded
WSDL SOAP binding choices
WS-I - Do use
literal
WS-I - Do not
use encoded

SOAP Encoded
<binding name="TemperatureConverterBinding" type="tns:TemperatureConverter">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="fahrenheitToCelsius">
<soap:operation soapAction="" style="rpc"/>
<input name="fahrenheitToCelsiusRequest">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:TemperatureConverter" use="encoded"/>
</input>
Literal
<binding name="CSharpTempConverterSoap" type="s0:CSharpTempConverterSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="celsiusToFahrenheit">
<soap:operation soapAction="http://wsbootcamp.com/webservices/celsiusToFahrenheit"
style="document" />
<input>
<soap:body use="literal" />
</input>
WSDL Encoding Example

“Wrapped” Document Literal
 If you use doc literal, the message may be “wrapped” or
“unwrapped”
 Wrapped basically means that the name of the operation is
part of the message schema
Message is ‘wrapped’ in another element that represents the
operation
Additional complex type when generating WSDL from code
 Essentially makes document style invocation look like RPC
 Easier for the server to identify which method to call
If not wrapped, the server must parse the message and look for
an appropriate operation that takes that message
 Assume that wrapped document literal will be the normal
case
This is what MS does already
Default of WSAD 5.1

Backups

The On Demand Architecture
On Demand Operating Environment Architecture
U
S
E
R
B
U
S
I
N
E
S
S
Enterprise Services Bus
Autonomic Services
Utility Business Services
Resource Virtualization Services
Information
Integration
Services
Business
Application
Services
Business
Process
Choreography
Services
Common
Services
Access
Services
Business
Process
Services
Business Connections
Mediation & Messaging, Events
Availability
Management
Security
Management
Billing
License Mgmt
Services
Rating
Metering
Services
Server Storage
Distributed
Systems & OGSA
Network
Choreography
Engine
Personalization
Reporting
Custom
Applications
Packaged
Applications
Topologies
Business Rules
Modalities
ETL
Acquired
Services
Business
Performance
Management
Business
Process
Services
Data
Access
Services
Automation Services
Provisioning
Management
Optimization
Management
Policy Based
Orchestration
User
Interaction
Services
Collaboration
Presentation
FormFactors
Business
Process
Services
Business
Process
Services
Business
Process
Services

Steps on the SOA adoption path
Point
of
Entry
Business
Value
On Demand
Business Transformation
4
Leverage SOA for outsourcing, off-
shoring, hosting, etc
Enterprise Wide IT
Transformation
Using SOA
3
Leverage existing EAI
infrastructure to build enterprise
wide SOA using ESB
Service Oriented
Integration
(BU or Department
Level)
2
Integrate several applications,
develop some new application
logic, model and choreograph
processes
Point of Entry
Web services
1
Make existing application available
to multiple clients via a web
service using App Server as
middle tier
Use Case

Enterprise Service Bus Defining Concepts – the
IBM View
Service Orientation
Middleware that facilitates
loose coupling between
software components.
Interoperability
Open protocols support the
interoperability of middleware from
multiple vendors.
Incremental Integration
The distribution of low-function
message brokers to provide low
initial costs and step by step
growth capabilities.
Heterogeneity
Integrated, multi-protocol, multi-API, message
distribution, routing and processing middleware to
support extremely diverse systems and
applications.
Substitution
Open APIs allow the
substitution of middleware
from different vendors.
Event Orientation
Decoupling applications
that publish business
events from subscribing
applications.
Qualities of Service
A variety of qualities of
persistence, performance,
reliability, security,
availability and
transactionality.
Universality
A universal connectivity
layer extends the scope
and scale of integration
across an extended
enterprise

Process
Server
Community
Integration
Server
Business Integration Reference Architecture
Services to Meet Business Requirements
Application
Server
Development Tools, Services
Model, Design, Development, Test Tools
Monitoring Server
Data Access Server
Enterprise Data
User
Interaction
Server
Common Runtime Infrastructure*
Enterprise Applications
Application Access Servers
Information
Integrator
Server

Implementing an Enterprise Service Bus Today
 WebSphere MQ and WebSphere BI Message Broker provide the basis for
today's service bus
 WebSphere MQ
provides message transport for SOAP and other data formats, accessible from
both JMS and .NET
 Message Broker
provides access to a variety of transport with different QOS, including HTTP and
MQ.
Provides data transformation and routing (mediation) services
 WebSphere BI Connect and the WebSphere Web Services Gateway
extend the bus to external service consumers and external service
providers

WebSphere 5.1 Web Services Gateway
SOAP/HTTP
query
Requstor
External
UDDI
Internet DMZ Intranet
firewall firewall
SOAP/HTTP
other channel
Service
Provider SOAP/HTTP
Private
UDDI
Requestor
Service
Provider
SOAP/HTTP
EJB/RMI-IIOP
SOAP/JMS
WSIF provider
publish
publish
query
‘Filters’
‘JAX-RPC
Handlers’
WS Gateway can be used to implement an Enterprise Service Bus TODAY.
WAS
5.1
WS
Gateway

 WebSphere MQ and WebSphere BI Message Broker provide the
basis for today's service bus
 WebSphere MQ
provides message transport for SOAP and other data formats,
accessible from both JMS and .NET
 Message Broker
provides access to a variety of transport with different QOS, including
HTTP and MQ.
Provides data transformation and routing (mediation) services
 WebSphere BI Connect and the WebSphere Web Services
Gateway extend the bus to external service consumers and
external service providers

Service provider policies
 Policy documents can be created/rendered from
configuration and deployment information at runtime
Bottom-up: Configuration files define WS-Policy document
Top-down: WS-Policy document requires particular configuration
 Service provider requirements and capabilities can
be
Integral to the business logic of a service
Requirements that the business logic places on the infrastructure
Functions of the infrastructure alone
 Client separates the business logic from the
mechanisms used to satisfy the policies
Finds policy documents from WSDL, UDDI
Invokes domain-specific policy providers to interpret policy
Invokes domain-specific mediations to implement policy

MQ
Messag
e
Brokers
Application
Servers
Integration
Server
MQ
Portal
Web Clients
Web Browsers
Legacy
Application
s
 The service bus within the enterprise will evolve to include existing MQ and
Event/Message Broker networks, seamlessly integrated with new
WebSphere platform messaging capability packaged in Application Servers,
Integration Servers, and potentially stand-alone offerings
 The messaging capabilities packaged within the App Server and Integration
Server will provide them with inherent messaging services and an on-ramp to
the enterprise bus.
 The bus will extend outside the enterprise via appropriate gateways such as
WebSphere BI Connect and the Web Services Gateway

WebSphere 5.x Web services performance monitoring
 WAS 5.02 provides detailed
performance monitoring for
Web services
Size of request and response
payloads
Response times
full request
Web services specific
processing
…
Counter/Statistic Name Description
numberReceived Number of requests service received
numberDispatched Number of requests service dispatched/delivered
numberSuccessful Number of requests service successfully
processed
responseTime The average response time, in milliseconds, for
a successful request
requestResponseTime The average response time, in milliseconds, to
prepare a request for dispatch
dispatchResponseTime The average response time, in milliseconds
between dispatch of a request and receipt of
reply
replyResponseTime The average response time, in milliseconds, to
prepare a reply after dispatch
size The average payload size in bytes of a received
request/reply
requestSize The average payload size in bytes of a request
replySize The average payload size in bytes of a reply

WAS 5.02 Tivoli Performance Viewer - Demo

Web Services Best Practices 072604.ppt

Recommended

More Related Content

Similar to Web Services Best Practices 072604.ppt (20)

Recently uploaded (20)

Web Services Best Practices 072604.ppt