Careers: Interviews
High-End Distributed Software Architectures

This week, Stephen Ibaraki, I.S.P., has an exclusive interview with Roger Sessions, considered by many as the world's foremost expert in high-end distributed software architectures, author of many books, magazine articles, a column in Software Magazine, and, his own ObjectWatch Newsletter plus he heads up ObjectWatch Inc. Roger is a highly regarded conference speaker. ObjectWatch is an information transfer company located in Austin Texas, specializing in courses geared towards Software Architects. They focus on Microsoft's .NET and Java's J2EE architectures, since these architectures offer companies the opportunity to build high throughput (100,000,000+ transactions per day) commerce systems with low cost per transactions.

From 1990-1995 Roger Sessions worked at IBM involved in the CORBA effort. He spent a year as a lead architect for the CORBA persistence service and four years as one of the lead architects for the IBM implementation of CORBA's persistence technologies.
Roger Sessions left IBM in 1995 to start ObjectWatch, Inc., a company dedicated to offering training and consulting services in the field of high scalability, component architectures. He started out focusing on the CORBA technologies, but then turned his attention to Microsoft's distributed technologies, including Java, COM, DCOM, MTS, MSCS, and MSMQ. His fourth book, published by John Wiley & Sons, was COM and DCOM; Microsoft's Vision for Distributed Objects. This book provided a rare, clearly articulated middle-tier architectual vision for Microsoft. His fifth book, also published by John Wiley & Sons, is COM+ and the Battle for the Middle Tier.

Q: First of all, thank you Roger for agreeing to this interview. What do your friends and family think about your career as a world famous authority?

A: The heavy travel schedule is hard on my family. Other than that, they all still seem to like me. It appears to have made no impression on my dogs whatsoever.

Q: Can you detail your personal history, the decisions you made, the jobs you have undertaken, and the roles you have played to get to your present position as head of ObjectWatch Inc.?

A: I graduated from Bard College with a BA in biology with no interest in computers. I was planning on going into biomedical research. I worked for three years at the U.S. National Institute of Health (NIH) as a Research Scientist and discovered terminals to the NIH time sharing computers. I got interested in what they could do, started tinkering with FORTRAN, and got hooked. I then worked at Software Arts (the developer of the venerable VisiCalc) learning the business of IT. I later moved to Prime Computer where I was immersed in software development and then on to IBM where I was part of the CORBA development project. IBM was my first exposure to the field that we today call Components. I have noticed an odd tendency for every company I join to start going down the tubes as soon as I start working there. ObjectWatch has been the happy exception to this rule

Q: You are well known for your views on J2EE versus .NET, some consider them controversial. Can you expound on your position and why you take your current position? Where do you see J2EE in the future? Where do you see .NET in the future? Can you comment on other players and their technologies?

A: I believe that both platforms have strengths. J2EE's strengths are the Unix/Linux market, better consulting support, and better marketing. .NET's strengths are its much lower overall costs, its superior development tools, its support for more languages, and its advanced approach to browser based applications.

J2EE has a tough future for a number of reasons.

First of all, it has been widely over hyped. Many companies buy into J2EE believing it will give them vendor independence. It will not. Many companies buy into J2EE believing it is highly scalable. The sketchy benchmarks we have today indicate that J2EE has serious scalability problems. Many companies believe that J2EE on Unix will have better security than .NET on Windows. The current security bulletins indicate that for all of the problems with the .NET platform, the Unix platform is even worse.

Second, the tools just aren't there. Because of this, the development costs with J2EE are much higher than with the VisualStudio.NET toolkit.

Third, Sun has refused to release their choke hold on J2EE. They own the trademark and all rights to dictate the future of the Java technologies. You cannot implement J2EE or any other Java technology without paying royalties to Sun. Sun is having a tough financial year already and its future looks only worse. With its over-reliance on hardware sales, Sun's existing customer base is being eroded at the low end by .NET/Intel and at the high end by Linux/IBM. It has few new revenue opportunities. As it become increasingly desperate, it will likely turn to what few revenue opportunities it does have, one of which will be the Java trademark. Thus I assume that Sun will tighten its grip on Java even further until Sun either gets sold or goes bankrupt.

As far as the future of .NET, that looks much better. Everything that is negative for J2EE is positive for .NET. First, it has been widely under-hyped. Companies have such low expectations for Microsoft in the enterprise that they are bound to be pleasantly surprised at what the technology can do. Second, the tools are incredible. I can't imagine a developer, once trying ASP.NET, ever looking at a Java Server Page again. Third, Microsoft has gone far beyond Sun in making large parts of .NET available to open standards organizations. This will likely result in open source versions of .NET being available for Linux in the near future.

Open source .NET will be good for Microsoft, who will benefit from their potential customers' mistaken beliefs that they can buy into .NET without getting overly dependent on Microsoft. It will even be good for IBM, who will see diminished J2EE sales, but will more than make up for that in Linux support and consulting services. The big loser will be Sun, whose hardware sales will continue to decline, and who will be left with a Java trademark that fewer and fewer people care about.

Q: You have a unique training philosophy and you use Fairies – please comment?

A: We use Fairies, Gnomes, Wizards, Dragons, and all kinds of other interesting and imaginative figures to illustrate advanced technical concepts. We push the animation limits of PowerPoint. We spend huge amounts of time on our slides, often spending hours working on a single slide that will be displayed for perhaps 10 seconds. We believe that when you have a captive audience, you must work hard to keep them interested and focused. Two hours of looking at "bullet" slides is enough to make even the most interesting material dull and tedious. People keep focused on our slides, just to see what they will do next! We believe it is every bit as important how you present the material as the actual material you present. We take seriously the maxim that a single picture is worth a thousand words. And by picture, we don't mean a bunch of boxes piled on top of each other!

Q: Can you both introduce and then describe your Software Fortress Model?

A: Most people describe enterprise software systems as an n-tier architecture. They describe an amiable presentation tier taking requests from complacent clients working at web browsers, a well behaved middle tier merrily chugging along executing business logic, and a single database shouting encouragement from the back-end. I think of this as the high tech equivalent of "Leave it to Beaver": a pretty picture that bears no resemblance to the real world.

In the real world, the clients are not meek, but malicious. The middle tier is not well behaved, but made up of a disparate bunch of applications developed without regard for the needs of their stable mates. The "database" is not a single anything, but rather a series of disorganized data storage technologies that spend most of their time cringing from the unreasonable and often conflicting demands of the business logic.

So we have two choices. We can either ignore this chaos. Or we can model it. And by modeling it, try to bring it under some degree of intellectual control. We choose the latter approach.

We propose a new model for enterprise systems called the Software Fortress Model. The Software Fortress Model treats enterprise systems as a series of self contained, mutually suspicious, marginally cooperating software fortresses (perfect for J2EE and .NET!). Each fortress makes its own choices as to software platform and data storage mechanisms and interacts with other fortresses through carefully crafted treaties.

A fortress represents a trust boundary. Everybody inside the fortress (including the data stronghold) trusts everybody else inside the fortress. The fortress is surrounded by walls that prevent entry into the fortress except by known entry points. The entry points (called drawbridges) are tended by guards, who make sure than any requests coming into the fortress are subjected to the strictest security scrutiny.

There are five main types of fortresses commonly found in large organizations:
  1. Presentation Fortresses (that deal with web browsers)
  2. Web Service Fortresses (that deal with SOAP requests)
  3. Line of Business Fortresses (that run the business logic)
  4. Legacy Fortresses (that allow controlled access to the organization's legacy systems)
  5. Treaty Management Fortresses (that manage complex treaty relationships between other fortresses).
At an organizational level, we don't worry about the implementation of the various fortresses, but instead, the relationships between the fortresses - problems like how we will ensure interoperability and how we will enforce security.

The Software Fortress Model has two main benefits. First, it helps tame the corporate IT spaghetti pile. Second, it provides an intellectual framework within which one can intelligently compare different technologies. Rather than argue about whether J2EE or .NET is better as a whole, one can look at the specific subsets of J2EE and .NET that are relevant, say, to a Presentation Fortress. Then the comparison becomes easier. Given what we are trying to accomplish in this particular Presentation Fortress, would Java Server Pages or ASP.NET be a better solution? Enterprise Java Beans and COM+ can be ignored, because, although they are part of J2EE and .NET respectively, they have nothing to offer in the building of a Presentation Fortress. They are only useful in the building of a Line of Business Fortress.

Q: In my travels and discussions, I find that security is a very serious concern for 100% of the IT public. What are your views on security?

A: The most important rule is this: don't trust your operating system vendor to take care of security for you. Microsoft does a poor job of ensuring security. The Unix/Linux vendors do even worse.

The vast majority of security problems are caused by lazy programming. Runtime environments like J2EE's Java Virtual Machine and .NET's Common Language Runtime can eliminate some of these problems, such as buffer overflows, but there are plenty of security problems that will still slip by. The bottom line is that security must be part of the earliest design goals of any system. That is why we focus on it so strongly in the Software Fortress Model. Every fortress has a guard. Every fortress is configured to trust nothing outside of itself. Every fortress is designed so that if it does fail, it fails in a secure manner. And every inter-fortress interaction is designed so that security breaches in one fortress do not propagate to other fortresses.

Q: Can you share your best tips for those thinking of getting into the computing field – many in the audience are in computing programs in university or are considering a career in computing?

A: If you want to get into computers, the single most important skill you should learn is how to communicate. The next most important skill is how to think. Too many people in our field are unable to communicate even simple ideas (especially simple ideas!), and all too many merely accept at face value what they are told by their vendors or their peers. Learn to subject every claim to logical scrutiny and decide for yourself what makes sense and what doesn't. Far down the line in educational priorities is learning to program. I can take any intelligent person and teach them to program. It is much more difficult to take a programmer and teach them to be intelligent.

Q: What additional books are you planning in the near and far term?

A: My next book will be about how to design Software Fortresses. Beyond that, who knows?

Q: Roger, you have a most illustrious career. If you had to do it over again ….?
A: I think next time I will be a monk.


Suggestions for this page?
Email NPA Web Services: click here

NPA      facebook      LinkedIN logo
© Copyright Network Professional Association® 1994-2024 All Rights Reserved.
NPA Privacy Statement