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.

—S.S.

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."

—S.S.

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."

—Matt Migliore

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."

—Matt Migliore