How to implement .NET code library as a service layer - sharing same BL/CRUD between several applications

Question

Setting: I'm developing an intranet tool set for my department, the main point of which is to centrally manage data quality and accessibility, but also to automate and scale some partial-processes.

Problem: I currently have my business logic in a CLR assembly, which is available on my SQL-Server for other CLR assemblies that run automated ETL directly on the SQL-Server. I am also developing an intranet site, which also needs the code information in that business logic assembly, but referencing the CLR assembly code has been working out sub-optimally, in terms of deployment and code maintenance. Also another department has voiced interest in using the code-base and data for their own intranet site.

Question(s): I've read quite a few Q&A(1,2,3,4,...) on SO to this topic, but I find it a very encompassing, so I'll try to ask questions for a more specific case(i.e. a single BL and Data Access code base)

• Is a WCF service the solution I want? All my potential service clients run on the same server, is there maybe another way to reference the same code base both in CLR assembly and website projects? I don't need support for different platforms(ex. Java) - everything is .NET(yay for in-house progr!) - is WCF overkill?
• Can code from a WCF service be used like a class library, or do I need to program a new way for accessing classes/methods from the service?
• Separation of Development, Test and Productive instances?
  • Can a WCF service be updated while clients are accessing it, or do I need to schedule maintenance windows? When I update the service, do I need to update the client as well in some way?
  • Can I dynamically set the service reference, like I currently am dynamically setting the database connection string, depending on if StageConfig = dev, test, or prod?
• My CLR assemblies are written for .Net 3.5, but the websites for .NET 4.0, will that pose a problem?
• What minimum set of .NET service architecture programming do I need to know to accomplish this? I'll learn more about WCF with time, but I need to evaluate architecting effort and weigh it against getting things done(feature requests). Does the MS tutorial get me the desired skill?

I appreciate answers to only single questions, if you feel you know something, I'll +1 whatever helps me get closer to a complete answer.

Answer 1

OK, so you want to make your code enterprise-wide. There are two fundamental problems to talk about when you want to do this, so I'll structure the answer that way:

• You have to understand what WCF is all about.
• You have to manage your dependencies correctly.

---

What WCF is about

WCF is a way of doing RPC/RMI (Remote procedure call/remote method invocation) which means that some client code can call code that is located somewhere else through the network.

A callable WCF service is determined by the ABC triplet:

• The service specification is implemented as a .NET interface with a "ServiceContract" attribute. This is the Contract ("C")
• The "location" of the service is determined by a pair : Address ("A") and Binding ("B"). The Binding determines the protocol suite to be used for communication between client and server (NetPipe, TCP, HTTP, ...). The Address is a URI following the scheme determined by the Binding ("net.pipe", "net.tcp", "http", ...)

When the client code calls a WCF service at a specific Address, with a specfic Binding, and a specific Contract (which must match what the server at the specific Address and the specific Binding is delivering), WCF generates a proxy object implementing the interface of the contract.

The program delivering the service is any .NET executable. It has to generate one or many WCF Hosts, that will register objects or classes that implement the service contract, and asociate each delivered service to a specific Address and Binding. (possibly many thereof)

The configuration can be through the app .config file, in which you will be specifying ABC triplets and assotiate these triplets with a name that you will use in your application. You can also do it programmatically, which is very easy.

WCF does not address your problem of deploying your application, or the configuration of addresses and binding. It just addresses the problem of letting two executables communicate with each other with strongly-typed objects (through a specific interface). Sharing the service configuration is up to you. You may use a shared .config file on a Windows share, or even set up a LDAP server that will deliver all the data you need to find your service (namely A and B).

---

Managing your dependencies correctly

In your scenario, there are three actors that want to use your WCF infrastructure:

• Your SQLCLR assembly, which will be a client.
• The intranet site, which will be another client.
• The service host, which will be a server.

The bare minimum number of assemblies will be 4. One for each of the aforementioned actors, and one specifying the contract, which will be used by all three actors. It should contain the following things:

• The interface specifying the contract.
• All types needed by the interface, which will of course be sent through the network, and therefore must be serializable.

There should be nothing more in it, or else, it will be a maintenance nightmare.

---

Answer to your questions

I hope that my answer is clear. Let's sum up the answers to your questions.

Is a WCF service the solution I want? All my potential service clients run on the same server, is there maybe another way to reference the same code base both in CLR assembly and website projects? I don't need support for different platforms(ex. Java) - everything is .NET(yay for in-house progr!) - is WCF overkill?

Everything is overkill. WCF is rather easy to use and scales down very well.

Can code from a WCF service be used like a class library, or do I need to program a new way for accessing classes/methods from the service?

Setting up a WCF on existing code requires only the implementation of an additional class, and some code creating the Hosts which will serve the aforementioned class.

Calling a WCF service requires the creation of a Channel, which is a .NET (proxy) object implementing the interface.

So basically, your business code remains in the same state.

Separation of Development, Test and Productive instances?

WCF does not take care of that. Different environments, different service addresses. You have to take care of this yourself.

Can a WCF service be updated while clients are accessing it, or do I need to schedule maintenance windows?

It depends on your maintenance policy. Kill the serving process and launch the new version is the basic upgrade mechanism.

When I update the service, do I need to update the client as well in some way?

Provided that you manage your dependencies correctly like I sketched in the previous section, you need to update the clients only if the service specification (the interface) changes.

Can I dynamically set the service reference, like I currently am dynamically setting the database connection string, depending on if StageConfig = dev, test, or prod?

You have to manage that, probably by etting Address and Binding for a service programmatically.

My CLR assemblies are written for .Net 3.5, but the websites for .NET 4.0, will that pose a problem?

Provided that you manage your dependencies correctly like I sketched in the previous section, the only constraint will be the minimum CLR version required by the "contract" assembly.

What minimum set of .NET service architecture programming do I need to know to accomplish this? I'll learn more about WCF with time, but I need to evaluate architecting effort and weigh it against getting things done(feature requests). Does the MS tutorial get me the desired skill?

You'll need the result of these exercises:

1. Make two executables, a client and a server, that will communicate through a WCF contract located in a separate DLL. The configuration should be located in the app .config file.
2. Make two executables, a client and a server, that will communicate through a WCF contract located in a separate DLL. The configuration should be determined programatically.
3. Try to send a serializable class as a parameter to your service.
4. Try to send a serializable class as a return value of your service.

After that, you'll need to think about the best/cheapest way to share the Addresses and Bindings of your services.

Hope it helps.