- Meet the Family!
- Typical Usages of Appliances
- A Closer Look at the DataPower Products
- DataPower as a Member of the Network Infrastructure
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
A Closer Look at the DataPower Products
Now that you have a general idea what “SOA Appliances” are, and have some familiarity with the IBM offerings in this space and what they are used for, we will describe them in more detail.
Physical Characteristics of Appliances
As stated earlier, and demonstrated in Figure 1-1 appliances are “pizza-box,” rack-mountable 1U (1.75-inch thick) hardware devices. The only external interfaces are a power switch, 9-pin serial port, and four RJ-45 Ethernet ports. (Appliances with HSM will have a Pin Entry Device [PED] connector.)
){kind=link}
Software Architecture of Appliances
As Figure 1-3 illustrates, the software architecture is simple from the user perspective. There is a customized, hardened, native-code operating system kernel that implements the appliance’s core functionality. The OS resides in firmware that can be updated by applying small firmware update files.
){kind=link}
On top of this is a layer of functionality that is implemented in XSLT stylesheets, which are read-only and used by the system to implement certain functionality. We get into more detail in Chapter 2, “DataPower Quick Tour and Setup.”
The next layer up the software stack consists of configurations developed by the user; these are the application proxies and processing policies to process message traffic for your applications. Configuration files and application artifacts can reside in the directory structure on the file system or they can be hosted on remote servers and retrieved and cached at start-up time so that they do not ever reside on the appliance file system (a requirement in some highly secure environments).
Although the operating system itself and many of the appliances’ implementation details are custom and proprietary, outwardly, the appliances are built on a standards-based model. A few important ones are listed here. These are based on a single foundation, XML.
- XML—A general purpose specification for creating other markup languages—and many are built upon it, such as MathML (a markup language to describe mathematics). It is a combination of data and metadata, consisting of tagged elements to not only show the data but to describe and delineate it; for example, <po_number>12345</po_number>.
- XSD—A set of rules that an XML file must conform to. So if you want to define a purchase order XML file to use with your applications, you can create an XSD file to be used to validate those incoming purchase order XML files to ensure they have the proper structures.
- SOAP—A message format used by Web services for sending and receiving XML-based messages. It is more sophisticated than “normal” XML in that its construct provides for a message header and body, among other things.
- WSDL—A language for describing Web services. It defines the services, ports, bindings, and operations that constitute the Web service, along with the endpoint information (hosts, ports, URIs) and perhaps other metadata such as policy information.
- XPath—XPath for XML is somewhat analogous to SQL for databases.6 XPath allows for searching and retrieving information (nodesets) from XML documents based on some criteria.
- XSLT—An XML language for transforming XML documents from one format to another. If you want to transform a vendor’s XML purchase order format to your own company’s XML format, you can write a set of instructions in XSLT to do so.
- EXSLT—A community extension to XSLT to provide a library for things like string manipulation, date/time functions, and other miscellaneous library functions.
Administrative Model
As part of the “secure by default” DataPower mantra, all remote administrative interfaces are shut down by default. The only way to enable them is by bootstrapping the appliance via the serial port. We show how to do this in Chapter 2. After you do this, you have several options for administrative interfaces. These are described in detail in Chapter 12 “Device Administration” and Chapter 13 “Alternate Management Interfaces,” but we give a brief overview in the following list:
- Command-shell Admin—This can be accessed using telnet, secure-shell (SSH), or the serial port. The Command Line Interface (CLI) is an IOS-like interface, which will be familiar to many network administrators. In the most ultra-secure environments, all remote administrative interfaces are disabled, forcing all administration to be done only by those with physical access to the appliances in the datacenter. For security purposes, telnet normally remains disabled.
- XML Management Interface—The XML Management interface provides a way to administer the appliance and obtain status information via XML-based SOAP requests. There are several different specifications that can be used, including DataPower’s own SOAP Configuration Management,7 WS-Management, and WSDM. This interface is commonly used for automated, programmatic, or custom approaches to administration.
- WebGUI Admin Console—This is a standard browser-based administrative interface. It is the most commonly used way to administer the appliances. However, in some high security or production environments, browser-based administration is not permitted and is allowed only in development environments as a convenience for developers. You can see in Figure 1-7 that the WebGUI is well laid out, attractive, and intuitive.8
)
Figure 1-7 DataPower Web Admin console.
The administrative WebGUI is not only used for administering the appliance, it is also used to create the application proxies that are the raison d’être (justification for existence) for the product. You can use the drag-and-drop capabilities of the Processing Policy editor to create work-flow type rules for requests and responses, to carry out various actions as traffic flows through the device. Figure 1-8 shows the simplicity of dragging an Encrypt Action from the upper palette row of actions to the processing rule to encrypt a message as it passes through to its destination. From here, only the certificate to be used for the encryption needs to be identified, although there are many other advanced options that can be chosen, such as the encryption algorithm to use. Compare the ease of this to creating policies to encrypt a message on other platforms (and then factor in the performance difference). Notice in this figure that the other types of actions can be just as easily applied for tasks such as message filtering, creating or validation digital signatures, transforming messages, dynamic routing, and AAA. The Advanced Action contains a great deal more.
)
Figure 1-8 Drag-and-drop policy editor.
Often, the browser-based console is used only in development environments for easily building proxies, and from there, automated, scripted processes are used to deploy these configurations to test, QA and production environments, leveraging either the command-line, or SOAP-based administrative interfaces. These techniques are described in Chapter 15, “Build and Deploy Techniques.”
Programming Model
As shown in the previous section, most of the work in configuring the appliances is done using the friendly drag-and-drop paradigm of the Processing Policy editor. For any customized scenarios not covered by the GUI, the devices can be programmed.
As the appliance is XML-centric, the custom programming model for DataPower is XSLT, which is a full Turing-complete programming language. Any custom programming is done in this language.
XPath is an important technology for these XML-centric products. Aside from custom programming done in XSLT, XPath expressions are used frequently in building configurations using the WebGUI. For example, if you are building a policy to sign and/or encrypt selected nodesets in an XML or SOAP document, you simply provide DataPower an XPath expression so that it can locate those nodesets. For nonprogrammer types, the DataPower WebGUI provides an easy-to-use XPath tool that enables you to load a sample document and click on the element or nodeset, and the XPath statement is generated for you.
The DataPower appliances offer much more than what standard XSLT and EXSLT have in their libraries. The appliances support crypto operations and many different protocols that are outside the domain of XSLT and EXSLT. To provide for custom programming that leverages the full scope of functionality on the appliances, they include a complete library of extension functions and elements that can be used for XSLT custom programming. These are covered in the chapters in Part VI, “DataPower Development.”
Of course, all the power of XML, SOAP, and many of the WS-* specifications/standards are available on the appliance. Some of the key WS- specifications are
- WS-Security—A specification to enable message integrity, message privacy, and non-repudiation,9 typically using digital signatures and encryption.
- WS-Addressing—A specification to enable Web services to communicate endpoint and addressing information between themselves.
- WS-Policy—A specification that allows Web services to advertise and enforce policies for things like security and quality of service.
- WS-ReliableMessaging—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.