Welcome to the newest addition to WebSphere Developer's Journal. This column is devoted to the subject of Web services within the WebSphere family of products.

You must have heard about Web services, and maybe even written a few; well, it's time to address this important topic in the context of WebSphere development. In this monthly column I'll cover the entire software life cycle, including using WebSphere Studio tools to develop Web services, testing and packaging of Web services, deployment on the WebSphere application server, and publishing Web services on registries. I'll also cover how Web services are used within a client application, how to use proxies to invoke Web services, and how you can use a registry to look up a service provider. Since the topic of Web services is so central to the Web computing paradigm, I'll also cover many advanced topics, including the use of Web ser-vices in a mobile computing environment, tools and frameworks published on the IBM developerWorks site, and even interoperability with platforms such as Microsoft's .NET - in which Web services play a very central role.

Let's start with what Web services are and how they came to be. Web services are functional elements deployed on a node on a network and accessed over the Internet. This description is quite generic and doesn't say much; what makes an element a Web service is the how, not the what. Web services are based on a set of standards - specifically, the Simple Object Access Protocol (SOAP), the Web Service Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). SOAP is the protocol by which a remote client can invoke the functionality implemented by the Web service. Developers of Web services use WSDL to define the metadata describing the Web service and remote clients use WSDL to learn what arguments are required for invoking the Web service (as well as other things required to make the remote call). Web services providers use UDDI to publish their Web services and clients of Web ser-vices use UDDI to discover where these Web services (and the metadata describing them) reside.

Web services seem to be the hottest technology these days - judging by the number of books, articles, analyst publications, and so on. Vendors and users alike are converging on this new set of technologies that promises simple and standards-based interoperability among distributed decoupled systems. It is by far the most talked about topic in the software technology space, and the investments being made in Web services technologies are considerable.

If you think you've heard it all before, you're absolutely right. The paradigm of remote invocation and application interoperability is certainly not new, and is full of failures. You need to go back only five years to remember the battles between the Object Management Group's Common Object Request Broker Architecture (CORBA) and Microsoft's Distributed Component Object Model (DCOM). Neither of these technologies, despite being good for interoperability between applications on a LAN, is really suited for interoperability on the Internet. More importantly, both are useful in tightly coupled environments but neither is really suited for the decoupled cooperation that can be achieved over the Web. Most importantly, they are competing technologies - you either used CORBA or DCOM. It's certainly not easy for applications using these interoperable technologies to interoperate (I wonder if there's a Dilbert comic on this subject?).

Why Web Services?
So what makes Web services different? Why are they so important and why do so many people believe that they are the cornerstone of the future of distributed computing? Why do all these people think that this time it will work? It's quite simple - Web services are simple, they're built for the Web, and they're based on de-facto standards.

Web services technologies - SOAP, WSDL, and UDDI - are relatively simple. I use the word relatively because they are certainly not trivial and it takes a bit of learning to master them. But they are certainly much simpler than other distributed computing technologies that existed before them. The history of computing has proven that simple technologies succeed and highly complex technologies fail. Just look at the World Wide Web itself - can you imagine anything simpler than the HyperText Transfer Protocol (HTTP) and HyperText Markup Language (HTML)?

Web services are built from the ground up as Web technologies. SOAP, WSDL, and UDDI are all based on the eXtensible Markup Language (XML), which has taken the world by storm and become the lingua franca of the Web. If you know XML, then you can understand SOAP, WSDL, and UDDI. If you understand advanced XML-related technologies like XML schemas, then you are even better off - but that's not mandatory. SOAP is an invocation and routing protocol involving XML documents that are usually delivered over HTTP to an endpoint deployed on the Web. While the underlying transport isn't limited to HTTP in SOAP, the vast majority of Web services are accessed over HTTP.

And finally, the most important factor: the fact that Web services have become de-facto standards. Regardless of whether you're a seasoned software professional or a relative newcomer, I'm sure you're aware of the phenomena involving the Microsoft camp and the non-Microsoft camp (which then breaks down into some additional but smaller rivalries). Many software vendors have created "standards" in the past through consortiums, organizations, and more, but when was the last time you remember companies like IBM, Sun, and Oracle together with Microsoft pushing the very same set of technologies and promoting them as standards?

Well, it's true; all these companies are cooperating and driving the standards being formed for Web services. In fact, the two most dominant companies in this campaign are IBM and Microsoft, and many of the definitions and specifications result from joint work between IBM and Microsoft. As atypical as it is, the fact that IBM and Microsoft are cooperating on a technological basis gives anything produced by this process a tremendous amount of clout; and the result is widespread industry acceptance. Analysts, too, are in agreement. IBM's research indicates that Web services have become a top customer-buying criteria for 2002/2003 and a research report issued by Gartner in April 2001 estimates there's a 0.8 probability that IBM and Microsoft will exert leadership in defining Web services standards. Anyone following analysts' estimates knows that for Gartner to give a 0.8 probability means that it's practically a done deal. As you know, such analyst reports often create reality, in addition to informing the business community on the state of the market.

Web Services Within the WebSphere Product Family
IBM is working on all of the Web services standards - SOAP, WSDL, and UDDI. As a vendor, IBM is committed to delivering an implementation of each of these standards, including development tools, deployment tools and runtime servers. Obviously, because the WebSphere product family is the cornerstone of IBM's product family, Web services star in all of the WebSphere product line.

As of version 4.0 of the WebSphere Application Server (WAS), support for Web services is incorporated into every edition of WAS. This means that the Web services libraries come within WAS, that Web services packaged as enterprise applications and Web modules can be deployed over WAS, and that WAS takes care of the SOAP marshaling and unmarshaling.

In addition to WAS, you can use the WebSphere UDDI Registry to publish your Web services for others to discover. In version 4.0 this isn't part of the WebSphere application server but it should become an integral part of WAS in a future version.

In terms of development, Web ser-vices are supported through the WebSphere Studio Integrated Devel-opment Environments (IDEs), as well as toolkits. Both of the new Web-Sphere Studio tools - WebSphere Studio Application Developer (WSAD) and WebSphere Studio Site Developer (WSSD) - include full support for developing, testing, packaging, deploying and using Web services. For example, when you install WSAD you're asked to select your primary user role (see Figure 1). Guess what - Web services developer is right up there along with J2EE developer, Java developer. and Web developer.

In terms of toolkits, it's important to mention at least a few. The Web Services Toolkit (WSTK) is available from AlphaWorks (www.alphaworks.ibm.com/tech/webservicestoolkit) and includes a runtime environment, tools, samples, and documentation for Web services. Most of the toolkit has been assimilated into WSAD but it's useful if you aren't yet using WSAD or WSSD. The toolkit can even be used if you're still using VisualAge for Java and WAS 3.5.

If you develop for hosted or ASP environments you can use the Web Services Hosting Technology toolkit for supporting Web services in a hosted environment. This toolkit helps you do common tasks such as provision services, monitor, and charge based on usage, and so on. And finally, the Web Services Gateway can act as a redirector for Web service requests and can be used to set up multiple routing paths through intranets, extranets, and the Internet - all for building Web service-based interaction models.

Don't think that this is it. I recently went to the developerWorks site, which has a zone dedicated to Web services. I clicked on the All category (see Figure 2) just to get a feel of how many tools and products are listed. There were 119 downloads! You could spend a lifetime just going through all this. Instead, I'll use this column to show you some of the gems.

And finally, there's WoW. Web ser-vices on WebSphere (WoW) is an IBM initiative to establish the WebSphere community as the premier Web ser-vices solution providers. The initiative is in its infancy, and it's still unclear exactly what it means for developers, but it talks about technical support, marketing programs, business development initiatives, and more. Once it becomes a little clearer, I'll be sure to include a column discussing it.

What Can You Expect Here?
This is a monthly column dedicated to the subject of Web services on WebSphere. You can expect articles showing you how to develop Web services using WebSphere tools and how to build applications that discover and make use of Web services using WebSphere tools. You can also expect articles devoted to the packaging and deployment of Web services on WAS, publishing services in private or public registries, and advanced topics such as workload management for Web services. I'll also try to insert examples and samples of Web services. I won't teach you SOAP, WSDL, or UDDI, nor show you lengthy XML documents. There are enough great resources on these technologies and you should have a basic understanding of them to make the most of this column. I look forward to seeing you here every month.