Java Reference
In-Depth Information
WS-* Specifications and Vendor Implementations
Vendor tools frequently make it so that you do not have to work with or even see the XML
that makes all of this go at runtime. In general, vendors will create some GUI as part of their
environment that allows you to check a box indicating that you want your service to be “reli-
able.” Behind the scenes, this will add 50 lines of XML to your WSDL and some other config-
uration files. Indeed, some products, such as the Active Endpoints BPEL engine, do not allow
you to edit the XML directly at all. Vendors tell you what their products do: they'll say, “our
product allows your service clients to dynamically determine what policies a service requires
at runtime so you don't have to redeploy.” That sounds like a neat feature, and it is. But it's
often the WS-MetadataExchange specification that they're implementing behind the scenes to
make it happen.
This means that it's a good idea to read specifications so that whatever tools you're using don't
do too much “magic” for you, and so that you know when they're locking you into something
proprietary. You want to know what specs there are and what they do. But as a web services
developer, you often won't be using the spec directly, typing loads of XML to make a WS-
Security Policy work. Instead, you'll be using a tool that uses the spec for you. Clearly, we
can't cover every vendor tool in this topic, so I'm going to stick with a couple of the basic
implementations of what I'm calling a subset of quality-of-service specifications. The WSIT
implementation, now folded into Project Metro, provides an implementation of several spe-
cifications that we'll look at in this chapter. Metro is available as a separate download and
within Glassfish, and is in turn used under the hood by Oracle's WebLogic 10gR3 product.
This is what we'll be using for the examples in this chapter.
