PREFACE: Writing a book is an adventure. To begin with, it is a toy and an amusement; then it becomes a mistress, and then it becomes a master, and then a tyrant. The last phase is that, just as you are about to be reconciled with your servitude, you kill the monster, and fling him out to the public.
Winston Churchill
This book provides a comprehensive road map for understanding the design, architecture, and inherent integrated nature of modern and legacy networking and application technologies. The audience for this book includes IS managers, systems engineers, software designers, network engineers, system administrators, network managers, systems architects, senior technologists, and senior management.
By reading this book, you will be introduced to a wide range of highly relevant enterprise networking and application technologies. Armed with this knowledge, you will be able to design new systems that better meet functional, performance, and operational objectives. For existing deployments, your ability to isolate poor performance to either the network, the application, or both will be improved. In addition, you will be able to design networks and applications that more seamlessly and efficiently integrate legacy technologies with modern ones.
To understand the purpose of this book, let's consider the following scenario:
The company's sales staff has called a meeting with the Information Systems (IS) department to discuss the increasingly poor performance of their worldwide sales processing application. The IS group has brought the folks responsible for the network to the meeting as well. The networking people blame the application developer arguing the application must be at fault and vice versa, the developer claims the network is slow. Furthermore, there's a desire to integrate the sales processing application with other corporate systems, and there's confusion and disagreement on exactly how to achieve that. The networking people claim the systems cannot be integrated due to differing incompatible protocols, and the application folks want to rewrite everything but don't have the time or resources for that approach.
Problems like these have existed for years, but we are now entering a new era in which less and less tolerance exists for this isolated approach to network and application design.
Distributed object technology, directory services information embedded within the network, vast connectivity, a huge base of older legacy technology that must be further integrated, and a host of other technologies we'll discuss in this book are producing a tighter coupling between the network and its applications. This means that our old habits of separating network and application design, which never worked well anyway, will no longer work at all. The functionality, efficiency, performance, reliability, and security of the network and its applications are so inter-twined, that designing them in isolation will repeatedly result in networks and applications that miss the mark in too many ways-- over budget, underperforming, poorly integrated, and too expensive to maintain.
As a result, there's a growing need for technical professionals to understand how both networks and applications behave together, as one. Like those systems-level hardware designers that are more concerned with how chips and boards work together than they are transistors and capacitors, there's a need to look at the design problem from a higher level of abstraction.
In this new tightly coupled era, one of the greatest challenges is the integration of existing (legacy) technologies with open multiplatform standards-based ones. To ignore what is installed across the enterprise today and just speak of what's new is to be unrealistic. This book places heavy emphasis on the understanding of legacy technologies and their role as part of an integrated heterogeneous open standards-based networking and application environment.
Can We Really Cover All That?
It's fair to ask ourselves this question. With all the information explored in this book, and its associated sea of endless details, is it practical to address all the subject matter here, or is it necessary to decompose it analytically, step by step, detail by detail, topic by topic, and span thousands of pages? Covering this many topics is a formidable challenge for both the author and the reader.
I've discussed this problem with many people over the years and have found that there are three general classes of responses:
(1) The Nay-Sayers
These people argue it can't be done. They look at me, from within their safe insulated and, in my opinion, overly simplistic world, and state it's not practical to expect one person to understand enough about both applications and networking technologies. They argue human beings aren't mentally capable of such things. They are separate areas of study and require individuals who solely focus on one or the other. That's the way it has been, and that's the way it will always be. And they add, that there are 'detailed people' and 'architectural people' and the two don't mix.
(2) The Curious
This group is usually very receptive. They start-off the discussion by giving me the benefit of the doubt. Their questions generally take the following form: What is the perspective, viewpoint, mental discipline- the magic if you will- involved in cultivating a deeper understanding of both?
(3) The Burned
These people have experienced first-hand the scenarios I described earlier. They've been in the meetings where the network engineers and the application developers clashed and the system didn't work. These people demand a copy of the book and usually our discussions last three to four times longer than we anticipated. They also ask me about viewpoint and discipline- how do you get to the bottom of problems in such complex systems, given that we agree it must be done.
Relative to the Nay-Sayers, I perhaps have more confidence than they do in the capabilities of technical professionals and management. I think they can indeed grasp this.
I also believe that detailed and architectural people do mix. I rebel against the belief that systems and architectural folks don't need to be bothered with details, despite the fact that I've had titles in my career such as Systems Architect. I believe in having such people and positions, but the moment they think they are the only ones who worry about architecture, and that they don't need to worry about details, then the project is guaranteed to be in for some serious trouble. People responsible for the system need to have a good understanding of concepts, architectures and yes, indeed, details. Details keep them honest. If you can't worry yourself with details such as the bytes of overhead for a packet or configured maximum packet and retransmission values for your applications and protocols, then you can't architect well, in my opinion.
For those that ask about the magic, the secrets of a mental discipline that will help one cut-across such a wide range of topics, in search of the key details, but not all the details, I offer more of a psychological argument. I often refer them to such abstract perspectives as those from a famous Chinese philosopher, Lao Tzu.
Lao Tzu, an acquaintance of Confucius and historically accepted by many as the author of an approximately 2500 year old famous text entitled the Tao Te Ching, wrote with great eloquence about Tao, or the Way. In his book he infers that the nature of everything in our universe escapes extreme rationalization and overly analytic definition. All that exists reflects a certain flexibility, or softness and, free from a desire to know each and every detail in our world, but instead to know its concepts (its flow) as well as the select details that guide it, we are then free to realize its mystery. The Tao is hidden but always present and is filled with infinite possibilities.
Keeping Lao Tzu's perspective in mind, let's consider again the aspirations of this book. Given that any single topic explored here can alone justify hundreds and occasionally even thousands of pages of explanation, how can its goals be met?
I believe the answer is rooted in perspective. For everyone I've come to know who takes true ownership for the quality of a given network and its applications together, I have observed that their problem solving approach and psychology consistently includes a virtually undescribable freeness while brainstorming, coupled with a willingness to dive deeply, looking for that one detail that when brought to the surface reveals the fundamental insight they are after. They seem instinctively to know which details to pursue, and which to leave alone. Their instincts tell them where to dive.
Their thought process isn't purely top-down, nor is it entirely bottom-up. Both techniques are applied at different times. The best problem solvers I've met don't fashion themselves purely as architects nor simply as programmers or network engineers. Instead, they see themselves as thinkers. They are willing to own the entire problem, not just a piece of it and, at the same time, they have the sense and fluidity about them to know when and where to focus. They know how to maintain their buoyancy, regardless of the infinite number of details involved, because they only focus on those details that matter.
I believe, consciously or not, these people have a sense of what Lao Tzu was writing about-- they have found a Way. And while I may not grasp or proclaim with great certainty that this book successfully shows this Way, I will admit to you that in writing it, I envisioned harmonizing with it, and I envisioned sharing it with you. We will dive together, and select which details are relevant for our design and architecture study, and which we will choose to leave alone. And, in doing so, we will explore a great expanse of networking and applications technologies and prepare ourselves for the new connectivity paradigm of our era- the design and architecture of Network Application Frameworks.
Book Organization
Our study of network application frameworks will be organized by technology provider and open standards, with emphasis on solutions offered by Netscape, Microsoft, Novell, and IBM as well as important open standards from organizations including the IETF, OMG, IEEE, ISO, and others.
You'll notice that every chapter in this book begins with a mind map. Mind maps are used to summarize the technical concepts presented and their relationships to one another. In addition, every chapter except the first and last contains a table summarizing the benefits of the technology addressed within it along with industry experience and observations which support why this technology is worth looking at.
Acknowledgements and Reflections
The writing of this book was a soulful endeavor, one not easily explained in terms of professional career goals or a desire for material gain. It expresses my strong passion for technology and for writing. I can confidently say that to complete this book I put forth every ounce of effort I had. Books like this one don't get completed in months. They demand years of ongoing sacrifice, in every aspect of your life.
I was not alone in this effort. First and foremost, I would like to thank Mary Treseler O'Brien of Addison Wesley Longman. The connection and work chemistry that Mary and I share is anything but common. From the first time we spoke and through every last painful, happy, and manic phase associated with completion of this project, Mary supported me and guided this book as if she and I had been preparing for its completion all our lives.
Working alongside of Mary was Elizabeth Spainhour, who put-up with my incessant nagging and worry about every detail of the process. Elizabeth and Mary make a great team. "Two on one" was the minimum requirement to keep me under control at times. Thank goodness Elizabeth was there to keep me in my cage.
Addison Wesley assembled a powerful and diverse team of reviewers for this book. Each one offered a unique perspective and style, and as a whole, they complimented each other wonderfully.
Clem Cole brought deep insight, character, maturity, and a great sense of humor and understanding to the review process. He provided seasoned input into the history and content of the technologies presented in this book.
Peter J. Welcher reviewed the manuscript with the utmost in tenacity, completeness, and precision. We disagreed often, right to the end. And there are a few holes in the walls of my office with Peter's name underneath them ;-) At the same time, this book is orders of magnitude better because of his involvement.
Thomas R. Amlicke, Jr. provided memorable kindness and understanding through his comments and guidance.
And then we have Lou Breit, Rich Sherman, Roger Snowden, and Ed Wax. While they acted independently, together they were great motivators. Rich, with the project from its beginning, was like a steady beacon, always reinforcing the premise of the book and encouraging me to move forward. Roger provided the greatest sound bytes- if I hadn't slept in what seemed like days, and needed more energy, I'd just pickup one of Roger's reviews and I'd instantly be motivated once again. And likewise, Ed provided great input and memorable words. And rounding out the group was Lou Breit, who also lent his expertise to the review of this book.
Now for my friends and colleagues.
I'd like to thank Judy Peck for noticing that the single guy living in the apartment below her didn't know how to keep anything but Diet Coke in his refrigerator. Judy brought me fruit salad every week and became a great friend.
And thanks to Tom McKnight, a friend of mine for years. He also happens to be the most brilliant person I know. Also thanks to Colleen, Tom's daughter, for putting up without her daddy while he helped me build a strategic consulting practice.
To my friends and former colleagues at Netscape, the Litronic crew, the Global SprintLink team, Simson Garfinkel, Susan Fitzgerald, Steve Petri, Cam, Leslie Aimone, Grace Adams, Chandra Shah, Eric Vaughn, Jeff Treuhaft, Jack Schiff, Sarah Gottlieb-Hecht, Jack Ziros, Larry Elfes, Vab Goel, Don Williams, Ian Little, and Sami Mousa.
Thanks to Katie, Rachie, and Robbie Greenberg for putting up with Uncle Eric's writing over the holidays. Thanks to my brother James and sister-in-law Lisa.
In memory of the late Phil Karlton and his wife Jan.
I hope that this book is helpful and I wish you great success in your professional endeavors. Please feel free to contact me directly with any comments, corrections, complaints, or kind words. My email address is
[email protected].
END