IBM DataPower Online Training

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

IBM DataPower Course Contents

IBM Data PowerXI52 Online Training Course Content

Course Name: Data power XI52

Course Duration: 20 Hours Approx

Course Recourse: Materials + XSL file+ Real time scenarios for practicing+Deployment scripts

Course Content: Given below

1. Introduction about IBM Websphere Datapower Appliance.

2. Overview of IBM websphere Datapower Appliances.

3. Introduction to the Datapower WebGUI.

a. Logging in to the WebGUI.

b. WebGUI Organization.

c. Datapower's On-Board Filesystem.

4. Creation of a simple XML Firewall Service.

5. About Show probe.

6. Tracing the flow by viewing the transactions.

7. Creation of Advanced XML Firewall Service(Loop Back)

a. Creating Policy.

b. Configuring Match action Rule.

c. Configuring Result Action.

9. Transform with XSL - Adding a Transform

10. Types of Variables and its scope.

11. Action in Loop Back Proxy Service.

a. Routing URL.

b. Extract using X-Path.

12. Differences between XML Firewall and MultiProtocol Gateway.

13. Multi Protocol Gateway (Static Backend).

14. Multi Protocol Gateway (Dynamic Backend).

15. Creating Certificates using Cryptographic tools in Datapower.

16. Encryption and Decryption actions In datapower.

17. Sign and Verify actions.

18. Call Processing Rule action.

19. Fetch Action.

20. Route Action using 3 ways.

21. Validate Action.

22. Authentication and Authorization using AAA action.

23. Creation of Web Service Proxy

· Authentication and Authorization using AAA action using AAA and XSl.

· Sign and Verify usage In WS Proxy

· Error handling

24. Problem Determination.

a. Default System Log

b. Audit Log.

c. Multistep Probe

d. Object Status.

e. Ping Remote

f. TCP Connection Test

g. Send Test Message.

25. SSL Handshake

a. Forward.

b. Reverse.

26. Trouble Shooting Mechanisms.

a. Ping Remote

b. TCP Connection Test

c. Packet Capture(default)

d. View System Log and generate Log messages.

e. Error Report

g. Probe

27. Log Target.

a. Configuring Log Target.

b. Event Filters

c. Event Subscriptions

28. Integration with MQ.

29. Integration with FTP.

30. Integration with DB.

31.Scenario on transforming xml to CSV and FLAT File.

32. Scenario on Accepting JSON as Payload.

33. Creating and Deploying Reusable Patterns (new feature in data power)

Some of the Administration Concepts

38. Exporting a service/object from a domain through Web GUI.

39. Importing a service/object in to a domain through Web GUI.

40. Deployment Policy while exporting a service through Web GUI.

41. Deployment Policy while importing a service through Web GUI.

42. Authenticating the user what is SOMA and its advantages.

43. Difference between WebGUI and SOMA.

44. SOMA Scripts

a. Flush Document Cache.

b. Flush Style sheet Cache.

c. Enable a Probe.

d. Disable a Probe.

e. Exporting an object/service.

f. Importing an Object/service.

45. SOMA Scripts

a. Deployment Policy while exporting a service.

b. Deployment Policy while importing a service.

46. Creating and Managing User Accounts.

IBM Websphere DataPower SOA Appliances

Introduction to DataPower SOA appliances

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.

1.1 Overview of the DataPower appliance

With SOAs, composite applications are created that are comprised of reusable, loosely-coupled service components. The technical foundation of an SOA is in the support for the XML and Web services built on top of it. By using SOAP, SOA clients can invoke services (RPC-style) without explicit support for a wide variety of transport protocols and message formats. By having a SOAP facade in front of an existing service, virtualization can occur where clients invoke a virtualized version of the underlying service. It eliminates the need to understand intricate details of the service’s implementation.

In this context, the use of XML enables data to be self-describing with explicit language support for common operations that manipulate the data. For example, by using the XPath language, you have a consistent way to select data items from within an XML document. In SOA, service intermediaries can use XML and other application-layer data to route, secure, control, transform, or otherwise process service requests and responses, decoupled from the actual service implementation that fulfills each particular request.

1.1.1 Challenges in service-oriented networking

Although greatly appealing, the promise of loosely-coupled, virtualized services in SOA comes at a price. Because the data-centric complexity of XML and SOA operations has increased, traditional software-based middleware has struggled to keep up. In particular, software-based service intermediaries have emerged as natural extensions to traditional server-side service stack environments. Unfortunately, their success and impact have been inhibited by three fundamental challenges of consumability, security, and performance. DataPower SOA appliances overcome these challenges.

Consumability

Often, middleware-service stacks have an underlying software engine (generally J2EE in origin) upon which a Web service hosting engine is built. In some sense, this group of products has been built by joining together necessary components in an embedded fashion.

For example, a J2EE servlet engine can be extended to receive SOAP over HTTP by providing a new Web service servlet. The Web service itself is deployed on this servlet. The result is a system built from multiple software layers, each with its own configuration and maintenance requirements. Taken individually, each layer’s requirements may prove tedious. Taken together, the collective set of installation and maintenance requirements often proves prohibitive. For example, patch upgrades that affect a layer in the stack of embedded software must be coordinated in a single atomic action. Further complicating this problem is the focus that the traditional software industry has. The industry tends to favor the addition of more functions to a software product over increasing the usability of the existing function.

Security

The advent of SOA has created a common communication framework to understand and operate on application data that has never been seen before. With self-describing XML, intermediaries can extract portions of the data stream and affect application-aware policies.

Unfortunately, this has also enabled a new opportunity for malicious attacks. That is, as XML regularly flows from client to enterprise through IP firewalls without much impediment, the obvious place to attack is in the application data stream itself, the XML. While we are just beginning to understand the repercussions of these types of attacks, they are emerging. XML denial-of-service (XDoS) attacks seek to inject malformed or malicious XML into middleware servers with the goal of causing the server to churn away valuable cycles and processing themalicious XML. Enterprise-ready application servers are susceptible to many of these types of attacks, leaving a security hole open that must be closed.

Performance

Another key challenge that has emerged with the adoption of XML is in the computational cost of XML processing. Computing on XML in traditional software-based middleware is orders of magnitude more costly (from the computational sense) than native data structures. XML must be parsed into the native data structures of the local computer’s architecture.

Further, XML transformations exacerbate processing needs because they require multiple passes through the XML structure and are highly sensitive to the transformation processing engine. Securing XML and SOA at the application (XML) level provides barriers that can requires as much as 60 times the processing capability as plain XML, based on typical workloads.

Additionally, it is often prohibitive from a performance point of view to enable key requirements such as monitoring, auditing, and security. Customers end up sacrificing those functions to keep equipment costs from growing unwieldly.