I recently received a question from a J2EE developer, who wanted to know how to get started with a multi-tiered architecture for .NET Web services.

The question:

I have some experience with J2EE and know that one good design is to create a multi-tier architecture. That is to say create control servers that will request processing from business tire (using some rpc) then forward the result to the display JSPs. I have never used .NET and need to build a web services application using this framework. My question is: what is the .NET alternative for that design? and where can I get the right information and documentation??

My answer:

.NET Web services are hosted within the ASP.NET runtime environment. They are exposed through .asmx endpoints which have what is known as a code-behind file that has a WebService-derived class linked to it. This class is essentially “the service”, and its methods (those marked with [WebMethod] attribute) are exposed as part of the automatically generated WSDL contract.

As a side note, typical of most platforms today, developers are building classes and methods to generate WSDL, however the better approach would be to create the WDSL contract first, and map that to business objects that handle processing. It requires discipline to follow this approach today.

The code that is encapsulated by the WebService object should never contain business logic, rather defer to other .NET assemblies that can be invoked in-process or out-of-process to perform the work required to execute the requested service method, and return a response (if not a one way method). That usually means that some form of façade layer is required to pull any business logic from the service class, and choreograph invocations to reusable business logic components (see Figure 1)

If you design your business logic in terms of logical, distributable services, then you should end up with a coupling of isolated sets of functionality that comprise an entry point assembly, one or more additional supporting assemblies, and some form of output or data store. For example, in Figure 1, you see that the application server tier has three entry point services: Service A, B and C. Imagine that Service C is a logging service that simply logs the Web service request “happened”; Service B is a service that handles the actual request processing, gathering data from the database, possibly committing some business information to the database; and Service A is a set of messaging and file IO services that handle generating some document output, like a PDF or email generated from the Web service request. Each of these business services can be isolated and distributed to whatever tiers you may desire, or be hosted entirely on the Web server tier, depending on your scalability requirements.

So, to your question, how do you distribute components and invoke them across tiers? Assuming your system is designed for reuse and distribution in this way, you can choose from Enterprise Services, Remoting or Web Services (these are the typical three choices).

1. Enterprise Services is the best approach if you want to migrate to future technologies like Indigo, since the programming model will follow this route. That means registering Service A assembly (for example) as a serviced component with COM+, which implies it will be invoked over DCOM with binary serialization messaging format. The beauty of this is that you can leverage COM+ to handle object pooling, encryption, authorization services, runtime identity services and distributed transactions. A recommended resource for this is Juval Lowy’s book, COM and .NET Component Services.
2. There are a few reasons why Enterprise Services may not be an option for you. One reason could be that restrictions were placed on the system deployment that precludes enabling COM+ services and MSMQ. This is usually an issue on inexpensive host domains (your $10/month service provider dilemma) or because the company imposes these restrictions (sometimes for no reason, sometimes for good reason). Remoting is an option for these cases, because it is a completely hand-rolled solution for invoking objects across process boundaries. Of course, this means rolling your own authentication, encryption, runtime identity impersonation, object pooling. No built-in support for distributed transactions will be provided here. A recommended resource for Remoting is Ingo Rammer’s book, Advanced .NET Remoting.
3. Lastly, you can slap a Web service in front of the business services shown on the application tier. Note, I call them business “services” because they are services in their own right, a la “service-oriented” system design. Each major function within the system should be designed in a service-oriented way so that distribution of the components of that business service can be accomplished transparent to how the entire system cohesively functions. In addition, those services could be reused by other “systems”.

So, the entry point to a business service can be through the remote invocation techniques described in 1 & 2, or through Web services if the business service either a) already exposed Web services due to its reuse outside of the firewall, or b) if the input to the service should be XML, and you want to reduce parsing overhead between the outer Web service and the business service. Behind the firewall, binary serialization over a speedy TCP/UDP protocol layer will perform better than XML over HTTP. The options for serialization and protocol selection will be seamless in future releases of the .NET framework (Indigo) however today it is a design decision that requires considering the deployment and invocation model during the design phase of the system.

Figure 1