Recently, I've been seeing some chatter around adding a programmatic aspect to Web services that is currently not part of the specifications – namely, adding object orientation (in particular inheritance, although I'm sure polymorphism is implied). I've thought about this, and I think it's a bad idea.

I have a lot of experience in object-oriented coding and design, from C++ and Java as well as in some languages where it was bolted on, like PowerBuilder (yes folks, at one point Powerbuilder was not object oriented). And although I can see advantages to the concepts of inheritance and polymorphism in a general purpose programming language, I don't see the same advantages in a non-programmatic, descriptive system where the main reason for existence is to create an abstracted, easily callable API regardless of platform, language, or software.

From my point of view, Web services is primarily about defining business processes. Web services are the business API of the programming world, an API that reflects the idea of a services-oriented architecture. And after years in the industry there's one thing I'm certain of – almost no business process needs to have inheritance.

Business processes are the computerized implementation of ways of doing business. Sometimes it's completely automated, sometimes it's partially automated, and sometimes it's almost completely manual, with just one or two systems for input and tracking. But regardless, people don't think in terms of inheritance. They think in terms of inventory processes and the like. What is important is how they do their job, not decomposing the job for reuse.

Not that reuse and its companions aren't important to business – they are. It's just that services, which are truly at the edge of an enterprise, are as much a part of the business world as they are the technical world. Or at least they should be. Given all the marshalling and other out-of-process work that has to be done to invoke a Web service, we shouldn't see them exposing granular methods of an object. There should be no "setCustomer- FirstName" as part of a Web service – there should only be a "Customer" Web service. And because of the coarsegrained nature of Web services, they should not be part of some inheritance structure.

Java has the keyword final for a reason. In some circumstances it just makes sense not to let someone further down the line extend a class. Whether it's because of innate complexity or just to keep certain methods from being misused, there are times when you don't want to allow inheritance. Nowhere is this more appropriate than at the system interface, where use of an API is turned over to coders who haven't the slightest clue what is behind the curtain. Nor should they have to know anything. But that's the point. You want the service to work as advertised. As a flat hierarchy.

I don't want to have to have a base inventory service from which my particular inventory service (such as a magazine inventory) is derived. Because as a user of the magazine service I don't want to have to know things about the base inventory service, I just want to check to see if a magazine is in stock.

Even further, one of the advantages of Web services is that both the consumer and the provider can be written in any language that supports Web services paradigms. Large companies that have invested decades of programming into CICS/COBOL can leverage that code just as easily as the most recent J2EE work or .NET assemblies. And languages and paradigms that have no objectoriented constructs, and there are many of them, can use Web services as long as they can connect. And it needs to stay that way. Leave inheritance for behind the edge, not at the edge. And that's my Final Answer.

About the Author
Sean Rhody is the editor-in-chief of Web Services Journal. He is a respected industry expert and a consultant with a leading consulting services company. Sean@sys-con.com