Using XML and tiered solutions

Links:

Design patterns

UML 1, UML 2

XML Programming with VB and ASP

This article uses a few diagrams and concepts from one of the chapters in the the book XML Programming with VB and ASP.  This article is only a very simple and short discusion of the logic in building 3 tier solutions with XML.

Together, the images on this page are over 100k so you may have to wait a few seconds before the page completes loading.

Simple 2 tier application

The UML sequence diagram below shows a typically simple 2 tier application.  The front end (VB or ASP) calls the database directly.  Any change which need to be made to the program must be rolled out to every front end (if you are using VB) or all the ASP pages on the webserver if you are using ASP or webclasses.

Simple 3 tier application

Now we step up a level, by moving the logic out of the VB or ASP or webclass application and into business objects (BO) on MTS.  This provides more scalability and better performance because ASP is not compiled while the BO DLL is compiled.  At this point many developers walk away feeling well chuffed that they have managed to develop the application.  But there is more that can be done to prepare your application for the future and for reusability.

Simple example of providing reuse and using some simple design patterns

In the example below, the ASP page (or VB or webclass app) calls the business object as per the previous example, but this time, the BO doesn't know anything about the database.  Therefore it is not hard coded and when you change the XMLParser - the system is upgraded everywhere.

As implied, the XMLParser is also aware of the different "registered" BO (another design pattern which provides for BOs to be registered and unregistered which is called the "observer" or "listener" pattern).  Now each BO can use the generic XMLParser and the XMLParser ensures their XML requests for data are serviced and replied to in XML.

The value of the transaction being in XML is that the communications can be versioned (by using namespaces intelligently) and provided the communicating partner uses the schemas correctly the XMLParser can check for validity and assume the communicating object's data is kosher.  XMLParser will now fetch the required data (from where ever, using OLEDB or BizTalk or against a mainframe)and will return the data to the participant.

(In the book, we also talk about using interfaces, which provides even more reuse and interoperability and lowers your cost of maintenance and even of development!  Interfaces mean that XMLParser knows EXACTLY what methods are available in the participating objects because those objects have implemented a standard interface)

Having said all of that, it can be reduced to this simple sequence diagram.

Distributed programming

Now building on the above, what if we want to have offline applications?

Taking a look at the sequence diagram below, we can see that we would publish a kind of interface is our ASP (or webclass) and have our VB app use the HTTPRequest object (which comes with IE5) to communicate with the ASP page.  XML would be an ideal communications stream, for the same extensibility reasons as is with the XMLParser and it's participating objects.

Taking it to the max with design for the future

OK, so given the distributed design above and since we (probably) agree that details such as databases (or more accurately "data sources") shouldn't be hard-coded, let's break that bit out of the client side VB app into it's own communications object on the client side, which will take care of "finding" the data our system needs.  And the rest is history.