TNC: [INTRO] I'm very pleased to welcome to the program Roger Sessions. Roger, welcome.

RS: Thank you for inviting me.

TNC: Well, when did the book [COM and DCOM] come out?

RS: Oh, let's see. It seems a long time ago, somehow. So many things keep changing. But I would say it came out just at the end of last year.

TNC: Roger has a web site, www.objectwatch.com.

RS: I do have a little bit about the book, but most of the writing that I have on the web site is the newsletter that I do. I do a newsletter which is focused on distributed component technology and in particular the middle tier infrastructures that are important in distributed component architecture. So that newsletter is kind of focused on that. And that's most of the writing that I keep up there.

Of course, people can subscribe to that, as well, but they can also see the newsletter on the web site.

RS: No, I worked for --

TNC: I'm sorry, I meant IBM…

RS: I've never worked for Microsoft. Despite what some people say to the contrary... I worked for five years at IBM on their implementation of the CORBA architecture. And during that time I was very involved in the SOM project, the system object model, which became IBM's implementation of CORBA. My field of expertise was the object persistence. I was basically on loan to be one of the lead architects for the CORBA persistent service and got very involved in a lot of the CORBA services which were related to persistence, such as lifecycle and transactions and things like that.

TNC: What was your experience prior to IBM?

RS: Well, I have a lot of background in objected oriented programming. My second book was "Class Construction in C and C++." And I've been the general area of object persistence, doing a little bit of work with object oriented databases. I've worked at Prime Computer and then (unintelligible) background in relational databases.

So I've had a lot of interest in the issues that surround distributed commerce type applications.

TNC: Do you see any analogies between the C++ object model and distributed component architectures?

RS: There are three primary characteristics that define object technologies: inheritance, encapsulation and polymorphism. For various reasons, a lot of those have really turned out not to be too interesting.

For example, encapsulation has turned out to be over-rated in the object world. It turns out that we probably understood how to do encapsulation better in the old procedural world. And for inheritance, the inheritance information has kind of broken down into a big debate about whether we have inheritance as implementation or inheritance as interface. Nobody can really agree on even what inheritance really is.

But the one area that has really been very, very powerful in the object-oriented world and which has continued to play an important role in the component world, is the idea of polymorphism. The areas that I'm interested in, large distributed commerce-like applications and trying to develop systems that will do high transactional throughput support of a very, very large number of clients, in that area we're seeing two technologies merge.

First of all, [we have] component technology, from which we get polymorphism and which enable us to develop distributed networks, which are a very, very important idea. And we're seeing that technology merge with transaction monitoring technology. So there's a lot of work being done in various areas of the industry to merge those two technologies. And that's what's basically going to be driving the commerce applications over the next three or four years.

TNC: What are some of the existing transaction monitor technologies that pre-existed distributed object technology on the PC?

RS: Well, the major ones that are most well known in terms of the middle tier, and the middle tier has traditionally not been a PC tier, but the main technologies have been Tuxedo and KIPS, for example. So we're seeing two different areas in terms of merging the transaction processing monitor and the component technology.

On the Microsoft area, we have this whole architecture that I've been describing as MDCA, for Microsoft Distributed Component Architecture. As far as the merging of the transaction processing monitor and the component technology, that's happening with COM, DCOM and MTS. And that is the area that we'll be calling COM+ in the future.

As far as non-Microsoft technology in that area, such as the CORBA area, we're seeing a lot of work being done. Unfortunately the CORBA standards don't define any infrastructure in the middle tier. So all that work that's being done in the CORBA area is being done in a proprietary manner.

So we have, for instance, IBM's component broker, which uses some of the CICS technology, and BEA's product, M3, which is merging TUXEDO with Digital Equipment's old object architecture, which was bought by BEA.

There's a third world, actually, that's probably worth mentioning as well, as far as convergence between transaction processing monitors and components: the attempt to put together the enterprise Java bean stack.

So those are the three [technologies] that are going on in this area. The Microsoft architecture, which is probably by far at this point the most developed and the most stable, the CORBA proprietary technologies, and the enterprise Java beans technologies.

TNC: What are some of the performance issues associated with transaction servers? What are some of the characteristics that they need in order to support the type of activities or traffic transaction volume that we're talking about here?

RS: The major thing that we've learned from the transaction processing monitor people is that we need to use a certain style of programming in order to achieve very high throughput. It's probably worth mentioning that we're talking about a very specific aspect of performance here. We're not talking about client response time. We're specifically talking about throughput.

And throughput is very related to the cost of the middle tier. So there are a couple of things that we're really interested in with these components/TPM technologies. One of those is the cost of the middle tier, how many clients can we support. And then we're also interested in the throughput. So those are two closely related issues. But we're not necessarily looking at client response time.

TNC: So throughput is a more important metric than processing power at the server level --the time it takes to process a transaction, how many transactions can you process in parallel, the locking mechanisms used in parallel transactions?

RS: I would say that throughput includes a lot of those things. In general, what we don't care as much about is how long it takes to process a transaction. That's really more related to client response time in general. What we're more interested in the middle tier is how many transactions can we process in a given unit of time. This has to do with how many can be processed in parallel, as well as how long each one takes.

The MTS has a whole architecture in place based very much on traditional transaction processing monitor technology. [Unintelligible fragment].

This is very, very similar to what BEA is trying to do, as well. It's just that that technology is much newer. The Microsoft technology has been out for much longer. BEA has just come out of Beta now. But I think they're trying to do very, very similar things, and basically if you can understand the approach one is taking you can understand the approach the other is taking.

TNC: How about the memory requirements of transaction servers? Don't they have to hold state information about running, instantiated objects? Is that a factor?

RS: That is one of the big issues being argued about right now. The TPM people have already gone through this state issue. They've basically discovered that the way to scale the middle-tier is to put state management in the data tier level. Scaling the middle tier is something we all care about, especially if we're on the Internet with a huge number of clients.

There is a clash of cultures between the TPM folks and the component folks in some areas, and this is one of those areas. But ultimately the TPM folks are going to win this because there's no alternative but to scale the middle tier. And the only way we know to scale the middle tier is to move the state management into the data tier.

TNC: Programmers with multi-threaded experience know that it's not necessarily more efficient to spawn more threads to get better performance. In many cases the cost of synchronizing tasks is more expensive than the benefit gained from running these tasks in parallel. The overall design of the system is important.

RS: I really do agree with you that all those things are very, very important in terms of getting an efficient distributed component based system.

What we've discovered and what the TPM folks have worked out for a while now is that those issues not only are very, very important but they're also very, very difficult to get right. So what we're trying to do now in the convergence of these two technologies is try to develop systems that enable us to build our business logic and components, but not have to worry about any of these details which are very, very hard to get right.

So rather than worry about them we're trying to use infrastructures designed to efficiently manage the middle tier. In the Microsoft case, that's MTS. And in the BEA's case, that would be M3. But basically, they're all trying to do the same thing, which is to give a very efficient infrastructure so that you don't have to worry about all those details, which are very difficult to get right.

You follow some basic programming rules and the underlying architecture takes care of all those details.

TNC: What are some of the main differences between the technologies you've presented? In terms of both performance and object abstraction.

RS: Actually, in terms of those issues, they're probably very similar. The differences between the CORBA proprietary path, the Microsoft path -- or MDCA path, if we can call it that, because it actually involves a lot of companies besides just Microsoft-- and the enterprise Java beans path, is primarily the underlying component model that they're using.

Obviously, the underlying component model in the CORBA proprietary technologies is based on the CORBA system. The reason there are proprietary technologies in that area is that the essential CORBA model for doing components is basically a model which is inconsistent with doing the TPM-like algorithms that we need on the middle tier. The basic CORBA model is a state full programming model where it's assumed that state is being managed in the component tier rather than the data tier.

It's not to say it's stateless or stateful. The real issue is, "where is the state being managed". In the CORBA model, it's being managed in the component tier, which is inconsistent with these infrastructures. So that's why these CORBA technologies are going down a proprietary path.

The Microsoft system has always pretty much leaned towards the stateless model. So it fits more naturally into what they're doing.

TNC: Actually, we should point out that these infrastructures are not necessarily mutually exclusive. There are bridges between COM and CORBA, for example.

RS: Right.

TNC: We have to take a quick break, Roger. We'll be back with Roger Sessions after these messages.

[COMMERCIAL BREAK]

RS: Thank you.

Maybe we could come back to this state issue... I think a lot of people are confused on this.

The one analogy I like to use to explain how this whole middle tier infrastructure works is to compare the work today with the way I used to work back when I was working at IBM. When I was working at IBM I worked in this very, very large building that had about 500 desks in it. And today the same number of people, including myself, work in this very, very small building that has about ten desks in it. Namely, when I want to go out and do some work at a desk, I typically go to Starbuck's and have a double macciatto or two and work on the desk there.

What's interesting to me is that the same number of people work at Starbuck's that used to work at IBM, but they do it on ten desks rather than 500. And the way that they are able to do that is that at IBM the desks are hard wired to each individual. So when you come in you always work at the same desk. You leave all your junk on the desk. Nobody else can use it because it's covered over with your junk. There is a conceptual connection between a human being and a single desk.

When we go to Starbuck's, I use the desk for as long as I need to use it, but no longer than I need to use it. And as soon as I leave I clear all my junk off of it. And if I don't, then the Starbuck's employees will come along and do it for me. And that enables somebody else coming in to use that very same desk.

And that's basically exactly what's going on in these middle tier infrastructures, when we're looking at component, the relationship between component instances and clients. If you keep all the junk or all your state inside your middle tier, in other words, in your component instance, then nobody else can come around and use that instance. It's hard wired to you. Even though most of the time the client isn't using that [state information] and you're tying up valuable resources on your middle tier.

So all of these architectures basically work the same way. They allow the resources associated with component instances to be shared among a very large number of clients. It's very, very similar to the desk situation, because I don't store my stuff there. I can walk away when I'm finished using it and somebody else can walk in and start using it themselves.

TNC: The language you use, the Starbuck's metaphor, is representative of the way the book is written. It's extremely simple to read and yet it explains rather complex concepts.

RS: Thank you. There's a lot of stuff in there. There's a lot of new stuff to understand.

Actually, in some ways, the book is misnamed, because it stands out as being about COM and DCOM. But it's really about this MDCA, this Microsoft distributed component architecture.

When I first got into this whole thing from the CORBA community, Wiley was trying to convince me to write a book about COM and DCOM and I didn't know anything about COM and DCOM. I said I wasn't really interested in it. And they finally convinced me to spend a little bit of time looking at it.

I spent about a week looking at COM and DCOM and I came away with this conclusion that it was pretty boring stuff. This was stuff that we've had in the CORBA community for a long time.

But then stumbled on the MTS work that was being done, the so-called Microsoft Transaction Server. This is really a bad name because it doesn't have too much to do with transactions. But, anyway, I got into the MTS. And when I realized that [MTS] was a component run-time environment, that's when this whole thing started to get very interesting, because that was something that went much further than anything that we had conceptualized at that point within the CORBA community.

COM and DCOM by themselves are not that interesting. But when you throw on the other parts of the MDCA, then I think you've got something which really make a lot of sense on the middle tier.

TNC: It seems that many people now concentrating on COM and DCOM haven't really grasped what the entire architecture is about.

RS: Well, let's look at it. There are six technologies that make up MDCA, Microsoft Distributed Component Architecture, and I'll go through them and see where they all are.

Of course, we have COM and DCOM at the lowest level. And they're very stable. They've been used for a long time, probably much more than any other component model around.

The next part of the whole thing is MTS, Microsoft Transaction Server, which is again misnamed. It really should have been called a component run time environment or something like that, because that's really what it is. It is in its second release, and everything I've heard is that it's very stable.

I've used it. I think it's a really good product. It has more that needs to be added in terms of being able to configure things really easily, but it's a very solid product and a lot of people are using it very successfully.

Then we have MSMQ and we can talk about that more when we talk about the COM/CORBA bridges. But MSMQ, which is Microsoft's message queue product, is a very solid product. I've heard nothing but good things about that.

Then we have DTC, the distributed transactional coordinator, very solid. And then we get to the sixth technology, which is MSCS, Microsoft Cluster Server.

Of the six technologies, that's the one that at this point is still the weakest. We're starting to see that get strengthened, but we still are a long way from where we'd like to be in terms of the whole cluster technology.

But of the six pieces, I would say that five of them are very strong, and one of them is just kind of coming on board now.

TNC: We can talk about clusters a bit later, but I do remember in the book that you say that it's absolutely critical to the success or failure of the entire architecture.

RS: The cluster story is very critical to the success. The reason for that is that right now Microsoft's architecture is very scalable on a single middle tier machine. So as long as your components are only running on one machine you can make very, very good use of it using the TPM algorithms that are part of MTS.

The problem is that when you want to scale beyond one machine you suddenly hit a road block right now. So we're depending on some kind of cluster technology to get beyond that road block.

When we talk about clusters, there are two aspects of them that we usually consider. There's fail loader, which means that if one machine goes down that another one can take over its work load with, hopefully, minimal interruptions. And then there is load balancing, which means that as one machine gets overworked you can distribute its workload to other machines.

Right now the cluster has a fail loader, limited to two nodes, and doesn't have any load balancing. When COM+ comes out load balancing will be available, but it may not be packaged as part of the MSCS. I don't really know, but let's say that MSCS does not support cluster load balancing within the NT5 time frame, we're still likely to have load balancing in that time frame, but we'll be getting it from COM+, because COM+ will support this idea of application clusters.

And what that will mean is that these instances of components that are working for you can be moved around to different machines without you having to be aware of that.

So that will give us load balancing. We are going to have load balancing, I think, but it may not be under the auspices of MSCS at that point.

Eventually, I think, we will have true load balancing within MSCS. But I think that the current focus with MSCS is to get the number of nodes much higher. Because two is not really an adequate number of nodes. We'd like to see it get to eight or 16…

TNC: It seems that the Wolf Pack project is hitting a dead wall. What are the prospects of seeing this architecture scale to more nodes. There may be some structural limitations that will require redesign of some basic components.

RS: Well, I think that the cluster technology that's there today, as best I know, is pretty solid. I haven't heard any complaints about it. It's limited in terms of the number of nodes.

TNC: Two nodes.

RS: Two nodes, right. And, of course, it only does fail-over, not load balancing.

TNC: What exactly is distributed in the context of object components clusters? Processing?

RS: Well, let me just talk about what a cluster is in the first place. Then we can kind of relate it back to that question.

Greg Pfister wrote a wonderful book on clusters called "In Search of Clusters", basically the bible of clusters. And he describes this as a single system image. And what that means is that you've got a bunch of machines out there that you don't see as a bunch of machines. You see them as a single system image.

In my book, I use a less technical term to describe this. I call them a blob of computers. So instead of asking a particular machine to do something for you, you ask the blob to do something for you. And if one machine in the blob has gone down, it doesn't really affect you because the other machines in the blob do it.

Right now there are only two machines in the blob. If one machine gets overworked then the other [machines] in the blob would take care of it.

That's basically a cluster. You don't see any of these machines. You just see a machine blob out there and you just make use of that.

TNC: A virtual processor distributed over many machines.

RS: Yes. You have to be a little careful when you use language like that. It sounds like you're getting implementation details on how it's done. Because you have a lot of people arguing about what is the right kind of hardware technology to achieve clustering.

But conceptually what we're talking about is just a blob of machines out there.

TNC: But what gets distributed? At what level do things get distributed? Tasks? Object methods?

RS: There's a lot of things that can be distributed.

From our point of view, as we look at this marriage between component technology and the transaction process of the monitors, what gets distributed, what gets moved around the blob are component instances. If I instantiate a component instance and ask it to do some work for me, I don't know what machine it actually lives on. You know, from my point of view it just lives on the blob someplace.

TNC: The entire object is instantiated on a machine, and any messages to that object are handled by that one machine.

RS: Right. But, again, we don't [specifically] know what machine is involved. We think of it as just being a blob. We think of it as running on the blob someplace, and that may be on any machine that's in the blob. But we can't tell that. We have no insight into that.

The whole point of this whole thing is to make it so that you don't know anything about that.

And a lot of that technology, I think, is going to be in COM+. It won't be called single system images. I'm not sure what the right terminology would be. I've heard various terms for it. It would be, you know, instances that can live on any number of different machines. And then the system as a whole will be responsible for doing routing to figure out which machine is available, and that's where it will instantiate the object.

So we'll have quite a bit of load balancing just as a result of that. If you do things properly, if you understand the programming model that we need to understand, if you're using any of these component/TPM technologies, then you have the potential to do some really nice load balancing of that work.

TNC: Roger, I'd like you to go back to one of the elements of MDCA that you mentioned earlier, message queues. What are message queues and why are they important?

RS: Well, there are a lot of reasons why message queues are important.

First of all, what message queues are a kind of an asynchronous message requesting facility. I usually think of message queues as being like E-mail for software. One piece of software can send another piece of software some E-mail.

Now, it's not exactly that right analogy, because generally you don't send a message to a particular piece of software, but you send the message in to a message queue. Whoever is listening to that message can respond. But it's a similar concept. It's asynchronous. The sender and the responder don't have to be online at the same time.

There are a lot of things this technology is very useful for, but in my opinion, and my opinion is probably different from most of the industry on this, in my opinion this type of technology is the ideal technology to do bridging between COM and CORBA.

Most of the industry is focusing on component level bridges between COM and CORBA.

TNC: Roger, I'm sorry, I have to cut you right here. We have to take a quick break and we'll be back with Roger Sessions after these messages.

[COMMERCIAL BREAK]

TNC: Welcome back. We're talking to Roger Sessions about Microsoft's vision for distributed objects. And Roger, before I rudely interrupted you, you were talking about message queues.

RS: Well, it's probably similar. I think that events are something that could be on top of message queues. We usually think of event technology as being different than message queue technology. We usually think of events as being more of a publish and subscribe type way of doing things. We usually think of message queueing as being more of a "ask preliminary questions to the message queue".

Message queues are really valuable for doing communication between COM and CORBA, [more valuable than] the COM/CORBA bridges which people are building and which are basically doing synchronous requests --with a component which can understand COM on one side and understand CORBA on the other side.

I don't think that's really the issue. The real important thing that we need to be able to do is to have applications that were developed in MDCA communicate with applications that were developed on CORBA. And that's the kind of technology that message queuing is perfect for.

So I see this as an application to application communication strategy. What we're trying to do is to enable these applications to work together and make sure that we don't have to have a homogenous middle tier, that we can support a very heterogeneous middle tier. We've got part of the middle tier which is doing COM/MDCA stuff, and another part of the middle tier which is doing CORBA stuff.

TNC: Message queues could be used as some kind of repository where different technologies could go and retrieve messages. This is where they would meet.

RS: Exactly.

Well, you can imagine. Let's say you had a sales order system and a shipping system, and your sales order system has developed with MDCA and your shipping system has developed with CORBA. Typically what you're going to want to do is, you're going to want to have your sales order thing all working together synchronously in a very tight package. But every once in a while it wants to tell the shipping system that, okay, we processed this order. When you get around to it, you know, if you're not up right now, don't worry about it. But as soon as you get around to it, you need to ship an order out to this particular customer.

That's the kind of thing that message queues are really good for, because, if the system is down and the shipping is not up right now, it doesn't really matter. When it comes up, that system will find out about that message. In the meantime, you don't need to sit around and wait for the shipping to occur. You can go ahead and start processing the next customer.

TNC: Okay, Roger, we only have ten minutes left and there's a whole range of topics I'd like you to address...

One of those topics is Java. You're very big in your book about Java. And you see Java as an ideal way of creating components that can then be wrapped in a COM wrappers. And then you see VB as a good place to host these components.

RS: Yes. I should probably clarify my thoughts on Java. I am very pro-Java. I think that Java is a wonderful programming language. It's one of the best things that happened to computer science. But I also think it's one of the worst things that happened, because in the same way that I think Java is an excellent programming language, it's a lousy operating system. And I also think it has very poor user interface technology.

So what I like about Java is Java on the middle tier, Java being used to program our business logic into these middle tier components. It's a great, great language for doing that. But not using it for an underlying operating system. Let's say you've chosen the Microsoft route. Then you should assume you're running under MDCA and use [MDCA] to its absolute highest capability.

On the other hand, if you've gone on BEA's M3 product, then you should assume that you're on M3 and make the absolute maximum use you can use of that.

So I believe in Java the programming language on the middle tier. It's unparalleled for that. As far as operating system, not interested. As far as user interface technology, I think that Visual Basic is far superior. Probably Dynamic HTML will be far superior. There are probably several other things that are far superior to Java on the client tier.

TNC: And actually in the book you hardly mention C++.

RS: One of the good things about the component technology is that you can use whatever language you want. If I say that Java is the best language, and you don't believe me and you want to use Visual Basic because that's what everybody understands, or C++ because that's what you've been doing all your work in, that's fine. The nice thing about this component technology is that it shields you from having to enforce a language rule across your whole corporation.

I think that most people who have real experience with C++ and Java will agree that Java is a much easier language to use. But it's not the only one. If you're a C++ shop, then by all means use that. I'm not really trying to push so much the idea of using Java in the middle tier. What I'm really trying to push is the idea of using component technology, use a combination of component technology and TPM technology on the middle tier to develop your large multi-tier component-based applications. That's the really important idea, not so much what language do you use at what particular point. You know, use what works for you. But definitely use the infrastructure.

TNC: Let's talk a little bit about CORBA. You spent five years of your life working on CORBA architectures, and yet you're very big on Microsoft COM/DCOM at the expense of CORBA.

RS: Well, the biggest failure of CORBA is that it has no middle tier infrastructure. [CORBA has] this whole architecture that allows you to do three-tier programming, but you can't do it efficiently because there's no middle tier architecture, there's no standards on the middle tier. So there's nothing on the middle tier that says, how do you go about managing a large number of clients trying to work with a very small number of instances? And you want a small number of instances on your middle tier, because otherwise your middle tier is going to cost you a fortune.

TNC: Correct me if I'm wrong, but that's also the case with COM. In the COM case, it happens that Microsoft also offers implementations that take care of these problems.

RS: COM and DCOM do not address this issue. MDCA addresses this issue. So when you look at this whole six-product architecture, then you've got something which addresses the issue.

The issue is addressed by COM, DCOM and MTS. When you're running COM and DCOM under the auspices of the Microsoft transaction server, then you have a solution to this problem. If you're running COM and DCOM without it, then you don't have a solution. But I would never suggest to anyone that they run COM and DCOM on the middle tier without MTS. That would be crazy. That would be as crazy as using CORBA technology. You'd have the same problems.

TNC: Is it a failure of CORBA or more a failure of the vendors?

RS: Well, it's a failure of CORBA because there are no standards. The vendors are actually coming through with stuff. So you have BEA coming through with their M3 product, which is based on CORBA. You have IBM coming through with its component product, so the vendors are coming through with that stuff.

The problem is that since there are no standards, they're all doing it in proprietary ways. This means that if you do any development for M3 and you want to move it over to IBM's component broker, you can just forget it. There would be no possible way of doing it.

In fact, it would be easier to port from Microsoft's MTS environment to one of those vendors than it would be to port from one of those vendors to the other. The reason for that is that the Microsoft middle tier architecture has a very, very minimal API. Since there's no API, there's really not much you'd have to rip out to do that.

TNC: Roger, we only have a couple minutes left. Why don't you tell us a bit about ObjectWatch and some of the resurces you make available on your site.

RS: Well, I do a lot of different things. Sometimes it's hard to keep track of them all... But I mainly divide my time between teaching/mentoring [and writing]. I teach companies about especially Microsoft middle tier architecture. I compare the Microsoft middle tier architecture to various other architectures, like CORBA and enterprise Java beans.

And then I do a lot of writing. I have a very heavy writing schedule. I do books. I do my newsletters, which I would be delighted to have any of your listeners to subscribe to, no charge. Just write to sub@objectwatch.com and I'd be happy to put you on the list and they can look at the old ones on the web site.

Then I do mentoring. I go in and evaluate architectures. A lot of times, people don't understand the middle tier issues. A good example of this is the IBM San Francisco. They've developed this very, very large, very, very interesting commerce-oriented application. But they're just now finding out that the whole thing doesn't scale. And the reason it doesn't scale is because they didn't take into account any of the infrastructure requirements of the middle tier. Now they've got this whole product and basically they can't use it with more than one or 200 users.

TNC: This is because there's a conceptual gap here to cross.

RS: Exactly. And there are two places where you need to do this. You have to explain to the component community and the object oriented community what it means to start adopting these TPM algorithms, which we need in order to get the middle tier to work.

And conversely, we need to explain to the TPM folks what it means to use polymorphism and frameworks in an intelligent way.

When I'm doing these courses, I usually find that I'm either talking to people who have a very good background with component/objects, and they totally understand the polymorphic stuff, or I'm talking to people who have a good understanding of TPM. Very rarely do these groups understand each other. And you need to understand both these technologies to make the stuff work. There's just no other option.

And that's true regardless of which of these solutions you go for, whether it's Microsoft or BEA or enterprise Java beans.

TNC: Okay, Roger, this is it. We have to wrap it up here.

RS: Well, I really appreciate the opportunity.

TNC: Roger, thank you very much for being on the program today.

RS: Well, thank you.

TNC: Roger Sessions' web site is at www.objectwatch.com.