Author: Alessandro Federici
Windows DNA multi-tier: a service-oriented approach
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
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:
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
Well, stay tuned and keep an eye on other articles that may come in the meantime!