Web Services: Still Just Software

ZapThink was speaking with a Web Services development tools vendor a few weeks ago, and we pointed out that Web Services were, after all, just software. The vendor was impressed with our perspective, pointing out that they had been talking with one of our fellow analyst firms, who didn’t get this very basic point. “In the future, you won’t need Java or C#,” said this unnamed analyst, “because all you’ll need is Web Services.” In response, ZapThink would like to put this issue to rest. Web Services may be the sizzle, but the steak is all software.

In fact, that analyst’s misunderstanding is relatively common, and makes up part of the hype that confuses the real issues surrounding Web Services. We believe the true value of Web Services is in presenting coarse-grained, location and connection independent business Services to Web Service consumers both inside and outside organizations. For enterprises to offer such Services, they must build loosely coupled Service-oriented architectures that both encapsulate and virtualize the underlying applications and systems. The confusion comes in those words encapsulate and virtualize. Encapsulation and virtualization have been important concepts since the invention of software, and are just as important to Web Services.

Encapsulation: taming software complexity
Encapsulation is one of the fundamental principles of object-oriented programming, and it is equally important to Web Services. A software object is encapsulated when its inner workings are hidden from the outside world. All interactions with such an object take place through its interface via public method calls. Encapsulation is important because it breaks up large software projects into bite-sized chunks. Different objects can be assigned to different developers, and as long as they agree on those interfaces, they can all work in parallel. Furthermore, encapsulated objects are defined by their functionality. As long as they work as they should, nobody has to know what’s going on inside.

There is a catch with object-oriented programming, however. That catch is in the phrase “as long as they agree on those interfaces.” What happens when a developer has to change the interface of an object? Well, all the other developers have to know about it and potentially change their own code in response. This is the problem of tight coupling. If those objects expose their functionality via Web Services interfaces, however, then the developers don’t have to agree with each other, they just have to agree to use standards like SOAP and WSDL. Now their objects can work with each other, but much more importantly, can work with other objects that the developers have no knowledge of, as long as those new objects also expose their functionality via a Web Services interface. That’s the power of loose coupling.

Virtualization: the key to software progress
While encapsulation dates back to the OO days, virtualization finds its roots in the very earliest software. The first programmable digital computers dealt in the world of zeroes and ones — that is, only zeroes and ones. Programs were zeroes and ones. Output consisted of zeroes and ones. As a result, programming was very difficult and programs were quite opaque. Into this black-and-white world came programs called compilers that let programmers work with English-like languages like COBOL. The compiler then took the COBOL code, crunched it, and spit out the zero-and-one object code that the computers actually understood. The COBOL compiler, therefore, virtualized the object code. COBOL statements were virtual computer commands, because the compiler had to turn them into the real commands. Humans could now work at a level of abstraction above where the computers worked.

As computers grew more powerful and complex, virtualization techniques continued to provide additional levels of abstraction. Timesharing mainframe computers allowed users to have virtual control of the machines. Another example is the graphical user interface, which provided virtual access to underlying system resources. Component architectures also provided virtual representations of distributed computing infrastructures. At every step, software allowed people to work with relatively simple tools that accessed complex systems behind the scenes. That’s the power of virtualization: the ability to layer one level of abstraction on top of another, so that the tools people use get simpler as they also become more powerful.

Connecting Web Services into Service-oriented architectures
Web Services herald the next evolutionary step in this inexorable progression to the next level of abstraction, which ZapThink calls Service orientation. By encapsulating software components, applications, and underlying systems with Web Services interfaces and then virtualizing these fine-grained functional Web Services into coarse-grained business Services, companies will have IT infrastructures that provide business functionality that meets the needs of business better than before. But make no mistake: this Service-oriented view of information technology is an abstraction — a virtualization of underlying software components and applications. Every Web Service is still software — still nothing but ones and zeroes — at its core.

So, back to that poor analyst who thought that Web Services would make software programming go away. The reality is that software is here to stay, which means that we will still need programmers to create it, and they will continue to need the platforms and tools they use to do their jobs. However, from the business user’s perspective, the choice of platform will become less relevant as their company implements a Service-oriented architecture. What matters to that user are the Services and the functionality they provide. The technology that makes those Services possible is rightly hidden from view.