Columns

At your service

• By John D. Williams
• January 1, 2002

The main need for Web services is to provide simpler access to the services and data that define a company's infrastructure. Consider what we find at many organizations. Systems are often created as data silos, with each system a kingdom unto itself that is not designed to share data. With the trend toward e-business, companies are finding that they need to integrate all types of data, but their siloed data systems make this difficult to accomplish. ERP was supposed to address this problem by providing a common base for systems. While ERP systems are typically more integrated than most, they still have rigid data silos. EAI tools are another approach to integration; they provide integration between individual systems, but creating integration across complete business processes is still a challenge.

Web services addresses this issue by making data available to everyone who needs it through easily accessible service interfaces. The idea is that by providing system capability and information through services, others can easily create systems that integrate new capabilities and information regardless of their source. Furthermore, some observers speculate that the need for companies to own or control all of their own services will disappear. They believe companies will be able to rent the services they need. This raises some interesting issues. For example, does anyone remember the ASP bandwagon? Why buy SAP when you can rent it? It turned out not to be as easy as many envisioned. Every customer wanted systems customized to their needs, and there wasn't a garden-variety system that worked for everyone. There were also performance issues. While it's fine to reduce costs through resource sharing, the need for high-level performance doesn't go away. Companies found it easier to control performance levels when they controlled the hardware and software.

Finally, companies aren't comfortable leaving their corporate data and services in someone else's hands. They want complete control over their own information. Does this mean the concept of Web services is stillborn? Not at all. It just means that before you uncritically accept all the buzz around Web services, you need to remember some of the lessons we've learned.

There are other issues that need to be addressed regardless of whether you use internal or external services. For example, common mechanisms and standards are needed to speed service adoption. We've made good progress in this area. We know that standards such as XML, SOAP and WSDL will simplify some of the technical issues around using services. Still, challenges remain for creating higher level standards for the information exchanged. It's not enough to ship information back and forth; it needs to mean something to the systems that use it. As I've said before, simple XML is often not enough. You need to provide contextual information, as well as raw data in the correct format. Additionally, with the broad use of services, we see problems similar to those we've tried to address through EAI. Accessing many individual services creates a spaghetti-like network of interfaces that have to be maintained. We still need approaches like the hub-and-spoke architecture to reduce the number of interfaces we must maintain. Work done in this area for EAI will still be needed in the Web services world.

In their Harvard Business Review article, Hagel and Brown defined a three-layer architecture to support Web services. At the lowest layer are standards and protocols. This is where XML, SOAP, WSDL, messaging and other technical components of the services are. Over the past few months, this is the portion of Web services that has received the most attention. Unfortunately, many developers want to stop there. But as Hagel and Brown point out, while this layer is necessary, it is not sufficient to create truly reusable Web services.

The next layer is the service grid, which contains the directory of services. This is where you find and connect to the set of services you need to build your apps. These services are typically at a lower level of functionality than a complete application. The idea behind this layer is to create a trusted environment for building and operating applications. The top layer is application services. These services represent the capabilities offered at the application level.

This architecture is a great place to start when thinking about Web services. What immediately becomes apparent, though, is that it is insufficient for building complete applications. For example, when you build a new application out of services, where does the overarching business logic reside? Where do you find the workflow oversight? The defined architecture is sufficient for organizing services, but it is not a complete application architecture. The thing that changes with services in building an application is deciding whether you are building your application by assembling components or simply calling the services a component may provide. In practice, you will do some of both.

In addition, issues such as flow of control do not go away. Consider what happens when you try to build an application from multiple frameworks. Frameworks typically believe the flow of control resides within themselves rather than within the calling application. Therefore, building with multiple frameworks typically requires some resolution of conflicts over who controls an application's flow. This will still be true even if you make the framework's capabilities available as Web services. Typically, we see this around issues of domain logic vs. cohesive logic. The domain logic is the business process workflow, and is often the easier flow to define. Cohesive logic is how the framework chooses to operate and communicate internally. The cohesive logic of a given framework may not be conducive to turning it into a service or working with others.

One of the key contentions in the Harvard Business Review article is that Web services allow IT to purchase only the functionality they need when they need it. In fact, you may even decide to sell the services you create to others. But does this make sense? It is clear that, as envisioned, Web services will support flexible collaboration between systems with loose coupling. This is great. But the idea that you might sell your services to others is generally a bad idea. Some companies may succeed at this because their business is essentially selling their IT capability. But becoming and operating like a business is outside most IT departments' area of expertise. Making a service available internally is quite different from becoming a business that sells services on the outside. If you want to do that, think about this: How big is your IT sales and marketing budget? If you think you don't need one for this effort, you are sadly mistaken.

Certainly one of the benefits touted for services is the ability to turn existing systems into common services. Hagel and Brown call this node enablement. This is not a new concept. The whole idea of wrapping legacy systems with objects addressed this same issue. Components addressed the issue in a similar manner with a focus on the interface. Web services now take that component interface and make it a service. Issues around the complexity and performance of the wrapper are still important. Wrapping an old, monolithic system and making it a service is no easier than it ever was.

I think the concept of Web services is a great one. The basic technology and architectures that have been defined are important steps in making this concept a viable practice. However, it is not a silver bullet. We still face some of the same fundamental issues we always have. Companies still want to control the corporate jewels. Even as Web services allow greater system collaboration, simple data exchange mechanisms such as XML will not be sufficient for all system communication. Systems still need to share contextual information. Standards—such as XML Frames, which I proposed last August—will be needed. Finally, let's not forget the lessons we've already learned. Making a capability available as a service doesn't mean all the planning, architecture and methodology we've focused on in the past is irrelevant. In fact, it is a necessary foundation to make Web services work.