Windows DNA multi-tier: a service-oriented approach

Problem/Question/Abstract:

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 Development 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!