Architecture that works well for web application development…
3-tier architecture, n-tier architecture is the commonly used words in today’s world and each of them have a different story on how they achieved isolation of various layers. I have been doing many experiments on this and several POC’s were established, but I could never make a POC that worked the way I wanted…
During one of my discussions with a company interviewer, I was asked “how can you decentralize the business layer, thus enabling multi-server hosting” using .net. I was shocked for a moment on how to answer this. I thought for a while and told him that “hey I have not attempted this but it is definitely possible by using web services effectively for inter-module integration”. The next question was “How”, I paused for a while and told him, well I will plan my modules in such a way that objects with higher interactions will be grouped together and each groups will be interacting with each other using WS, thus enabling multi-server’s. Again “okay, give me an example”, the only think came to my mind was the message queue service which is a reasonable answer (I read about the mail queue architecture on web the previous day).
Frankly speaking the same old repeated explanation came to my mind, “business logic layer is a layer that contains an application ‘business logic’ and is stuffed between a persistence layer & presentation layer”.
I was not sure whether my answer was correct at that point of time, but it was definitely wrong for the interviewer as the job was never offered :)
The above incident made me think more for sure. I wanted to crack this and was ready to put in more time to find a solution / approach. Finally I have something to share with you all, now it’s up to you all to comment on this with your thoughts…
The main idea was to use XML/XSLT, of course we all know that it separates the presentation from the business logic.
I see many advantages in this approach.
a) You don’t have to re-invent the wheel again, since the reuse of business logic code will be reliable and faster
b) You don’t have to tamper with any code at the business layer to take care of your branding, look and layout
c) The designer – developer idea exchange / dependency is always a fight (DIV is the best, No html is the best), the dependency here is very less
d) The testing cycles can be restricted up to interface level
e) The validation can be controlled at XML level hence no need to touch the code even for validation changes. Validation here refers to the field level such as First Name, Last Name etc
The disadvantages I can think of below
a) You will not be able to use VS up to the extend you are doing now
b) Since the Ajax control tool kit is not fully reliable you many have to use a normal way, if you are looking for a google style
c) XML cache issues along with the mixed content will be another problem to handle
If any of you want to know what I mean by XML & XSLT, read the sample from http://www.w3schools.com/xsl/xsl_transformation.asp
Coming to XML, it can represent any data structure and MS SQL Server has option to output data in XML format, which makes it easier.
All of these above are much easier to handle, now the next item to tackle is to build in the ability for multi-server operation…After much reading, I have found a solution for this also. The assumption I had in mind was of an application where the delivery has to be done in various devices such as browsers, mobile platform, Kiosk’s and desktop.
Let’s assume that the application we are developing is a Air ticket reservation system where consumers can book online using browsers, mobiles and also through Kiosks, corporate will be using a desktop application for reports and all such related stuff’s...
While doing the BLL, I will ensure that the module that requires high integration is kept together. The SMS & email alerts definitely will be a detached module that will be invoked on demand (sending SMS, email after a successful booking) using WS and also this module will be capable of doing scheduled stuff’s like reminders etc. It is also possible to detach the scheduled stuff to another server if required. User profiling and reservation / cancellation will be kept together as interactions are high here. The payment module can be again kept separate if required as the gateway is 3rd party and will not have any issues. The reporting engine will be individual engine hence am not too bother d about it. The other modules that will have high interactions will be the flight schedules, routes and crew.
I am not very sure whether my example really made sense but I would always make a chart of all modules and degree of their interactions before deciding on the separation of BLL.
The interface of the application will not be a problem in browser, mobile and kiosk’s as we have planned it well and this architecture is futuristic, that can stay forever as we have thought through the whole...
Moreover, you are not dependent on any system variables; hence having no impact for upgrades and updates since you can handle each of them individually!
I hope this was helpful, looking forward to hear more from all…
Cheers,
Sudhish Chemmur
Friday, February 6, 2009
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment