|
News from National -- Current Articles
2/15/2002
8:19:10 AM
High-End Distributed Software
Architectures
Interview by S. Ibaraki, I.S.P.
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 was the time anybody had
articulated a middle tier architectural vision for Microsoft. His fifth
books, also published by John Wiley & Sons, is COM+ and the Battle for
the Middle Tier.
Discussion:
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:
- Presentation
Fortresses (that deal with web browsers)
- Web Service Fortresses
(that deal with SOAP requests)
- Line of Business
Fortresses (that run the business logic)
- Legacy Fortresses
(that allow controlled access to the organization's legacy systems)
- 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.
|
|
