Distributed

Well organized, complete, nontrivial, wealth of sample code, interesting historical notes, good index. Magnificent work. Definitely worth the money.

For nearly a decade this book has been the definitive reference on transaction processing. Although the more recent, May 2001 book titled "Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control" by Gerhard Weikum and Gottfried Vossen will probably supplant this book as the standard reference, there is still much material that makes this book useful.

In particular, this book covers the following topics in more depth than the newer boom cited above:
- Fault tolerance and availability, both topics are covered in depth from hardware and software perspectives. This is unique for a book on transaction processing in that most books on the subject confine their scope to software and databases.

- A wide and complete survey of transaction models. True, some of this material is about models that are falling into disuse, but the value is the way the authors go deeply into the mechanics. I've always felt that this part of the book is the most valuable because the principles can be refactored into hybrid models. Moreover, comparing this material with the newer book by Weikum and Vossen shows that these principles are still employed in today's TP solutions.

Material about transaction processing monitors is obviously out of date, but, like the TP models, the principles still apply to contemporary systems. My recommendation is if you are going to buy a single book on the topic get the Weikum and Vossen I cited in the first paragraph. However, if your budget allows, I also highly recommend this book as well because of the depth in which fault tolerance and TP models are covered. If you want to just learn the basics of TP I recommend that you consider "Principles of Transaction Processing" by Philip A. Bernstein and Eric Newcomer because it is less daunting than this or the Weikum and Vossen book (both of which are 1100+ pages).

I used this book as a CS grad student in college
for a class on transaction based systems and it covers
how to do transactions from top to bottom. Although
it was published in 1993 the techniques described in this
book are actually more advanced than techniques
used in a lot of real world systems today so it is not
out dated. I have yet to see a book as comprehensive as
this on how to actually implement transactions. Good
book for software engineers to read. My only complaint
is that the book has a lot of typos and some bugs in the
source code listings. Also because the book is so damn big
(i.e. lot of pages) they chose to use very thin paper which
makes it not very good for using hilight markers on. Still
this is the definitive book on how to implement transaction
processing.

This book is really good.It gives clear picture of software developement methdologies. I really enjoyed reading this book.This will be my one of the favorite books.

I thoroughly enjoyed reading Roger Fournier's book. I am a voracious reader with many books on Client-Server, Web technology, systems development, etc.; however, Mr. Fournier's methodology is a welcome addition to my library. This may be the most practical book that I have seen for systematically approaching the development of complex systems. I plan on incorporating much of his methodology and ideas in my future projects. I would recommend it for anyone interested in learning about client-server or web technology and it is a great reference for professionals involved in project development (both large and small).

I am encouraged by the books honesty in stressing that building large systems is hard work. Too often the literature touts "sure-fire" success if you follow a particular "cook book" sequence or employ specific technology. As anyone in the business knows, good preparation, realistic goals, teamwork and attention to detail are more important than choosing the latest "hot" technology. The book walks through the stages of a projects life cycle and provides much "food for thought" in how to get each stage right. But it never deceives one into thinking the process is easy and it never implies that the proposed methods are the only logical approach to take.

Although the title focuses on C/S and Web Application development, the methodology presented has a much broader application. It provides an excellent framework for development of any complex system. The book is well written. It provides broad coverage from requirements discovery through project deployment. The book contains so much information that the reader may want to focus on specific areas of high personal interest at first- such as Web architecture or systems analysis. Fortunately, Mr. Fournier's style is such that you can concentrate on the chapters that are most relevant to your needs first and later read the other sections without a significant loss of continuity.

As an Enterprise Architect, I have found the book very helpful. It contains useful information for project managers, enterprise and system architects, analysts, developers and test engineers. Without going into details I'll say that the tables, checklists and web-references presented throughout the book have been very useful.

I believe the survey, analysis and joint facilitated session chapters are well presented and offer a lot of information on project definition and scoping. They certainly make clear the importance of up-front planning to a projects success. For my purposes, the C/S and Web Architecture chapter was of high interest and was well presented. I was glad to see a chapter devoted to software re-use. However, I would like to see this chapter expanded to include more information on infrastructure, middleware and components. I would recommend anyone interested in the book to quickly scan the table of contents to see the wide range of information that can be found.

Mr. Fournier mentions that there might be a follow-up book focusing on the project management aspects of building complex systems. I sincerely hope he writes this.

Excelente para el desarrollo de grandes proyectos tanto en Web como de todo tipo de sistemas.

Very practical, helpfull and easy to follow book. What is more important it gives you possibility to easily make your own templates for analysis and design.

Easy to read and understand. Good and practical methodology. Cover most essential parts of Software Analysis and Design.

I agree with every words that printed on the back cover i.e. the analysis and design techniques that really work.

I have read this book three times, and each I learn something new. It is nice to have a book that is independent of any development platform, and in PLAIN ENGLISH to boot. This book is more valuable than the course I had taken in college.

This book is for people who want to be productive. It is not for people who like sitting in all day meetings trying to come up with the CUTEST idea.

To get a straight forward answer on associative entities/relationships was like a breath of fresh air. I was told once that you should never have to use association tables. You should maintain the integrity of the database via code - yeah right.

I have recommended this book to every developer I know. This book should purge your mind of every piece of useless information that anyone has ever told you on how to approach building and designing applications.

I found this book very helpful as I was developing a paper on improving performance for my company's enterprise application. It is the only book I could find that generically dealt with the techniques for designing applications with performance in mind. It covers a broad range of topics explaining the causes of performance problems and possible solutions. I particularly liked the realistic view of a "distributed" architecture which is a hot topic. I did have some problems relating to the "standard" architectures presented; none of them exactly matched the current popular standards like J2EE.

Now that client-server is mainstream, it is OK to knock it. Specifically, performance problems arise with enterprise client-server systems due to the complexity of the distributed processing. The more hops between platforms, the more overhead, and the more points of failure. Client-server architecture is inherently distributed and often has to occur across multiple platforms connected by skinny wide area network (WAN) pipes. What can help? This wide-ranging diagnosis and treatment of the many aspects of the dilemma is highly recommended for its extent, depth, humor, and penetrating insight. Part One on performance fundamentals list 23 components of response time, offering incisive distinctions for both the beginner and the advanced practitioner. When cross-referenced in the extended application resource usage matrix to identify bottlenecks, these components become powerful drivers of response time tuning using trade-offs, choices, and priorities to squeeze every once of performance out of the available computing configuration. Part Two treats the software performance engineering process. One important goal is to build a performance model out of the hardware/software environments, application flow, data structures and business factors. In addition to complex interrelations of computing components, Loosley provides pointers to some very simple principles and methods for tuning complex systems. Part Three on principles is the heart of the book. Software engineering principles - formality, completeness, simplicity - provide the foundation for design principles of abstraction, decomposition, and information hiding - which, in turn, support refinement, independence, and localization (p. 207). These are explained and applied in sufficient depth and detail so that practicing performance engineers will find both helpful tips and techniques, amusing anecdotes, and theoretic principles. Queuing theory is explained but not treated mathematically other than the marshaling of a few simple metrics of practical interest. With the emergence of parallel processing as a relatively new candidate solution for decision support and data warehouse applications, the Chapter on The Parallelism Principle contains one of the best concise explanations I have seen in the literature of the differences between massive parallel processing, non-uniform memory architecture, and clusters as a processing resource. Part Four on Applications drills down into middleware and performance. The authors argue the concept of logical unit of work transaction management is sound and well proven in the world of host-centered (i.e., mainframe) computing. However, when the architecture of synchronous communications is transferred to distributed client-server, then problems arise. As soon as one of the multitude of processors waits, the entire system is at risk of log jamming. And since all computers wait at the same speed - both a humorous and sobering anecdote called "Bell's Law" - no amount of souped up hardware or software will make a difference. The authors document at least twenty points in which enterprise client-server - that is, three tiered - systems can experience bottle necks. The problem with client-server is that frequently only the database and the client workstation are suitably instrumented to gather performance metrics and data; and, even then, it is the interaction between the component that is most significant, not what goes on within each taken in isolation. Therefore, there is no easy answer. The bottlenecks must be worked and pushed down stream and squeezed out of the system. However, in the view of the authors, what will make a difference is a high performance architecture built on a form of asynchronous multi transaction workflow using decoupled processes (sometimes called "message-queuing" or "MQ" middleware). This is a major conclusion for which the authors argue persuasively in the climatic Chapter 16 on Architecture for High Performance. Part Five on Technologies looks at the inner workings of relational database management systems, transaction managers and monitors, and data warehousing technologies such as OLAP, ROLAP, and multidimensional data analysis (MDA). The availability of this material rounds out the completeness and comprehensive scope of the treatment provided. The authors set a high standard for collecting insightful and humorous one-liners, with proper credit to many other brilliant contributors, which also cut to the heart of the challenges of delivering performance in a client-server environment. "Software workloads expand to consume the available computing capacity" (p. 11). "There is nothing so useless as doing with great efficiency what should not be done at all" (p. 80). "Always work on the biggest bottleneck" (p. 113). "If you can't see the bug, you are looking in the wrong place" (p. 333). These zingers kept me returning to this text time and again. The book contains a rich assortment of illustrative and instructive graphics. The figures and tables are superbly drawn and produced in attractive gray scale. The performance guidelines - and as benefits a thorough compendium of over 700 pages of encyclopedic proportions - are separately listed at the back in a voluminous section of over 500 entries, extensive enough to be designated as Part Six. Given the challenges of mainstream client-server, Loosley and Douglas are like the cavalry to the rescue with a comprehensive and richly-ladened resource of distinctions and methods for understanding, addressing, and resolving the dilemmas faced by those tasked with building and managing distributed client-server. -- review originally submitted to Computing Reviews in 1998 -- but the good folks there already had someone else reviewing the book, so they decided not to publish it

This book should be required reading for all professional software systems engineers and software development engineers. It is an outstanding overview of the performance engineering discipline as it applies to client/server architectures. I am a practicing systems performance engineer with 20 years experience--10 in development and the last 10 in systems engineering. Many of the things I've learned through "experience" are included in this book. It is definitely worth the money.There is only one area which is not addressed in the book--how to apply SPE to one-of-a-kind complex multiprocessing/multitasking shared resource systems development which are without precedent (as far as I know this is not addressed anywhere in the literature). Such systems do not lend themselves to the preassigned quantitative software budgets required by the literal application of SPE. But because I am major proponent of designing in flexibility and performance all the other SPE principles certainly apply. Again, I highly recommend this book.

Not a beginner's book: The technologies presented are relevant to (gasp) some real life problems. The treatment of Distributed Constraint Satisfaction problems was well written and usable. The initial treatment of all subjects was broad, delving into details after laying a sound foundation. Assumes a bit of mathematical sophistication on the part of the reader, but on the whole, well written, well organized and well worth it.

While perhaps this should not be your first book in AI, it should definitely be your first book on agents. It took me years to accumulate the knowledge present in this book, and it's a great survey of the field for the beginning investigator. However, while this is a great way to get started in agents, understand how agents can be used in intelligent applications (from distributed AI type problem solving, to resource optimization problems), and "get the agent paradigm," coverage of agent software engineering techniques is light. This is not a fault of this book - you will simply need other resources to understand the difficulties and current research in engineering multi agent systems (or indeed any concurrent distributed system). So if you are trying to figure out what to do with agents, or how agent systems work, this is the book for you. If you already know that and want help with formal specification of an agent, verifying your agents meet the specifications, etc. this is not the book for you. Understand that to build systems you will need both!

I have been using this book probably for an year now, and this has become indispensable to my work. The collection of authors in this book reads as an 'who's who' in multiagent systems and distributed AI research. Although, its' difficult to maintain continuity in edited books, the editor has done an commendable job. The authors provide a readable introduction to their area of expertise, and supplement them with an excellent bibliography...enough to get u started fast.

COM is built on top of RPC. This book is a bit dated, but still a good guide for learning the technology that COM is based on. COM will make much more sense if you take a little time to learn RPC first.

using a microsoft rpc interfac

using a microsoft rpoc interfac

A good book for high level description of the structure of Sybase System 11. When concerning details, there are many places the explanations are confusing. Pretty often two or more contradiction view of points appear in the same page. Considering the lack of good Sybase books, I would like to give this one a favorable recommendation, but don't expect too much.

I've got more than 30% improvement in my Server , After reading & use the concept which is describe in this book

This books gives an insight into sybase internals and how to get the best out of your server. The material on locking included in this book is one of the best I have seen so far.

At MIT, I took the course 6.852 Distributed Algorithms under Professor Nancy Lynch. It was an excellence course. This books is based on her lecture notes. Before this book, there is really no book that covers these material in rigorious and consistent matter. One usually have to read the actual published academic papers. Because different author may use different notations or models, sometimes it is hard to see the whole picture. This book shows exactly that. The algorithms are presented in a consistent notation, and the models and the assumptions all the explicit, clear and consistent. However, Professor Lynch's lecture style can get really dry and boring, sometimes I can't help felling asleep because the class was so early in the morning. For that, I decided to give it only 4 stars.

Professor's Nancy Lynch's "Distributed Algorithms" is a definite reference for theoretical treatments of many hard problems in distributed computing. It is a textbook, but written in such a clear style that makes it almost a pleasure read. Rarely have I seen something like that! The book has a right proportion of theoretical proofs, practical applications, philosophical appreciation of the problems, research questions, examples and study points.

"Distributed Algorithms" has 3 main parts - synchronous, asynchronous and partially synchronous network algorisms. Each part describes consensus resolution, mutual exclusion, resource allocation, leader election, termination detection and failure detection as main problems in distributed computing theory. Lynch has done a masterful job of leading us from simple to complex, from theoretically solvable to practically intractable problems.

For a practitioner of computer science, who is not necessarily involved in fundamental research, this book gives a clear appreciation of problems of 2PC, resource management, failure profiles in faulty and noisy networks, optimization and fault management in distributed networks. All those things are foundations of databases, network computing and enterprise scalability. It also helped me greatly in estimating the best and worst case boundaries in certain practical distributed system optimization problems.

This book is in the same class as "Discrete mathematics" by Knuth and others. Important topic, extensive coverage, good English, zero vendor's propaganda. Super. An unexpected gift from up above (after struggling with reams of MS's (dis) information .) I am working on something distributed and ran into this book accidentally, while browsing in a bookstore--I'm glad I did. Btw, it's a few bucks cheaper in B&N store (here goes my review .)

This is a book on Knowledge Workers, and on business management, actually. It does discuss industrial age and post-industrial age workers, but it's not so much about industry, industrial workers, and modern factory automation.

The sense I came away with is that the aim of the authors was on making work teams more effective. However, for me, the book gets back to a more fundamental issue, the possibility of effectively eliminating levels of management in any organization. This is done not just by eliminating some staff, and giving the remaining staff communications. On a superficial level, automation of information access and communications for today's knowledge workers is required. However, on a more fundamental level, this is done by the assumption of a greater degree of the responsibilities by Knowledge Workers.

The book does get to the nub of flat (empowerment) versus hierarchical (delegation) management styles, which has come about with downsizing and the advent of empowered workers. It discusses how to manage processes and people with fewer managers, by enabling them to gather and use information and make decisions. Most importantly, it prioritizes: responsibility, empowerment, the management of processes, the management of people, management styles, downsizing, and information sharing. They all go together, but some of these are ends, and others are only means to an end. Further, some of these means to an end are prerequisites and others are only facilitators.

Whether tasks are delegated one-at-a-time to individuals (hierarchical), or projects and processes are turned over to a work-team (flat), in both cases communications is required. However, the differences today, are that Knowledge Workers in empowered organizations: are on multiple teams, not having just one job to do; must communicate with all team members, not just with supervisor and immediate coworkers; are responsible for the entire job, not just for one aspect of it.

Without proper orientation by management, Knowledge Workers in empowered work teams can remain focused on technical skill development or on information sharing, as ends unto themselves, or on doing their narrow tasks. What could be missing is a focus on the success of the process or project, and on the achievement on the goals of the organization. In the absence of middle managers, whose job it was to not only manage workers, departments, and processes, but also to focus on the goals of the larger organization, empowered Knowledge Workers must assume a large share of these responsibilities.

Team members must understand firstly, that responsibilities have been thrust upon them, and secondly, how to carry out these responsibilities as a self-directed work team. Today, we're not just providing communications systems to workers. We are holding people responsible, and therefore we're providing them with communications systems.

"This is the age of knowledge work. It is the age of the smart worker. The operations that learn the secret of tapping into this knowledge will always outperform those that do not. Those that master the 'collective intelligence' of knowledge work teams will be the architects of the future...As individuals, knowledge workers are smart people. But their individual effectiveness is amplified when they are also part of a smart organization. As an effective knowledge team, they can often create a sort of synergy where the outcome of the whole is greater than the sum of its individual parts. These smart teams appear as though all team members are of a common mind that shares information and ideas seamlessly across the membership-a distributed mind...This book is about knowledge work teams. Knowledge work requires a special set of skills related to an area of expertise, such as those of an engineer, a salesperson, a consultant, a manager, or a health-care professional. But it requires much more than technical competence to be successful as a knowledge worker" (from the Introduction).

In this context, Kimball Fisher and Mareen Duncan Fisher:

* define knowledge work by comparing five characteristics that differ for physical and knowledge work as follows:

- Job Characteristics: (1). Core task, (2). Critical skills, (3). Work process, (4). Work outcome, (5). Knowledge used.

- Job Characteristics of Physical Work: (1). Doing, (2). Physical, (3). Usually linear, (4). Product, (5). Applied.

- Job Characteristics of Knowledge Work: (1). Thinking, (2). Mental, (3). Usually nonlinear, (4). Information, (5). Created.

* argue that "the nature of work is changing from mostly linear to mostly nonlinear and from requiring mainly physical skills to requiring mainly mental acuity. Jobs now usually produce more information than product and require more improvisation than rote, automatic application of process. While this trend is dramatic in a few cases, for most of us the change has been a slow, steady evolution of our jobs", and illustrate this trend.

* show how teams and team-based operations differ from groups and non-team-based operations, and illustrate how these teams differ from the traditional organizations by comparing hierarchical organizations with team-based organizations as follows:

- Hierarchical Organization: hierarchical order, local optimum, maximum specification, functional defect control, specialized skill, vertical information flow, work ethic value, and conservative improvement.

- Team-Based Organization: information order, global optimum, minimum critical specification, source defect control, multiskilled, source information flow, work life value, and continuous improvement.

* illustrate the differences between physical and knowledge work teams by comparing typical physical work teams with knowledge work teams.

- Typical Physical Work Teams: physical labor, multiple generalists, inside single organization, fairly stable membership, and repetitive responsibilities.

- Typical Knowledge Work Teams: mental labor, multiple specialists, across multiple organizations, shifting membership, and single-purpose responsibilities.

* explore the process of knowledge work design, and illustrate the characteristics of evolving organizational form-learning lattice organization.

* discuss the metaphors and practices needed to create successful knowledge teams.

* argue that "environmental shifts and changes in organizational capabilities have created opportunities and need for virtual knowledge teams in contemporary organizations. To effectively create, utilize, and support VKT's, we must focus more attention on the VKT challenges", and then discuss the challenges of making VKTs effective.

* discuss fostering innovation and creativity as a critical challenge for knowledge work.

* discuss what is becoming a critical attribute of effective knowledge work teams: the ability to transfer knowledge effectively without causing information overload.

* discuss the role of leaders in knowledge teams, and argue that "in knowledge work teams, team leadership is critical. Although this formal leadership is often shared or rotated, we believe it must be done properly for the team to be effective".

* discuss a number of practical tips to prevent illness in teams, including providing team training, integrating new team members, setting goals and measuring results, understanding group decision-making processes, managing team conflict, building team communication skills, giving and receiving feedback, defining team members' roles and responsibilities, developing operating guidelines, and creating a team charter.

* explore how technology aids knowledge work, and argue that "technologies must be appropriately integrated into the organization if they are to benefit knowledge teams. Three particular problems to avoid are technology misuse, expecting more from technology than it can reasonably deliver, and serving technology instead of having technology serve the team".

* discuss future trends in knowledge work by illustrating six key work trends for the new millennium: (1). automation of physical work, (2). elimination of traditional jobs and work structures, (3). empowered knowledge workers, (4). knowledge work teams predominant, (5). workplace flexibility, (6). more virtual knowledge teams.

Strongly recommended.

The T-word, team, has been badly devaluated during the last few years. People talk about teams without really understanding, what they actually are about. No wonder some people react with cynicism when their CEO returns from a training seminary with the word Team on his lips.

There is a solid case for this book that addresses teams, especially knowledge work teams from a practical no-nonsense perspective. This book makes good reading not only for knowledge work team builders but also for the people that actually make up the teams. The language and structure is exceptionally readable and the issues are easy to grasp. Someone might even say that Fishers use too many cases to justify their points. Fishers start with discussing knowledge work, then teams and finally knowledge work teams and finally building a working organisation made of knowledge work teams.

Fishers do not limit their perspective to teams and organisations but discuss also their influences to societies and individuals. Teams do not work in a vacuum but change the way people work and think and live their lives.

The one thing that I disagree with is they way Fishers create an artificial (in my opinion) distinction between physical work and knowledge work, and the consequent physical work teams and knowledge work teams. Fishers stress the point that even knowledge workers do physical work and physical workers do knowledge work, but within their definition of knowledge work!

This book goes into more detail about IDL than most people care about. However if you start wondering why your interface is not being properly marshalled, knowing your IDL will save you from scratching your head in biwilderment.

If you dont want any surprises from COM marshalling this is the book to get. Even in the .NET world, this book will be useful. All the COM components out there today are not just going to go away.

Forget about class factories and such...
The real issue in COM is type libraries and proxy/stubs and how these are created using IDL. Also of great importance is designing COM interfaces so that they may be utilized by VB and C++. This is a one stop reference for all that good information.
If you program COM, buy this book. It will pay for itself in minutes.

This is a great book that teaches you how to design and develop COM interfaces that work for C++ and VB clients and also explains the intricacies of the Interface Definition Language.

Even if you use COM at a higher level - ATL wizards, VB wizards and dont really write your own IDL file, you need to read this book to get an understanding of how you can do write even better COM clients and servers.

One thing i wish it also had is information about accessing these COM classes from VBScript.