Who should be taking advantage of Web services, and which flavor should they choose?
What do you say to a salesperson or consultant who tells you, “It’s time to get into Web services”? “Absolutely”? “Get lost”? Or is your reply a blank stare? Many large corporations are wrangling with pilot Web service projects. What are these Web services and is it time for smaller businesses to be looking into them? This has already been called The Year of Web Services, but the issues may be “For whom?” and “In what way?”
No matter who is whispering in your ear about getting into Web services, they will likely be from one of two camps: Microsoft .NET or Java. Although many companies have important Java Web service products–not the least being Sun Microsystems, Oracle, BEA, and Borland–we’ll primarily cover IBM and its WebSphere products as the main competition for Microsoft. This is an old rivalry, going back more than a decade to the bad blood from the early days of Windows and IBM’s moribund OS/2. IBM and Microsoft have a lot at stake in the struggle over Web services leadership, but this is not a question of who will be the last man standing. Bringing Web services into the commercial mainstream has turned out to be a struggle in itself. Sometimes the combatants have found it more important to work together rather than compete on every detail.
The hype surrounding Web services is beginning to subside. Does this tell us that vendors are starting to soft-peddle the technology, or is it that Web services have entered a less glamorous period of evolution and development? Actually, both. Vendors such as IBM and Microsoft are just as keen about Web services as ever, but they’ve become somewhat more cautious about making promises for it. Web services is a tricky business technically, and the applications are something of a complex sell. Consider sending small chunks of data and programming from multiple sources down the wires (or across the air) to be assembled into working programs on a PC, portable, telephone handset, or whatever. In short, Web services can bring to bear every aspect of an enterprise. Just getting started is a difficult task.
Still, analysts have not dubbed this The Year of Web Services by caprice. There are lots of solid reasons for at least learning about Web services and developing a plan of action regarding them. Using the universal network (a.k.a. the Internet) for finding and acquiring Web services is a huge plus. So is the availability of Web browsers for a common user interface. There are lots of places that would like to share data and programming on a rental basis. It’s a potential revenue stream for software companies that have grown tired of the version game, and it provides users with the option to find and consume only those bits of programming and data that they actually need–presumably for less money. Web services may also solve, or help solve, one of the biggest needs of business–the ability to share data and programming with trusted partners.
Exactly what Web services means for any given company, or user, is not so easy to describe. This is a minus. Web services are dynamic; they can be requested, sent, and used on the fly. This can include the ability to cobble together a word processing program from six different sources, share a freight tariff calculator, or plug in another company’s inventory at a moment’s notice. In short, Web services can do a lot–the possibilities are too numerous to describe and no catalogs of Web services categories (much less actual Web services) exist, although they’re in the works.
We had initially considered describing Web services offered by two or three representative companies, but quickly discovered that such examples don’t generalize very well. Current Web service implementations tend to be industry-specific and, more often than not, company-specific. That’s kind of the point–Web services technologies consist of modular applications that can be stitched together and tailored to fit specific needs in an enterprise.
Given the business-centric nature of Web services, it’s not uncommon for companies to hire consultants to help them determine what, if any, Web services they might produce, publish, or consume. Of course, IBM, Microsoft, and many others have consultants waiting in queue.
Standards in all shapes and sizes
Sharing data and programming over a network can be a great thing. Dynamically assembling software applications from off-the-shelf Web services has great promise. It’s all part of distributed computing, which has been tried before but with limited success–too difficult, too fragmented, too costly. Now the suite of industry standards supporting Web services represents an agreeable and functional set of protocols. This time, the industry may have gotten it right.
eXtensible Markup Language (XML) leads the list of standards. IBM WebSphere and Microsoft .NET-connected products (notably Visual Studio.NET) have made the data management qualities of XML a cornerstone. Simple Object Access Protocol (SOAP) is another cornerstone because it details how Web services can be packaged and accessed. How a Web service is used is described by another key standard–Web Services Description Language (WSDL). Rounding out the basic foundation of standards is Universal Description Discovery and Integration (UDDI), which is a protocol for describing Web services so that people and programs can decide if they want to use them.
These basic standards cover how to package, find, and use a Web service. They were developed several years ago and have been steadily refined since. But in a post-9/11 world, people wonder, “Where are the security standards? Aren’t they kind of basic?” Well, yes. They’re important enough that IBM and Microsoft, in April 2002, jointly (along with Verisign) proposed a standard called WS-Security. It is still under consideration and development by the Organization for the Advancement of Structured Information Standards (OASIS).
The lack of security standards highlights that there are gaps, some big and some small, in Web services protocols. In fact, all the basic standards are in the process of revision and expansion. XML has more than a dozen sub- and co-standards; Microsoft has introduced an extended language for SOAP, there are proposed protocols for Web services routing, Web services attachments, and so forth. The changes and improvements in standards are mostly to the good, but they underline the fluidity of Web services development as companies push into more demanding projects. The situation recalls the mid-1990s, when standards surrounding the Web itself made the Web a fluid medium.
The WebSphere world
Developing Web services projects brings us to a look at Web services tools, the ones used to create, package, and distribute Web services. Here lies the watershed choice between Java and .NET connected technologies. (Note: Microsoft is in the midst of a brand change as I write this. What used to be called .NET will henceforth be called .NET connected. We’ll refer to Microsoft’s tools as Visual Studio. NET, which is the centerpiece of its platform.) Though the services are important to software developers, consumers theoretically don’t care how the services were developed, but even here some corporate projects use programming in Studio .NET or Java at the user’s end.
IBM threw in with Java soon after the language was introduced. Then it put its weight behind the concept of open-source software (where underlying programming is publicly available) and adopted the open-source Apache Web Server and Linux operating system. None of this was native to IBM, nor was it remotely part of its culture. Credit is due for managing the tumult and arm-twisting that must have been necessary to swing the giant company to this direction in a few short years.
In concert with its successful application server platform, WebSphere, IBM now markets its software development system as WebSphere Studio. The key to this product is Eclipse, IBM’s open-source framework for software development. Eclipse is like a pegboard into which other products and tools can be plugged in. It provides an organizing structure (or architecture) and a set of interface standards, which help the developer use a wide variety of tools and produce a wide variety of software–including Web services–without needing to learn multiple languages and interfaces.
WebSphere Studio v5 (released in September 2002, Application Edition $3,499; Enterprise Edition $7,500) welds Eclipse, support for Java 2 Enterprise Edition (J2EE) 1.3 and 1.4, the Apache Struts framework, and optimized linkage for WebSphere 5 Application Server to the Web Services standards (XML, SOAP, WSDL, and UDDI). WebSphere Studio represents IBM’s mighty attempt to bring open-source, Java, and Web service standards into an integrated development environment. This approach is used to clearly differentiate the WebSphere platform from Microsoft’s proprietary approach.
For many software developers, WebSphere Studio has the correct credentials and is one of the two or three best development environments (other candidates: Microsoft Visual Studio .NET, Borland JBuilder, and Oracle 9i Developer Suite). WebSphere Studio tends to do less handholding than other products and appeals to skilled programmers who want to customize their tools and save as much time as possible.
Although IBM isn’t shy about touting its enterprise-level integration products, its long-standing lead in IT consulting, or its own hardware, WebSphere Studio v5 puts software development in a very visible position for the company-and Web services at the front of that effort.
The .NET connected world
At Microsoft, all roads lead to .NET. Several years were spent consolidating and reworking its products to conform to a master design–the .NET-connected architecture. The process continues in 2003 with the appearance of the flagship server operating system Windows 2003 and the continued development of Web services a la Microsoft.
While .NET encompasses much more than Web services they are its centerpiece. Web services are emphasized in Microsoft Visual Studio .NET (Professional Edition $1,079; Enterprise Developer Edition $1,799; Enterprise Architect Edition $2,499), especially in the new 1.1 release. The importance of XML as an underlying protocol continues to increase; Visual Studio .NET has some of the best XML tools available. Support for other Web service protocols is evolving; in this arena Microsoft seems to be as committed to industry standards as anyone.
In contrast to the Java world, Visual Studio .NET is not married to a single programming language. Its collegial approach includes Visual Basic .NET (VB.NET), C#, C++, and J#. C# is a new language. J# is a bridge from or replacement for Microsoft’s version of Java (J++). Visual Basic .NET is so changed as to almost constitute a new language. Support for other languages is added regularly.
Visual Studio languages use the same integrated development environment (IDE), one of the best in the business, and build program components and user interface elements using one or more of three formats: Windows Forms (the basic Windows window), Web forms (Web pages enabled by ASP.NET), and Web Services. All the languages rely on the .NET Framework Classes, a huge library of some 6,500 classes that provide the native features available to Visual Studio programming.
Regardless of language, all code in VS.NET runs through a compiler that produces the Common Language Runtime (CLR) object code. The CLR also provides for memory management (e.g., garbage collection), debugging, and the Just-in-Time compilers that produce binary code for specific platforms. In short, the end product of .NET programming behaves much like Java programming. It allows Microsoft to say that .NET programs can run on multiple platforms while programmers can work in the language of their choice.
It’s not that simple, of course, but the issue of Java’s portability across platforms versus .NET’s interoperability (multiple languages and XML data) will be argued by software developers for a long time. In practice, .NET plays strongly to the 90 percent of the world’s desktop computers, which use Windows operating systems and software. It is less compelling on the world’s servers, which particularly in larger enterprises run a variety of operating systems. In the new world of Web services, which for the moment tend to be server-based, Microsoft’s desktop monopoly doesn’t carry a lot of weight.
The crucial mobile market
Web services are expected to hit the road in a big way. Mobile devices such as portable computers, handhelds (Palm, Pocket PC), telephone handsets, and Tablet PCs are already oriented to networking and tend to work best taking online information and programming in small doses-just what Web services promise to deliver. It’s way too early to tell where Java or .NET will have their biggest successes (or failures) in the communications and mobile computing markets, but for many companies this will be a critical area to watch.
Microsoft is deeply involved with the success of hardware and software across the mobile market, including being an important player in the handheld market (Windows CE, Pocket PC, Tablet PC) and an aggressive newcomer to telephone devices. The new .NET Compact Framework provides a unified software development environment. This scope is an advantage. By contrast, IBM must depend in part on how Java plays on mobile devices, which so far has been under the aegis of Sun.
Look for low-hanging fruit
Where basic Web service is defined as something like a few companies dynamically exchanging some well-understood information or programming, the resources of Visual Studio .NET and WebSphere Studio will make developing Web services easy. Web services that involve complications such as multiple sources and consumers, complex transactions, or high security requirements will not be easy. Constantly evolving Web service standards do not make it easier. Consequently, for 2003, production and implementation of Web services requires a fairly sophisticated IT capability. For many smaller businesses this implies outsourcing. Using Web services is easier, but it too may force changes in business procedure and IT configuration that are difficult. In short, the use of integrators, independent software vendors, and consultants will be close to a necessity.
Most of these people will be talking either Windows/.NET-connected or Java/open-source, a choice that will be mutually exclusive for all but the largest companies. Predictably, companies will go with what they’ve got. If they have IBM mainframe or server systems, they’ll probably stick with IBM for Web services. If they have a lot of Microsoft products in both the front and back office, then .NET will be more appealing. Other than in specific applications, such as mobile Web services, choosing .NET or WebSphere may carry little specific advantage; but in any given year, the situation can change.
It’s a long road to successful Web services projects: The need for Web services as a delivery method for information and programming must be defined. In most cases, the development of Web services and the means of deployment are technically demanding. The use of appropriate Web services standards continues to evolve. Companies employing Web services often need to change business and IT procedures. Is this a tall order for small or medium-sized businesses? Not necessarily. There is an advantage to not being overly ambitious. Early in the history of a technology, it’s often the smaller, well-targeted projects that are the most successful.