Building a Robust and Highly Scalable Distributed Architecture using VB.NET
This article starts with an introduction to .NET Enterprise Services and finally concludes with an implementation of very flexible approach to build robust distributed enterprise solutions using .NET Enterprise Services. We will build a simple distributed enterprise solution just by building and integrating COM+ components, remoting components and Windows Services and accessing through remoting clients.
Let me start out by listing the most frequently used .NET Enterprise Services in the distributed environments:
COM+ or Serviced Components
.NET Remoting
Windows Services
XML Web Services
MSMQ Services
A serviced component is the mechanism that enables COM+ services to be available to .NET Framework classes. Just-in-Time (JIT) Activation, Synchronization, Object Pooling, Transactions, and Shared Property Management are examples of well-known COM+ services that are available for us to use.
.NET remoting enables you to build widely distributed applications easily, whether application components are all on one computer or spread out across the entire world. You can build client applications that use objects in other processes on the same computer or on any other computer that is reachable over its network. You can also use .NET remoting to communicate with other application domains in the same process.
Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. This makes services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer.
An XML Web service can be used internally by a single application or exposed externally over the Internet for use by any number of applications. Because it is accessible through a standard interface, an XML Web service allows heterogeneous systems to work together as a single web of computation.
Microsoft Windows Message Queuing makes it easy for application developers to communicate with application programs quickly and reliably by sending and receiving messages. Messaging provides you with guaranteed message delivery and a robust, fail-safe way to carry out many of your business processes.
You can use the .NET Framework on Windows 2000 and create a great application. Building and deploying your application on Windows Server 2003 will give you more options for the design and architecture of your system and your application will run faster and more reliably than ever before.
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.
The following diagram (Fig 1) illustrates the architecture implemented in this scenario.
There exists a Stored Procedure (pAreaInsert) in the database. A Serviced Component (CDataAccess.vb in COM+ Services) acts as a DAL (Data Access Layer) between Remote Component and Database. The Business Component (CArea.vb) is designed using Remoting and a Windows Service (RemoteAccessAgent.vb) hosts the Remoting Component to make it available to different Remote clients.
The downloadable Visual Studio.NET 2003 solution with this article contains following projects built into it:
DataAccessComponent – Serviced component acting as data access layer.
ConsoleCOMPlusClient – To test Services Component.
ConsoleRemoteServer – just to Host Remoting Component as server (without windows service).
ConsoleRemoteClient – Just to test the Hosted Remoting Component Server with a Remote Client (without windows service).
BusinessComponentService – Windows service hosting the Remote component.
ConsoleServiceClient – To test the Remote component hosted by Windows service.
Setup1 – A windows setup project to generate windows client installation MSI.
DON’T RUN THE ENTIRE SOLUTION. You can test every tier (or layer) individually with the respective Console client application. Consider the following:
Use projects 1 and 2 to access DB through Data Access Component directly using console application.
Use Projects 1, 3, 4 and 5 to access DB through Data Access Component from Remoting component using a Console Remoting Client hosted by Console Remote Server.
Use Projects 1, 3, 6 and 7 to access DB through Data Access Component from Remoting component hosted by a Windows service using a Console Service Client (same as Remoting Client).
The following are the steps which are to be followed very strictly (we are about to work with projects 1 and 2):
Create a table named ‘tAreas’ with a single column ‘Area’ of type ‘varchar’ (I am currently using SQL Server 2000).
Create a stored procedure named ‘pAreaInsert’ with the following code:
CREATE PROCEDURE pAreaInsert
@Area varchar(50) AS if exists (select Area from tAreas where Area = @Area) begin return 10 end else begin
insert into tAreas values (@Area)
end return 0
Download the enclosed zip file and extract it
Open Visual Studio.NET 2003 Command Prompt
Using the DOS prompt move to the DataAccessComponent\bin folder from the extracted directory (in this case MyTrial\DataAccessComponent\bin)
Type the following command to place the COM+ serviced component in GAC (Global Assembly Cache):
gacutil /i DataAccessComponent.dll
Further proceed with the following command to register the component in COM+ services registry:
Regsvcs /fc DataAccessComponent.dll
Open Programs -> Administration Tools -> Component Services
Right-click on the component and go to properties as shown in following figure Fig. 2
Go to Activation tab and change the constructor string according to your requirements (as shown in Fig. 3)
Now move to MyTrail\ConsoleCOMPlusClient\bin folder using the same command prompt and execute ‘ConsoleCOMPlusClient.exe’, which should return a message ‘Successful’.
Check your table ‘tAreas’ where a dummy value ‘this is from COM+’ gets inserted just to prove the Serviced Component Functionality.
Huh?! Let us further proceed to test other components.
The following are the steps which are to be followed very strictly (we are about to work with projects 1, 3, 4 and 5):
This is continuation from previous section. None of the previous configuration should be changed to implement the remoting in a cool manner.
Now move to MyTrail\ConsoleRemoteServer\bin folder using the same command prompt and execute ‘ConsoleRemoteServer.exe’, which should return a message ‘Press ENTER to stop this process’. This makes remoting server ‘ON’. (Please see Fig 4)
Leave it like that and open another Visual Studio Command prompt and move to MyTrail\ConsoleRemoteClient\bin folder and execute ‘ConsoleRemoteClient.exe’, which should return a message ‘Successful’. (Please see Fig 5)
Check your table ‘tAreas’ where a dummy value ‘from Remoting Client (without WinService)’ gets inserted just to prove the Remoting functionality.
Switch to ‘RemoteServer command prompt window’ and press ENTER to shut down the remoting server.
You can close one of the command prompt windows and keep the other to proceed through next section.
Let us further proceed to our final implementation i.e., executing a stored procedure using a COM+ serviced component as DAL, Remoting Component (hosted with Windows Service) as Business layer and a Console application as a Remoting Client.
The following are the steps which are to be followed very strictly (we are about to work with projects 1, 3, 6 and 7):
This is continuation from previous sections.
Now move to MyTrail\BusinessComponentService\bin folder using the same command prompt and execute the following command at the prompt to register the service in the windows services registry.
Installutil BusinessComponentService.exe
Open Programs -> Administration Tools -> Services and check whether ‘RemoteAccessAgent’ service (our own service) is started or not. If not, start it. (show in the Fig 6)
Now move to ‘MyTrail\ConsoleServiceClient\bin‘ folder using the same command prompt and execute ‘ConsoleServiceClient.exe’, which should return a message ‘Successful’.
Check your table ‘tAreas’ where a dummy value ‘from Remoting Client (with WinService)’ gets inserted just to prove the Windows Service with Remoting Functionality.
Conclusion
Strictly speaking, these many tests are not at all required to design the architecture. But this methodology at every level (or layer) with simple Console applications makes our life easier in examining the reliability of the respective component together with debugging. You can also further extend this with a Web service so that it is accessible globally across platforms!
All of the above tests can also be executed within Visual Studio.NET environment. But the registrations are to be done manually (like gacutil, installutil). You are also required to change your ‘start up projects’ within the solution accordingly to meet the respective criteria of tests.
In all of the above projects, I kept my coding as simple as possible and arranged ‘heavy commenting‘ wherever necessary, just to understand the implementation of distributed architecture. With a very good implementation of DAL, life becomes very much simpler together with Business Components. I hope this would give you a very good start on an INTRODUCTION to designing and implementing scalable distributed architectures using .NET Enterprise Services.
I used Windows Server 2003 standard edition, Visual Studio.NET 2003 Enterprise Architect together with SQL Server 2000 to have this solution completed. But the same should also work with Windows 2000 family too. In case, if it doesn’t work, you need to check out at MSDN (as COM+ 1.5 version of Windows 2003 and XP has got some enhancements when compared with COM+ 1.0 version of Windows 2000). But the modifications would be very minor, and that too just changing the attributes in coding. The execution is always the same.
I leave it to the programmers for further enhancements. Any doubts, comments, suggestions, bugs, errors or feedback are welcomed at the discuss link at the bottom of the page.
Visual Basic.NET 
Visual Basic for Beginners
