Hello and welcome to the column dedicated to exploring the evolving world of Web services from the inside out. Over the course of the next few months I will examine, in great depth, the fundamental principles of the Web Services Architecture as well as pay special attention to the core promise that drives this new, quickly evolving, emerging technological paradigm: interoperability.

I will begin, however, not by looking forward to what Web services will bring us in the future, but by taking a quick look back at just how far Web services have come, what the current playing field looks like in terms of tool availability, and offering some insight into just how far we have to go in order to make this exciting new set of technologies viable and competitive.

From whence we came

If it seems to you that this whole concept of Web services exploded onto the Internet development scene very quickly, you're all too correct. As difficult as it is to believe, the building blocks of this new paradigm (SOAP, WSDL, and UDDI) are no more than just a few months old and yet are already having a massive impact on the way we think about designing, developing, and deploying Web-based applications.

The Simple Object Access Protocol (SOAP [see Resources]) was born out of an idea for an XML-based RPC mechanism originally fostered by Dave Winer of Userland Software back in 1998. The idea evolved through a joint effort of Winer, Don Box at DevelopMentor, and Microsoft to publicly emerge as SOAP version 0.9 in the latter part of 1999. At that time, the reaction of the developer community was mixed. My own reaction, if I recall correctly, was that SOAP looked like a cool toy, but it was a long way from being useful. Things change quickly. Soon after the release of SOAP 0.9 came the release of SOAP 1.0, which brought with it many improvements and broadening support among developers.

IBM officially joined the SOAP development effort in May of 2000 by coauthoring the SOAP version 1.1 specification (see Resources) and cosubmitting it as a W3C Note, officially signaling the start of the "Web services revolution." With IBM on board, developers on non-Microsoft development platforms stood up and took notice of SOAP for pretty much the first time. The promise of seamless cross-platform interoperability between loosely coupled and dynamically integrated applications was a powerful lure that fit in perfectly with Java's development philosophy.

From that point on, Microsoft and IBM took the lead in putting SOAP-enabled development tools into the hands of developers. Starting simple, IBM was the first to produce a Java-based toolkit for SOAP (see Resources) that was promptly donated to the open-source Apache Software Foundation for further development. Microsoft released the first rendition of their SOAP Toolkit soon thereafter and announced their massive .NET Web services initiative the following July.

With industry support for SOAP growing rapidly, IBM and Microsoft next turned their attention to filling the various holes in the Web Services Architecture that was emerging. Namely, with the potential that SOAP-enabled applications would grow rapidly, there needed to be a mechanism for describing the capabilities of such services as well as a mechanism for locating services once they had been deployed. In September of last year, Microsoft, IBM, and Ariba jointly announced the Universal Description, Discovery and Integration initiative (UDDI [see Resources]) that would provide an open specification and a set of tools for discovering Web services deployed on the Internet. Then, just a matter of weeks later, the same three companies announced the Web Services Description Language (WSDL [see Resources]), an XML-grammar for describing the capabilities and technical details of SOAP-based Web services that compliments SOAP by allowing for dynamic cross-platform integration.

In future installments of this column, I intend to discuss how each of these three complimentary yet distinct technologies work together to provide the foundation of the Web Services Architecture and how IBM is leading the charge to drive the most value out this new paradigm in Web development.

Back to top

You are here

Looking at where we've been often gives us great insights into where we are and where we need to go. Looking back at the time line, I'm happy to say that Web services is reaching the first stage of technology maturity - and that is acceptance. The Web development world is beginning to see Web services as a viable tool to accomplish what so many older, larger, and bulkier technologies could not: seamless interoperability between platforms and operating systems. This is made obvious by the fact that nearly every major player in the Web Development industry is looking at how they can best take advantage of SOAP and the other Web Service enabling technologies.

Today, the types of applications that you can create with the Web Services Architecture are, for the most part, fairly simplistic toys intended mostly to help developers grasp the fundamental concepts as opposed to demonstrating true enterprise-scale applicability of the platform. Now, granted, while there are some exceptions to this status, the fact remains that if you take a good look at the maturity of Web services development tools as compared to say the Java Enterprise SDK or the Microsoft COM+ Platform, it is clear that there still remains quite a bit of work to be done to unleash the true potential of Web services upon the enterprise development community.

So, what does this statement mean? It means that in the enterprise environment, SOAP, WSDL, and UDDI have yet to be tried, tested, and proven to work and work well. Does it mean that, as a developer, or as a technology decision maker, you should not look to Web services to solve enterprise-level problems? Or, even more drastically, that you should not even dare a look at SOAP until time and effort has allowed the tools implementing these standards to evolve to a state of maturity suitable for mission-critical environments? Absolutely not! While I would not quite yet deploy SOAP, WSDL, and UDDI based Web services into enterprise environments, as I mentioned before, this area is evolving and growing very quickly. Enterprise-ready tools such as Microsoft's .NET Platform and the Apache Axis Engine (both of which are still currently in development) promise to deliver a high level of value, performance, and stability upon which to build enterprise Web services. By learning and experimenting with SOAP today, your development team will gain critical experience that will help them succeed with this new development paradigm. Perhaps just as important, their experiences will assist those of us building these tools to refine and tweak them to meet the ever-challenging requirements of our customers.

Back to top

The playing field

At last count, I know of at least 39 different implementations of the SOAP Specification with growing support for multiple operating systems and development languages. While each of these all have their own level of capability, standards support, and quality control, they all share at least one thing in common: they all understand how to create and consume SOAP Envelopes. The significance of this fact should not be underestimated. This simply means that regardless of how the tool was implemented, or where it is deployed, there exists the potential of seamless interoperability that would allow applications written in one language on one platform to consume the services of applications written in a completely different language on a completely different platform.

Below is a side-by-side feature comparison of four of the most popular SOAP implementations available for the Java, Win32, and Perl environments. As you can tell from the results, there are far more similarities between implementations than differences in specific SOAP or SOAP-related features that are supported. This is a good thing because it means that we're getting closer and closer to realizing SOAP's true potential. The differences that do exist, however, are, in some cases, significant enough to cause quite a few headaches if you don't know the secrets to getting around them (anybody who has tried to use the Microsoft Toolkit with Apache SOAP can attest to this fact). I plan to discuss many of these differences in-depth in an upcoming article, so stay tuned.

Back to top

Building common ground

The most amazing thing about the current effort to define and evolve this area of Web services is not the speed at which things are moving, but the fact that so many companies have signed on to the developement project and are working together to build a common ground of basic interoperability upon which they all can play. Microsoft and IBM, longtime rivals in the Web Development industry, have worked hand-in-hand, leading the charge to ensure that their tools can seamlessly communicate with one another by fully supporting the SOAP, WSDL, and UDDI specifications. Obviously, there is more work to be done; in fact, as I am writing this article a delegation from the IBM Web services team and the Apache SOAP development team are busily working with a group from Microsoft to work out whatever interoperability problems may exist between their various implementations.

One of the most common questions I see posted on the SOAP-related mailing lists deals with how to get a Microsoft SOAP client or server to communicate with an Apache or IBM WSTK client or server. The problems that most developers have with this scenario is getting around certain differences and limitations in the way that both Apache and Microsoft implemented the SOAP specification. In a future article I will provide an in-depth example of just how to go about doing this. Until then, be sure to download the latest version of Apache SOAP (at least version 2.1 [If you've already downloaded the IBM Web Services Toolkit version 2.1 or higher, then you already have Apache SOAP 2.1]) and the latest beta version of Microsoft's SOAP Toolkit (see Resources). Each of these updates provides improved interoperability as well as a host of other features that should prove to make your life easier.

Java developers using the Apache SOAP tools may also optionally download the IBM Web Services Toolkit (WSTK) or Web Services Development Environment (WSDE) -- two sets of tools that augment and extend the functionality of Apache SOAP. Available through alphaWorks, these preview technologies provide WSDL and UDDI support as well as a host of other features and development tools that fulfill the promise of a comprehensive Web services development platform.

Back to top

So . . . now what?

Your next question should be: now what? I've taken a brief look at the history of Web services and a brief look at where it is now. I've told you that given the current state of the tools available to build Web services, it is not yet a good idea to go out and build your entire enterprise around Web services, but, at the same time, that the time is coming soon when you may be able to do just that. And I've provided you with a side-by-side comparison of the most popular SOAP tools currently available to help you get a head start on where to go if you need to develop Web services on a particular platform.

The next step that you should take would be to start learning about the Web services tools that are currently available:

• If you haven't done so already, read the SOAP, WSDL and UDDI Specifications.
• Download the latest version of the IBM Web Services Toolkit.
• Study the sample Web services I've provided with the Toolkit.
• Begin implementing your own Web services.

Resources

• See Part 2 of this series.
  
  
• Check out Part 3 of this series.
  
  
• Read the SOAP Version 1.1 Specification
  
  
• Familiarize yourself with the WSDL Version 1.1 Specification
  
  
• Information about UDDI can be found at the UDDI Web Site.
  
  
• The IBM Web Services Toolkit is available through IBM's alphaWorks Web Site.
  
  
• The IBM Web Services Development Environment preview is also available through alphaWorks.
  
  
• IBM also offers the WSDL Toolkit for download.
  
  
• Information about Microsoft's SOAP Toolkit and .NET can be found at http://msdn.microsoft.com.
  
  
• Download Paul Kulchenko's SOAP::Lite for Perl module.
  
  
• Get an overview of the Web services architecture with this article.
  
  
• Review the IBM UDDI4J release, an open-source Java implementation of the Universal Discovery, Description, and Integration protocol.
  
  
• Learn about XML messaging with SOAP with this tutorial.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• From whence we came
• You are here
• The playing field
• Building common ground
• So . . . now what?
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers