Architecting Enterprise Solutions with UNIX Networking

Features

• Cover Type: Paperback with 352 pages
• Published by: Prentice Hall PTR
• Edition: 1st Edition October 15, 1998
• Written in: English
• ISBN 10 Number: 0137927061
• ISBN 13 Number: 978-0137927067
• Book Dimensions: 9.2 x 7 x 0.9 inches
• Weighs: 1.6 pounds

Card Catalog Description
Architecting Enterprise Solutions with UNIX Networking is the first step-by-step guide to building UNIX-based architectures that maximize performance, growth, reliability, manageability, and security.

From the Inside Flap
Preface

This book is about UNIX and the corporate network. It's about architecting enterprise-wide computing solutions for finance, engineering, and manufacturing. It's about integrating desktop computer applications and UNIX systems. It's about using UNIX networking to create scalable open systems.
The author is a 15-year veteran with Hewlett-Packard Consulting and has had the pleasure of recommending, developing, and implementing HP UNIX (HP-UX) and network solutions for HP customers. This book may lean a degree or two toward HP products, but so great is HP's (and the author's) commitment to open systems that the reader will find all the information between these covers to be widely applicable.

Architected enterprise networked computing solutions have long been a strength of UNIX. This O/S has always enjoyed multivendor support. Robust implementations suited for commercial applications abound. The hardware that UNIX runs on is scalable; you can buy a low-cost workstation or a powerful high-availability networked cluster. Inherent support for multiple protocol stacks and services makes UNIX a major player in desktop integration solutions. With such depth and breadth, it is no wonder that architecting UNIX networks can be so challenging.

Now consider yourself in the following situation: You are preparing to meet your boss, the CIO (chief information officer), about the company's plans to install UNIX servers across the enterprise network. When the meeting is over, it will rest on your shoulders exactly how to architect the solution so that your team can implement it. Into the meeting you go, intent on plumbing the depths of all that this portends. Fresh coffee is poured, and you settle down to the interviewing task at hand.
You learn that your company has chosen a new client-server application to be implemented across your corporate network. Serious UNIX iron will run the database engines and application servers. Desktop computers will run the client software. Your job is to develop an architectural blueprint that will be used to implement the new application. The CIO wants a solution that is "able"-scalable, maintainable, upgradable, supportable, and reliable. A disaster recovery plan has to be developed, presented, and implemented. Naturally, the UNIX and desktop computers, the network printers, and existing productivity software such as Email collaboration tools all have to work together. You indicate that a comprehensive IP numbering plan has to be worked out, too, and, by the way, it's also time to design and implement a company-wide DNS system to support all these applications and systems. The CIO nods in understanding. You take another sip of coffee.
So far, so good, you think. But the company president wants customers to be able to send in orders and messages via the Internet. And why don't we put up a web site to let customers and prospects search for and download product information and download software updates, too? The CIO passes the buck to you. Then you're reminded that company orders are growing 30% annually. The training department wants to put in a UNIX video server so that they can deliver training clips via the network to any employee in the company. In the back of your mind, you ponder. You take another sip. Can the UNIX servers and the network handle it all? How much expansion can a UNIX network accommodate? What if the UNIX boxes run out of capacity? How can the IP and DNS configurations be worked out for the multihomed UNIX servers and the IP routers? You swallow another mouthful of coffee to stop the pain growing inside your head. The CIO sums up: we need a complete UNIX network architecture drawn up for a review session next week. The architecture requirements to specify topology, configuration, security, performance, and functionality. You agree, drain your coffee mug, and exit to ponder your next move.
Back in the sanctum sanctorum of your work space, one thing is clear. This is not a simple IP numbering problem. It's not jut about desktop computers using DHCP, WINS, or DNS. And performance will not be achieved simply by dropping ATM switches into the data center. Meeting reliability goals using multiple LAN adapters, backup servers, mirrored disks, and distributed DNS servers is a tricky business, too. In short, architecture is not simply a matter of forcing together a bunch of point solutions until you stumble across one that looks like it will work. You glance up at your bookshelf for a reference about UNIX and networking architecture .
If this is a situation you've been in, then this book will help you with the necessary architecture. We introduce desktop operating system integration issues with UNIX. Two- and three-tier architectures are covered. Special features of IP and DNS are explained in context. And we go into high-availability design methods. You will see example architectures for UNIX networking solutions in industries such as wireless, cable TV, manufacturing, utilities, and engineering. Applications such as SAP, Oracle Financials, Digital Video, X-Windows, NFS, and WWW are covered. We analyze these architectures, applications, and solutions for scalability, reliability, performance, manageability, and weakness.
Enjoy the read!



Reader Reviews
Maybe I don't have the background to appreciate the subtlety of the author's arguments; but it seems to me there is a great deal of assertion and not enough explanation. The author generally does not introduce or explain terms, including obscure acronyms (fortunately there is a good glossary). Often, by the time I have looked up the terms and acronyms and put the author's statement together for myself there is nothing left to understand - in other words it appears the author would be adding little value for a reader that actually has the knowledge he assumes. The index is generally poor and the text obviously has not had the editorial support it deserves. The author does cover a lot of ground and touches on many topics, and the book consistently addresses a technical professional reader. This book could have value as a resource or reference, as one member of a library; by itself it occupies an unusual middle ground, neither introduction nor deep discussion. Comment | | (Report this)