Interviews

October 18, 2005
Volume 3, issue 7

Download PDF version of this article PDF

A Conversation with Roger Sessions and Terry Coatta

In the December/January 2004-2005 issue of Queue, Roger Sessions set off some fireworks with his article about objects, components, and Web services and which should be used when (“Fuzzy Boundaries,” 40-47). Sessions is on the board of directors of the International Association of Software Architects, the author of six books, writes the Architect Technology Advisory, and is CEO of ObjectWatch. He has a very object-oriented viewpoint, not necessarily shared by Queue editorial board member Terry Coatta, who disagreed with much of what Sessions had to say in his article. Coatta is an active developer who has worked extensively with component frameworks. He is vice president of products and strategy at Silicon Chalk, a startup software company in Vancouver, British Columbia. Silicon Chalk makes extensive use of Microsoft COM for building its application. Coatta previously worked at Open Text, where he architected CORBA-based infrastructures to support the company’s enterprise products.

We decided to let these two battle it out in a forum that might prove useful to all of our readers. We enlisted another Queue editorial board member, Eric Allman, CTO of Sendmail Inc., to moderate what we expected to be quite a provocative discussion. Our expectations were dead on.

ERIC ALLMAN I’ve talked to people who work on object-oriented stuff, who have read your “Fuzzy Boundaries” article, Roger, and every single one of them starts off by disagreeing that the difference between objects, components, and Web services is location-based.

Many of them speak of object-oriented RPCs (remote procedure calls), which aren’t quite components. They are components that live together in a process and so forth. Since that was the fundamental point of your article, could you comment?

ROGER SESSIONS Unfortunately, none of these terms is very well defined. We’re all using the terms as they make sense to us. Some of our disagreement may be simply semantic.

The component industry started with CORBA. The developers of CORBA were trying to solve one problem: distribution. They weren’t trying to get objects to work together within the same process. Yes, you could have CORBA objects live together on the same machine, even in the same process, but that was not the main problem that CORBA cared about solving.

As far as Web services go, we could say that, yes, Web services could be in the same process or on the same machine. They could be in the same environment. But what was the essential problem Web services were trying to solve? It is about heterogeneous environments. It is about getting a .NET system to work with a WebSphere system, for example, not getting a .NET system to work with another .NET system.

TERRY COATTA It strikes me that it’s hard to distinguish Web services from CORBA from EJB using that kind of rationale, because all three systems have open or at least standardized and available protocols. I can certainly make my WebSphere interoperate with an appropriate CORBA implementation that has the mappings for doing EJB. I can cross technology boundaries with all kinds of different standards.

RS If you’re using the J2EE standards such as RMI (remote method invocation) over IIOP (Internet Inter-ORB Protocol), you are primarily going to be doing that within a single vendor’s system, such as a WebSphere system. If you’re going from a WebSphere system to a WebLogic system, your best shot at interoperability is through Web services. Why? Because you’re crossing a technology boundary.

TC You’re claiming that RMI over IIOP doesn’t actually work?

RS It doesn’t work for interoperability across technology boundaries.

TC There seem to be people out there getting it to work. Certainly, back in the days when I worked with CORBA there was no problem having different vendors’ ORBs (object request brokers) interoperate with one another. We used three or four of them at Open Text and had no difficulty at all with those environments interoperating with one another.

RS As long as you’re going CORBA to CORBA, it works fine. But not when you are trying to get a CORBA system to work with a non-CORBA system.

TC But going from WebSphere to one of the other EJB vendors (e.g., WebLogic) in the CORBA space, there were probably five or six different major ORB vendors floating around, not to mention a couple of open source efforts, and all of those interoperated really well with one another.

RS CORBA to CORBA. They’re all running on the same basic core of CORBA technology. The difference between that and Web services is that for Web services, unlike CORBA, there is no assumption whatsoever about what the underlying technology is.

TC That’s not true. There’s an assumption that one is using a certain set of protocols; otherwise, it doesn’t work, and I mean CORBA was the same thing—a standard set of protocols. Nobody said that you had to actually implement the server-side aspect of the CORBA stuff to interoperate over the Internet. Everybody did because that’s the way they defined the standards.

RS You could say the same thing about DCOM or RMI. While all of them support communications protocols, they, like CORBA, are about much more than communications protocols. They are about a platform. CORBA was 95 percent API, 5 percent interoperability. Web services is zero API and 100 percent interoperability.

TC That part I agree with, absolutely. That was probably the downfall of CORBA.

RS It’s exactly the downfall of CORBA, and it will also be the downfall of J2EE. They didn’t learn from that mistake.

EA Isn’t Web services just essentially another standard for how to interact? The world has settled on CORBA protocols, not CORBA implementations. Wouldn’t it have had exactly the same effect and maybe even better had the world agreed to use only the CORBA protocols?

RS It’s quite possible, but the world didn’t. CORBA lacked focus. The Web services effort has a lot of focus beyond interoperability.

The big difference between Web services and CORBA is that the Web services people said right from the beginning: there is no API. The only thing that we standardize is how messages go from one system to another and the coordination around that. CORBA was 95 percent about how the client binds into the system. That was its downfall.

TC Of course, from the perspective of a programmer, that’s not necessarily a downfall, but a shortcoming. CORBA provided very nice interceptor architecture, a basic mechanism for dispatch, which everybody in Web services land has to rebuild from scratch. You can see that coming out now in the various Web services standards.

We were able to build an OTS (object transaction service) implementation on top of CORBA because of the appropriate interceptor mechanisms, support for global thread IDs, etc., etc. That work is taking a huge amount of time in Web services land, of course, because nobody has the infrastructure for it.

RS I’ve dedicated quite a few years of my life to CORBA, and there were some very good ideas in it. Unfortunately, there was so much baggage that those good ideas were never allowed to flourish.

Hopefully we’ve learned from those mistakes. The only successful part of CORBA—of that massive effort, of those millions and millions and millions of dollars that were spent—was the tiny sliver of it that had to do with interoperability.

TC It wasn’t just the interoperability. That was a big part of it, but the notion of a standard mechanism for interception and dispatch on the actual implementation side was also hugely successful because it allowed one to deploy things like OTS in a reasonable way without everybody having to basically rediscover from the ground up how to do that kind of stuff.

RS The reality is that CORBA is mostly about APIs, none of which anybody uses.

TC I agree. I was involved in the CORBA world, too, and of all of the interface specifications and the verticals, very little of them amounted to anything. But I think that although it’s true historically to say one of the driving things behind CORBA was this desire to make things talk across the network to one another in interoperable fashion, the reality of it is that when people started using CORBA, they discovered the power that the standardized infrastructure offered. The basic server-side architecture, with standards for the dispatch mechanism, the interceptor mechanism, object lifecycle, and object identification, is an extremely powerful tool in the hands of developers actually delivering working systems.

RS Lots of things worked well in CORBA, as long as both sides agree that they’re in a CORBA world.

The Web services world is certainly borrowing ideas from CORBA, as CORBA borrowed ideas from earlier technologies. What they’re trying to do in Web services is borrow the few ideas in CORBA that actually panned out.

EA I get the distinct impression, Roger, that your attitude is CORBA failed, and Web services has succeeded. Yet CORBA is used for lots of very real things.

CNN, for example, uses CORBA. Most phone systems use CORBA. And the poster-child example of Web services has been Google. It looks to me like CORBA is more of a success than Web services.

RS I totally disagree with that. I would say that relatively few CORBA applications have panned out. Anybody who is investing any money in a CORBA architecture is making a big mistake.

None of the major players that was instrumental in bringing CORBA about is investing in its future. IBM is investing nothing into CORBA. Sun is investing nothing into CORBA. Microsoft never cared about CORBA. So who is investing in it? Some marginal player someplace.

When you mention Google, you’re talking about a very specific, and limited, application. When you look at Web services, you really need to categorize it into one of two types of applications: inter-enterprise or intra-enterprise. Google is an example of inter-enterprise.

My position has always been that inter-enterprise is a marginal area of Web services. It’s the one that Microsoft and IBM peddle when they’re talking to everybody about this. But the much more important area for Web services—the one that’s being used many, many places—is getting different technology systems to interoperate within the same enterprise.

EA Roger made the rather telling statement that Microsoft never looked at CORBA. Could I make a legitimate argument that CORBA failed and Web services “succeeded”—and I’m not admitting that yet—because of the Microsoft hegemony over the world? What I’m suggesting is, had Microsoft supported CORBA, would we not be talking about Web services at all?

RS No, because Microsoft is not what killed CORBA. J2EE killed CORBA. If you want to blame somebody for killing CORBA, blame IBM and Sun, because all the major players that were originally looking at CORBA as their savior technology abandoned it and moved on to J2EE.

TC I actually agree, totally, with Roger on this. But it seems to me that one of the reasons we have a huge wealth of Web services stuff cropping up is because our friends at Microsoft are making it completely trivial to build Web services, in the sense that you simply build .NET implementations and then say, “Hey, I’d like to have the Web interfaces available for these.”

Do you think that’s true? Are the tools that are making Web services essentially transparent to the developer responsible for part of why they are so popular and why we’re seeing a lot of these services inside the enterprises?

RS There is some truth to that. Certainly, if you look at the major enterprise players, which are, in my view, BEA, IBM, and Microsoft, they are all doing the best job they can to make it as transparent as possible to use Web services.

They did a similar thing with components. They tried to make it very easy to use them, and the problem was that people really never understood what the fundamental differences were between these technologies: objects, components, and Web services.

In some sense, the transparent ability to make something a Web service is not really a good thing, because making an effective Web service requires a much more in-depth understanding of what it means to be a Web service. It’s the same with components. These tools don’t give you that. They give you the ability to slap a SOAP interface on top of some code, and that’s it.

EA How do you think this is going to affect the evolution of Web services? Given that people are going to use these tools, is this going to result in a huge period of extremely poor architectures because people have just slopped Web services on top of existing architectural solutions?

RS Yes, that’s my expectation. We have great tools today for building Web services and virtually no understanding of why, when, and where we should build Web services.

EA I’m curious about your view of the developer’s world when building up a system. Clearly you believe that one has to see the boundaries between what you refer to as objects and components and Web services. But do those differences actually translate in your mind to very specific different implementation technologies? Are objects truly different from components, or is it just a design distinction about the role that something plays in the system?

RS I see it as more a design distinction. Just to give you a simple example: state management. If you have an object, it’s perfectly OK to keep state in the object long-term. As long as the object lives, it can have state in it. In a component, you can’t do that. You’ve got to get the state out of there or your component will not scale. None of the tools tells you that. You have to know that, and you have to design the system accordingly.

Just because you can use objects to implement your components doesn’t mean that objects and components are semantically equivalent. State management is one example, but there are many others. These are design issues, not technology issues.

EA Now you’ve just introduced the semantic element. There are lots of semantics that objects have—polymorphism, encapsulation, inheritance—which you can sort of build into Web services, perhaps just as I can write object-oriented C, but it’s not the same thing.

RS It’s not even clear that that’s a good idea. In my mind, to have inheritance on top of a Web service is probably a bad idea.

In the “Fuzzy Boundaries” article I said that the defining characteristics that differentiate objects, components, and Web services are location and environmental boundary. But location and environmental boundaries have many implications in terms of security, transactions, and other design issues.

EA There’s a very, very strong impression that came out of this article, and that is if I’m going to use components, I would never ever consider using components in something in the same process. But I’ve talked to a number of people now who have said, “Nonsense, we do that all the time, and it’s an important point of our flexibility.”

RS Then they’re really using the wrong technology for what they’re doing. They should just be using object technology for that.

TC No, that’s false. One of the elements that defines a component architecture is the point of interception. This is incredibly useful even if I have things talking within the same process, because it gives me the opportunity to, for example, track invocation patterns without actually having to disturb my architecture at all.

We actually do this for the product that we’re building at Silicon Chalk. We transparently introduce a layer of debugging proxies and get all kinds of tracing information that vastly improves our ability to debug the system. We couldn’t do that if we were building it out of C++ without having some base class nightmare to deal with.

So the fact that component technology provides a point of interception actually turns out to be an incredibly valuable tool to the developer.

RS There are object systems that provide that as well. You’re picking on the shortcomings of a particular language and using that to condemn all object-oriented systems. That’s not fair. If you need interception, if that’s a useful tool, then you choose an object technology that provides interception.

TC I don’t have those choices as a developer out in the real world. Sometimes you have to work in a particular language or system. That’s the land that I live in, and that’s the reality for most developers as well. Component systems offer me the power that I need to build my product and deliver it to my customers. Now it’s true, if I had been programming in Smalltalk, I could go in there and fiddle with the dispatch mechanism. But I don’t have that option.

RS That’s unfortunate. You chose the wrong language.

TC I chose the only language that made any sense, given the other realities of the world that I deal with. It’s nice to talk about distinctions between objects and components as if one could make a completely free choice about how to implement things, but the real world doesn’t work that way. As a person who is responsible for actually getting a product out the door and satisfying customers, you can’t choose arbitrary technologies because they happen to satisfy purist notions of what is appropriate.

RS If you’re saying that you are using one particular aspect of one particular component technology to make up for a regrettable constraint on one particular programming language, then that’s OK. Do what you need to do. But just because you are using interception doesn’t make it a defining difference between components and objects. That’s just a particular artifact of the constraints that you happen to be working under.

EA OK, gentlemen, let’s shift gears a little. In the course of this discussion we’ve hit upon various standardization efforts that have come out or are evolving. For example, a lot of stuff is happening with WS security and WS transactions, WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration). I’m curious to get Roger’s point of view on which of these things are good, and where we should be doing things differently. There are lots of standards out there, and, frankly, they’re at least as hard, if not harder, to understand than some of the CORBA specifications were.

RS I agree that the Web services standards are harder to understand than most of the CORBA specifications, but there’s one fundamental difference between these specifications and the CORBA ones. The CORBA specifications had to be understood by developers. The Web services standards don’t. Nobody needs to understand the Web services standards except for Microsoft and IBM because these standards are about how Microsoft and IBM are going to talk together, not about how the developer is going to do anything.

EA So, nobody is ever going to interact except Microsoft and IBM?

RS The people who are building the platforms are the ones who care about these standards. These standards have no relevance to Joe or Jane Developer, none whatsoever.

TC Do you mean that Joe or Jane Developer is never going to make use of anything that uses UDDI?

RS They’re going to use things that make use of UDDI, but UDDI is going to be at a much lower level than anything they will see.

TC You are saying that they’ll never see UDDI?

RS They will see their particular vendors’ tools for using UDDI. But they’re not going to see UDDI itself. It’s like a Web developer worrying about TCP/IP. Yes, they’re going to use it, but they’re not going to see it.

TC So, again, looking at this from a developer’s point of view, I’m going to build a service-oriented architecture and basically you’re saying I don’t need to know anything about Web services standards, but I need to know about Web services as an abstract idea in order to get my architecture correct.

RS You need to understand architecturally what you need to do to build effective Web services, but as far as how the Web services standards move information around, that’s not your problem.

TC What about issues of performance?

RS You’ll need to know what your vendor supports. These standards are not about development. They are about interoperability among different vendor platforms.

Look at the standards. Give me one example of a standard that would bubble through to a developer? One API that has been defined in all the Web services that would bubble back to a developer? There aren’t any!

TC It sounds like what you’re saying is that the tools that automatically supply Web services interfaces are, in fact, absolutely necessary because they’re that insulation between the developers and the underlying protocols. At the same time, they’re the downfall that’s making it possible to generate poorly architected systems. Two-edged sword?

RS Even if you didn’t have those tools, it would still be perfectly possible to implement poor systems. In fact, it’s probably even easier because you’d have a lot more things you could mess up.

Perhaps you could argue that without these tools, you would have to know so much about Web services that you would be bound to pick up some design smarts somewhere along the path. I think the answer to this dilemma is not to get rid of the tools, but to educate people, through magazines such as Queue, that show them the right way to build these things.

Originally published in Queue vol. 3, no. 7—
Comment on this article in the ACM Digital Library