Design Decision - WCF Service or Shared Class Library (DLL)

Question

Hello everyone,

I am presently designing a message queue system that will be used by various applications and am having a difficult time trying to decide whether to use WCF to provide the services or use a shared class library (DLL) and deploy the DLL with the clients.

For some additional information:

• The queue is stored in a SQL database.

• We expect to have approximately 3-7 different applications/clients using this message queue system.

• The clients/applications may or may not run all on one machine.

• We do not expect a heavy load of messages being queued on a daily basis (approx 1000-10000 per day (gross estimates btw))

• Somewhat “mission critical” – several clients/applications cannot do its job if this service is unavailable.

• Everything operates within the corporate network – no access to Internet required.

I have given some though to the pros and cons for each decision:

WCF Service

Pros:

• Can update the logic in the Queue system without having to update the clients

• Room for scalability – but most likely not going to be an issue.

Cons:

• More difficult to diagnose/debug

• More effort required when deploying

• Queue System unavailable if the service is down (unless we cluster/farm)

Shared Class Library (DLL)

Pros:

• Easier to debug

• Easier development efforts

• Only have to ensure that the DB is available – no dependence on another service/machine.

Cons:

• Deployment headaches when we make updates to the DLL – we may forget to update all the applications that depend on the DLL.

If anyone can provide more arguments for a solution – that would be helpful! If you have an opinion to what you believe is the best direction, please do tell! I’ll appreciate any input that will help make me a decision.

Thanks for your time,

Adrian

Answer 1

You can do both:

• Implement a class library that encapsulates all the functionality you wish to expose. Consumers that wish that level of control can reference the library directly.
• Develop a WCF service that only acts as a Remote Facade for the class library. It would only expose and translate the class library into DTOs/messages, and contain no logic in itself.

In other words, the class library is your Domain Model, and the service is just a thin Facade in front of that model. That's the way any WCF service should be developed in any case.

---

That said, I you must choose one or the other, I'll try to add my own thought to yours (which I find most reaonable).

One disadvantage of WCF that you forgot is that it does add some processing overhead because it must serialize and deserialze messages.

Even so, selecting the best model is not only about counting the number of bullets in each pro/con section, as each bullet has different weights.

Without knowing your exact situation and requirements, I would still consider the deployment/versioning issue that relates to direct use of a class library to be a very strong argument against that strategy.

A web service interface will allow you to vary service and each client independently of each other as long as the contract remains stable. That could also be made possible with a class library, but is more difficult.

An interoperable web service interface also gives you a better ability to grow and respond to new business opportunities, as the clients are not constrained to .NET applications. You may have only .NET applications today, but are you sure it will stay that way forever?

If, on the other hand, you decide to go the class library route, make sure to have each client consume abstract base classes, because that will provide you with the most flexible options of changing the implementation without breaking existing clients.

Given the information you provided, I don't think there's a clear-cut winner here. I lean slightly towards WCF despite the added complexity, because I consider the flexibility it provides gives you better options for responding to unforseen changes.