Standards

Web services hold the promise to revolutionize the way architects build systems and how software is delivered and sold. While the full realization of these advances will take years to play out, most of these benefits are rooted in technologies that are available today. This article will look at what can be achieved today using Web services technologies to prepare yourself to take advantage of Web services as the standards and tools mature. We will discuss five things that you can do to take advantage of Web services core technologies and point out trends to pay attention to in the near future.

Five Things You Can Do Today
XML for Data Interchange
If your system can export and import data as XML then you can take advantage of many of the benefits of existing XML technologies. One critical problem faced by IT managers is the blizzard of data formats that their systems generate. Whenever two systems need to communicate with one another, software needs to intervene and convert the syntax and meaning of data from one system and convert those data into the language and dialect understood by the other. While this is a fairly straightforward programming assignment, it consumes time and money, and can introduce spectacular errors into your operations.

XML technologies can help a lot here. XML and XML Schema provide a framework where architects can unambiguously define data formats. The format definition, written in XML Schema, is human-readable but is specifically designed to be processed by computers. This contrasts with the current state of practice where data formats are described in a format that a programmer can understand (e.g., Word document, PDF). Using this definition, a programmer can write software to process the data. With XML formats, data are described in XML Schema which can be interpreted and acted upon very easily by XML components that are available today. The benefit is that a broad collection of data-processing tasks can be automated. Schema-aware software can read a schema document and automatically create code to help the programmer convert and process disparate data formats. In some cases, programmers will be able to handle data parsing and integration tasks without writing a single line of source code.

Developers can realize several benefits by standardizing on XML as a data interchange format.

1. Consistent rules for creating formats that can be enforced across an organization
2. No need to create custom data parsers. Off-the-shelf parsing technologies from major vendors are abundantly available.
3. XML transformation technologies (XSLT) can be used to solve common data translation and transformation tasks with minimized coding.
4. Tools from major vendors (Microsoft, IBM, Open Source) can read schema files and auto-generate code. And they are able to greatly accelerate tasks that involve manipulating XML-formatted data.

XML as a New Interface Type
Even without strict adherence to emerging SOAP and WSDL specifications, your applications can use XML and HTTP as a sophisticated new interface type that gives you the loose coupling benefits of Web services. This approach can be easily migrated to native protocols when your organization is comfortable with their maturity. For many years Web developers have leveraged the plumbing that supports Web browsing to also implement distributed systems. By leveraging HTTP as a readily accessible transport (heck, everyone has a Web server) and SSL as a secure pipe, developers have implemented secure conversations among distributed applications for a number of years. Web services and technologies such as SOAP and WSDL formalize some of the ad hoc mechanisms that we've used for years, but the underlying mechanisms are the same.

Brew Your Own
Whether you adhere to the spiffy new protocols or not, you can easily gain the same benefits in your system designs by leveraging HTTP as a transport and XML as your payload. You won't automatically interoperate with emerging Web services technologies such as WSDL, but you may in fact get a better understanding of how to program in this model without getting overly confused by the acronym soup of Web services. As many Web developers know, there are plenty of tools that, in less than a dozen lines of code, allow a developer to post an arbitrary text message to a Web server. By placing XML in this message you now have an extensible mechanism where one program can talk to another. Sure, there's a Web server in between but this "protocol handler" simply strips the XML payload out of the message and passes it on to a program (cgi, xSAPI, dll, jsp, asp, etc.). A program receiving one of these messages can read the message, act on it, and send information formatted in XML back to the sender in the HTTP response. Tada! You now have a Web service.

Now, to the Web services purists out there I'm a DBWS (Dirty Blaspheming Wayward Soul) for speaking like this. Why am I advocating anything other than "The Way"? Here's why. One of the fundamental benefits of Web services is its support for a distributed, loosely coupled architectural model that is interoperable. The main enablers of this interoperability are the ubiquitous deployment of HTTP servers and XML as a data standard. While SOAP formalizes the packaging of messages sent among machines and WSDL formalizes a way to advertise the nature and availability of a service, these are secondary to the core benefit of being able to implement loosely coupled distributed architectures using a single, standardized data-modeling language (XML Schema).

The industry has developed so much HTTP and HTML processing software that all major programming environments (Java, C++, C#, Perl, Python, etc.) have rich, capable tools for moving data around over the Web. Implementing a home-brew Web service requires less than 50 lines of server and client code. Finally, once you've adopted the Web services design paradigm, making the hop to SOAP and WSDL (and whatever other helper protocols and technologies may emerge in the future) is trivial.

One final sacrilegious note: the software industry risks killing the Web services golden goose. One of the largest factors that drove adoption of HTML and HTTP was that they were exceedingly simple to implement. A developer could open vi, tap in a handful of HTML tags, and in a few minutes create globally available, hyperlinked content. Once developers became comfortable with HTML and simple editing, we began demanding more sophisticated features from our tools and the protocols. We evolved these technologies based on the intimate understanding we gained through real-life experience. With today's Web services activities many tools vendors, ISVs, and protocol developers are trying to jump right to the end of the game. By providing developers with all-encompassing developer tools, protocols, and products, we're potentially robbing the industry of the opportunity to become familiar with and to truly understand the underlying technologies. OK, enough said.

Decouple Your GUIs
Good design practice recommends that when we build applications, we separate business logic from UI logic. We figured this out pretty well in client/server applications but regressed substantially when we moved to Web technologies. For various reasons, it was difficult to build a well-separated Web application. Decoupling your Web-presentation logic from your business logic brings significant benefits to your Web application user interface design.

Whether you use Web services protocols like WSDL and SOAP or just brew your own XML messages and transports, one of the most important places where Web services can impact system architecture is at the GUI. By splitting the presentation tier from the business tier(s) using Web services, you derive two important benefits. First, the model enforces the separation of business code and display code. Despite best intentions, many implementations end up with undesirable coupling between interface code and business code. The result is not only inelegant but also can prevent a Web interface implementation from being easily scaled using Web farming techniques. Web services avert this issue by placing XML messaging between display logic and business logic.

Another benefit of exposing the business tier to the presentation tier via Web services is that Web services are presentation technology agnostic. While you may choose to implement all your presentation code in server-side JSP, a partner or customer may want to display some of your information in their Web-based GUI that uses another technology. If you use JSP on Apache and your partner has a Microsoft IIS/ASP-based site, seamlessly integrating your Web portal with your partner's can be a challenge. Typically, you have to play games with frames or you have to coordinate closely with your partner so that the look and feel of both sites is comparable.

If your business tier exposes its information to the presentation tier as XML, however, then a partner can either choose to use your Web pages (and play around with frames or risk discrepancies between sites) or they can consume the XML that your business layer generates, massage it however they want, and present it "natively" within their user interface.

One final benefit is that for many applications, XML transformations (XSLT) can be used to format the XML data for display as HTML. This can be highly efficient and can lead to elegant and easily managed presentation logic.

XML for Data Modeling
XML Schema provides a sophisticated environment for modeling data of any type. It can be used to capture data models across an application including code modules, wire formats, and database tables. Today, there are few tools (outside of formal modeling tools) that can help us unify the different islands of data design that exist in any system implementation. For instance, on any given project a database designer may design tables using DDL, a C++ programmer designs data in header files, and the people responsible for data import/ export define data in Word documents. The same data may be represented in multiple formats within a single implementation. Nothing guarantees that these formats are compliant with one another and nothing guarantees that if the "master" format is changed the other formats are updated.

XML Schema holds a lot of promise to act as a single data-modeling environment from which environment-specific instances can be created. Consider the case where a customer contact data format is required. This format would be defined in schema. The schema would then be used to create the database tables to store the format, the C++ objects to manipulate the data in memory, and the wire format to exchange the data among multiple programs. Leveraging XML to unify data modeling gives system architects a common ground for data design.

Cool, Fast New Tools
I realize that I have just finished warning of the dangers of relying on tools without understanding the underlying bits. However, once you have the fundamentals under your belt, then the new tools and protocols, once they settle down, will offer significant developer productivity. For those ready to tackle these new tools, there are important new offerings on the market from vendors such as Microsoft and IBM. While many of these tools are still under development, others, such as Visual Studio .NET, are available and provide powerful tools to take advantage of XML and Web services protocols. These tools can shave weeks off of complex integration projects.

What Next?
Full SOAP and WSDL Compliance
Once you've become comfortable with core Web services technologies such as XML, you can graduate to other technologies without significant reengineering. SOAP and WSDL provide structure for XML conversations that are powerful as you extend your Web services to integrate with other XML-based systems.

In reality, the state of the world today is such that implementing SOAP and WSDL does not guarantee that you will be able to automatically work with another Web services-compliant tool. It's a bit like a transmission where the gears don't quite line up. Things are getting close to interoperability but there's still a lot of grinding going on. This should smooth out within the next 18-24 months as more real applications begin to use the tools and protocols and the kinks get worked out.

UDDI Integration
UDDI provides a directory for you to advertise your services. Though you may think you don't need this function unless you're a service provider, UDDI will be a very useful tool for intranet and extranet developers who embrace Web services. Watch out for the marketing hype however. The world today is neither ready for, nor in need of, a global registry where companies can expose the guts of their enterprise for casual browsing and integration (never mind close competitive scrutiny or outright hacking). Where UDDI will be most useful initially is within the enterprise as a mechanism for IT to publish services company-wide (think of things like benefits information, phone lists, conference room schedulers, etc.). Once IT has sorted things out on the intranet, extranet use will follow. UDDI (administered "behind the firewall") will be used to expose limited access to business functions (e.g., inventory, payments) to partners.

Web Services Interoperability Organization (WS-I)
It's not certain how the Web services landscape will eventually look. One place to look for some idea, however, is the Web Services Interoperability Organization, formed by Microsoft, IBM, BEA, and Intel. It aims to guarantee the consistent application of Web services in the industry. You can expect that this group will "bless" protocols as well as promote those under development by member organizations. You can expect to see numerous protocols that are currently under development at Microsoft under the aegis of GXA (Global XML Architecture) appearing as recommendations from this group. The issues addressed by the group will cover both the consistent adoption of Web services technologies as well as the identification/development of technologies missing today. Key among these will be Web services protocols and best practices for implementing security, message routing, and transactions.

Conclusion
The utter din of Web services proclamations has put off many a rational IT manager. Most people are taking a wait-and-see approach and are not attempting to build anything using these technologies today. This is unfortunate since core technologies like XML, HTTP, SSL, and other bread-and-butter Internet technologies can be leveraged in the Web services pattern to create better system architectures as well as to prepare IT organizations to leverage Web services when the tools and protocols fully mature.