My hype meter has been revved up lately, and what has pegged it is Web services. Who is hyping up Web services? Hmm...Microsoft, Sun, IBM, HP, BEA, SilverStream, Ariba, BowStreet, webMethods...my aunt Judy. I'm expecting to see this e-mail soon: "Quit your job and make $100,000 a year writing Web services in this groundbreaking business opportunity." Oh...that one might be true <G>.

Okay, so what's behind all this hype? Is all this real?

My take: absolutely real - or at least it will be very soon. This is my fourth "sea change" in software development. I can recognize a good thing when I see it.

In the '80s, the PC computing revolution took off. Snicker, snicker, PCs will never be serious. This revolution networked individual PCs but didn't change how corporate IT was implemented. That evolved from file system-based databases (dBase anyone?) to client/server applications using relational databases - that did change how IT was implemented. Snicker, snicker, client/server is for departmental apps. The Internet revolution has networked practically every system in the world and has led to some changes in corporate IT. Snicker, snicker, great for brochureware and shopping. We're now evolving to allowing applications to be easily built through networked businesses. Do I hear a snicker from the back row?

Web services is a subset of a service-oriented architecture. Each piece of business functionality is encapsulated into some sort of object/component that is then made available as a stand-alone service. Pretty basic stuff, really. What turns a service into a Web service is that it uses XML-in and XML-out for parameter and return value passing and that the service is accessible through a standard wrapper. It also has some easy-to-use protocol such as HTTP or SMTP. So you send XML to a URL. Magic happens. XML gets returned. Pretty simple.

What differentiates this from a servlet wrapper to a session bean? The servlet parses the XML, calls the bean, gets return data, remarshals the return XML, and sends the string back. Well, at the core, not much. However, a proper Web service has a SOAP wrapper along with a description written in WSDL. If the service is public, it will be registered with some registry, most likely using UDDI. The registry might be private to your organization, public to the world, or available in an industry-specific registry. The services you create will be made available to others who need them.

The cool thing about having a standard such as SOAP and WSDL that supersedes any specific technology standard (EJB, DCOM) is that an application can be built without regard to the underlying technology implementation. Service-based architectures allow you to separate the business use of a function from its actual technical implementation. Creating a business process that includes DCOM, EJB, CICS, and AS/400 functionality becomes a snap if each function is packaged as a Web service.

This alone is useful, but if you're a pure-Java shop, what's the real benefit? You can wrapper all of your functionality with EJBs and just call them. Of course, we know things aren't that simple because of the proliferation of technology in many companies. But let's take this to the next level: assume each business process you want to call exists in different businesses. This means you're building an application that spans your internal systems and interacts with your business partners.

As a developer, you'd look up the various services in the appropriate registries. From the registry you'll get a location and documentation you need to call the service. (A phone call might still be required for authorization, etc. Don't be fooled into thinking everyone will just use complex services without humans getting involved.) Your application would call each service (remember, a service is basically a URL with XML-in and XML-out). Your job is to integrate the pieces and spindle, fold, and mutilate the XML passed between the services. You're creating workflow and processing rules - a business process. Odds are you'll then publish the new object you've created as its own service. This isn't too different from normal OO except services are much more coarse-grained and don't require the same language to interoperate.

Service-oriented architectures and Web services look to fulfill the promise of application assembly. Discrete business functionality deployed as services is assembled into applications. To me this implies heavier reliance on workflow, rules engines, and messaging systems such as JMS. If we're manipulating XML at each step of the process, then a higher-level, more productive way of building applications can be achieved. However, at the core, each service still has to be written, and "real" work must be accomplished. This is where J2EE comes in and why I think J2EE is the perfect platform for a robust Web services architecture.

So keep your eyes open. Begin reading about Web services. It is the next big thing and it's already happening. It's a steamroller that will change how we write software. But at the core it's not a revolution - it's an evolution. And, luckily, J2EE puts us in the perfect position to take advantage of it.