Web Services: Building for a Brave New World (Part I)
Part I: The Web Services promise is tempting. How close is real fulfillment?
Say the term "Web services" around a lot of enterprise administrators, and you'll probably trigger some hype detectors. That's because the Web services arena currently has all the heated atmosphere and buy-now promises of a paid programming infomercial on late-night television. Some vendors are pushing the Web services model as a solution for platform and application integration problems of any and all kinds; others are hyping Web services as a quantum leap forward in business-to-business integration.
Loosely defined, Web services is a suite of standards and technologies that offer the ability to Web-enable applications and to connect them with other similarly enabled applications over the Internet. Although still in their infancy, Web services enjoy the support of most of the big industry players—IBM Corp., Sun Microsystems Inc., Oracle Corp. and Microsoft Corp. have all signed on enthusiastically.
Somewhat out in left field, Microsoft champions .NET, a combined Web services and Web application infrastructure initiative. On the Web services front, Sun pushes Sun ONE. On the Web application infrastructure side, Sun markets Java 2 Enterprise Edition (J2EE) in conjunction with Oracle. For its part, IBM pushes WebSphere, an integrated platform for Web Services and Web applications. Meanwhile, a host of smaller vendors, including Ariba, are marketing solutions based on "Web services" as well.
"A lot of folks are trying to sell Web services as a solution for anything that ails anybody, and that's just impractical," according to Rob Enderle, a research fellow with consultancy Giga Information Group.
Even some Web services proponents acknowledge the need for damage control. "There's a lot of hype out there and everything's been a little overblown by some vendors [working] to suit their own needs," agrees John Magee, senior director of Oracle 9 marketing with Oracle.
Working Together, for a Change
The development of the technologies and protocols that constitute the bulk of the Web services integration stack is actually a result of a remarkable level of cooperation among vendors.
SOAP, for example, was originally created by none other than Microsoft, a vendor better known for its proprietary excesses than for its contributions to open Internet standards. Microsoft submitted SOAP to the W3C in late 1999. Since then, it's evolved into a cross-platform standard—with further input from IBM, among others—that has been embraced by most vendors as a means to facilitate the seamless exchange of XML information.
XML, for its part, was originally developed by an engineer with Sun Microsystems.
Java, while not itself an open Internet standard, was developed by Sun co-founder Bill Joy. And since 1996, in an extraordinary display of industrywide cooperation, the Java Community Process (JCP, www.jcp.org), which comprises dozens of vendors—including Sun, IBM, Oracle, Hewlett-Packard Co. and BEA Systems Inc., among others—has helped to oversee the development of Java technology specifications. The Sun- and Oracle-driven J2EE effort is itself a result of contributions from JCP members—most notably, from IBM.
Still a Work in Progress
Broadly put, Web services constitute a suite of standards and protocols that facilitate interoperability among applications distributed across the Web. In this regard, Web services technologies promise to link heterogeneous platforms of all kinds with one another, and, proponents say, can involve so-called "legacy" operating system environments and applications in even the most cutting-edge e-business initiatives.
Sound too good to be true? That's what a lot of others are saying.
"I've seen stuff like this come and go before," says a Unix and Windows NT systems administrator with a large telecommunications company. "[The Web services standards] aren't even finalized yet, and already everyone's telling me that I can build applications on them. I think it's usually a good idea to let someone else be on the bleeding edge of these kinds of things."
The whole concept of Web services has become possible largely because the industry is at last moving toward some standards for programming (Java, much as Microsoft would deny it) and data exchange (XML). Other standards are still up in the air. In fact, the very protocols and standards that provide the foundation for today's Web services are still very much a work in progress. In early July, for example, the World Wide Web Consortium (W3C) announced the latest version of the Simple Object Access Protocol (SOAP) specification—which W3C continues to describe as a "public draft." SOAP has been almost two years in the making; it's supposed to be finalized later this year.
The foundation for what are today called "Web services" is the eXtensible Markup language (XML), which in its broadest sense defines data elements on a Web page and in other documents. Sounds a lot like HTML, doesn't it? Although XML may smack superficially of HTML, the two languages actually have very little in common. Both XML and HTML leverage programming tags, for example, but XML tags are considered far more versatile because they can define the actual content that a data element contains; HTML tags, conversely, are regarded as comparatively limited because they can merely define the manner in which data elements are displayed. Moreover, developers can also use XML to identify almost any conceivable data item because it gives them the ability to define document or page tags (HTML, on the other hand, uses predefined tags). XML, in effect, lets Web pages function like database records.
Web Services in Action
The term "Web services" is still so vague and poorly defined that examples often prove the best way to get a handle on how the concept might change the way you do business with suppliers and customers.
Take Hewitt Associates LLC, a solution provider for human resources, which recently found itself at a strategic crossroads. Hewitt provides benefits management and HR outsourcing services for most of its customers, many of which were now asking it to provide a way for their employees to access up-to-date information on benefits, 401(k) plans and other HR-related data.
"Right now, we provide outsourcing services in the area of benefits, and we're kind of an ASP where we host HR information on our site, and we have a variety of channels that let our customers access the site," comments Tim Hilgenberg, chief technology officer for applications with Hewitt.
In the past, Hilgenberg says, Hewitt would probably have accommodated this sort of customer request by designing a proprietary application that leveraged proprietary APIs—a practice that was invariably expensive and that tended to introduce a raft of additional problems.
"We're running a mainframe, we don't know what they're running, and we'd have to make sure that they could connect from environments like Notes to CICS, which tends to complicate things" he continues.
It's because of this, Hilgenberg says, that he determined to leverage the potential of Web services to solve his company's problem. "In addition to being able to expose our services in a secure way, we also wanted to make it as easy as we could on the companies that wanted to access that data, and we didn't want to develop on the client side a Java interface and a COM interface," he concludes. "So now, instead of designing a proprietary client and maybe even a proprietary protocol, we can use HTTP and XML as a way to deliver these capabilities to our customers."
So how does SOAP fit into the picture? Simply put, it's an enabling mechanism for XML exchange between applications. SOAP allows XML data to invoke objects running on remote servers across both corporate intranets and across the Internet. In practice, SOAP borrows heavily from the client/server space and operates as a remote procedure call mechanism that leverages HTTP as a base transport and encodes requests and responses as XML documents. SOAP's support for a range of Internet protocols means that it can easily traverse corporate firewalls, which commonly pose an obstacle to any proposed application interoperability solution. Because SOAP object invocations can appear to a Web server as HTML code, for example, they can pass through existing firewalls without modification.
SOAP is seen as an important cog in an XML platform integration stack that also includes a business-to-business services discovery standard called Universal Description, Discovery and Integration (UDDI) and another emerging standard called the Web Services Description Language (WSDL). Still another proposed standard—the Security Assertion Markup Language (SAML)—is expected to provide authentication and authorization services between heterogeneous platforms. The rub, of course, is that none of the standards in question have yet been finalized, although both vendors and analysts say that they are close.
"These standards are already robust, and much of the work involved in revising them is just minor details. They're also designed with backward compatibility in mind," says Bob Suitor, director of e-business services strategy with IBM. "So customers can develop applications based on them right now and expect them to be fully supported in the future."
Mike Schiff, vice president of e-business and business intelligence with analyst firm Current Analysis, agrees. "The core technologies, like XML and SOAP, have been refined over the course of two years, and the latest SOAP releases have been maintenance-type releases," he points out.
Even in their current incarnations, Web services technologies can link together business partners, customers—or even competitors—over the Internet. In this model, Schiff says, XML and SOAP work in tandem to allow companies to access the business-to-business services of other companies without regard for platform considerations. Meanwhile, Schiff continues, standards such as UDDI and WSDL also provide core e-business description, location and registration services.
A Foundation Based on Open Standards
Visualize Inc. of Phoenix provides data visualization software for analysts, executives and other corporate decision makers. The company has embraced Web services as a means to allow customers access over the Internet to its core data visualization technologies. According to CTO David Krider, Visualize was attracted to a Web services model in part because open standards like XML and SOAP enable interoperability between multiple platforms.
"The standards are important because we're going to have clients connecting from a lot of different platforms and through a lot of different network transports," Krider says. "So with our application [based on Web services], any standards-based approach will interoperate with it pretty well. "
Companies like Visualize are using technologies like XML and SOAP to Web-enable their applications and to provide enriched—and easily accessible—solutions for their customers. "We've Web-enabled our StockPlot product, which is based on a [Java] applet or a servlet which can take static or real-time market data and display that in static form," Krider explains.
And although some observers suggest that the technologies underlying the Web services model are still in their infancy, users like Visualize's Krider aren't concerned. "We use the latest version of SOAP that's been proposed. It's got all of the features that we need right now and it will be compatible with future releases," he points out.
Sun ONE, Web Services and YOU
Should Web services achieve the popularity many predict, the war between Sun and Microsoft figures to rage on well into the future, as Sun's Open Net Environment is the J2EE-driven equivalent of Microsoft's .NET initiative.
But don't make the common mistake of thinking that these two offerings are Web services. Instead, Web services are simply tools the technology industry's favorite foes are using to bring their latest brainchildren to life.
"What Sun is talking about [with Sun ONE] is really larger than Web services," says Bill Roth, group marketing manager for the Sun ONE program. "We're talking about services on demand, and Web services are a part of that."
Roth says Sun ONE is being designed to enable developers to create, assemble and deploy solutions. "It's how we crisply articulate our software portfolio," says Roth. "It's how we take our products forward."
Much of what developers create, assemble and deploy using Sun ONE will, in fact, be Web services. However, those Web services are only small pieces of a larger vision, which when realized will be Sun ONE.
Think of Sun ONE as a massive architecture comprised of hardware, software and services that are completely interoperable. Web services are the pieces of business logic that will support the specifications, standards and protocols—such as WSDL, SOAP, XML and UDDI—to enable the interoperability of this massive architecture.
Basically, that's what Web services are and how they figure into Sun's Open Net Environment. No doubt, there are still a lot of details to be worked out regarding how Sun ONE and Web services will evolve into the future. But that doesn't mean enterprises should be taking a wait-and-see attitude, says Roth.
"Web services is really an evolution of component software," says Roth. For Sun's customers, J2EE will be the platform of choice for describing Web services. SOAP and XML will allow Web services to express themselves to other Web services, while UDDI will reveal the details of Web services. And Roth says, enterprises need to be working to figure out ways to integrate these technologies into their organizations.
"People should be looking at, ‘How do I take advantage of directory? How do I build robust applications with J2EE?' They should also begin to start thinking of how to express their data in terms of XML," says Roth. "That is going to past- and future-proof their data."
For the enterprise, preparing for the future is extremely important. And while enterprises aren't yet putting Web services to widespread use, Roth says they need to be careful not to hinder their ability to participate when Web services actually does become a movement.
"If you're not developing in a new generation language like Java, you're putting yourself at a disadvantage," says Roth, who feels enterprises really need to start taking their applications to the Web. "There's some serious catching up to do if you haven't started delivering applications through a Web browser."
Web Application Infrastructures
Too often, initiatives like Microsoft's .NET and Sun's and Oracle's J2EE are mistakenly combined with the broader spectrum of Web services. But while both .NET and J2EE provide comprehensive support for the standards and protocols that comprise the Web services integration stack, both initiatives actually describe a Web application infrastructure that's capable of leveraging Web services.
Web services don't exist in a vacuum. Rather, they exist primarily as a means to provide vital interoperability and integration facilities for applications that are written to appropriately exploit their standards and protocols. In this regard—and despite the air of open hostility between the .NET and the J2EE camps—both infrastructures should be able to leverage open Web services standards to interoperate very well with one another.
.NET, for example, is a nascent initiative that on the application infrastructure side heavily leverages Microsoft's Visual Studio .NET development environment and—for the next few months, anyway—the Windows 2000 operating system. J2EE, on the other hand, is a mature schema that describes an application infrastructure that heavily leverages version 2.0 of the Java programming language, the CORBA object model and Sun's Enterprise Java Beans (EJB) server-centric component software architecture.
Considered solely as discrete application infrastructures, .NET and J2EE are about as different from one another as First Lady Laura Bush and former First Lady Hillary Rodham Clinton. Add to this the sobering fact that Microsoft intends to decaffeinate the next version of its Windows operating system (Windows XP) by removing support for Java—which has the not-unintended consequence of disabling support for J2EE—and you've got two platforms that, at first glance, don't seem to have a chance of playing nicely with one another in the crowded enterprise schoolyard.
For Oracle, Web Services is Old Hat
For Oracle Corp., Web services means configuring its software to support the emerging standards and protocols that go along with this new technological innovation. So, when developers build a solution that leverages Oracle9i, for example, they're able to take advantage of opportunities on the Web services front as well.
Oracle has thrown a lot of weight behind XML and J2EE, and it continues to add support for SOAP and WSDL (Web Services Description Language). But according to John Magee, senior director of -Oracle9i marketing, UDDI is another issue.
"UDDI is not strictly required for doing Web services," says Magee. "It's a sort of facilitating technology. The foundation of [UDDI] is HTTP, the same technology that we use for users of the World Wide Web."
The primary function of UDDI is to allow potential users or developers of Web services to locate and define different types of Web services. Magee's argument, while not shared by all, is that UDDI is unnecessary and that the location and definition of Web services could be handled in the same way users of the Web locate and define Web sites.
However, Magee does not believe Web services should simply be looked at as Web-enabled applications. "There's a trend in large companies to bring Web access to existing applications, but what we're really talking about is accessing function-ality from other programs that lies behind an application using Internet protocols."
For example, a currency conversion feature on a Web site would be a Web service. "The next evolution is…let's call that service from a program that we're writing because that program needs a conversion function," says Magee. "What's revolutionary is that this can happen over Internet protocols." And what allows such a scenario to be played out is that the service—a currency conversion feature in this case—adheres to the XML and SOAP and WSDL standards.
Essentially, the concept of joining applications over an IP network is the driving force behind Web services. "Companies like Oracle have been doing a lot of this -Internet integration work already through exchanges and supply chains" says Magee. So, from Oracle's perspective, Web services are really just the latest model for integrating applications over the Internet.
Oracle's support for Web services is closely tied to J2EE. J2EE is the development platform Oracle's 9i Application Server works best with, which in turn makes it the ideal platform for building Web services in an Oracle environment.
Using just J2EE for development and XML for expression, enterprises can start building Web services. "We already have a lot of support for XML in the J2EE environment in general and in Oracle's software in particular," says Magee. "What's still evolving, [however], are the definitions of some of these SOAP descriptors and so on, but companies that want to move ahead are able to do so."
to read the rest of "Building for a Brave New World."