In-Depth
Building for a Brave New World (Part II)
Part II: Getting Real about Web Services and "Transparent Interoperation."
"Building for a Brave New World" (Part I)Set Aside the Hype Detector Not so fast: In the age of Web services, you're going to have to learn to put your hype detectors aside and try to get your head around the (once unthinkable) notion that heterogeneous systems can interoperate transparently. Because the .NET framework incorporates exhaustive support for Web services standards, .NET applications can leverage SOAP, which is commonly used to facilitate interoperability between and among XML-based applications, as a means to communicate with other Web services-enabled application infrastructures, such as J2EE. In this regard, .NET applications can make SOAP calls to Java applications running on J2EE, which can in turn spawn EJBs. Voila: Instant interoperability.
Not surprisingly, while it's possible to design individual applications that will exploit Web services standards—and while many vendors will probably do so—just as many ISVs and IT organizations will probably design their applications to run in conjunction with Web application infrastructure products from vendors such as Sun, Oracle, IBM and Microsoft.
"Everyone wants to do Web services, and the question becomes ‘How are you going to build these solutions?' For Oracle, the answer is that you're going to do that with J2EE and then you're going to expose that functionality through Web services, using SOAP, WSDL and XML," says Oracle's Magee.
"You can think of J2EE as a platform that brings together the whole middleware market," Ralph Gallantine, J2EE product manager with Sun, continues. "So it brings together component software, transaction management and messaging, and it also leverages the suite of Web services."
Indeed, Java development efforts thus far have largely been predicated upon the creation of client-side applications, in the form of downloadable Java applets, that are supported in the overall context of a more conventional, platform-specific application model. J2EE radically alters this paradigm because it proposes a Java-based infrastructure—a kind of Java middleware layer—for enterprise applications. More often than not, this Java middleware layer is enabled by virtue of the Web application server, of which IBM's WebSphere is but one example.
But because of J2EE's write-once, run-anywhere Java underpinnings, Gallantine points out, mainframe administrators can leverage it as extensively as can their counterparts in client/server or Unix environments. "Mainframe managers will see J2EE as something that comes in and which can help them integrate their mainframe solutions, and in particular bring the software they're already running to the Web," he contends. "[J2EE offers] simplified development with Java server pages and the servlets so that they can do that layer very easily and still have the connectivity back to their mainframe systems."
Ironically enough, the Web services model heralds a return to the canned integration of mainframe environments, which typically enjoyed seamless interoperability between and among applications—which were, of course, usually written to a single operating system (S/360, S/390) and to a single set of operating system services. The client/server world changed all of this, however. In addition to their lower price points and their reduced total costs of ownership, client/server environments also brought with them the integration headaches that accompanied the distribution of applications across discrete systems and (in many cases) heterogeneous platforms.
The Web services model, on the other hand, lets developers write their applications to a single application infrastructure (.NET, J2EE, WebSphere) with the expectation that they'll be able to seamlessly interoperate—by virtue of the protocols and standards that comprise the Web services integration stack—with applications residing on other, possibly dissimilar application infrastructures. In this respect, a CICS transaction processing (TP) monitor running on an S/390 (z/OS) mainframe from IBM and interoperating with Big Blue's WebSphere application server by means of EJB can expect to exploit Web services to exchange TP information with a BEA Tuxedo TP monitor interoperating—also by means of EJB—with BEA's own J2EE-compliant WebLogic application server.
| At the Core of Web Services: Standards The whole concept of Web services—interoperability among applications distributed across the Web—rests on standards. After all, for companies to access the business-to-business services of other companies without regard for platform considerations, everyone needs to agree on some standards. Without industry agreement on languages and data exchange protocols and methods, Web services can't happen. Key standards include: J2EE: Java 2 Enterprise Edition is a standard set by Sun Microsystems Inc. for developing server-side applications in Java. The broad adoption of J2EE application servers has allowed J2EE to become a de facto industry standard. J2EE operates on a number of platforms and operating systems, so developers know what to expect from an application server, despite the different environment. J2EE applications run on Java Application Servers, which offer standard objects for the functionality often needed in enterprise applications. The plug-in functionality allows developers to write the logic of an application without the need to rewrite basic services. SOAP: Simple Object Access Protocol is one of the base technologies in Web services. It uses XML syntax to send commands across the Internet, and share data through the HTTP protocol. One application can initiate a SOAP command, asking for data from another application. SOAP is still in draft version, but a final protocol is expected before the end of the year. UDDI: Universal Discovery, Description and Integration. UDDI registries are XML-based directories of what Web services different enterprises offer. Applications can query the UDDI registry to discover new services, ensure services are still up, and see if a company offers the same or compatible services. Microsoft, IBM and HP all offer UDDI registries, which are replicated reciprocally. WSDL: Web Services Description Language is a protocol that describes what capabilities a Web service offers. For example, an inventory application may offer another business to order inventory using machine-to-machine messaging, or only offer the ability to check inventory and prices online, leaving the customer to talk to a rep over the phone. WSDL would be used to describe this capability. Microsoft, Ariba and IBM have submitted version 1.1 of WSDL to the World Wide Web Consortium (W3C), which is considering ratification of the standard. Although the body has not endorsed the standard, the three companies have the pull in the industry to make it happen—whether or not the W3C agrees. Peer-to-Peer: Although Web services will operate primarily on servers, it has one similarity with file sharing services such as Gnutella and Freenet—transactions are conducted machine-to-machine, with no central server mitigating transactions. Unlike older standards such as EDI, which often required third parties to operate services, Web services are conducted between machines treating each other as equals. .NET: Although opinions differ about what Microsoft's initiative really means, it's clear that XML and Web services comprise a large chunk of the .NET enterprise strategy. Microsoft already offers an XML-based machine-to-machine product with BizTalk Server, which was released in the fall of last year, but Redmond has been aggressive in both pushing and adopting published standards for its next generation of integration products. In addition, its C# language—designed to rival Java—has been submitted to the ECMA standards body and has some Web services functionality built into its libraries. XML: eXtensible Markup Language. Like HTML, XML uses a tag structure to designate how data is used. Unlike HTML, which uses a circumscribed set of predefined tags, users can define any number of tags or schema for marking up data. The tags can be used for a variety of purposes – from page rendering duties to denoting fields in a database. In the Web services paradigm, XML schema are used to show what data goes where, plugging text data into database fields. —Christopher McConnell | |
Of Course, IBM is in the Game
For its part, IBM has quietly marketed a Web application infrastructure solution for the better part of five years under the auspices of its WebSphere product.
"We have chosen not to put a brand name on the Web services technology," says Stefan Van Oversveldt, program director of WebSphere product marketing with IBM. "Our platform for Web services tech is WebSphere, both from a run-time and from a developer's perspective. As a matter of fact, we were the first to market with a product that incorporates all of the important run-time tools from a developer's perspective."
Now shipping in version 4.0, WebSphere provides complete support for J2EE. Not surprisingly, as IBM's Van Oversveldt points out, WebSphere also provides built-in interoperability with CICS, MQSeries and with other application mainstays of the mainframe world. "We are now already able to take existing S/390 apps, for example, and make them available as a Web service, and we will continue to extend those capabilities," he concludes.
Hewitt Associates' Hilgenberg concurs. "We do record-keeping for 401(k) plans on a Z/OS mainframe, and we're able to use WebSphere and SOAP to create an XML stream [from the Z/OS application] and format it into a kind of ‘envelope‘ technology so that someone on the receiving end can say that they're looking at this request and can route it accordingly."
IBM is also taking a leadership role in other ways as well. For example, Big Blue has been content to assume a behind-the-scenes—but nonetheless pivotal—position in Sun's J2EE initiative. According to IBM's Suitor, Big Blue has actually been working in conjunction with Sun on J2EE development since 1996.
"IBM started working with Sun back in 1996 on J2EE, and it's been evolving for a long time," he comments. "We donated a significant amount of the code for [J2EE]. In fact, usually, if you think about Java and J2EE, you think of Sun and IBM as the two top companies—Sun by marketing association and IBM by virtue of how we've supported it in our products."
For some time now, IBM has pushed the open source software (OSS) Linux operating system on not only its low-end Netfinity servers, but also on its high-performance z/OS mainframes. Not surprisingly then, Big Blue has worked to flesh out OSS' Web services portfolio—especially with regard to the Apache Software Project (http://www.apache.org/) Apache Web server. To date, IBM has written an implementation of SOAP for Apache, and has also designed an XML parsing component for "Tomcat," a servlet and Java Server Pages server for Apache.
| Unity Key to IBM's Web Services Vision At IBM, Web services are the next logical step moving forward in the middleware space, as the integrations they support help Big Blue give developers the ability to create application environments that work together. "If you look at our e-business middleware, we're an enabler for building new business services," says Jan Jackman, vice president of strategy for IBM's NetGen business. "So, we partner at the application level, but what we really do is provide a solid infrastructure for building and deploying new applications." The latest versions of IBM's WebSphere Application Server and WebSphere Studio Tools both incorporate Web services standards and protocols, including SOAP, WSDL and UDDI. IBM believes Web services offer tremendous potential for easily integrating different pieces of applications. "What makes [Web services] really unique from previous methods is their means of communication," says Jackman. "What they do is they use asynchronous messaging—which is based on universal Internet standards—and it allows components to talk to each other through firewalls and across different public networks." IBM views Web services as the next-generation of a component-based model. Whereas previous iterations of component computing required more synchronous standards for communications and more support for various protocols, IBM sees the power of Web services in their ability to open communications up to universal standards so enterprises don't get tied into proprietary systems. Jackman says, by deploying Web services an enterprise is opening up components of its business logic to a massive distribution channel that with UDDI can be a huge revenue boost. "The technology [behind Web services] enables a whole set of new applications to integrate in a more efficient way than was previously possible," says Jackman. "So, from a revenue-generating perspective an [organization] now has a vehicle to distribute its application or application components to a much broader audience." For the enterprise, this means it can easily expose its suppliers and customers to pieces of business logic in order to streamline business operations. For instance, a supplier could hook into an enterprise's inventory control component to measure product levels without doing any integration work if it were deployed as a Web service. "It started with Java-based applications, XML for data exchange," says Jackman. "[Web services] takes it to the next layer. Now we've got a communications protocol so that you can get application to application identification." "I think you're going to see uses within the enterprise, the service provider and the independent software vendor community of which all are going to take advantage of this technology and these protocols so that they can enable new revenue streams for their business." For IBM, its middleware offerings are the most obvious fit for Web services. With the WebSphere line and related offerings under Tivoli and DB2, IBM can give developers the ability to build and work with applications that support the Web services standards and protocols so they can swiftly seize integration opportunities as they present themselves. —Matt Migliore | |
Rapid, Cross-Platform Application Development
TransAct Tools Inc. of New York City, an application service provider that caters to the wholesale financial services industry, needed a way to seamlessly link its clients together across the Internet. Like many other companies these days, TransAct Tools looked to Web services as a means to solve its problem.
"We had an idea when we created this company to create centralized repositories. So we started paying attention to things like UDDI, XML and the whole Web services space," explains TransAct Tools CEO Sam Johnson.
Eight months later, TransAct Tools supports 150 clients—and is adding five to 15 more a day. The key to the company's quick time-to-implementation, says TransAct Tools CTO Brian Oberstein, was the rapid application development process facilitated by Web services standards such as UDDI and XML and by a Web application infrastructure based on Apache and Tomcat.
"I think that it was relatively pain-free because our applications were written in Java, so we were able to leverage a lot of the tools and libraries that were out there already and sort of rapidly create an infrastructure that was easy to grow and manage," he concludes.
And because IBM, Sun/Oracle and Microsoft provide Web services development toolkits, Visualize's Krider says that IT organizations have a lot of integrated development resources at their disposal.
"If you use the IBM Web Services toolkit, then it's really straightforward, and it'll let you design applications that interoperate with any standards-based Web services [implementation]," he says. "Basically, you just define your interface, and the toolkit develops the code along with the wrapper code necessary to deploy your software as a Web service. It already works well with Tomcat and with Websphere."
At the same time, observers caution administrators in mainframe and in other so-called "legacy" environments against irrational exuberance.
"There are different ways to [output data from mainframe systems to Web application servers], but it's just not going to be as easy as designing an application from the ground up to run on a Web application server," says Giga's Enderle. "Depending on how the application is designed, they could end up having to scrape the screen and output the data that way."
IBM's Van Oversveldt agrees. "It really depends on how the applications that they have are structured. If there's a clear separation between the business logic and the presentational logic in those applications, it's fairly easy to architect that solution. In applications where the presentational logic and business logic are completely integrated, it's going to be really hard."
Start Planning Now
Although Web services are still untested and for the most part unproven, industry watchers say that IT organizations need to start thinking about Web services strategies. Market research firm and consultancy Gartner Inc., for example, recently advised its clients that they need to determine Web services strategies by the end of 2002 or risk falling behind competitors.
The good news for companies that want to get an early start on things is that vendors such as IBM, Oracle and Sun are today providing solutions that deliver on the long-term promise of Web services, says Big Blue's Bob Suitor.
"You can absolutely do it right now," he maintains. "The technologies are out there, the toolkits are out there. [Web services aren't] something that you still have to wait years for, but that with a product like WebSphere 4.0, you can make use of right now."