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.
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. |
|
|