IBM Websphere DataPower SOA Appliances

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.

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.