While Java is known for its portability, and many web services artifacts are portable, vendors frequently offer considerable extras in an attempt to make things more convenient for you (or lock you in, depending on your level of cynicism). Given the fact that we’re covering such a wide array of material already, it is simply not possible to cover the minor changes in how to do everything on specific platforms. Given products such as WebLogic, Tomcat, WebSphere, Glassfish, ServiceMix, CXF, Mule, Active Endpoints, OpenESB, and dozens of other vendor offerings that address different aspects of SOA, there is problem of multiplication in a book such as this one. So I’ve chosen a middle-of-the-road stance for the most part, and kept mostly focused on what tools will be available to the most people. Here’s the lineup:
This chapter defines relevant terms and introduces architectural topics that will guide the growth of your SOA. The items covered in this chapter are not exhaustive, nor are they intended to be followed in a specific order; it is an orientation to SOA concepts.
Because SOA and web services rely so heavily on XML, this chapter covers how to use XML, XPath, and Schema in ways that specifically support your service-oriented effort. Some useful tools are highlighted, as well as how to use JAXB to convert between Java and XML. We’ll cover key SOA topics such as canonical data models and schema-based validation.
Whereas Chapter 2 focuses largely on XML schema, design, and validation topics, this chapter extends the discussion of Java and XML into document instance processing. It addresses the new StAX API, JAXB, and XML catalogs.
As Java programmers, we’re used to a variety of convenience methods and classes; this chapter is a bit of a “convenience chapter.” That is, you’ll just set up shop with some different containers so that you are ready to execute clients and services in a few different popular environments. You’ll do a “Hello World” service, and I’ll introduce WSDL, discuss service clients, and show you tools for monitoring and debugging your services during development. Then we can move on to more specific API work in the coming chapters.
The SOAP with Attachments API for Java (SAAJ) is introduced in this chapter, which deals largely with how to build SOAP messages programmatically. SAAJ is a low-level API that works directly with the XML in your services and clients.
The Java API for XML Web Services (JAX-WS) builds on the older JAX-RPC API to make creating and invoking web services much easier than it is with SAAJ. This chapter covers how to do many of the same kinds of things you do with SAAJ, but in a slimmer, more abstract manner. But beware: if you’re used to the JAX-RPC API, things have changed considerably.
Now that we’ve seen how to consume SOAP-based web services, this chapter covers how to provide them with a variety of advanced features, including binary content, headers, and more.
REpresentational State Transfer, popularly known as REST, does not use SOAP. As a consequence, you don’t use the SAAJ or JAX-WS APIs to work with a REST-based SOA. This chapter covers REST, discusses why it’s popular, and explores how to create meaningful web services that take advantage of the native protocols of the Web, without some of the overhead that SOAP-based services can create.
This chapter introduces using the WS-BPEL (Business Process Execution Language) 2.0 standard to create business processes or workflows. BPEL allows you to orchestrate invocations of multiple web services and perform a variety of powerful activities on the inputs and outputs, including XSL transformations and other common elements of structured programming.
BPEL is a large and complicated beast, and this chapter dives into some of the more advanced aspects of using orchestrations, including dealing with faults, parallel activities, delays, and correlations.
Your SOA needs some measurement, some standards, and some tools in place to watch over it. Without these, you could spend considerable time and effort inadvertently creating a monstrous mash of rogue and duplicate services and unknown clients. Add to the mix the potential for poor documentation, low visibility, and inconsistency, and you’ve got a very expensive art project on your hands. SOA governance, an extension of IT governance, can provide some structure, visibility, consistency, and even policy enforcement to your SOA.
Integration has been a thorn in the side of architects and developers for decades, and web services valiantly aim to overcome many of the issues surrounding it. And while very simple web services may readily interoperate out of the box, in the real world things can be trickier. This chapter introduces standard ways to enhance the ability of your web services to interoperate with services and clients on other platforms. The WS-Addressing specification is examined, along with implementing clients in a variety of languages, such as Ruby and .NET. You’ll also find tips and tricks for working around gray areas in the specifications.
This chapter examines concrete, standard ways that SOAP-based services can improve their reliability, with specifications such as WS-ReliableMessaging.
Here we step away from the recipe format to provide an overview of the enterprise service bus (ESB), which frequently serves as the backbone of an agile SOA. Because ESBs are typically implemented as a collection of patterns and there is no standard specification for what an ESB is, I offer an overview of some of the leading ESBs. Despite the fact that they generally serve as message mediators and provide routing, security, and rules, they all work very differently. There is no single, clear market leader in this area, but we’ll take a look at some of the most popular, including the Oracle Service Bus, TIBCO’s ActiveMatrix ESB, OpenESB, and Apache ServiceMix.
Unfortunately, there wasn’t time to cover more topics relevant to SOA, such as security with WS-Security. Although related topics such as authentication are addressed in a few recipes, web services security is not given a full treatment here.