3 8 0-ApplianceOverview

WebSphere DataPower SOA Appliances

Version 3.8.0
Appliance Overview
WebSphere DataPower SOA Appliances
®

Version 3.8.0
Appliance Overview
Note
Before using this information and the product it supports, read the information in “Notices and trademarks” on page 41.
First Edition (November 2009)

This edition applies to version 3, release 8, modification 0 of IBM WebSphere DataPower SOA Appliances and to all
subsequent releases and modifications until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 2002, 2009.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Preface . . . . . . . . . . . . . . . v TCP Proxy service . . . . . . . . . . . . 22
Who should read this document . . . . . . . . v XSL Coprocessor . . . . . . . . . . . . 22
How this document is organized . . . . . . . v XSL Proxy . . . . . . . . . . . . . . . 22
Publications . . . . . . . . . . . . . . vi XML Firewall . . . . . . . . . . . . . . 23
Installation and upgrade documentation . . . . vi Web Application Firewall . . . . . . . . . . 23
Administration documentation . . . . . . . vi Multi-Protocol Gateway . . . . . . . . . . 23
Development documentation. . . . . . . . vi Web Service Proxy . . . . . . . . . . . . 24
Reference documentation. . . . . . . . . vii B2B Gateway . . . . . . . . . . . . . . 25
Integration documentation . . . . . . . . vii Low Latency Messaging . . . . . . . . . . 25
Problem determination documentation . . . . vii
Supplemental documentation . . . . . . . viii Chapter 6. Key administrative functions 27
External resources . . . . . . . . . . . . viii Controlling access . . . . . . . . . . . . 27
Typeface conventions . . . . . . . . . . . ix Access control list . . . . . . . . . . . 27
Key prerequisites . . . . . . . . . . . . ix Accounts and groups . . . . . . . . . . 27
Role-based management . . . . . . . . . 27
Chapter 1. Introduction . . . . . . . . 1 Application domains . . . . . . . . . . . 27
At a glance . . . . . . . . . . . . . . . 1 Configuration management . . . . . . . . . 28
Physical characteristics . . . . . . . . . . . 2 Importing configurations . . . . . . . . . 28
Software architecture . . . . . . . . . . . 2 Exporting configurations . . . . . . . . . 28
Administrative model . . . . . . . . . . . 2 Comparing configurations . . . . . . . . 28
Web-based graphical user interface . . . . . . 3 Managing files . . . . . . . . . . . . . 28
Command line interface . . . . . . . . . 3 Appliance management . . . . . . . . . . 29
SOAP-based XML management interface . . . . 3 Time settings . . . . . . . . . . . . . 29
Programming model . . . . . . . . . . . . 3 Shutting down and rebooting . . . . . . . 29
Configuration architecture . . . . . . . . . . 4 Uploading firmware images . . . . . . . . 29
Secure network communication . . . . . . . . 5
Logging and monitoring . . . . . . . . . . 5 Chapter 7. Configuration procedures 31
Monitors. . . . . . . . . . . . . . . . 5 Network services and user access configuration . . 31
Available add-on features . . . . . . . . . . 6 Application development . . . . . . . . . . 31
Production management . . . . . . . . . . 32
Chapter 2. Appliance types . . . . . . 9
XML Accelerator XA35 . . . . . . . . . . . 9 Chapter 8. Decision-making for
XML Security Gateway XS40 . . . . . . . . 10 solutions . . . . . . . . . . . . . . 33
Integration Appliance XI50 . . . . . . . . . 11
B2B Appliance XB60 . . . . . . . . . . . 13
Appendix A. Getting help and technical
Low Latency Appliance XM70 . . . . . . . . 13
assistance . . . . . . . . . . . . . 37
Searching knowledge bases . . . . . . . . . 37
Chapter 3. Document processing . . . 15
Getting a fix . . . . . . . . . . . . . . 37
Phases of document processing . . . . . . . . 15
Contacting IBM Support . . . . . . . . . . 38
Client-side processing . . . . . . . . . . . 16
Processing policy in the DataPower service . . . . 16
Server-side processing . . . . . . . . . . . 16 Appendix B. Standard and
Error handling . . . . . . . . . . . . . 17 specifications . . . . . . . . . . . . 39
Important standards . . . . . . . . . . . 39
Chapter 4. Anatomy of a service . . . . 19 Important specifications . . . . . . . . . . 39
Chapter 5. DataPower services . . . . 21 Notices and trademarks . . . . . . . 41

Services on appliances . . . . . . . . . . . 21 Trademarks . . . . . . . . . . . . . . 41
HTTP Server service . . . . . . . . . . . 21
SSL Proxy service . . . . . . . . . . . . 21 Index . . . . . . . . . . . . . . . 43
© Copyright IBM Corp. 2002, 2009 iii

iv Appliance Overview
Preface
IBM® WebSphere® DataPower® appliances are purpose-built, easy-to-deploy
network appliances that simplify, help secure, and accelerate your XML and Web
services deployments while extending your SOA infrastructure. These appliances
offer an innovative, pragmatic approach to harness the power of SOA while
simultaneously enabling you to leverage the value of your existing application,
security, and networking infrastructure investments.
Who should read this document

This document is intended for anyone who is interested in understanding
appliances in the IBM WebSphere DataPower SOA Appliances product family.
How this document is organized

This document has the following organization:
v Chapter 1, “Introduction,” on page 1
Contains general overview information about DataPower appliances.
v Chapter 2, “Appliance types,” on page 9
Describes the various DataPower appliances.
v Chapter 3, “Document processing,” on page 15
Describes the various phases of document (request and response message)
processing.
v Chapter 4, “Anatomy of a service,” on page 19
Describes the building blocks needed to create a DataPower service.
v Chapter 5, “DataPower services,” on page 21
Provides information about the various services provided by DataPower
appliances.
v Chapter 6, “Key administrative functions,” on page 27
Provides information about the primary administration functions the DataPower
appliances provide.
v Chapter 7, “Configuration procedures,” on page 31
Provides information about the different configuration phases.
v Chapter 8, “Decision-making for solutions,” on page 33
Provides information a sample decision-making scenario to develop the optimal
DataPower services.
v Appendix A, “Getting help and technical assistance”
Provides details about contacting IBM Support.
v Appendix B, “Standard and specifications,” on page 39
Provides details about the standards and specifications on which DataPower
appliances are built.
© Copyright IBM Corp. 2002, 2009 v

Publications
The IBM WebSphere DataPower library is organized into the following categories:
v “Installation and upgrade documentation”
v “Administration documentation”
v “Development documentation”
v “Reference documentation” on page vii
v “Integration documentation” on page vii
v “Problem determination documentation” on page vii
v “Supplemental documentation” on page viii
You can access and download documents in the DataPower library from the IBM
WebSphere DataPower Product Documentation Portal. These details are discussed
in technical flash 1377654.
http://www.ibm.com/support/docview.wss?rs=2362&uid=swg21377654
Installation and upgrade documentation

v IBM WebSphere DataPower SOA Appliances: 9003: Installation Guide
Provides instructions for installing and powering up the Type 7993 (9003)
appliance, creating a startup configuration script, and placing the appliance in
operation.
v IBM WebSphere DataPower SOA Appliances: Type 9235: Installation Guide
Provides instructions for installing and powering up the Type 9235 appliance,
creating a startup configuration script, and placing the appliance in operation.
v IBM WebSphere DataPower SOA Appliances: Type 9235: Hardware Problem
Determination and Service Guide
Provides information about diagnosing and troubleshooting hardware problems,
ordering consumable replacement parts, and replacing parts.
v Upgrade and Rollback Guide
Provides instructions for upgrading firmware and rolling back firmware
upgrades.
Administration documentation
v Appliance Overview
Provides an introduction and understanding of the DataPower appliances.
v Administrators Guide
Provides instructions for using the DataPower GUI for managing user access,
network access, appliance configuration and system configuration of the
appliance.
v Hardware Security Module Guide
A user guide for using a Hardware Security Module (HSM) installed in the
appliance.
Development documentation
v XSL Accelerator Developers Guide
Provides instructions for using the WebGUI to configure XSL Proxy and XSL
Coprocessor services.
v XML Firewall Developers Guide
vi Appliance Overview
Provides instructions for using the WebGUI to configure XML Firewall services.
v Web Application Firewall Developers Guide
Provides instructions for using the WebGUI to configure Web Application
Firewall services.
v Multi-Protocol Gateway Developers Guide
Provides instructions for using the WebGUI to configure Multiple-Protocol
Gateway services.
v Web Service Proxy Developers Guide
Provides instructions for using the WebGUI to configure Web Service Proxy
services.
v B2B Gateway Developers Guide
Provides instructions for using the WebGUI to configure B2B Gateway services.
v Low Latency Messaging Developers Guide
Provides instructions for using the WebGUI to configure a DataPower appliance
for low latency messaging.
Reference documentation
v Command Reference
Product-specific documentation for using commands from the command line.
The documentation provides an alphabetic list of all commands with syntax and
functional descriptions.
v Extension Elements and Functions Catalog
Provides programming information about the usage of DataPower XSLT
extension elements and extension functions.
Integration documentation
The following documents are available for managing the integration of related
products that can be associated with the DataPower appliance:
v Integrating with Tivoli Composite Application Management for SOA
Provides concepts for integrating the DataPower appliance with IBM Tivoli®
Composite Application Management for SOA.
v Integrating with Tivoli Security Policy Manager
Provides detailed information about integrating the DataPower appliance with
IBM Tivoli Security Policy Manager.
v Integrating with WebSphere MQ
Explains the concepts and common use patterns for connecting DataPower
services to WebSphere MQ systems.
v Integrating with WebSphere Transformation Extender
Provides detailed information about integrating the DataPower appliance with
WebSphere Transformer Extender.
Problem determination documentation

v Message Reference
Provides the list of messages and event codes by message identifier.
v Problem Determination Guide
Provides troubleshooting and debugging tools.
Preface vii
Supplemental documentation
v Converting between JSON and JSONx
Provides information about and procedures for converting between JavaScript™
Object Notation (JSON) and JSONx. JSONx is the JSON as XML.
v Configuring DoD PKI
Provides conceptual information about and procedures for configuring the
DataPower appliance with Department of Defense (DoD) Public Key
Infrastructure (PKI).
v Optimizing through Streaming
Provides conceptual information about and procedures for optimizing the
DataPower appliance through streaming.
v Securing the Last Mile
Provides conceptual information about and procedures for understanding the
DataPower appliance while securing the last mile.
v Understanding LTPA
Provides conceptual information about how the DataPower appliance can use
Lightweight Third Party Authentication (LTPA).
v Understanding SPNEGO
Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO). SPNEGO is
also referred to as Integrated Windows® Authentication.
v Understanding Web Services Policy
Web Services Policy (WS-Policy).
v Understanding WS-Addressing
WS-Addressing.
External resources
Beyond the online help, no other informational resource is available on the
appliance. You can access the following external resources if a problem occurs or if
you need help.
DataPower Product Documentation Portal
You can access and download documents in the DataPower library using
the details in technical flash 1377654.
http://www.ibm.com/support/docview.wss?rs=2362
&uid=swg21377654
DataPower product Web site
http://www.ibm.com/software/integration/datapower
This Web site provides information about the appliances in the DataPower
portfolio. From this page, you can access the product library, news, and
support areas. The Support link, in particular, has important flash notes
plus a wealth of pointers to Redbooks®, frequently asked questions, and
troubleshooting information.
An important link of this page on the DataPower Support page is
“Firmware and documentation download”. From this page, you can access
viii Appliance Overview

and download updated documentation and firmware images for your
particular appliance. This page also provides directions for getting
assistance from IBM Support.
Redbooks Web site
http://www.redbooks.ibm.com
This Web site provides a search field where you can query for documents
that are related to DataPower products. A query against the term
DataPower yields a number of resources in the Redbooks series. These
documents relate to integrating DataPower products with other products in
the IBM ESB portfolio.
developerWorks®
http://www.ibm.com/developerworks
This Web site yields an extensive list of articles about DataPower products.
DataPower discussion forum
http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1198
This forum is the only discussion area that is officially sanctioned by IBM.
In this forum, you can find members from the IBM technical community
(technical sales, engineering, support, and field consultants) to answer
questions on a continual basis. This forum is not formal product support.
Answers to the questions that you post to this forum are on an ad-hoc
basis.
Typeface conventions
The following typeface conventions are used in the documentation:
bold Identifies commands, programming keywords, and GUI controls.
italics Identifies words and phrases used for emphasis and user-supplied
variables.
monospaced
Identifies user-supplied input or computer output.
Key prerequisites
Before using an appliance in the DataPower portfolio, you need to following:
v Network interfaces and Ethernet network cables
v Network information (IP address, domain name server, gateway)
v Computer and console with serial port, keyboard, and mouse
v Power requirements for country specifications
v Internet access for connecting to external trading partners (B2B Appliance XB60
only)
v IBM WebSphere MQ Low Latency Messaging (Low Latency Appliance XM70
only)
Preface ix
x Appliance Overview
Chapter 1. Introduction
IBM WebSphere DataPower appliances are fundamentally network devices. They
communicate with other nodes on an IP network.
DataPower appliances simplify, help govern, and enhance the security of XML and
IT services. The products in the DataPower portfolio extend the capabilities of your
infrastructure by providing service-oriented architecture (SOA) connectivity,
business-to-business (B2B) connectivity, gateway functionality, and extremely low
latency messaging. By offering an innovative, pragmatic approach to harness the
power of SOA as purpose-built, easy-to-consume, and easy-to-use products,
DataPower appliances help you leverage the value of your existing infrastructure
investments.
The products in the DataPower portfolio includes the following rack-mountable

appliances:
v IBM WebSphere DataPower XML Accelerator XA35
v IBM WebSphere DataPower XML Security Gateway XS40
v IBM WebSphere DataPower Integration Appliance XI50
v IBM WebSphere DataPower B2B Appliance XB60
v IBM WebSphere DataPower Low Latency Appliance XM70
At a glance
In general, the management of network products has the following requirements:
v Use of multiple administrative interfaces
v Support of different access methods
v Privileges that are based on user
Consequently, you can access DataPower appliances through a command line, a

Web-based user interface, or a SOAP-based XML management interface. Regardless
of the administrative interface, properly authenticated and authorized users can
access the entire range of configuration data and status data.
DataPower appliances help you:

v Improve competitiveness by strengthening business connectivity with partners
and customers and between internal organizations
v Streamline seemingly complex, but highly valuable SOA and XML applications,
with specialized, low total cost of ownership, drop-in appliances
v Load balance service requests across your infrastructure
v Extend existing Microsoft® and TIBCO infrastructure with security, integration,
and connectivity
v Leverage z/OS® infrastructure as part of your SOA enterprise
v Shorten SOA application deployment times when using DataPower
configuration-driven simplicity
v Enhance B2B connectivity, protection, XML-level security, and Web service access
control with powerful and thoughtful appliance security features
v Accelerate message distribution and XML and Web services processing with
dedicated, high-performance capabilities
© Copyright IBM Corp. 2002, 2009 1

v Assist in governing ever-valuable SOA infrastructure by adopting standardized
runtime control points through the DataPower appliance
v Comply with U.S. federal IPv6 network (all appliances except B2B Appliance
XB60)
Physical characteristics
DataPower appliances are rack-mountable 1U hardware devices. The only external
interfaces are a power switch, 9-pin serial port and four RJ-45 Ethernet ports.
Appliances with HSM have a PIN Entry Device (PED) connector.
At their physical core, DataPower appliances are network devices. The most
apparent feature is the set of four network interface ports. You can choose how to
segregate traffic across these ports. For example, it is common to dedicate the
management (MGMT) port to the administrative subnet. From there, the remaining
three can be split up so that two receive client traffic and the third connects to the
back-end, private network. This common configuration segregates the network
data for network security.
Software architecture
From a user perspective, the software architecture is simple. There is a customized,
hardened, native-code operating system kernel that implements core functionality.
The OS resides in the firmware and can be updated by applying updated firmware
images.
On top of this layer is the functionality that is implemented in XSLT style sheets.
These style sheets are read-only. The appliance uses these style sheets to implement
specific functionality.
The next layer is the software stack that consists of the configurations that you
developed. These configurations are the application proxies and processing policies
to process message traffic for your application. Configuration files and application
artifacts can reside in the file system on the appliance or can be stored on remote
servers and retrieved and cached at startup. Storage and retrieval from remote
servers means that in a highly secure environment these files and artifacts never
reside on the appliance.
Although the OS itself and many of the implementation details of the appliance are
custom and proprietary, the appliances are built on a standards-based model.
Administrative model
By default, all remote interfaces are shut down. The only way to enable them is
through the serial port. DataPower appliances have the following administrative
interfaces:
v Web-based graphical user interface (WebGUI)
v Command line interface (CLI)
v SOAP-based XML management interface
Regardless of the administrative interface, properly authenticated and authorized

users can access the entire range of configuration data and status data.
2 Appliance Overview
Web-based graphical user interface
The Web-based graphical user interface (WebGUI) is a standard browser-based
administrative interface. The WebGUI is the most common way to administer
appliances. Beyond administration, you can use the WebGUI to create the
application proxies. For example, you can use the drag-and-drop capabilities of the
Processing Policy editor to create workflow rules for requests and responses. The
rules in the processing policy can perform the various actions as messages flow
through the appliance.
Often, the WebGUI is used in only development environments. After development,

the use of automated, scripted processes deploy these configurations to test,
quality assurance, and production environments. To deploy configurations to these
environments, use either the command line or SOAP management interface.
Before using the WebGUI, you must enable this interface and make it available to
administrators. Generally, access to and enablement of the WebGUI occurs when
the administrator performs the initial appliance setup. Instructions for setting up a
DataPower appliance are provided in the machine type-specific Installation Guide.
Command line interface

The command line interface (CLI) can be accessed using Telnet, secure-shell (SSH),
or the serial port. In the most secure environments, all remote administrative
interfaces are disabled, which forces all administration to be done by only those
with physical access to the appliance in the datacenter. For security purposes,
Telnet normally remains disabled.
SOAP-based XML management interface

The SOAP-based XML management interface provides various ways to administer
the appliance and obtain status information using XML-based SOAP requests.
There are several different specifications that can be used, including SOAP
management, WS-Management, and WSDM. The interfaces available are commonly
used for automated, programmatic, or custom approaches to administration.
Programming model
You can perform most appliance configurations with the administrative interfaces.
For customized use cases that are not available through the WebGUI, you can
program the appliance. Because the appliance is XML-centric, the custom
programming model is XSLT. All custom programming must be done in this
language.
XPath is an important technology for these appliances. Aside from custom

programming done with XSLT, XPath expressions are used in building
configurations using the WebGUI. For example, if you need to build a policy to
sign and encrypt selected node sets in an XML document, you simply provide an
XPath expression to locate these node sets. For non-programmers, the WebGUI
provides an easy-to-use XPath builder that enables you to load a sample document
and click the element or node set to generate the XPath statement.
The appliances offer more than what standard XSLT and EXSLT have in their
libraries. The appliance supports cryptographic operations and many different
protocols that are outside the domain of XSLT and EXSLT. To provide for custom
Chapter 1. Introduction 3
programming that leverages the full scope of functionality on the appliances, they
include a library of extension functions and elements that can be used for XSLT
custom programming.
Configuration architecture
The configuration architecture of the DataPower appliance consists of layers of
related objects. Services occupy the top layer and provide the coordinated runtime
to implement solutions to SOA requirements. A single appliance can run many
services simultaneously.
At the next layer, the processing policy provides message handling and routing.
Rules and actions in processing policies perform such tasks as message
transformation, message filtering, authentication and authorization, cryptography,
error handling, and message routing. A single service has only one processing
policy. The processing policy, however, can have any number of rules. Each rule
can contain any number of actions. Many actions can employ an XSLT style sheet.
Refer to Figure 1 for an illustration of this relationship.
DataPower appliance
Service
Processing policy
Rule
Action
Filter
XSLT
Figure 1. Basic configuration architecture
A wide range of objects provide ancillary or supporting capabilities to the top-level

service or processing policy. The following list contains use cases and their
supporting objects:
v A service require the use of secured communications. The implementation for
secure communications requires the use of SSL-related objects.
v A processing policy includes an action that dynamically routes messages.
Dynamic routing requires a routing map.
v A service implements threat protection. Depending on the threat, the
configuration might require one or more monitor.
v A service uses log targets to deliver real time updates to SNMP consoles running
elsewhere in the enterprise. This type of log target requires the configuration of
the log target and SNMP.
Secure network communication
The appliance can implement SSL communication between the appliance and its
clients, between the appliance and remote servers, and among peer appliances
involved in a transaction (such as an LDAP server). SSL-based communication can
involve the following cryptographic objects:
v Keys
v Certificates
v Identification credentials
v Validation credentials
v SSL proxy profiles
Logging and monitoring

SNMP is ubiquitous and useful for infrastructure monitoring, The appliance comes
with SNMP MIB files that you can import into your monitoring tools to set up
monitoring policies. When a critical event occurs on the appliance, it can send out
SNMP traps. Monitoring can also be achieved by using SOAP, as is the case with
integrating with IBM Tivoli Composite Application Manager (ITCAM) for SOA.
Most logging is done off-appliance, using protocols such as syslog and syslog-ng
or by writing logs to a remote NFS mount. DataPower appliances never share their
file system but can connect to shared file systems on other servers. There is a full
suite of logging formats and protocols to use as well as a model for specifying
event notifications at various levels or granularity.
The logging utility on the appliance works on the principle of publish and
subscribe. Objects publish log messages. Log targets subscribe to message streams.
More than one log target can subscribe to the same set of log messages. This
allows the appliance to distribute log messages to multiple destinations, including
network management consoles, file servers and databases.
Monitors
You can implement a variety of monitors to allow for constant feedback on
messages that flow through the appliance. You can configure monitors to generate
log messages at a given log level after reaching a count or latency threshold or
other event trigger. Monitors can also throttle (reject) or shape (delay) traffic after
reaching a count or latency threshold or other event trigger.
DataPower appliance provide one or more of the following monitors:

Count monitors
Count monitors increment a counter every time messages of a particular
type pass through a service. You can configure Count monitors can
distinguish the direction of the message as well as report on each IP
address in a range.
You can use count monitors to meet the following use case requirements:
v Generate notifications when requests from any single client reaches a
threshold
v Generate notification and throttle requests when any single client fails
authentication a set number of times within a given period
v Delay requests arriving at a rate greater than a set number of times, to
maximize the likelihood of successful completion
Duration monitors
Duration monitors increment a counter every time a configured amount of
time passes during the processing of messages of a particular type.
Duration monitors can distinguish the direction of the message.
You can use duration monitors to meet the following use case
requirements:
v Delay or throttle requests when application latency reaches a configured
threshold, which protects remote resources
v Delay or throttle requests when total request processing latency reaches
a configured threshold, which meets service level agreements
Web service monitors
Web Service Monitors read a WSDL file. The WSDL file defines the Web
services to monitor. Web services monitors offer the ability to configure
monitoring based on the services that the WSDL file defines. Web service
monitors provide a solution to the all of the same kinds of use cases
provided by count and duration monitors.
For example, a DataPower service can monitor specific service level
activity and provide logging based on levels of errors and transactions.
Assume that a bank offers account query, loan processing, and wire
transfer services to its business partners through a set of Web services
interfaces. The traffic from each business partner passes through the
service. The service provides security services and validation.
The DataPower appliance can be configured to monitor traffic for each
particular service the bank offers. When levels of errors or transaction rates
are met, the DataPower appliance can post messages to the log. The
information that is gathered by Web services monitors can be used to
summarize and monitor the health of the Web services offerings for a bank.
Service level monitors
Service level monitors provide a finer degree of control. For example, you
can create a service level monitor and assign it at the service level, port
level, or operations level as the WSDL-defined Web services. Control
extends to the precise definition of users or resources and the scheduling
of operations.
With a service level monitor, you could create a peak-hours monitor and
an off-hour monitor. The peak-hours monitor can provide strict monitoring
of frequently-accessed resources by defined user groups. The off-hours
monitor can provide looser control over the same set of resources and user
groups.
Service level monitors provide solutions to the following use cases:
v Enforce Service Level Agreements with business partners
v Protect application server resources against denial of service attacks
v Enforce thresholds and monitoring across multiple appliances.
Service level monitors can be applied across multiple DataPower
appliances (SLM peers). These monitors allow for environments to enforce
SLM policies that are based on aggregated counts across peer appliances.
Available add-on features

The following features are available on IBM WebSphere DataPower SOA
Appliances products:
IBM Tivoli Access Manager
The Option for Tivoli Access Manager enables DataPower appliances to
leverage access control policies stored in IBM Tivoli Access Manager. This
feature is available on the following products:
v XML Security Gateway XS40
v Integration Appliance XI50
v B2B Appliance XB60
v Low Latency Appliance XM70
TIBCO
The Option for TIBCO lets you extend DataPower appliances so that you
can send and receives messages from TIBCO Enterprise Message Service
(EMS). This feature is available on the following products:
v B2B Appliance XB60
Database Connectivity
The Option for Database Connectivity lets you extend DataPower
appliances to provide direct-to-database access (read and write data from
relational databases), such as IBM DB2®, Oracle, Sybase, and Microsoft SQL
Server.
You can use this feature to connect natively to a DB2 version 9 database,
running on a range of platforms, including z/OS. Appliances can use the
XML capabilities built into DB2 version 9 to:
v Insert XML directly into the database
v Modify XML text stored in the database
v Query XML data using XQuery and SQL
v Retrieve XML data
This feature is available on the following products:
This feature as part of the B2B Appliance XB60.
Application Optimization
The Option for Application Optimization enables groups of DataPower
appliances to participate in a self-balanced standby group or a single
DataPower appliance to use intelligent load-balancing. This feature is
available on the following products:
You can purchase this feature as a field upgrade on Type 9235 products
running firmware level 3.8.0.0 or later.
HSM with PIN entry device
The PIN entry device (PED) provides personal identification number (PIN)
entry to the Hardware Security Module (HSM). PIN entry is used along
with the trusted path to allow for highly secure user authentication and
controlled hardware access. This feature is available on the following
products:
Chapter 2. Appliance types
The rack-mountable IBM WebSphere DataPower SOA Appliances family includes
the following appliances:
v IBM WebSphere DataPower XML Accelerator XA35
v IBM WebSphere DataPower XML Security Gateway XS40
v IBM WebSphere DataPower Integration Appliance XI50
v IBM WebSphere DataPower B2B Appliance XB60
v IBM WebSphere DataPower Low Latency Appliance XM70
XML Accelerator XA35

The XML Accelerator XA35 is a highly efficient XML processing engine that makes
use of purpose-built features such as optimized caches and dedicates SSL hardware
to process XML at near wire-speed.
The XML Accelerator XA35 is a hardened appliance, but has limited security
processing. For example, the XML Accelerator XA35 does not have the full XML
threat protection or encryption/digital signature capabilities as other models. For
these reasons, the XML Accelerator XA35 generally sits behind the DMZ, in the
trusted zone to augment the processing of XML files. For example, the services on
an XML Accelerator XA35 can perform validation and transformation of XML
before it reaches (or for traffic flowing between) remote (back-end) servers. The
XML Accelerator XA35 can be used inline in the network topology, not as a
coprocessor that hangs off a particular server. A popular use for the XML
Accelerator XA35 is to receive XML responses from servers and transform them
into HTML before forwarding the response to the client.
The XML Accelerator XA35 has full SSL and SNMP capabilities to fit into the
network infrastructure.
Outstanding performance
The DataPower purpose-built message processing engine can deliver wire
speed performance for both XML to XML and XML to HTML
transformations to help increase throughput and decrease latency.
Ease-of-use
The self-learning XML Accelerator XA35 provides drop-in acceleration with
virtually no changes to the network or application software. No propriety
schemas, coding, or APIs are required to install or manage the appliance
and it supports popular XML Integrated Development Environments
(IDEs) to help reduce the number of hours spent in the development and
debugging of XML applications.
Reduction in infrastructure costs
Unlike simple content switches that only redirect business documents, the
XML Accelerator XA35 fully parses, processes, and transforms XML with
wire speed performance and scalability to help reduce the need for stacks
of servers. The XML Accelerator XA35 also supports accelerated SSL
processing to help further lessen the load on server software.
Reduction in development costs
The XML Accelerator XA35 can enable multiple applications to leverage a

single, uniformed XML processing layer for all XML processing needs. By
standardizing on high-performance hardware appliances, enterprises can
deploy sophisticated applications while helping to eliminate unnecessary
hours of application debugging and tuning for marginal performance
gains.
Intelligent XML processing
In addition to wire speed processing, XML Accelerator XA35 supports
XML routing, XML pipeline processing, XML compression, XML/XSL
caching, as well as other intelligent processing capabilities to help manage
XML traffic.
Advanced management
The XML Accelerator XA35 provides real-time visibility into critical XML
statistics, such as throughput, transaction counts, errors, and other
processing statistics. Data network level analysis is provided, and includes
server health information and traffic statistics, as well as management and
configuration data.
XML Security Gateway XS40

The XML Security Gateway XS40 provides a security-enforcement point for XML
and Web services transactions. The XML Security Gateway XS40 generally sits in
the DMZ to take advantage of its extensive security capability. The XML Security
Gateway XS40 provides all the capabilities of the XML Accelerator XA35 described
in “XML Accelerator XA35” on page 9 plus the following capabilities:
Centralized policy management and enforcement
The outstanding performance of the XML Security Gateway XS40 can
enable enterprises to centralize security functions in a single drop-in device
that can enhance security and can reduce ongoing maintenance costs.
Simple firewall and Web services proxy functionality can be configured via
the Web user interface (WebGUI) and run in minutes, or, using the power
of XSLT, the XML Security Gateway XS40 can also create sophisticated
security and routing rules. Combining integration with leading policy
managers and service registries and support for such standards as
WS-Security, WS-SecurityPolicy, WS-ReliableMessaging, and WS-Policy, the
XML Security Gateway XS40 is an ideal policy enforcement and execution
engine for securing next-generation applications. Managed locally or
remotely, the XML Security Gateway XS40 support SNMP, script-based
configuration, and remote logging to provide seamless integration with
leading management software.
XML/SOAP firewall
The XML Security Gateway XS40 filters traffic at wire speed, based on
information from protocol stack layers 2 through 7, form field-level
message content and SOAP envelopes to IP address, port and host name,
payload size, or other metadata. Filters can be predefined and
automatically uploaded to change security policies based on time of day or
other triggers.
Field-level XML security
The XML Security Gateway XS40 selectively shares information through
encryption/decryption and signing/verification of entire messages or of
individual XML fields. These granular and conditional security policies can
be based on nearly any variable including content, IP address, host name,
or other user-defined filters.
XML-based Web services access control
The XML Security Gateway XS40 supports a variety of access control
mechanisms, including XACML, Security Assertion Markup Language
(SAML), SSL, LDAP, RADIUS, and simple client URL maps. The XML
Security Gateway XS40 can control access rights by rejecting unsigned
messages and verifying signatures within SAML assertions.
Service virtualization
XML Web services require companies to link partners to resources without
leaking information about their location or configuration. With the
combined power of URL rewriting, high-performance XSL transforms, and
XML/SOAP routing, the XML Security Gateway XS40 can transparently
map a rich set of services to protected remote resources with high
performance.
Data validation
With its unique ability to perform XML schema validation as well as
message validation at wire speed, the XML Security Gateway XS40 ensures
incoming and outgoing XML documents are legitimate and property
structured. This protects against threats such as XML denial-of-service
(XDoS) attacks, buffer overflows, or vulnerabilities created by deliberately
or inadvertently malformed XML documents.
SSL acceleration
The XML Security Gateway XS40 scales transport layer security by
accelerating bidirectional/mutual SSL transactions in hardware. The XML
Security Gateway XS40 can be configured with multiple SSL identities
functioning as client or server, with SSL policies based on message content
or metadata such as port number or HTTP header.
Integration Appliance XI50

The Integration Appliance XI50 is a complete, purpose-built hardware platform for
delivering highly manageable, security-enhanced, and scalable SOA solutions. As
specialized SOA hardware, the Integration Appliance XI50 provides many core
functions to SOA deployments in a hardened device. There are numerous
opportunities to take advance of the Integration Appliance XI50 Enterprise Service
Bus (ESB) capabilities, its data enablement and integration features, and its
capacity to improve Web services management and SOA governance.
The Integration Appliance XI50 generally sits in your private network. However,
the Integration Appliance XI50 is just as suitable for the DMZ.
The Integration Appliance XI50 provides all the capabilities of the XML Security
Gateway XS40 described in “XML Security Gateway XS40” on page 10 plus the
following capabilities:
Drop-in integration for heterogeneous environments
As a core offering in the IBM ESB product portfolio, the Integration
Appliance XI50 is a purpose-built hardware ESB for simplified deployment
and hardened security with the ability to quickly transform data between a
wide variety of formats. The Integration Appliance XI50 provides core ESB
functionality, including routing, bridging, transformation, and event
handling. The Integration Appliance XI50 provides a reliable,
performance-oriented solution to many integration challenges. Because the
Integration Appliance XI50 is not limited to handling just XML, it resonates
with IT organizations that need to benefit from the connectivity of SOA
deployments but must also deal with their current reality of managing
Chapter 2. Appliance types 11

multiple proprietary, industry, company-specific, or data formats. The
Integration Appliance XI50 is a true drop-in integration point for
heterogeneous environments, helping to reduce the time and cost of
integrations, and speed the time-to-market for services.
Innovative XML and Web services enablement
For accelerated, security-rich integration capabilities, the Integration
Appliance XI50 provides transport mediation, routing, and transformations
among binary, text, and XML message formats. Visual tools can be used to
describe data formats, create mappings between different formats, and
define message flows. With native connectivity to DB2 and z/OS, the
Integration Appliance XI50 offers an innovative solution for security-rich
XML enablement of legacy data on systems as well as mainframe
connectivity.
Policy-driven approach to Web services management and SOA governance
Centralized Web services management tasks and policy enforcement,
de-coupled from applications, can help the Integration Appliance XI50
increase your SOA infrastructure flexibility and scalability while
simultaneously offering you improved insight, visibility, and control.
Moving functions such as access control, Web services management,
security, and policy enforcement to the Integration Appliance XI50 means
that IT architects and operations, security, and business personnel can
de-couple these functions from the core business applications, helping to
simplify development, deployment, and manageability.
Integration with registry and repository, security, identity, and service
management software
The Integration Appliance XI50 integrates with a variety of registry and
repository, security, identity, and service management software
applications. Coupled with access control software, such as IBM Tivoli
Access Manager, IBM Tivoli Federated Identity Manager, the Integration
Appliance XI50 provides federated Web services identity and policy
management between organizations and enterprises. Integrated with IBM
Tivoli Composite Application Manager for SOA, the Integration Appliance
XI50 monitors Web services and SOA traffic flows for end-to-end service
management and dashboard monitoring. Using a registry and repository,
such as WebSphere Registry and Repository (WSRR) can help you discover
and reuse services and configure new services for DataPower policy and
security enforcement. The combination of these applications and the robust
Integration Appliance XI50 security features can provide the
comprehensive capabilities for SOA security and Web services management
that enterprises increasingly require.
Advanced Web services standards support and interoperability
IBM recognizes that SOA must address the need to integrate heterogeneous
environments both within and outside the enterprise. The IBM WebSphere
DataPower SOA Appliances portfolio has a long-standing history of
support for key and advanced standards, including WS-Security,
WS-Policy, Ws-ReliableMessaging, Simple Object Access Protocol (SOAP),
Web Services Distributed Management (WSDM), WS-I Profiles,
WS-Addressing, Extensible Access Control Markup Language (XACML),
Security Assertion Markup Language (SAML), Secure Socket Layer (SSL),
and proprietary single sign-on (SSO) tokens. Additional third-party
interoperability capabilities include Universal Description, Discovery, and
Integration (UDDI) registries, and such databases as Oracle and Sybase.
Integration across the IBM SOA foundation for smart SOA deployments
The Integration Appliance XI50 has broad and deep integration across the
IBM SOA foundation. Integration with popular integrated development
environments, such as the IBM Rational® portfolio can help reduce the time
you spend in development and debugging. In addition to interoperability,
the Integration Appliance XI50 also features deep integration with products
such as WebSphere MQ, WebSphere Enterprise Service Bus, WebSphere
Message Broker, and DB2 to help process SOA transactions in a faster,
more secure and simplified way. Additionally, the Integration Appliance
XI50 enables you to take advantage of the IBM autonomic computing
self-management capabilities, creating infrastructures that require minimal
intervention, which can help lower cost of ownership and improve service
availability.
B2B Appliance XB60

The B2B Appliance XB60 provides a high throughput, secure entry point at the
edge for routing data into the enterprise. The B2B Appliance XB60 provides a
hardened infrastructure for protocol and message-level security in DMS
deployments. The B2B Appliance XB60 leverages the core DataPower features, such
as performance, security, and integration, as well as provides a full-featured user
interface for simplified B2B configuration, management, and deployment.
The B2B Appliance XB60 appliance is designed to help your business:

v Recognize a low total cost of ownership
v Easily manage and connect to trading partners using a broad range of industry
standards
v Extend integration beyond the enterprise with a securely deployed B2B gateway
in the DMZ
v Improve the performance and scalability of your B2B interfaces
v Govern B2B integration points through consolidated trading partner
management
v Monitor B2B transactions through the B2B transaction viewer that provides
end-to-end document correlation.
v Display and search on message identifiers in the B2B transaction viewer
Low Latency Appliance XM70

The Low Latency Appliance XM70 provides a configuration-driven approach to
low latency publish-subscribe messaging and content-based routing. The Low
Latency Appliance XM70 combines the power of a drop-in network solution with
powerful LLM technologies to address the challenges inherent in low latency and
high throughput messaging environments, such as unpredictable performance,
scaling required to meet increasing message and feed volumes, and overall
management and complexity of messaging environments. In financial, government,
and energy markets, the Low Latency Appliance XM70 can act as a highly
available messaging backbone for data feeds and other high-volume transactions.
The principal features of the Low Latency Appliance XM70 are as follows:
v Highly scalable unicast and multicast messaging with minimal latency
v Native XML and FIX parsers for routing based on destination, property, or
message content
Chapter 2. Appliance types 13

v Optimized bridging to standard messaging protocols (WebSphere MQ,
WebSphere JMS, TIBCO EMS, HTTP, HTTPS)
v Support for WebSphere MQ Low Latency Messaging clients
Chapter 3. Document processing
All of the primary services employ a processing policy to examine and manipulate
documents. Documents might include any of the following:
v Request messages from service clients
v Response messages from backend application servers
v Results returned from third party, or ancillary servers
v Documents retrieved from file servers, Web servers or database servers
Application developers must create processing policies for all services, except the
Web Service Proxy. The Web Service Proxy generates a processing policy based on
the information in the WSDL files that configures the service. A processing policy
consists of one or more processing rules, which in turn contain one or more
processing actions.
The set of processing actions that a service can make available implements the
following capabilities:
v XML message schema validation (validate action)
v XML message transformation (transform action)
v Binary message transformation (binary transform action)
v XML message filtering (filter action)
v Digital signing and signature verification (sign and verify actions)
v XML and binary message encryption and decryption (encrypt and decrypt
actions)
v Authentication, authorization and token exchange (AAA action)
v Dynamic message routing based on content or protocol header (route action)
v Message distribution to multiple endpoints (results action)
v Retrieve additional data (fetch and results actions)
v Connect directly to remote database servers (SQL action)
v Scan messages for viruses (antivirus action)
This list does not include the full range of capabilities.
Phases of document processing

A service has three high-level processing phases that must be performed for all
requests and responses.
1. A service accepts an incoming request on the established front-side connection
2. The service processes the request
3. The service passes the request to the remote server over the backside
connection
On the response from the server to the client, the invocation of the phases are in
reverse order.

Client-side processing
As a request is submitted to the DataPower appliance, there could be many
different services that can processing incoming messages. However, only one
service can receive a single request from the client. Therefore, there must be
something in the configuration that decides which service will handle the request.
The selection of which service is determined by the IP address-port combination on
which the service is configured to listen. The one exception is the Web Service
Proxy, where selection is defined at a more granular level. For simplicity, assume
that a service listens on a specific port for incoming requests.
After a service receives the incoming message, there is addition client-side

processing applied. If the request is using SSL, client-side processing performs the
specified level of SSL negotiation to establish the secured connection. The
connection might include mutual authentication. Transport-level decryption of the
data stream is also performed on requests sent over SSL.
After establishing the secured connection and decrypting the data stream (if
applicable), client-side processing applies additional processing on the request,
such as service-level monitoring (SLM), threat protection, attachment processing,
message throttles, and URL rewriting. All of this processing is configurable in the
service. For now, it is important to understand that there is a significant amount of
processing that occurs during client-side processing before the service begins to
process the message.
Client-side processing can reject the message before attempting any message
processing. The DataPower appliance provides much of this processing out-of-box,
such as schema validation and message processing. Other details need to be
configured.
Processing policy in the DataPower service

The processing policy within a DataPower service is known as multistep processing.
After a request passes client-side processing, the service can start to perform all the
configured processing operations on the message. A processing policy is a list of
rules that contain processing actions that can be applied to the message. Actions
are specific processing operations that are applied to a message, such as document
format transformations, encryption and decryption, message signing,
authentication, and so forth. As the request message passes through the processing
policy, the actions are applied to the message in the defined sequence, producing a
final message to be passed to server-side processing.
Server-side processing
After the service processes the message, the request is almost ready to be passed to
the server. Before sending the message to the server, there might be additional
required processing. This processing could be creating a new SSL connection,
setting additional headers in the request, setting the protocol version to what the
server expects, and so forth. For example, suppose an incoming request from the
client uses HTTP 1.1, but the server supports only HTTP 1.0. Server-side
processing would send the request to the server using HTTP 1.0.
The most important part of server-side processing is to sent the request to the
server. The location of the server can be defined in one of two different ways:
v If all requests that a service processes go to the same server, the configuration
for that service uses a static back end.
v If some requests that a service processes go to one server and others go to
another server, the configuration for that service uses a dynamic back end.
When the service configuration uses a dynamic back end, the processing policy
determines which server receives the request at runtime. This decision can be
based on metadata, such as protocol headers, URI, or the message content itself.
Error handling
Errors can occur at any point during the processing of messages. Processing of
messages, or a set of messages comprising a transaction, can be divided into the
following primary phases:
1. Communication with clients (either request or response)
2. Message processing
3. Communication with remote resources (either request or response)
By default, the appliance returns a terse fault message to clients when errors occur
during any of these phases. The default behavior can be changed by including one
or more error rules or by including an on-error action. Both methods allow
developers to do the following processing:
v Return a custom error message to clients
v Return custom protocol headers to clients
v Generate custom log messages
Errors that occur during the initial request communication with clients might not
be available for custom handling, because the connection closes before the
processing policy executes. Errors that occur during communications with backend
resources, such a broken connection, typically can be customized.
When you are planning a solution, consider the kinds of error handling behavior
required. You might need to build your processing policy to create custom error
handling.
Chapter 3. Document processing 17

Chapter 4. Anatomy of a service
To create a service, you must understand the building blocks. A service can contain
different components to provide end-to-end processing. A DataPower service is
object-oriented, so that almost every component of a service is an independent,
reusable part. A DataPower service is a collection of parts that are each configured
to perform a specific task. These parts are arranged hierarchically with many
references and dependencies. During configuration, many of these parts are
automatically created. However, it is important to know about them even if you
never manually configure them.
The primary reusable parts (objects) in a service configuration are as follows:

Front-side handlers
A front-side handler is the entry point to several service. A handler listens
on a specific IP address-port for incoming requests (or polls for messages)
and performs some level of validation on the requests. Most validation is
protocol-specific.
SSL proxy profiles
An SSL proxy profile handles SSL communication and negotiation. An SSL
proxy profile determines the SSL version as well as the keys and
certificates to use in the SSL handshake. Basically, an SSL proxy profile
defines everything that is needed to establish a secured connection.
Processing policies
A processing policy is where all processing occurs. A processing policy
references processing rules that define the actions to perform against
request and response messages.
Processing rules
A processing rule is simply a path that a request or response message
follows as it flows through a service. The processing rule references a
sequence of processing actions that perform the actual processing. You can
configure separate processing rules to handle the request and the response.
You can configure a processing rule to run in the event of a processing
error.
Processing actions
An action is a processing step in a processing rule. An action can be any
type of processing that can be applied to a message. There are many
different types of actions that perform different functions. Some of the
different types of actions include XSLT transformations, encryption,
decryption, signing, logging, and AAA.
XML managers
An XML manager is responsible for managing document caching, XML
parser options, XSLT compile options, and much more. There is only one
XML manager associated with a service.

Chapter 5. DataPower services
Although every DataPower service has the same general characteristics, there are
different types of services that can be created on the DataPower appliance. Each
service type has built-in features and functionality to handle different of
transactions and protocols for the type of traffic that is expected as well as the type
of back end being proxied.
Services on appliances
DataPower appliances provide services to process traffic. Table 1 lists which
services are available on which DataPower appliances.
Table 1. Services by appliance
XA35 XS40 XI50 XB60 XM70
HTTP Server Yes Yes Yes Yes Yes
SSL Proxy Yes Yes Yes Yes Yes
TCP Proxy Yes Yes Yes Yes Yes
XSL Coprocessor Yes Yes Yes No No
XSL Proxy Yes Yes Yes No No
XML Firewall No Yes Yes No No
Web Application No Yes Yes Yes No
Firewall
Multi-Protocol Gateway No Yes Yes Yes Yes
Web Service Proxy No Yes Yes Yes Yes
B2B Gateway No No No Yes No
Low Latency No No No No Yes
Messaging
HTTP Server service

An HTTP Server service can serve documents that are stored on the DataPower
appliance to HTTP clients. The HTTP Server service can provide access to certain
files without necessarily requiring a log in to the appliance. This functionality can
be thought of as a mini HTTP/Web server. This functionality is generally
superseded by a robust, enterprise-class Web server in your IT architecture.
However, it is an available service option.
The use of an HTTP Service is not a recommended practice. It is not the intent of
the DataPower appliance and can deplete available memory when you use it to
store many file on the file system.
SSL Proxy service

An SSL Proxy service acts as a proxy for SSL traffic, accepts input from a defined
set of clients (potentially any), and forwards this traffic to a defined remote
destination. An SSL Proxy masks the remote server from client interactions.

An SSL Proxy service is most commonly used to enable the transmission of
syslog-ng from an SSL application (for example, Stunnel). The SSL Proxy service
uses a secure connection to relay all traffic that is received on a specified local
address (or host alias) to a specified remote peer.
Refer to the Administrators Guide for more information.
TCP Proxy service

A TCP Proxy service acts as a proxy at the TCP network layer. A TCP Proxy
service accepts input from a defined set of clients (potentially any) and forwards
this traffic to a defined remote destination. A TCP Proxy service masks the IP
address of the remote server.
A TCP Proxy service uses a TCP connection to relay or forward all traffic that is
received on a specified local address (or host alias) to a specified remote peer.
XSL Coprocessor
Like the XSL Proxy, the XSL Coprocessor provides schema validation and
transformations for a remote service. However, the XSL Coprocessor is a loopback
service that can be called by only a Java™ application that communicates with the
service through the JAXP API. The calling Java application would pass the XML
document to the XSL Coprocessor for validation, parsing, and transformation. The
XSL Coprocessor would perform the required processing and return the results to
the Java application.
Although the XSL Coprocessor is a supported service, it is not a recommended

practice. The preferred method is to keep the DataPower service inline rather than
as a coprocessor. This approach provides for easier configuration of the service and
the remote application. This approach also allows the service to scan the incoming
message for threats before the message reaches the application.
XSL Proxy
The XSL Proxy validates and transforms incoming or outgoing XML documents.
An XSL Proxy would proxy a remote service, applying all the necessary schema
validation and transformations to the incoming document before the message
reaches the remote service. Alternatively, it can provide content rendering of
outbound messages from XML to other formats (XML, HTML, and WML).
Additionally, an XSL Proxy can perform the following functionality:

v Accept and send SOAP, raw XML, or unprocessed input
v Process large documents in the streaming mode
v Communicate with clients, servers, and peers with SSL encryption
v Monitor and log activity by delivering log information to external managers
v Allow, strip, or process attachments (DIME, MIME)
The functionality provided by the XSL Proxy is also provided by XML Firewall or
Multi-Protocol Gateway services. The primary use of this service is on an XML
Accelerator XA35 where other services are not available.
XML Firewall
The XML Firewall is designed to process generic XML requests and responses
transmitted over HTTP or HTTPS. The XML Firewall uses a single protocol and
contains one processing policy with a set of request, response, two-way, and error
rules. Its configuration defines the listening IP address-port pair as well as general
threat protection.
Although the design of the XML Firewall is to process XML documents of all
types, including SOAP-formatted messages, it can accept unprocessed (text/binary)
documents. Through the processing policy, the XML Firewall can apply all of the
various processing actions to the request and response message, regardless of
format. Processing can include AAA, transformations, schema validation, logging,
and cryptographic operations.
Like all other DataPower services, the XML Firewall can be configured to proxy
remote services. However, one of the commonly used features of the XML Firewall
is to define the configuration as a loopback service. As a loopback service, the
remote server is undefined. In this case, the service itself generates a response to
the client after processing the request. This functionality is useful when
developing, testing, and debugging a service when the remote server is
unavailable.
Web Application Firewall

The Web Application Firewall is intended to be used to proxy Web applications,
provide AAA services as well as cookie encryption, cross-site scripting protection,
session timeout management, and name-value input processing and filtering. A
common use of a Web Application Firewall is to provide perimeter authentication
for Web applications, asserting the user’s identity to the remote application server
in a format that the application server can consume. For example, a Web
Application Firewall can authenticate the user with the credentials in the request
using HTTP basic authentication and create an LTPA token that can propagate the
identity to a remote application server. This functionality can also be implemented
in other service types. However, the Web Application Firewall provides a wizard
that guides you through the creating of the service.
Although the Web Application Firewall might appear to be the best choice to proxy
all Web applications, there might be cases where it is not. It is important to note
that the tools available in the WebGUI for configuring the Web Application
Firewall are different than the tools to configure other service types. For example,
the WebGUI does not provide drag-and-drop functionality, such as the policy
editor, where the actions can be dragged on the policy line and configured.
The terminology used for this service type is also different from other service
types. For example, a rule in other services is called a map in the Web Application
Firewall.
Multi-Protocol Gateway
The Multi-Protocol Gateway is a powerful and versatile service. In additional to
threat protection and multistep processing capabilities, the Multi-Protocol Gateway
can process requests between various protocols. The supported protocols are HTTP,
HTTPS, WebSphere MQ, WebSphere JMS, IMS™, FTP, NFS, SFTP, and TIBCO EMS.
Chapter 5. DataPower services 23

The Multi-Protocol Gateway receives incoming requests, processes them with a
processing policy, and forwards the request to the remote server. The
Multi-Protocol Gateway processes the response similarly, applying the applicable
response rule, if configured.
The Multi-Protocol Gateway uses front-side handlers to manage client connections.

A single Multi-Protocol Gateway can have multiple front-side handlers that listen
or poll for requests. The ability of configuring multiple front-side handlers allows a
Multi-Protocol Gateway to receive requests from different protocols. For example, a
Multi-Protocol Gateway can have one front-side handler listening for HTTP
requests and another handler polling a WebSphere MQ queue for messages. Both
front-side handlers forward the incoming message to the Multi-Protocol Gateway
for processing and forwarding to the remote server.
All of the available protocols on which the Multi-Protocol Gateway can receive
incoming requests can also be used on the server-side to forward the request to its
destination. The client-side protocol does not need to match the server-side
protocol.
A Multi-Protocol Gateway service offers many of the same services and capabilities
as a Web Service Proxy service. Unlike a Web Service Proxy service, a
Multi-Protocol Gateway service cannot use a WSDL to determine a configuration.
Web Service Proxy

The Web Service Proxy provides security and abstraction for remote Web services.
By loading a WSDL file and adding a front-side handler, a Web Service Proxy is
ready to start receiving requests. Although this configuration is simplistic, it is a
fully functioning, feature-rich service that provides endpoint/URI abstraction,
parser-based XML threat protection, XML well-formedness checking, SOAP schema
validation, payload schema validation, hooks for monitoring, and a platform for
building operation-level rules.
The WSDL file provides critical information about a Web service, including
endpoint locations, instruction on binding to these endpoints, and expected
message schemas. With just the WSDL and a front-side handler, a Web Service
Proxy has the basic configuration. Additional configuration can be defined to meet
your case requirements, such as AAA, document transformations, message
encryption, and so forth.
In addition to the Web Service Proxy being able to upload or fetch a WSDL file, the
configuration of a Web Service Proxy can be through a subscription to a UDDI
registry or WSRR server. Through subscription, the Web Service Proxy receives
automatic updates of the WSDL file or dynamically looks up the endpoints for the
service.
The Web Service Proxy has powerful monitoring and logging capabilities. Web
services traffic that flows through a Web Service Proxy can be monitored and
logged at the service level down to the WSDL operation level. Other features of a
Web Service Proxy are service-level monitoring (SLM), WS-ReliableMessaging,
WS-Policy, and WS-Addressing.
B2B Gateway
A B2B Gateway supports B2B (business-to-business) transactions among trading
partners. The gateway supports the Applicability Statement protocols (AS1, AS2,
and AS3) for the transport of B2B messages with external trading partners.
v An external trading partner sends inbound documents to the B2B gateway and
receives outbound documents from the B2B gateway. This trading partner,
probably in a separate company, generally exchanges messages with
Applicability Statement protocols.
v An internal trading partner receives inbound documents from the B2B gateway
and sends outbound documents to the B2B gateway. This trading partner,
probably in the same company, implements some B2B processing logic and
exchanges messages with the B2B gateway with HTTP, WebSphere MQ, or
another non-AS protocol.
For message bodies, the gateway supports the following standards:

v XML
v EDI (Electronic Data Interchange) ANSI X12
v Electronic Data Interchange for Administration, Commerce, and Transport
(EDIFACT)
v Binary that is neither XML nor EDI
Low Latency Messaging

Low Latency Messaging (LLM) can process messages through rapid routing or
through message transformation. LLM offers the following features:
v Multicast and unicast support
v Low latency and high throughput
v Reliability
v Stream failover for high availability
v Fine-grained message filtering
v Statistics and performance monitoring
v Congestion and traffic rate control
Chapter 5. DataPower services 25

Chapter 6. Key administrative functions
Controlling access
It is possible to control access to the DataPower appliance and to control access to
the various objects that the DataPower appliance offers. The following methods are
available to control access:
v Access control lists
v Accounts and groups
v Role-based management
Finally, it is possible to create virtual systems, called application domains.

Application domains are separate from one another. Access to each application
domain can also be controlled.
Access control list

An access control list (ACL) restricts access by ranges of IP addresses. Only hosts
with addresses in a listed range can access the DataPower resource. An ACL is the
most restrictive level of control. An ACL overrides all other access control methods.
Accounts and groups

Like most network appliance, an administrator can create local accounts and can
create local groups. Even when performing remote authentication, an administrator
must create local groups. Groups provide a means to control access at a broad level
or a fine-grained level in one or more application domains.
Local groups are assigned specific access rights called access policies. Access policies
identify resources and permissions that users in the group can perform on these
resources. Access policies can be restricted by IP address, by application domain,
by resource type, or by a combination of these resource identifiers. Resource
identification can be as broad as all objects of a specific object type or as specific as
only objects of a specific name.
Role-based management
Role-based management (RBM) extends local access control to use remote
authentication and authorization servers, such as an LDAP server or a RADIUS
server. All of the flexibility that is available through groups can be integrated into
authentication systems in your enterprise.
Application domains
Application domains allow administrators to separate a DataPower appliance into
multiple management spaces. After appliance and firmware initialization, the
default domain is the only application domain that is available. The default
domain should be used only for managing the network for the appliance and for
managing the appliance itself. Application domains should be used for the
development of Web services.
By creating an application domain, an administrator in the default domain can

restrict access to vital appliance resources. Application domains allow for easier
porting of development domain configurations among appliances without affecting

the core network for the appliance. After an administrator in the default domain
creates an application domain, that administrator should configure access to that
application domain.
Only administrators in the default domain can create an application domain. Also
only administrators in the default domain can change network settings such as the
Ethernet or VLAN interfaces, and change appliance settings, such as appliance
time.
Configuration management
A new DataPower appliance or a new application domain in an existing
DataPower appliance can be completely configured by importing a saved
configuration. Configurations can be exported and downloaded to other
workstations. These archives can provide backup copies that might be useful when
migrating a configuration among appliances or during disaster-recovery.
Importing configurations
To rapidly configure a newly initiated DataPower appliance, to update the
configuration of an existing appliance, to configure a new application domain, or
to modify an existing application domain, use the Import Configuration utility.
Exporting configurations
You can use the Export Configuration utility to perform the following tasks:
v Back up the entire appliance
v Export the configuration of an application domain, including the default
domain
v Export select parts of an application domain (services, access configurations, or
other elements)
Configurations can be exported to one or more XML files or to an archive file that
includes the data that is needed to reproduce a domain configuration. The
exported files can be downloaded to the connecting workstation.
Comparing configurations
You can use the Configuration Comparison utility to determine what has changed
between current and saved configurations, including exported configurations.
Configuration checkpoints can also be set at any time within application domains.
You can then compare these checkpoints to any other configuration or roll back the
configuration of a domain to an existing checkpoint.
Managing files
The appliance provides a File Management utility to administer files that are
stored in the predefined directories and in any user-defined subdirectories.
Depending on the file type and directory, you can use the File Management utility
to upload, fetch from other locations, copy, delete, download, move, or edit files.
Appliance management
The primary aspects of managing the appliance are:
v Setting the local time and timezone of the appliance
v Shutting down and restarting the appliance
v Uploading or rolling back a firmware image
Time settings
Administrators can set the local time on the appliance. The local timezone can also
be set. The appliance adjusts for daylight savings time according to the specific
timezone setting.
Shutting down and rebooting

Administrators can shut down the appliance and reboot the appliance.
Uploading firmware images

Administrators can upload firmware images to change the image that is currently
running on the appliance.
Chapter 6. Key administrative functions 29

Chapter 7. Configuration procedures
Configuration of the DataPower appliance consists of several distinct phases.
v Network services and user access configuration
v Application development
v Production management
Each phase involves a different set of objects, and often each phase of
configuration is performed by different enterprise personnel. Each phase, and the
best practice procedures used in each phase, are discussed here.
Network services and user access configuration

This is the first phase of configuration. In this phase, the various objects that
control the Ethernet interfaces, packet routing, time services and emergency failure
notification are configured. The basic networking values, such as IP address and
gateway address, are provided during installation. If the appliance is subsequently
moved, these values might change. For the most part, these objects all reside in the
default application domain of the appliance. These objects can be found under the
Network branch.
Administrators often implement a set of user access policies at this time. User
access policies determine who can access the appliance to view or alter the
configuration of the appliance. The objects used to set access policies can all be
found under the Administration branch. User access policies might change over
time, so these objects might be altered as the appliance gains usage.
The appliance administrator might create one or more application domains, to

facilitate development of services on the appliance. It is a best practice to create all
application services in a domain other than the default domain. In this way, only a
limited number of select users can gain the power to change the fundamental
configuration settings of the appliance, such as the IP address. Any number of
developers might be given access to one or more specific application domains to
implement service solutions.
Most of these objects reside in the default domain. The configuration of these
fundamental objects often do not change once set. The administrator who sets
these values typically exports a complete appliance backup, with the Export
Configuration utility, which forms the basis of a reusable appliance configuration.
Application development
During this phase, architects and developers create the various services that
implement the solutions needed to meet the enterprise SOA requirements. In every
case, it is best practice to first review the services available on the appliance to
determine the service that best fits the requirements for the implementation. After
the service is selected, the range of additional objects needed to implement the
solution can be decided. This phase is often iterative, as more and more top level
services are configured on the appliance. The object-oriented nature of the
architecture, together with the WebGUI, offer three different methods for creating
services.

1. Use a wizard or task template. The WebGUI provides wizards that configure a
service and many of the related or referenced objects. In many cases, the fastest
path to developing a solution begins with a wizard. The service the wizard
creates can then be modified to meet more specific needs.
2. Begin with the top-level service. The configuration interfaces for each of the
top-level services, such as an XSL Proxy, lead the developer to the objects
needed to implement a complete solution, The interface provides a relationship
map.
3. Begin with the lower-level objects. For developers who are very familiar with
the object-oriented nature of the architecture, this method can be more efficient
to first develop the various supporting objects, such as monitors, log targets,
and network server objects first, and then relate these prebuilt objects to a new
top-level service. This method can be effective when developing a library of
potentially reusable objects.
Production management
This phase occurs when the appliance is moved into a runtime, production
environment. Administrators commonly require that the appliance provide the
means to produce status reports on a regular and timely basis, that the appliance
provide a quick, secure and reliable means of upgrade, configuration deployment
and backup, and that access to the configuration interface is limited. These objects,
such as SNMP Communities, statistical monitors and audit logs are configured as
the appliance goes into production and might be altered over time. These kind of
objects do not affect the application services developed on the appliance.
Chapter 8. Decision-making for solutions
The DataPower appliance offers many ways to implement solutions for enterprise
SOA requirements. In many cases, the appliance provides more than one
implementation solution to a single set of use case requirements.
For example, an enterprise architect wants to extend an internal resource to

external business partners. For security reasons, the enterprise cannot allow direct
connections between external partners and the internal resource. The actual
location and HTTP URL of the internal resource must remain hidden to those
partners. The solution must mask, or proxy, the internal resource.
The appliance offers five different services that meet this requirement to proxy, or
mask, an internal resource. Each service makes available different kinds of
capabilities in addition to acting as this kind of proxy. To select the best
implementation method, architects must consider the complete set of use case
requirements.
For example, the complete use case might require the following:
v Mask (proxy) a backend SOAP over HTTP-based enterprise resource
v XML message validation and transformation
v Logging of key data to a remote collection point
v Throttling of messages arriving too quickly from any client address
v SNMP monitoring of the appliance
v Low implementation time and effort
Four DataPower services meet these requirements. However, the simplest service
meets these requirements and also requires the least time and effort to implement.
The architect can run the configuration wizard for an XSL Proxy and arrive at most
of the solution in a short amount of time.
The implemented solution consists not of a single service or application that

contains a set of capabilities, many of which overlap with other services, but rather
consists of a set of configured objects which are linked together to implement a
solution.
For example, the first and simplest solution (an XSL Proxy) actually consists of the
following configuration objects:
XSL Proxy
A top-level service limited to HTTP and HTTPS protocols. These protocols
meet the requirements
Processing Policy
The set actions applied to a message. The kinds of actions available in the
policy are constrained by the top-level service selected. In this case, XSL
Proxy allows only Validate and Transform actions.
Monitors
Several different kinds of monitor objects can be created to throttle traffic
from clients that appear to be attacking the service. In the case given, a
Count Monitor provides throttling protection against clients apparently

mounting a denial of service attack on the appliance. Monitors can also be
used to generate log messages, which in turn can be delivered to network
management consoles.
Log Targets
The log targets required to meet the requirements subscribe to the desired
log message categories and severity and are configured to upload log files
to a remote location. In addition, another set of targets delivers messages
to a configured SNMP Community console.
The configuration Wizard automatically configured the XSL Proxy service and the
Processing Policy. The administrator must now use the WebGUI to complete the
solution by configuring associated log targets and monitors. As these are all
objects, the objects can all be reused or cloned for other services at any time.
If, however, the enterprise requires that all messages that are exchanged with
external partners must be encrypted for security, then an XSL Proxy service will
not meet the need because an XSL Proxy cannot perform cryptography. An XML
Firewall service offers all of the capabilities of an XSL Proxy plus full
cryptographic services. The administrator can run the configuration wizard for an
XML Firewall and arrive at a solution quickly. If an XSL Proxy has already been
built, the log target and monitor objects can simply be reused.
If, finally, the enterprise architect adds the requirement to drive the configuration
of the solution from a WSDL file, the administrator instead configures a Web
Service Proxy, which takes the WSDL file describing the enterprise resource and
automatically configures itself with only a minimum of additional input from the
administrator. The Web Service Proxy can handle encrypted messages with little or
no additional configuration needed. This final set of requirements looks like the
following:
v Mask (proxy) a backend HTTP-based enterprise resource
v XML message validation and transformation
v XML message decryption and encryption
v WSDL-driven configuration
v Logging of key data to a remote collection point
v Throttling of messages arriving too quickly from any client address
v SNMP monitoring of the appliance
v Low implementation time and effort
The choice of the best implementation solution requires examining all of the use
case requirements and comparing these requirements to the capabilities of the
DataPower services. The first step in identifying the solution is selecting the correct
service.
Having successfully extended an internal enterprise resource to external partners

(inventory checking, for example), the enterprise architect might then decide to
move forward and externalize more internal services. However, the next internal
resource selected for sharing with external partners might employ a messaging
protocol that is not HTTP. External partners, however, can only use HTTP as a
messaging protocol because this is the only port and protocol open at the
enterprise internet firewall. This use case then adds the requirement to bridge
disparate messaging protocols.
Only the Multi-Protocol Gateway offers this capability. A Multi-Protocol Gateway
also offers full cryptography as well as the logging and monitoring required by the
enterprise. The gateway can implement the full range of cryptographic services,
including encrypting and decrypting messages. Configuration of the Multi-Protocol
Gateway cannot be driven automatically by a WSDL, however.
To determine the configuration that meets the complete requirements of the use
case, you must identify and configure a range of objects. This chapter has
presented an overview of objects to help you identify the components of the
required solution.
Follow these steps to create a checklist of objects to configure to meet your use
case requirements:
1. Identify the best service to use
2. Identify the message processing needed
3. Identify the additional capabilities required
4. Assemble identified items into a task list
This activity should provide you with a basic configuration activity roadmap for
implementing the required use case solution.
Chapter 8. Decision-making for solutions 35

Appendix A. Getting help and technical assistance
This section describes the following options for obtaining support for IBM
products:
v “Searching knowledge bases”
v “Getting a fix”
v “Contacting IBM Support” on page 38
Searching knowledge bases

If you encounter a problem, you want it resolved quickly. You can search the
available knowledge bases to determine whether the resolution to your problem
was already encountered and is already documented.
Documentation
The IBM WebSphere DataPower documentation library provides extensive
documentation in Portable Document Format (PDF). You can use the
search function of Adobe® Acrobat to query information. If you download
and store the documents in a single location, you can use the search facility
to find all references across the documentation set.
IBM Support
If you cannot find an answer in the documentation, use the Search Support
feature from the product-specific support page.
From the Search Support (this product) area of the product-specific
support page, you can search the following IBM resources:
v IBM technote database
v IBM downloads
v IBM Redbooks
v IBM developerWorks
Getting a fix
A product fix might be available to resolve your problem. To determine what fixes
are available for your IBM product, check the product support site by performing
the following steps:
1. Go to the IBM Support site at the following Web address:
http://www.ibm.com/support
2. Select Support & Downloads → Download to open the Support & downloads
page.
3. From the Category list, select WebSphere.
4. From the Sub-Category list, select WebSphere DataPower SOA Appliances.
5. Click the GO icon to display the list of most recent updates.
6. Click the link for the firmware and documentation download that is specific to
your WebSphere DataPower product.
7. Follow the instructions in the technote to download the fix.

Contacting IBM Support
IBM Support provides assistance with product defects. Before contacting IBM
Support, the following criteria must be met:
v Your company has an active maintenance contract.
v You are authorized to submit problems.
To contact IBM Support with a problem, use the following procedure:

1. Define the problem, gather background information, and determine the severity
of the problem. For help, refer to the Software Support Handbook. To access the
online version of this handbook, use the following procedure:
a. Access the IBM Software Support Web page at the following Web address:
http://www.ibm.com/software/support
b. Scroll down to the Additional support links section of the page.
c. Under Support tools, click the Software Support Handbook link.
d. Bookmark this page for future reference.
From this page, you can obtain a PDF copy of the handbook.
2. Gather diagnostic information.
a. Access the product support at the following Web address:
http://www.ibm.com/software/integration/datapower/support
b. Locate the Assistance area of the product support page.
c. Click Information to include to access that technote that lists the
information that is required to report a problem.
3. Submit the problem in one of the following ways:
Online
From the IBM Support Web site (http://www.ibm.com/support), select
Support & Downloads → Open a service request. Following the
instructions.
By phone
For the phone number to call in your country, refer to “Contacts” in the
Software Support Handbook. From the Software Support Handbook Web
site, click Contacts. In the U.S. and Canada, call 1–800–IBM-SERV
(1–800–426–7378) and select option 2 for software.
If the problem you should submit is for a software defect or for missing or
inaccurate documentation, IBM Support creates an authorized program analysis
report (APAR). The APAR describes the problem in detail. Whenever possible, IBM
Support provides a workaround that you can implement until the APAR is
resolved and a fix is delivered.
Appendix B. Standard and specifications
DataPower appliances are built on a standards-based model.
Important standards
A few important standards, based on the XML foundation, are as follows:
XML XML is a general purpose specification for creating other markup
languages. XML is a combination of data and metadata. XML consists of
tagged elements that not only show the data but describes and delineates
it.
XSD XSD is the set of rules to which an XML file must conform. For example, to
create a purchase order XML file for your application, you can create the
XSD file that validates whether the incoming purchase orders (the XML
files) have the proper structure.
SOAP SOAP is a message format that Web services use for sending and receiving
XML-based messages. SOAP is more sophisticated than XML in that its
construct provides for, among other items, a message header and body.
WSDL
WSDL is a language for describing Web services. WSDL defines the
services, ports, bindings, and operations that constitute a Web service,
along with endpoint information (hosts, ports, URIs) and perhaps other
metadata, such as policy information.
XPath XPath for XML is similar to SQL for databases. XPath allows for searching
and retrieving information (node sets) from XML documents based on
some criteria.
XSLT XSLT is an XML language for transforming XML documents from one
format to another. For example, to transforms the format of a vendor’s
purchase order to your XML format, you can use XSLT to write this set of
instructions.
EXSLT
EXSLT is a community extension to XSLT to provide a library for string
manipulation, date/time functions, and other miscellaneous functions.
Important specifications
Of course, all the power of XML, SOAP, and many of the Web services
specifications and standards are available on the appliance. Some of the key Web
services specifications are as follows:
WS-Security
WS-Security is a specification to enable message integrity, message privacy,
and nonrepudiation, typically using digital signatures and encryption.
WS-Addressing
WS-Addressing is a specification to enable Web services to communicate
endpoint and addressing information among themselves.
WS-Policy
WS-Policy is a specification that allows Web services to advertise and
enforce policies for things like security and quality-of-service.

WS-ReliableMessaging
WS-ReliableMessaging is a specification that enables Web services to
reliably transmit SOAP messages, even when there are problems in the
infrastructure that would otherwise lead to failure.
Notices and trademarks
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information about the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law: INTERNATIONAL
BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS”
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE. Some states do not allow disclaimer of express or implied warranties in
certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements or
changes in the product(s) or the program(s) described in this publication at any
time without notice.
Trademarks
IBM, the IBM logo, CICS, developerWorks, DB2, DataPower, IMS, RACF,
Redbooks, Tivoli, WebSphere, and z/OS are registered trademarks of the
International Business Machines Corporation in the United States or other
countries.
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered
trademarks or trademarks of Adobe Systems Incorporated in the United States,
and/or other countries.
Microsoft and Windows are trademarks of Microsoft Corporation in the United

States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and other countries.
Other company, product, and service names may be trademarks or service marks
of others.
Index
A B D
access B2B Appliance XB60 database connectivity
controlling 27 See XB60 add-on features 6
Access Control List B2B Gateway DataPower discussion forum viii
See ACL overview 25 DataPower product Web site viii
access policies 27 bold typeface ix default domain 27
ACL 27 developerWorks Web site viii
administrative interfaces discussion forum, DataPower viii
command line 3
listing 2
C document processing
client-side 16
certificates
WebGUI 3 error handling 17
network security 5
XML management interface 3 multistep 16
characteristics, physical 2
ANSI X12 25 overview 15
checkpoints, configuration 28
appliance phases 15
CLI
firmware 29 processing policy 16
access 3
rebooting 29 server-side 16
administration 3
setting time 29 documentation conventions, typefaces ix
client-side processing, messages 16
shutting down 29 domains
command line interface
appliances application domains 27
See CLI
administrative model 2 default 27
communication
application development 31 duration monitors
certificates 5
configuration phases 31 message monitor 5
identification credentials 5
network services 31 overview 5
keys 5
physical characteristics 2
secure network 5
production management 31
SSL proxy profiles 5
programming model 3
software architecture 2
validation credentials 5 E
configuration EDI ANSI X12 25
types 9
phases EDIFACT 25
user access 31
application development 31 Electronic Data Interchange for
XA35
network services 31 Administration, Commerce, and
capabilities 9
production management 32 Transport
XB60
user access 31 See EDIFACT
add-on features 6
scenarios error handling
capabilities 13
solution 33 error rule 17
XI50
Configuration Comparison utility 28 message processing 17
add-on features 6
configuration data on-error action 17
capabilities 11
checkpoints 28 Ethernet ports 2
XM70
comparing 28 events
add-on features 6
exporting 28 logging 5
capabilities 13
importing 28 Export Configuration utility 28
XS40
managing EXSLT standard 39
add-on features 6
introduction 28 Extensible Markup Language
capabilities 10
count monitors See XML
Applicability Statement protocols 25
message monitor 5 Extensible Stylesheet Language
application development 31
overview 5 Transformation
application domains 27
cryptography See XSLT
application optimization
certificates 5 external resources, accessing viii
add-on features 6
intelligent load-balancing 6
keys 5
self-balancing 6
architecture
network communication 5
F
software 2 File Management utility 28
validation credentials 5
AS1 25 files
customer support
AS2 25 managing 28
contacting 38
AS3 25 firmware
obtaining fixes 37
available services 21 uploading images 29
searching knowledge bases 37
fixes, obtaining 37
front-side handlers 19

H Multi-Protocol Gateway
overview 23
serial port 2
server-side processing, messages 16
Hardware Security Module multistep processing 16 service level monitors
See HSM overview 5
HSM services
add-on features 6
PED 6 N application development 31
B2B Gateway 25
HTTP Server network communication
building blocks 19
overview 21 certificates 5
by appliance 21
HTTP Server 21
keys 5
Low Latency Messaging 25
I secure 5
Multi-Protocol Gateway 23
IBM Tivoli Access Manager overview 21
validation credentials 5
See TAM SSL Proxy 21
network services
IBM Tivoli Composite Application TCP Proxy 22
configuration 31
Manager for SOA Web Application Firewall 23
NFS
See ITCAM Web Service Proxy 24
logging 5
identification credentials XML Firewall 23
notices 41
network security 5 XSL Coprocessor 22
Import Configuration utility 28 XSL Proxy 22
Integration Appliance XI50 Simple Network Management Protocol
See XI50 O See SNMP
intellectual property 41 ODBC Simple Object Access Protocol
intelligent load-balancing See database connectivity See SOAP
add-on features 6 SLM peers 5
application optimization 6 SNMP
italics typeface ix P MIB files 5
monitoring 5
ITCAM patents 41
monitoring 5 traps 5
PED
SOAP
add-on features 6
administrative interfaces 3
HSM 6
K PED port 2
monitoring 5
XML management interface 3
keys physical characteristics 2
SOAP standard 39
network security 5 PIN entry device
specifications
knowledge bases See PED
listing 39
searching 37 processing actions 19
WS-Addressing 39
processing policies 19
WS-Policy 39
message processing 16
WS-ReliableMessaging 39
L multistep 16
processing rules 19
WS-Security 39
library, DataPower portfolio vi SSL Proxy
product documentation Web site vi, viii
licensing overview 21
product Web site, DataPower viii
sending inquiries 41 SSL proxy profiles 19
production management 32
log targets 5 network security 5
publications, DataPower portfolio vi
Low Latency Appliance XM70 standards
See XM70 EXSLT 39
Low Latency Messaging listing 39
overview 25 R SOAP 39
RBM WSDL 39
See role-based management XML 39
M Redbooks Web site viii
role-based management 27
XPath 39
XSD 39
message monitors XSLT 39
overview 5 support
message processing
See document processing S See customer support
syslog
monitors scenario
logging 5
count monitors solution configuration 33
syslog-ng
overview 5 security
logging 5
duration monitors certificates 5
overview 5 identification credentials 5
message keys 5
overview 5 network communication 5 T
service level monitors SSL proxy profiles 5 TAM
overview 5 validation credentials 5 add-on features 6
Web services monitors self-balancing TCP Proxy
overview 5 add-on features 6 overview 22
monospaced typeface ix application optimization 6
TIBCO Enterprise Message Service XA35 (continued)
add-on features 6 capabilities 9
Time Settings utility 29 XB60 21
timezone add-on features 6
setting 29 capabilities 13
trademarks 41 XI50 21
trading partners 25 add-on features 6
typeface conventions ix capabilities 11
XM70 21
add-on features 6
U capabilities 13
XML Accelerator XA35
user access
See XA35
configuration 31
XML Firewall
user accounts 27
overview 23
user groups 27
XML management interface
utilities
access 3
Configuration Comparison 28
administration 3
Export Configuration 28
XML managers 19
File Management 28
XML Path
Import Configuration 28
See XPath
XML Schema Definition
See XSD
V XML Security Gateway XS40
validation credentials See XS40
network security 5 XML standard 39
XPath
custom programming 3
W XPath standard 39
XS40 21
Web Application Firewall
add-on features 6
overview 23
capabilities 10
Web Service Proxy
XSD standard 39
overview 24
XSL Coprocessor
Web Services Description Language
overview 22
See WSDL
XSL Proxy
Web services monitors
overview 22
overview 5
XSLT
Web services specifications
custom programming 3
WS-Addressing 39
XSLT standard 39
WS-Policy 39
WS-ReliableMessaging 39
WS-Security 39
Web sites
DataPower product viii
developerWorks viii
discussion forum viii
product documentation vi, viii
Redbooks viii
Web-based graphical user interface
See WebGUI
WebGUI
access 3
administration 3
controlling access 27
role-based management 27
WS-Addressing specification 39
WS-Policy specification 39
WS-ReliableMessaging specification 39
WS-Security specification 39
WSDL standard 39
X
X12 25
XA35
available services 21
Index 45

Printed in USA

3 8 0-ApplianceOverview

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

3 8 0-ApplianceOverview

Загружено:

Авторское право:

Доступные форматы

WebSphere DataPower SOA Appliances

First Edition (November 2009)

Chapter 5. DataPower services . . . . 21 Notices and trademarks . . . . . . . 41

© Copyright IBM Corp. 2002, 2009 iii

Who should read this document

How this document is organized

© Copyright IBM Corp. 2002, 2009 v

Installation and upgrade documentation

Problem determination documentation

viii Appliance Overview

The products in the DataPower portfolio includes the following rack-mountable

Consequently, you can access DataPower appliances through a command line, a

DataPower appliances help you:

© Copyright IBM Corp. 2002, 2009 1

Regardless of the administrative interface, properly authenticated and authorized

Often, the WebGUI is used in only development environments. After development,

Command line interface

SOAP-based XML management interface

XPath is an important technology for these appliances. Aside from custom

Figure 1. Basic configuration architecture

A wide range of objects provide ancillary or supporting capabilities to the top-level

Logging and monitoring

DataPower appliance provide one or more of the following monitors:

Available add-on features

XML Accelerator XA35

© Copyright IBM Corp. 2002, 2009 9

XML Security Gateway XS40

Integration Appliance XI50

Chapter 2. Appliance types 11

B2B Appliance XB60

The B2B Appliance XB60 appliance is designed to help your business:

Low Latency Appliance XM70

Chapter 2. Appliance types 13

This list does not include the full range of capabilities.

Phases of document processing

© Copyright IBM Corp. 2002, 2009 15

After a service receives the incoming message, there is addition client-side

Processing policy in the DataPower service

Chapter 3. Document processing 17

The primary reusable parts (objects) in a service configuration are as follows:

© Copyright IBM Corp. 2002, 2009 19

HTTP Server service

SSL Proxy service

© Copyright IBM Corp. 2002, 2009 21

Refer to the Administrators Guide for more information.

TCP Proxy service

Although the XSL Coprocessor is a supported service, it is not a recommended

Additionally, an XSL Proxy can perform the following functionality:

Web Application Firewall

Chapter 5. DataPower services 23

The Multi-Protocol Gateway uses front-side handlers to manage client connections.

Web Service Proxy

For message bodies, the gateway supports the following standards:

Low Latency Messaging

Chapter 5. DataPower services 25

Finally, it is possible to create virtual systems, called application domains.

Access control list

Accounts and groups

By creating an application domain, an administrator in the default domain can

© Copyright IBM Corp. 2002, 2009 27

Shutting down and rebooting

Uploading firmware images