THIS MONTH I'M GOING TO TALK about Web Services (capitals intended - I'll explain in a minute). Specifically, as one of the architects of BEA's SOAP/WSDL stack, I'd like to talk to you about Web Services and where they fit in with J2EE and Java in general.

I capitalize the term "Web Services" because when I use it I'm referring to a very specific set of specifications and protocols. Many companies have retargeted their marketing machines at this space and they're using the term "web services" (lowercase s intended) to mean a wide variety of things, some even stretching it out to mean regular Web sites. Web Services are, by my definition, services whose shape (or interface) is determined by a corresponding WSDL document and that are accessed through some binding to the SOAP protocol. Currently, services falling under this umbrella should follow the SOAP 1.x and WSDL 1.x specifications published by W3C. Commonly, the transport protocol is either HTTP or SMTP, but there are probably others out there. There's another type of Web Service that I'll refer to as Business Web Services. These are built using conversation-based protocols on top of something akin to SOAP (or even SOAP itself). Some examples include ebXML, BizTalk, and RosettaNet.

SSB and JMS
When you look at the J2EE programming model for ideal points of integration with Web Services, there are two that jump out at you. Stateless Session Beans (SSB) look almost exactly like a typical Web Service. They have an interface that should map to a WSDL document; they're stateless like RPC-style Web Services; and they have the right granularity for loosely coupled systems. On the other hand, JMS destinations map very well to document-style Web Services. You can define an end-point; routing can be done; and the systems are nicely decoupled from one another. There may be other points of integration between the two systems, but because we know that these integration points are more appropriately decided by the Java Community Process (JCP, see JSR 101 & 109), at BEA we felt that we should stick to the obvious overlaps.

Performant, Extensible, Configurable...and Fast
When using our Web Services stack versus others, the main difference is that it's been built to be highly performant, extensible, and configurable. There are hooks for building extensions to the base functionality to ensure that while Web Service usage patterns are developing, you're not left waiting for the next release.

On the performance side, we developed an extremely fast XML parser and layered a very programmer- and execution- efficient API on top of it. Known as an XMLEventStream, this API allows you to access your XML data efficiently like SAX, while at the same time retaining a lot of the convenience of DOM. We also provided tools to deploy Web Services straight from your SSBs and your JMS destinations, so that you can get started right out of the box.

The more difficult decision was to support only very simple types. Our implementation supports the base types (like int and String) and structs (mapped to JavaBeans or Maps) and arrays of these types. We left the type codec very extensible so that you can map more complicated constructs to your own Java class implementations, but we don't encourage using it if you don't have to. It should be used only when interoperability would suffer without it. We also left out some of the higher-level J2EE constructs such as entity beans.

J2EE Should Never Be Stretched Too Far
Ensuring that your system is interoperable with many different clients has become very important. When you're architecting your applications, you need to make careful decisions when choosing what functionality you'll expose and how you'll expose it. For instance, many people are building Web service gateways to entity beans. Since I don't even believe that a Java client should access entity beans over the network (access should always be through a session bean), how could I support the access of entity beans through what should be a stateless interface with no support for remote references?

Another alarming feature that's becoming prevalent with the more "dynamic" implementations (by which I mean unmanageable) is the passing of serializable Java datatypes directly in a SOAP message. Some are even BASE64-encoding the serialized byte array! This is exactly the sort of thing developers should not do when building interoperable systems. All access points to your application should be designed with cleanliness, compatibility, and above all, maintainability firmly in mind.

If there's one thing the browser has taught us, it's that it is possible to have cross-platform applications hosted over the network. The arrival of Web Services promises that we can host cross-platform application services as well, if only a little care is taken.