BEA founders on object-oriented transactions

BEA founders on object-oriented transactions

BEA Systems originally made its mark by marketing the Tuxedo transaction processing monitor for Unix systems, which was originally built by AT&T and sold to BEA by Novell. Today, BEA is getting notice for its capability to deliver object-oriented transaction processing software that allows servers to process heavy transaction loads generated by Internet traffic. BEA began shipping its latest M3 Object Transaction Manager middleware in July and is partnering with Symantec on application development. BEA's three founders - chairman and CEO Bill Coleman, executive vice president Ed Scott, and chief technology officer Alfred Chuang - shared their views with IDG's Michael Vizard and Jon CornettoIDG: You guys are primarily associated with enabling high-volume transactions on Unix systems. Can you leverage that on other platforms?

Scott: If you take the whole transaction market, we're a fly speck because the transaction market is clearly dominated by IBM. The CICS transaction processing system has 29,000 licensees, and there's probably more than a million CICS programmers. But when you take the distributed transaction market, we're clearly a giant and about 25 per cent of our business is [Windows] NT.

[Do you have] any concerns about competing with Microsoft? Windows NT 5.0 has a lot of the functionality you're talking about built into the OS.

Coleman: Microsoft will be too late. They will not be a major player in the high end of the enterprise because of the problem with COM+ [Component Object Model+], which is connections-based. With connection-based architectures, you can only have so many packages or objects talking to one another. And then when you add thousands of users times many, many applications, it becomes an impractical problem that limits you to these tens of transactions a second. It's fine for departmental level or below, but until they re-architect that from the bottom up, it's not going to provide an infrastructure for large applications.

Scott: There are two other elements. The first is a legal element that questions whether they're going to forever get away with bundling discrete things in the OS where they already have a monopoly in order to get a monopoly where they're weak.

I think they are clearly violating the antitrust laws by doing that. The second element of it is that Microsoft's view of the world is not an open view. Microsoft's view of the world is NT and everything else is going to be secondary to NT. But the rest of the market believes a heterogeneous, mixed world is best.

Has BEA thought about making its tools easier to use for mid-range companies that don't typically have the resources of a billion-dollar company?

Chuang: Our goal is to be able to bring the ability to develop M3 technology and proliferate it down to a commodity level.

So how then will you make something as complex as M3 available to developers using different development environments?

Chuang: There is a suite of things that we will have to develop to fill the gap between a tool for doing raw programming to a tool that allows you to browse components that have already been built. We have a project called Ice Crystal that we're building for that.

And we're hoping to ship that toward the end of this year. The analogy should be to let someone look at developing server-based enterprise applications as [easily] as you're developing Windows-based applications today.

What impact is the Internet having on transactions?

Coleman: As people run into the wall, they realise they need to do something to manage it. This whole market is finally starting to get to the level where [people] are truly doing high-volume mission-critical business on the Web.

It would seem that Netscape, Oracle, Sun, IBM, and others are targeting this space. Any concerns about increased competition?

Coleman: Not one of those guys is within five years of having the level of complexity to handle large volumes of complex applications that require reliability, scalability and manageability in a distributed world.

One [issue] we're starting to hear [about] is that the advent of the Web is making people less interested in distributed computing because they're centralising servers and using browsers for data access.

Coleman: If you want to spend a lot more money and end up being a lot less competitive and have a lot less opportunity to react to changes in the future, certainly put yourself into yesterday's buggy whips and carriages instead of flying in jet planes.

Everybody uses this server consolidation movement as proof that the world's not distributing. But that sort of says that we're moving in reverse. What's going to happen over the next 10 years is going to drive distribution much more rapidly. Ultimately, if you have free bandwidth and free computing, the only thing to do is put the computing closest to the data. Now, if you believe everybody's going to allow their data to go back to one server and give up their control of that data, then distribution is not going to happen.

In reality, the fact that intellectual property is going to be the lingua franca of the next century means you're going to want to control your data. That's going to drive distribution enormously.

Scott: It's an amazing thing. Time-sharing has been there forever, and it just keeps getting reborn in different incarnations. They're all just different incarnations of the same idea.

We believe in distributed computing and there's no way it can go away because the Web is distributed computing.

But a lot of people say that distributed computing environments are just too hard to manage.

Coleman: I think a lot of that has to do with the fact that we've looked at the world as a network management problem and not as an application management problem. Networks are not that hard to manage.

The problem is they have all these pesky little applications that run on them. But people don't care if the failure is on the network or the computer, they care if they lose service on their application.

Today, there's a lack of distributed infrastructure. And by the way, that's the business BEA is in.

So where does the move to components lead?

Coleman: It's still a lot harder to build distributed applications than it is to get on Visual Basic and build a relatively trivial application. The problem today is you have to choose.

You have to choose whether you're doing a large mission-critical application in which you have to consider architecture and you have to plan it before you build it. BEA's mission is to take advantage of two technology dislocations.

The first is the move to distributed applications and the second is the move to component-based applications.

Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments