Simple framework for business applications

• Download source and demo files - 236 Kb

Introduction

I usually don't like application frameworks because most of the frameworks I have seen or used, whether built in-house or bought from a vendor, don't deliver the main thing they promise: they don't save your time or money. The reason, I think, is that developers and vendors don't get any incentives or don't know how to make things simple and direct. You end up writing a lot of complicated code that is framework/vendor specific. Large frameworks cost a lot more than expected because you have to train your developers as well as your support team. The framework will likely become obsolete in a few years (typically the vendors will have new technologies to sell by that time).

What if I develop my own framework? Can I make things any better? This article is an attempt in that direction. My goal is to build a framework that supports various business functions in a simple and direct manner. In my previous code project article, "A web service as a framework for simplifying development and deployment of business functions", I described a simple web service that could support various business functions by simply copying .NET DLLs that implement those business functions to the server and by modifying some entries in the web.config file. Now, I have made some significant improvements in this approach so that it looks more like a real framework for business applications.

My web service is called DataSetService, it requires the business functions to be implemented by methods that take DataSet or typed DataSet as input and output types. A typed DataSet derives from the .NET System.Data.DataSet class and the code is generated automatically by Visual Studio .NET from a user defined XML schema file (.xsd file). I realize this is a big restriction, however, it gives me type-safety. Business functions deployed by this framework can easily be exposed to (and used by) programs and systems outside of the .NET world.

My own .NET Framework for business applications

First, let me describe the physical architecture:

The picture shows three server machines each having a single instance of DataSetService installed. You can have all the three servers support exactly the same set of business functions (for example, you want to do load-balancing) or you can deploy different business functions on these servers. Each business function (implemented in your .NET DLL) can invoke other business functions on the same server and it can also invoke business functions on other servers.

The communication between the server and the client is via the web service call (SOAP protocol). Each business function is identified by a service key string which is unique to the server. The web method RunService takes a DataSet object (or a typed data set object) and a service key string as input, and it returns a DataSet object (or a typed DataSet object) as output.

1. If you want to call a business function deployed on one of these servers, you should make a web service call to the RunService method with the appropriate service key string and the input DataSet object.
2. If you are developing a business function and need to call another business function, then you can use the RunService method in the library DataSetServiceUtility.dll, the library will figure out whether the business function you need is deployed locally or on another server and make the corresponding call for you.

Installation. The included FrameworkInstaller.msi file can be used to install the framework. After installation, the DataSetService files will be copied to your server machine and a virtual directory will be created for this web service. The web service contains a web page ServiceAdmin.aspx which is used to manage business functions. The sample programs included in the zip file will not be installed automatically.

Here are the main parts of the framework:

• Communication between the server and the client: handled by the framework.
• Interfaces of the business functions: defined by XML schema files.
• Implementation of the business functions: written as .NET DLLs by application developers.
• Deployment of business functions: handled by the framework (to be covered later in this article).

With this framework, you can deploy your business functions on unlimited number of servers. Any one of your business functions can invoke another in a consistent manner. You can also have a single server as a gateway, and have your clients access all of your business functions through this server (more details in the next section).

How does a non .NET program use the business functions deployed with this framework? DataSetService has a web method called RunServiceXML. Instead of using DataSet as input and output types, this method uses string as input and output types. The input and output strings are simply XML representations of the DataSet objects (or typed DataSet objects).

Note: The WSDL of DataSetService does not tell you much about the input and output types of the various business functions deployed. Users know the type of input and output once they have the XML schema files for the business function they need. It is recommended that the typed DataSets (generated from XML schema files) for a business function be contained in a separate .NET DLL so that the DLL can be shared on both the server side and the client side.

Managing business functions

The framework comes with a tool (a web page, to be exact) that allows you to dynamically and visually add or delete a business function. Before you can use this tool to add a new business function, here is all that you need to do:

1. Implement the business function as a public method of a class in a .NET DLL. The type of input and output of the public method must be either DataSet or typed DataSet (generated from the XML schema file). The class must have a default constructor.
2. It is recommended that the typed DataSets for the business function be contained in a .NET DLL separate from the DLL that implements the business function.

Once you have the DLLs built and tested, open the page ServiceAdmin.aspx on the server. This page is part of DataSetService. The following picture shows the top portions of the web page where you can see where the business functions are deployed:

If you enter the admin password (the default is 123456) and click the "Display Existing Business Functions" check box, two tables will appear on the page showing you what is currently deployed on the server. The service key string uniquely identifies a business function.

1. Local business functions: The first table lists all the business functions that are deployed on the server. The "DLL Path" column shows the physical path of each business DLL. The "Class Name" and "Method Name" columns tell you the class and the method within the DLL that implements the business function.
2. Remote business functions: The second table lists all the business functions that are deployed on different servers but can be accessed from this server. If you invoke a business function listed in the second table, the framework will figure out the server it resides in and make the web service call for you. That is, the client can invoke a business function in exactly the same way as long as the service key string is in one of the two tables, regardless of whether the business function is deployed locally or remotely.
3. Deleting an existing business function: Clicking the "delete" link next to the service key string will remove the business function from the current server. After deletion, the business function cannot be invoked by the clients.
4. Adding a new business function: The following picture shows the bottom portions of the ServiceAdmin.aspx page. It shows the user interface for adding a new business function:

   

   To deploy a new business function in the server, you need to enter the Service Key, Class Name, and the Method Name, and upload the .NET DLL that implements the business function. Optionally, you can upload the .NET DLL that contains the input and output typed DataSets, plus up to 6 other files (shared class libraries, configuration files, etc.) needed by this business function. All these uploaded files will be stored in the same folder on the server created specifically for this new business function.

   If you enter a class or a method for a new business function that does not exist in the DLL you uploaded, or the method does not have the correct input and output types, then you will get an "Invalid class or method" error message.

   

5. Configure remote business functions: If you have a business function that is deployed on another server, and you want the clients to access it through this server, you can click the "Configure Remote Business Function" check box. The appearance of ServiceAdmin.aspx page changes (as shown in the picture above) enabling you to specify the Service Key and the Service URL for the remotely deployed business function.

   Your clients will be able to access this remote business function as if it was deployed locally.

6. Manually install business functions: The framework uses web.config file to store information about various business functions. Adding and deleting business functions means modifying the web.config file of DataSetService. In my previous article, I had explained how the business functions are defined in the web.config file. There are cases where you need to manually edit the web.config file to install or update a business function.
7. Share files among different business functions: As mentioned earlier, all the files (DLLs, configuration files, etc.) of a deployed business function are stored in a folder for that particular business function. However, you may have multiple business functions implemented in the same set of files. In this case, you deploy the first business function as described in #4. When deploying the other business functions, click the "Share Files With Existing Function" check box. The appearance of ServiceAdmin.aspx page changes as shown in the following picture. You only need to enter the Service Key, Class Name, Method Name, and the Service Key for the existing business function. There is no need to upload any file:

   

Final note

Please note that the Admin Password is stored in the web.config file. Each time you add or delete a business function, you will have to re-enter the password in the ServiceAdmin.aspx page. You also need to re-enter the password if you don't perform any action on the ServiceAdmin.aspx page for more than 5 minutes.

Keep in mind that when you use the ServiceAdmin.aspx page to add or delete a business function, the ASP.NET application will be interrupted because its web.config file is being modified.

The approach I have described in this article may be suitable only for internal use (the clients are other applications within the company). Please refer to my previous article for more implementation details.

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here