Author: Alessandro Federici

Windows DNA multi-tier: a service-oriented approach

Answer:

Introduction

The Windows platform comes well equipped with a set of tools that permits the 
creation of scalable distributed systems, multi-vendor database access, load 
balancing and high level of security. All these techologies are commonly grouped 
under the name Windows DNA (Distributed iNternet Architecture). COM+, ADO, MSMQ, 
SOAP and XML are some of the core technologies on which a Windows DNA system is 
built upon.

In this series of articles I will analyze each of those technologies and try to 
demonstrate how you can practically use them to build multi-tier systems. I will do 
this by using an real life, A to Z example which is not too complex but neither too 
easy. My goal is to provide the reader with an understanding that goes beyond the 
hot technology topic of the day. It won't be only about SOAP, it won't only explain 
how you remotely access a COM object trought SOAP, it won't only show you how to 
parse an XML document.

My primary goal is to show how you can use all these technologies togheter to solve 
a business problem in a practical, efficient and easy-to-maintain manner. It will 
be more about design than implementation. I will show you what I learnt during 
years of practice, the design I prefer and sometimes I will also go against some of 
the teachings that are spread over the net about design patters and so called 
"correct" object-oriented designs.

The second goal I have is to demonstrate that in order to build enterprise-ready 
distributed systems you don't need to spend hundreds of thousands dollars like some 
companies would like you to belive. Specifically I will only use 3 products: Delphi 
6 Professional, Windows 2000 and SQL Server 2000. Delphi 5 Professional could be 
used as well but you will need to translate my examples with whichever ADO 
component set you are using or, in case you are using Delphi 5 Enterprise, you are 
ready to go. Interbase could be used instead of SQL Server as well but there are a 
few issues that would make your life more complicated.

But what matters are the principles. Almost any technology can get the job done . 
The difference is how you prefer to do it.

A final note: this series of articles will be a big effort for me given the tied-up 
schedule I have like the rest of you. I cannot promise *when* these articles will 
be completed nor they will. The only thing I can promise is that I will do my best 
to finish the job.

The golden rules

We live in a world in which practically time-to-market is more important than 
quality. It is simple to understand why. If you don't get out there soon-enough, 
somebody else will. Then you can have the most beautiful system ever made by human 
kind but you won't make a penny out of it.

But obviously if your product is not well thought or too many corners have been 
cut, you may end up spending more in maintenance than in adding new functionality. 
The result may be even worse than not having sold the product in the first place: 
in top of not gaining you will end up with a ton of tedious work to do, nasty 
attourney's threats to dribble and a frustration level that spreads as quickly as 
an epidemic disease.

So what's the solution? Well, if you ask me, the solution is to follow a very short 
and general list of principles:

Understand the big picture 

Keep it simple: only do what's required but have a good-enough understanding of 
what's coming next 

Don't get fooled by hype 

Don't overspend nor underspend money 

Be ready and happy to refactor code

If you have read books about Extreme Programming or have heard about the Agile 
Software Development you should see many similarities. Take a look at Manifesto for 
Agile Software Developmenthttp://www.agilealliance.org/principles.html if you are 
new to this. It's eye-opening reading material in my opinion.

I am not an advocate of XP or Agile methodologies. I think all past, present and 
future methodologies have some value. At the very end the perfect approach is a 
personal decision that should be based on common sense and understanding of the 
situation in which we work in rather than "infallible" thomes of paper.

A simple business scenario

Imagine you are asked to build a warehouse management system. The system will need 
to do a number of things:

Return a list of customers of the warehouse 

Allow the user to insert new customers 

Return a list of orders and the details of each of them 

Insert a new order 

Return an inventory of stored items

I call each of these subfunctions a "service". Each service does one thing and one 
thing only. A service can either:

Read data 

Write data 

Invoke a series of other services to do something (workflow )

Now, what's important to us is how you design and implement these services. There 
could be many different ways to achieve our goal.

Best of breed OOP or pure RAD?

Some people advocate having an class for everything. For instance an order would be 
a class and each item in the order would be wrapped in another class. The header 
and the footer will be other classes as well along with a collection class that 
holds all the items togheter. And then why not, let's make the customer a class as 
well, it's address another one and so on... Where does this end? Probabily when the 
budget for your product ends and you are out of business or when you start taking 
shortcuts and everything falls apart because you are mixing approaches.

OOP is good. OOP is your friend. There are no objections to this but balance is in 
my opinion a better friend.

Delphi (or Visual Studio or the .Net framework for that matter) provides us with a 
number of very useful classes that have a clear objective: minimize our efforts and 
help us building maintainable systems. The first object that comes to mind can be 
the Borland TDataset or the Microsoft _Recorset. Those are great classes but at the 
same time they are very dangerous. They can help you build systems at lightening 
speeds but if not used properly they can generate so much chaos and mess that will 
make you wish of getting another job or finding another company.

I am making a joke out of this but this is a serious problem and probabily each and 
everyone of you witnessed the results of this at least once.

Perfectly engineered OOP projects cost a lot of money. The amount of detail that 
has to be put in up-front design is tremendous. This doesn't mean you should just 
start coding from day 1 or avoid doing such things. It means that practically few 
companies can afford it done right. Quite honestly, there's an big amount of risk 
involved in trying to figure out all the factes of a system before starting to 
implement it. It's a life fact: customers always change their minds and never know 
what they want.

At the same time starting beliveing that the OnClick or the OnBeforePost is the 
solution to the world's problems will put you in even more serious trouble.

What I hope I will be able to demonstrate is that there's something in between the 
two approaches that is much more effective, cost-effective and realistic. It's what 
I call a "service-oriented approach".

In the next articles I will try to define the architecture of our sample system and 
define our goals. I will discuss about server clusters and web farms, about stress 
testing, about quality assurance, COM+, security, transactions and databases plus a 
lot more.

Well, stay tuned and keep an eye on other articles that may come in the meantime!