IBM DataPower online training
Introduction
to DataPower SOA appliances
The emergence and proliferation of the Extensible Markup
Language (XML) and Web services has seen an explosion in the middleware
infrastructure required to support them. An important component in this
middleware architecture is in the enterprise service bus (ESB), a collection of
runtime components that provides service intermediation such as routing,
transformation/bridging, management, security, and other control functions.
While XML and SOAP enable a rich application-aware communication lingua franca,
their emergence in this space has been riddled by three key challenges. First,
the size and complexity of traditional software-based middleware product
installations has increased installation and maintenance costs of
service-oriented architecture (SOA) deployments and decreased overall solution
consumability. Second, the text-based, application-centric parsing and
processing demands placed on middleware infrastructures have negatively
affected overall system performance. While most middleware solutions “scale
out”, the overall effect is increased license and operational costs as more
instances of individual middleware components must be deployed to meet service
consumer demand. Third, the new genre of application-awareness has likewise led
to a new genre of security attacks and exposures that use the architecture of
middleware components. DataPower SOA appliances address these three challenges
with the creation of specialized, purpose-built, consumable SOA appliances that
redefine the boundaries of middleware. As the “hardware ESB,” DataPower SOA
appliances are an increasingly important part of the IBM ESB family. In this
chapter, we introduce you to the DataPower appliance and present the most
common scenarios and use cases. In addition, we discuss configuration and usage
of the DataPower appliance as well as SOA governance.
Why Use an
Appliance for SOA
- Hardened, specialized hardware for helping to integrate, secure, and accelerate SOA
- integrate, secure, and accelerate SOA
- Many functions integrated into a single device
- Higher levels of security assurance certifications require hardware
- Example: FIPS 140-2 Level 3 HSM, Common Criteria
- Higher performance with hardware acceleration
- Impact: ability to perform more security checks without slow downs
- Addresses the divergent needs of different groups
- Example: enterprise architects, network operations, security operations, identity management
- Impact: Reduces need for in-house SOA skills &accelerates time to SOA benefits
- “Commodity” Processes Migrate to Hardwars
- e Historical Trend Favours Appliances for XMLAwareNetworking
SOA
Appliances Operations
- Logging
- Role-based Management
- Managing configs & policy – Deploying,
- backing up, Diff/Undo, App domains: many
- virtual devices
- Separate, locked audit log
- Troubleshooting aids
- Security – Device security, Key and
- Certificate management, HSM option,
- Security Audit, Single Image Firmware
- Upgrade
DataPower
SOA Appliance Usage Scenarios
1. Securing Web Services
- Securely enabling access to
back-end system of record for partners and customers
- Protecting against XML-borne
threats
2. Legacy Integration
- Connecting mainframe or legacy
application to Web services/SOA
- XML-enabling mainframe and
legacy systems
3. Hub Mediation
- Efficiently transforming,
routing, logging messages among applications and Web services
4. Enterprise Service Bus (ESB)
Deployments
- Provide on- and off-ramps to
ESBs, manage Web services easily through service-level
management, security management,
enterprise management console
5. Web Portal Acceleration
- Speed up rendering for dynamic
content generation
SOA governance
The clear fit of the DataPower
appliance for gateway-style use in the ESB pattern means that
it becomes the single entry point
for service requests. This is the primary place to perform
service virtualization and impose
common policies on the services of the enterprise. Those
common policies and information
concerning where services are to be found can be
configured directly into the
gateway. However, they are really part of the wider cataloging of
services for the enterprise. It is
preferable if the gateway simply acts upon the policies set at
the enterprise level. This is one
of the reasons why a service registry is needed.
With the introduction of the
WebSphere Service Registry and Repository product, all of the
related products in the SOA
Foundation suite are being upgraded to include mechanisms to
contact the registry at run time
or interact with the registry during configuration time. This
includes integration with other
key ESB products such as WebSphere Enterprise Service Bus,
WebSphere Message Broker
