Building a Robust and Highly Scalable Distributed Architecture using VB.NET - A Brief Discussion on Architectural Considerations
(Page 2 of 6 )
Architecture is design, but not all design is architecture. The architectural style with which you build an embedded, event-driven, hard, real-time system will be quite different than what you'd use for a globally distributed GUI- and data-intensive system for the enterprise.
One of the most useful architectural styles for software that you'll find is the three-tiered architecture. This is a layered architecture in which layers close to the user build upon lower layers that are closer to the machine. For many globally distributed GUI- and data-intensive systems for the enterprise, you'll find the following three tiers:
- User Services, which format the information, and present it to the user.
- Business Services, which implement the system's business rules.
- Data Services, which maintain the Customer and Catalog Data of the application.
Almost every experienced programmer can easily understand the above tiers. But the problem is figuring out what technologies are to be considered at what tier using .NET technologies. I am not going to talk about Microsoft’s suite of servers (like BizTalk Server, Commerce Server, Content Management Server, Share Point Portal Server, etc.) or EAI (Enterprise Application Integration). I just wanted to consider “what .NET Enterprise Services can be considered at what tier.
- COM+ is well suitable for automatic database connection pooling (and even object pooling), and automatic management of distributed transactions across different databases.
- .NET remoting is pretty fast in performance when compared with DCOM in remote access. It is very well suited for intranet applications (or inter-process communications) with high yield in performance.
- Windows Services are very good for providing long running services (like SQL Server Service Agent).
- XML Web Services are very good for providing services over the Internet.
- MSMQ Services are very good for maintaining continuous flow of communications between connected applications.
Mostly Data Services are handled by an RDBMS (along with server side programming like store procedures, triggers etc). But it is always suggestible to open as few database connections as possible when working with data (which requires connection pooling). In this scenario, it is recommended to use COM+ services which act as mediator (Data Access Layer) between Business Services and Data Services (just like an n-tier) just to make use of automatic pooling and automatic transaction handling.
Business Services can be implemented using any of COM+, Remoting or Web Services. MSMQ can be implemented in almost all of those technologies. But the selection of a technology among them gives an impact on future expansions or enhancements of existing architecture. Web Services are always good for expansion to web, but slow in performance when compared with Remoting. Another wonder is that even a COM+ or Remoting component can be exposed as Web Services (with the help of SOAP headers). Remoting would be more powerful if you integrate them with Windows Services. So I considered Remoting with Windows Service in this scenario, although it's not necessarily the best.
User Services can be implemented in many ways right from Windows Forms (desktop application) and Web Forms (Web application) to mobile, handheld, or embedded development environments. In this scenario, I just considered a simple Console application acting as Remote Client.
Next: Architecture Implemented >>
More Visual Basic.NET Articles
More By Jagadish Chaterjee
/ 42 
