Designing for Scalability with Microsoft Windows DNA

Rating:
Summary: A disappointing book
Review: As an Internet programmer working with Microsoft technologies, I have had a hard time finding decent books covering Windows DNA in a practical manner. The problem is that a great deal of the distributed programming books either a) are all theory or b) have C++ examples to show the implementation of COM in the "real world". It is nice to finally have a book that covers the theory of distributed applications with examples in Visual Basic. "Designing for Scalability with Microsoft Windows DNA" is a lovely primer in Windows DNA programming for the Internet. Using technologies like MTS (NT 4), COM+ and XML, this book deals with some practical answers to real business problems.

There are a couple of shortcomings I find with the book, however. First off, I disagree with some of the XML methodology employed. Having built VB COM Internet apps using the IE5 XML DOM, I find much of the information presented is trivial. As it aims for the Intermediate audience, I find this shortcoming minor. The other is the push to use DHTML as the UI. In the current state of the Internet, this is not a real option. This may not be a problem with Intranet developers.

The coverage of COM+ is decent, but it would be nicer if more information was included on moving from MTS (Chapter 14) to COM+ (Chapter 16). I believe the assumption was that you would be using one or the other. As many "legacy" apps move to Win2K, this will not be the case.

Overall, this is a nice introduction to developing distributed COM and COM+ applications. If you are interested in more of the OO concepts that COM and COM+ are based on, the Microsoft Visual Basic Design Patterns book (also MS Press) is a wonderful work to complement the theory found here.

Rating:
Summary: Contains some interesting concepts but needs improvements
Review: I believe that this book does fulfill its title of scalability with DNA. Although I'll agree that the writing is somewhat easy at some places and at others, useless, but it's also a book that was published in March 2000 where it was among the first to touch the subject.

One of the funny area was that in the middle of the book, we are 'scraping' part of what we've done so far because of a 'design flaw'. Well it shows the ongoing environment of Business VB Development but at the same time, it was not really something I was expecting in a book.

Beyond that, it's at least worth 3/5 since there it does contains some interesting concepts even though it's a light read. It is definitely not a bad book but it could have some improvements. I did learn with this book and I will use some of those concepts.

Windows DNA (hopefully .NET soon) are pumping out right now, about Scalability, Security, and so forth, we'll soon be able to compare with the DNA/.NET new writers.

Rating:
Summary: The DNA Book For the beginner and intermediate VB Programmer
Review: I reviewed the book as a candidate for the textbook of choice in a VB training curriculum. I found the book to be most suitable to beginners and intermediate programmers. The book covers the architectural aspects of DNA by developing the concept step by step to derive the proper design. The methodology used through out the book enhances learning through an iterative design tuning process. A welcomed addition is the use of UML for modeling.

If you are an experienced VB developer you will be better reading "Professional Windows DNA: Building Distributed Web Applications with VB, COM+, MSMQ, SOAP, and ASP"

Rating:
Summary: A bit of everything
Review: I think it is a great book. It gives you an overview of a great concept to have in mind in these days.
Everyone should start learning Windows DNA with this book.
The book goes through many topics. Every one of them is very important. But you must have in mind that it is just the begining. Then you'll have to extend your knowledgement with more specific books in each topic.

Rating:
Summary: A fine, if superficial, overview
Review: It's a bit tough to decide just who this book is directed to. From its title, one would expect it to be aimed at the software architect. For the architect, its recommendations can be summarized as follows:
1. Define a 3 tier architecture with a GUI layer, a COM+ or MTS business services layer, and a database layer.
2. Place business rules in or as close to the database as possible.
3. Define objects by function, rather than state (data storage).
4. Release server resources (objects, db connections) as quickly as possible.
5. Move raw data to the GUI layer via ADO disconnected recordsets or XML data streams.
6. Divide the business services layer into "facade" objects (with which the GUI communicates), business objects (which enforce the business rules), and data access objects.
7. Divide data access objects into "fetcher" (read-only, no transaction) and "modifier" (transaction required) objects.

Items 3 and 4 summarize the principle message. In a sense, this view discards the OOP paradigm of objects as combining state and functionality. It moves them more in the procedural direction: the db holds the persistant state, the GUI has what it needs to display/manipulate/update the data, the middle layer connects the two, passes the state transiently between the two, and enforces business rules in transit. Objects are created, perform one operation, then vanish. They are "stateless."

My own prejudice, coming into a large scale project, was that maintaining state in objects (e.g. held by the ASP session object), to the extent that slow db hits could be avoided, would improve performance. The problem with this view is that those objects consume scarce server resources, and if they are not properly or promptly deleted when no longer needed - or if the demand simply exceeds the resource supply, they will - sooner or later - crash the server. Also, special effort has to be made to point a particular user session to the server maintaining his state, and coordinating multiple users' access to the same information. Stateless objects immediately permit multiple application servers, minimize server memory use, and mitigate the multiple access problem by moving it to the db layer.

I'm not entirely converted to the "stateless" faith, but I'm convinced that the problems of stateful objects are real, and at least need to be carefully considered in the design. This book is the gospel of statelessness.

Ok, that's the architectural content in a nutshell. The rest (90%) of the book is consumed with implementation details. In passing, some design trade-offs - such as where to locate data access objects, are touched on. Along the way, we see how to use Rational Rose to structure and document the design, and speed code development. Since this is a Microsoft Press book, MS Visual Modeler (a Rose clone) is also given its due. XML gets a chapter's intro, and SOAP gets a very brief one. Mostly, the conveniences of ADO are featured including heirarchical recordsets and ADO 2.5 support for the XML DOM. The basics of MTS and COM+ are covered, and many useful developer do/don't tidbits are supplied. Alas, error handling is virtually ignored, and ASP is hardly mentioned, although DHTML rates a nice, if brief, chapter. In summary: it's a light but valuable read. Spend a day or so reading it; you won't regret it.

If you're already a software architect, then most of the implementation details are either well known or irrelevant to your job. If you're a developer, some are familiar and others new - depending on your speciality and experience. Perhaps the real audience for the book is developers who are architect-wannabe's, or need a roadmap of the technologies so they can understand what the other members of the team are doing, why the project is structured as it is, and what they need to learn to do their piece of the job right.
As such, it's excellent. It is clearly written, with one simple but illustrative example followed throughout, and maintains a gentle sense of humor. If you're looking for in-depth treatment of any of the various technologies, or a careful study of architectural tradeoffs, this book will disappoint.

Rating:
Summary: A fine, if superficial, overview
Review: It's a bit tough to decide just who this book is directed to. From its title, one would expect it to be aimed at the software architect. For the architect, its recommendations can be summarized as follows:
1. Define a 3 tier architecture with a GUI layer, a COM+ or MTS business services layer, and a database layer.
2. Place business rules in or as close to the database as possible.
3. Define objects by function, rather than state (data storage).
4. Release server resources (objects, db connections) as quickly as possible.
5. Move raw data to the GUI layer via ADO disconnected recordsets or XML data streams.
6. Divide the business services layer into "facade" objects (with which the GUI communicates), business objects (which enforce the business rules), and data access objects.
7. Divide data access objects into "fetcher" (read-only, no transaction) and "modifier" (transaction required) objects.

Items 3 and 4 summarize the principle message. In a sense, this view discards the OOP paradigm of objects as combining state and functionality. It moves them more in the procedural direction: the db holds the persistant state, the GUI has what it needs to display/manipulate/update the data, the middle layer connects the two, passes the state transiently between the two, and enforces business rules in transit. Objects are created, perform one operation, then vanish. They are "stateless."

My own prejudice, coming into a large scale project, was that maintaining state in objects (e.g. held by the ASP session object), to the extent that slow db hits could be avoided, would improve performance. The problem with this view is that those objects consume scarce server resources, and if they are not properly or promptly deleted when no longer needed - or if the demand simply exceeds the resource supply, they will - sooner or later - crash the server. Also, special effort has to be made to point a particular user session to the server maintaining his state, and coordinating multiple users' access to the same information. Stateless objects immediately permit multiple application servers, minimize server memory use, and mitigate the multiple access problem by moving it to the db layer.

I'm not entirely converted to the "stateless" faith, but I'm convinced that the problems of stateful objects are real, and at least need to be carefully considered in the design. This book is the gospel of statelessness.

Ok, that's the architectural content in a nutshell. The rest (90%) of the book is consumed with implementation details. In passing, some design trade-offs - such as where to locate data access objects, are touched on. Along the way, we see how to use Rational Rose to structure and document the design, and speed code development. Since this is a Microsoft Press book, MS Visual Modeler (a Rose clone) is also given its due. XML gets a chapter's intro, and SOAP gets a very brief one. Mostly, the conveniences of ADO are featured including heirarchical recordsets and ADO 2.5 support for the XML DOM. The basics of MTS and COM+ are covered, and many useful developer do/don't tidbits are supplied. Alas, error handling is virtually ignored, and ASP is hardly mentioned, although DHTML rates a nice, if brief, chapter. In summary: it's a light but valuable read. Spend a day or so reading it; you won't regret it.

If you're already a software architect, then most of the implementation details are either well known or irrelevant to your job. If you're a developer, some are familiar and others new - depending on your speciality and experience. Perhaps the real audience for the book is developers who are architect-wannabe's, or need a roadmap of the technologies so they can understand what the other members of the team are doing, why the project is structured as it is, and what they need to learn to do their piece of the job right.
As such, it's excellent. It is clearly written, with one simple but illustrative example followed throughout, and maintains a gentle sense of humor. If you're looking for in-depth treatment of any of the various technologies, or a careful study of architectural tradeoffs, this book will disappoint.