Using Reflection to dynamically expose your Business Logic through a Webservice.

Introduction:

Many people are using web services to communicate with their business logic. There are many advantages to this - Using this approach allows a wide range of flexibility in the architecture that would otherwise be very hard to come by. However, there are also a few disadvantages. One disadvantage is the amount of tedious work involved in keeping your web service methods in-sync with your business logic methods. This article will show you how you can avoid those issues, while still enjoying all the benefits of using web services.

The Reasoning:

I recently designed and built an application which used web services for business layer communication. The interface used a custom component to get data, and the custom component used the web services to communicate with the business layer. This allowed the interface to be deployed (almost) anywhere we wanted, and also gave us the ability to secure (via SSL) all communication. Our architecture was similar to this:

Interface <-> Communication Component <-> Web Service <-> Business Logic <-> Data Access Layer

Note that the Business Logic classes contained static methods to process data before being sent to the Data Access Layer, or returned to the Communication Component.

This was working great for about the first two weeks while we worked on the main system functionality. However, as time went on, we began adding more and more methods to the business logic that needed to be exposed via the web service. This was consuming a tremendous amount of time, as we had a one-to-one ratio of web services to business logic classes. Every time we added a new business logic class, we had to make a new web service, make the proxy class for the web service, keep the proxy class in-sync with the web service, and keep the web service in-sync with the business logic. It was quickly becoming more trouble than it was worth.

We had a hard deadline, and a very tight schedule. What we needed was a way to automate or simplify the maintenance associated with using web services. After tossing around some ideas (such as code generators - we already used one to generate classes from DB tables), I came up with the idea of using reflection to dynamically invoke methods in the business logic and return their results through the web service. After a 1/2 hour or so I had the first prototype, and about 2 hours later I had a component that I felt would work in a production environment.

The Setup:

Let's assume that you already have some classes developed. These classes can be thought of as "Data Transfer Objects" (DTOs). One of these classes is "CustomerData", which provides data on a particular customer. There are several ways you want to be able to access a Customer. You will either use the Customer's ID, or you will use an Order Number. You also have an "OrderData" class that you need to access. For the Order class you need to be able to either access a single order or every order for a given customer (ArrayList). The business logic classes will be called "Order" and "Customer" respectively.

Normally, for this type of situation, you would have 2 web services - One for returning CustomerData objects, and one for returning OrderData objects (you could pack them into one web service, but that gets crowded when dealing with a large number of classes). You would also have two methods in each of those web services. The web service methods would be called from your interface layer, and then they would call your business layer to get the data required. So for the normal situation, we've got two classes, two web services, and two methods in each web service.

For example:

Customer.LoadByCustomerID() <-> Customer Web Service <-> Customer Business Logic Customer.LoadByOrderID() <-> Customer Web Service <-> Customer Business Logic Order.LoadByOrderID() <-> Order Web Service <-> Order Business Logic Order.LoadAllForCustomerID() <-> Order Web Service <-> Order Business Logic

Using reflection, you can have one web service, with two methods, handle each and every single call you would ever need to make to your business layer.

For Example:

Customer.LoadByCustomerID() <-> Generic Web Service <-> Customer Business Logic Customer.LoadByOrderID() <-> Generic Web Service <-> Customer Business Logic Order.LoadByOrderID() <-> Generic Web Service <-> Order Business Logic Order.LoadAllForCustomerID() <-> Generic Web Service <-> Order Business Logic

The Code:

The following is the code for implementing a generic web service. I called this the "BusinessPipe" for my project.

[WebService(Namespace="http://tempuri/")]

[XmlInclude(typeof(CustomerData)),XmlInclude(typeof(OrderData))]

public class BusinessPipe : System.Web.Services.WebService

{

private const string BUSINESS_ASSEMBLY = "My.Business.Assembly";

#region Component Designer generated code

//Required by the Web Services Designer

private IContainer components = null;

///

/// Clean up any resources being used.

///

protected override void Dispose( bool disposing )

{

if(disposing && components != null)

{

components.Dispose();

}

base.Dispose(disposing);

}

#endregion

private Type AccessType(string typeName)

{

Type type = null;

Assembly assembly = System.Reflection.Assembly.Load(BUSINESS_ASSEMBLY);

if(assembly == null)

throw new Exception("Could not find assembly in BusinessPipe! Assembly: " +

BUSINESS_ASSEMBLY);