I am going to write series of articles using Windows Communication Framework (WCF) to develop client and server applications and this is the first part of that series. What is WCF As Juwal puts in his Programming WCF book, WCF provides an SDK for developing and deploying services on Windows, provides runtime environment to expose CLR types as services and consume services as CLR types. Building services with WCF is incredibly easy and it’s implementation provides a set of industry standards and off the shelf plumbing including service hosting, instance management, reliability, transaction management, security etc such that it greatly increases productivity Scenario: Lets consider a typical bank customer trying to create an account, deposit amount and transfer funds between accounts, i.e. checking and savings. To make it interesting, we are going to divide the functionality into multiple services and each of them working with database directly. We will run test cases with and without transactional support across services. In this post we will build contracts, services, data access layer, unit tests to verify end to end communication etc, nothing big stuff here and we dig into other features of the WCF in subsequent posts with incremental changes. In any distributed architecture we have two pieces i.e. services and clients. Services as the name implies provide functionality to execute various pieces of business logic on the server, and clients providing interaction to the end user. Services can be built with Web Services or with WCF. Service built on WCF have the advantage of binding independent, i.e. can run against TCP and HTTP protocol without any significant changes to the code. Solution Services Profile: For creating a new bank customer, getting details about existing customer ProfileContract ProfileService Checking Account: To get checking account
balance, deposit or withdraw amount CheckingAccountContract CheckingAccountService Savings Account: To get savings account
balance, deposit or withdraw amount SavingsAccountContract SavingsAccountService ServiceHost: To host services, i.e. running the services at particular address, binding and contract where client can connect to Client: Helps end user to use services like creating account and amount transfer between the accounts BankDAL: Data access layer to work with database BankDAL It’s no brainer not to use an ORM as many matured products are available currently in market including Linq2Sql, Entity Framework (EF), LLblGenPro etc. For this exercise I am going to use Entity Framework 4.0, CTP 5 with code first approach. There are two approaches when working with data, data driven and code driven. In data driven we start by designing tables and their constrains in database and generate entities in code while in code driven (code first) approach entities are defined in code and the metadata generated from the entities is used by the EF to create tables and table constrains. In previous versions the entity classes had to derive from EF specific base classes. In EF 4 it is not required to derive from any EF classes, the entities are not only persistence ignorant but also enable full test driven development using mock frameworks. Application consists of 3 entities, Customer entity which contains Customer details; CheckingAccount and SavingsAccount to hold the respective account
balance. We could have introduced an Account base class for CheckingAccount and SavingsAccount which is certainly possible with EF mappings but to keep it simple we are just going to follow 1 –1 mapping between entity and table mappings. Lets start out by defining a class called Customer which will be mapped to Customer table, observe that the class is simply a plain old clr object (POCO) and has no reference to EF at all. using System;
namespace BankDAL.Model
{
public class Customer
{
public int Id { get; set; }
public string FullName { get; set; }
public string Address { get; set; }
public DateTime DateOfBirth { get; set; }
}
}
In order to inform EF about the Customer entity we have to define a database context with properties of type DbSet<> for every POCO which needs to be mapped to a table in database. EF uses convention over configuration to generate the metadata resulting in much less configuration.
using System.Data.Entity;
namespace BankDAL.Model
{
public class BankDbContext: DbContext
{
public DbSet<Customer> Customers { get; set; }
}
}
Entity constrains can be defined through attributes on Customer class or using fluent syntax (no need to muscle with xml files), CustomerConfiguration class. By defining constrains in a separate class we can maintain clean POCOs without corrupting entity classes with database specific information.
using System;
using System.Data.Entity.ModelConfiguration;
namespace BankDAL.Model
{
public class CustomerConfiguration: EntityTypeConfiguration<Customer>
{
public CustomerConfiguration()
{
Initialize();
}
private void Initialize()
{
//Setting the Primary Key
this.HasKey(e => e.Id);
//Setting required fields
this.HasRequired(e => e.FullName);
this.HasRequired(e => e.Address);
//Todo: Can't create required constraint as DateOfBirth is not reference type, research it
//this.HasRequired(e => e.DateOfBirth);
}
}
}
Any queries executed against Customers property in BankDbContext are executed against Cusomers table. By convention EF looks for connection string with key of BankDbContext when working with the context.
We are going to define a helper class to work with Customer entity with methods for querying, adding new entity etc and these are known as repository classes, i.e., CustomerRepository
using System;
using System.Data.Entity;
using System.Linq;
using BankDAL.Model;
namespace BankDAL.Repositories
{
public class CustomerRepository
{
private readonly IDbSet<Customer> _customers;
public CustomerRepository(BankDbContext bankDbContext)
{
if (bankDbContext == null) throw new ArgumentNullException();
_customers = bankDbContext.Customers;
}
public IQueryable<Customer> Query()
{
return _customers;
}
public void Add(Customer customer)
{
_customers.Add(customer);
}
}
}
From the above code it is observable that the Query methods returns customers as IQueryable i.e. customers are retrieved only when actually used i.e. iterated. Returning as IQueryable also allows to execute filtering and joining statements from business logic using lamba
expressions without cluttering the data access layer with tens of methods.
Our CheckingAccountRepository and SavingsAccountRepository look very similar to each other
using System;
using System.Data.Entity;
using System.Linq;
using BankDAL.Model;
namespace BankDAL.Repositories
{
public class CheckingAccountRepository
{
private readonly IDbSet<CheckingAccount> _checkingAccounts;
public CheckingAccountRepository(BankDbContext bankDbContext)
{
if (bankDbContext == null) throw new ArgumentNullException();
_checkingAccounts = bankDbContext.CheckingAccounts;
}
public IQueryable<CheckingAccount> Query()
{
return _checkingAccounts;
}
public void Add(CheckingAccount account)
{
_checkingAccounts.Add(account);
}
public IQueryable<CheckingAccount> GetAccount(int customerId)
{
return (from act in _checkingAccounts
where act.CustomerId == customerId
select act);
}
}
}
The repository classes look very similar to each other for Query and Add methods, with the help of C# generics and implementing repository pattern (Martin Fowler) we can reduce the repeated code. Jarod from ElegantCode has posted an article on how to use repository pattern with EF which we will implement in the subsequent articles along with WCF Unity life time managers by Drew
Contracts
It is very easy to follow contract first approach with WCF, define the interface and append ServiceContract, OperationContract attributes.
IProfile contract exposes functionality for creating customer and getting customer details.
using System;
using System.ServiceModel;
using BankDAL.Model;
namespace ProfileContract
{
[ServiceContract]
public interface IProfile
{
[OperationContract]
Customer CreateCustomer(string customerName, string address, DateTime dateOfBirth);
[OperationContract]
Customer GetCustomer(int id);
}
}
ICheckingAccount contract exposes functionality for working with checking account, i.e., getting
balance, deposit and withdraw of amount.
ISavingsAccount contract looks the same as checking account.
using System.ServiceModel;
namespace CheckingAccountContract
{
[ServiceContract]
public interface ICheckingAccount
{
[OperationContract]
decimal? GetCheckingAccountBalance(int customerId);
[OperationContract]
void DepositAmount(int customerId,decimal amount);
[OperationContract]
void WithdrawAmount(int customerId, decimal amount);
}
}
Services
Having covered the data access layer and contracts so far and here comes the core of the business logic, i.e. services.
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
ProfileService implements the IProfile contract for creating customer and getting customer detail using CustomerRepository.
using System;
using System.Linq;
using System.ServiceModel;
using BankDAL;
using BankDAL.Model;
using BankDAL.Repositories;
using ProfileContract;
namespace ProfileService
{
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class Profile: IProfile
{
public Customer CreateAccount(
string customerName, string address, DateTime dateOfBirth)
{
Customer cust =
new Customer
{ FullName = customerName, Address = address, DateOfBirth = dateOfBirth };
using (var bankDbContext = new BankDbContext())
{
new CustomerRepository(bankDbContext).Add(cust);
bankDbContext.SaveChanges();
}
return cust;
}
public Customer CreateCustomer(string customerName, string address, DateTime dateOfBirth)
{
return CreateAccount(customerName, address, dateOfBirth);
}
public Customer GetCustomer(int id)
{
return new CustomerRepository(new BankDbContext()).Query()
.Where(i => i.Id == id).FirstOrDefault();
}
}
}
From the above code you shall observe that we are calling bankDBContext’s SaveChanges method and there is no save method specific to customer entity because EF manages all the changes centralized at the context level and all the pending changes so far are submitted in a batch and it is represented as Unit of Work.
Similarly Checking service implements ICheckingAccount contract using CheckingAccountRepository, notice that we are throwing overdraft exception if the
balance falls by zero. WCF has it’s own way of raising exceptions using fault contracts which will be explained in the subsequent articles.
SavingsAccountService is similar to CheckingAccountService.
using System;
using System.Linq;
using System.ServiceModel;
using BankDAL.Model;
using BankDAL.Repositories;
using CheckingAccountContract;
namespace CheckingAccountService
{
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class Checking:ICheckingAccount
{
public decimal? GetCheckingAccountBalance(int customerId)
{
using (var bankDbContext = new BankDbContext())
{
CheckingAccount account =
(new CheckingAccountRepository(bankDbContext)
.GetAccount(customerId)).FirstOrDefault();
if (account != null)
return account.Balance;
return null;
}
}
public void DepositAmount(int customerId, decimal amount)
{
using(var bankDbContext = new BankDbContext())
{
var checkingAccountRepository =
new CheckingAccountRepository(bankDbContext);
CheckingAccount account =
(checkingAccountRepository.GetAccount(customerId))
.FirstOrDefault();
if (account == null)
{
account = new CheckingAccount() { CustomerId = customerId };
checkingAccountRepository.Add(account);
}
account.
Balance = account.
Balance + amount;
if (account.
Balance < 0)
throw new ApplicationException("Overdraft not accepted");
bankDbContext.SaveChanges();
}
}
public void WithdrawAmount(int customerId, decimal amount)
{
DepositAmount(customerId, -1*amount);
}
}
}
BankServiceHost
The host acts as a glue binding contracts with it’s services, exposing the endpoints. The services can be exposed either through the code or
configuration file, configuration file is preferred as it allows run time changes to service behavior even after deployment.
We have 3 services and for each of the service you need to define name (the class that implements the service with fully qualified namespace)
and endpoint known as ABC, i.e. address, binding and contract. We are using netTcpBinding and have defined the base address
with for each of the contracts
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
<system.serviceModel>
<services>
<service name="ProfileService.Profile">
<endpoint binding="netTcpBinding" contract="ProfileContract.IProfile"/>
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:1000/Profile"/>
</baseAddresses>
</host>
</service>
<service name="CheckingAccountService.Checking">
<endpoint binding="netTcpBinding"
contract="CheckingAccountContract.ICheckingAccount"/>
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:1000/Checking"/>
</baseAddresses>
</host>
</service>
<service name="SavingsAccountService.Savings">
<endpoint binding="netTcpBinding"
contract="SavingsAccountContract.ISavingsAccount"/>
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:1000/Savings"/>
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
Have to open the services by creating service host which will handle the incoming requests from clients.
using System;
namespace ServiceHost
{
class Program
{
static void Main(string[] args)
{
CreateHosts();
Console.ReadLine();
}
private static void CreateHosts()
{
CreateHost(typeof(ProfileService.Profile),"Profile Service");
CreateHost(typeof(SavingsAccountService.Savings),
"Savings Account Service");
CreateHost(typeof(CheckingAccountService.Checking),
"Checking Account Service");
}
private static void CreateHost(Type type, string hostDescription)
{
System.ServiceModel.ServiceHost host =
new System.ServiceModel.ServiceHost(type);
host.Open();
if (host.ChannelDispatchers != null
&& host.ChannelDispatchers.Count != 0
&& host.ChannelDispatchers[0].Listener != null)
Console.WriteLine("Started: " + host.ChannelDispatchers[0].Listener.Uri);
else
Console.WriteLine("Failed to start:" + hostDescription);
}
}
}
BankClient
The client has no knowledge about service business logic other than the functionality it exposes through the contract, end points and a proxy
to work against. The endpoint data and server proxy can be generated by right clicking on the project reference and choosing
‘Add Service Reference’ and entering the service end point address. Or if you have access to source, you can manually reference
contract dlls and update clients configuration file to point to the service end point if the server and client happens to be being built
using .Net framework. One of the pros with the manual approach is you don’t have to work against messy code generated files.
<system.serviceModel>
<client>
<endpoint name="tcpProfile" address="net.tcp://localhost:1000/Profile" binding="netTcpBinding" contract="ProfileContract.IProfile"/>
<endpoint name="tcpCheckingAccount" address="net.tcp://localhost:1000/Checking" binding="netTcpBinding" contract="CheckingAccountContract.ICheckingAccount"/>
<endpoint name="tcpSavingsAccount" address="net.tcp://localhost:1000/Savings" binding="netTcpBinding" contract="SavingsAccountContract.ISavingsAccount"/>
</client>
</system.serviceModel>
The client uses a façade to connect to the services
using System.ServiceModel;
using CheckingAccountContract;
using ProfileContract;
using SavingsAccountContract;
namespace Client
{
public class ProxyFacade
{
public static IProfile ProfileProxy()
{
return
(new ChannelFactory<IProfile>("tcpProfile")).CreateChannel();
}
public static ICheckingAccount CheckingAccountProxy()
{
return (new ChannelFactory<ICheckingAccount>("tcpCheckingAccount"))
.CreateChannel();
}
public static ISavingsAccount SavingsAccountProxy()
{
return (new ChannelFactory<ISavingsAccount>("tcpSavingsAccount"))
.CreateChannel();
}
}
}
With that in place, lets get our unit tests going
using System;
using System.Diagnostics;
using BankDAL.Model;
using NUnit.Framework;
using ProfileContract;
namespace Client
{
[TestFixture]
public class Tests
{
private void TransferFundsFromSavingsToCheckingAccount(int customerId,
decimal amount)
{
ProxyFacade.CheckingAccountProxy().DepositAmount(customerId, amount);
ProxyFacade.SavingsAccountProxy().WithdrawAmount(customerId, amount);
}
private void TransferFundsFromCheckingToSavingsAccount(int customerId,
decimal amount)
{
ProxyFacade.SavingsAccountProxy().DepositAmount(customerId, amount);
ProxyFacade.CheckingAccountProxy().WithdrawAmount(customerId, amount);
}
[Test]
public void CreateAndGetProfileTest()
{
IProfile profile = ProxyFacade.ProfileProxy();
const string customerName = "Tom";
int customerId = profile.CreateCustomer(customerName, "NJ",
new DateTime(1982, 1, 1)).Id;
Customer customer = profile.GetCustomer(customerId);
Assert.AreEqual(customerName,customer.FullName);
}
[Test]
public void DepositWithDrawAndTransferAmountTest()
{
IProfile profile = ProxyFacade.ProfileProxy();
string customerName = "Smith" + DateTime.Now.ToString("HH:mm:ss");
var customer = profile.CreateCustomer(customerName, "NJ",
new DateTime(1982, 1, 1));
// Deposit to Savings
ProxyFacade.SavingsAccountProxy().DepositAmount(customer.Id, 100);
ProxyFacade.SavingsAccountProxy().DepositAmount(customer.Id, 25);
Assert.AreEqual(125,
ProxyFacade.SavingsAccountProxy().GetSavingsAccountBalance(customer.Id));
// Withdraw
ProxyFacade.SavingsAccountProxy().WithdrawAmount(customer.Id, 30);
Assert.AreEqual(95,
ProxyFacade.SavingsAccountProxy().GetSavingsAccountBalance(customer.Id));
// Deposit to Checking
ProxyFacade.CheckingAccountProxy().DepositAmount(customer.Id, 60);
ProxyFacade.CheckingAccountProxy().DepositAmount(customer.Id, 40);
Assert.AreEqual(100,
ProxyFacade.CheckingAccountProxy().GetCheckingAccountBalance(customer.Id));
// Withdraw
ProxyFacade.CheckingAccountProxy().WithdrawAmount(customer.Id, 30);
Assert.AreEqual(70,
ProxyFacade.CheckingAccountProxy().GetCheckingAccountBalance(customer.Id));
// Transfer from Savings to Checking
TransferFundsFromSavingsToCheckingAccount(customer.Id,10);
Assert.AreEqual(85,
ProxyFacade.SavingsAccountProxy().GetSavingsAccountBalance(customer.Id));
Assert.AreEqual(80,
ProxyFacade.CheckingAccountProxy().GetCheckingAccountBalance(customer.Id));
// Transfer from Checking to Savings
TransferFundsFromCheckingToSavingsAccount(customer.Id, 50);
Assert.AreEqual(135,
ProxyFacade.SavingsAccountProxy().GetSavingsAccountBalance(customer.Id));
Assert.AreEqual(30,
ProxyFacade.CheckingAccountProxy().GetCheckingAccountBalance(customer.Id));
}
[Test]
public void FundTransfersWithOverDraftTest()
{
IProfile profile = ProxyFacade.ProfileProxy();
string customerName = "Angelina" + DateTime.Now.ToString("HH:mm:ss");
var customerId =
profile.CreateCustomer(customerName, "NJ", new DateTime(1972, 1, 1)).Id;
ProxyFacade.SavingsAccountProxy().DepositAmount(customerId, 100);
TransferFundsFromSavingsToCheckingAccount(customerId,80);
Assert.AreEqual(20,
ProxyFacade.SavingsAccountProxy().GetSavingsAccountBalance(customerId));
Assert.AreEqual(80,
ProxyFacade.CheckingAccountProxy().GetCheckingAccountBalance(customerId));
try
{
TransferFundsFromSavingsToCheckingAccount(customerId,30);
}
catch (Exception e)
{
Debug.WriteLine(e.Message);
}
Assert.AreEqual(110,
ProxyFacade.CheckingAccountProxy().GetCheckingAccountBalance(customerId));
Assert.AreEqual(20,
ProxyFacade.SavingsAccountProxy().GetSavingsAccountBalance(customerId));
}
}
}
We are creating a new instance of the channel for every operation, we will look into instance management and how creating a new instance of channel affects it in subsequent articles.
The first two test cases deals with creation of Customer, deposit and withdraw of month between accounts. The last case, FundTransferWithOverDraftTest() is interesting. Customer starts with depositing $100 in SavingsAccount followed by transfer of $80 in to checking account resulting in $20 in savings account. Customer then initiates $30 transfer from Savings to Checking resulting in overdraft exception on Savings with $30 being deposited to Checking. As we are not running both the requests in transactions the customer ends up with more amount than what he started with $100. In subsequent posts we will look into transactions handling.
Make sure the ServiceHost project is set as start up project and start the solution. Run the test cases either from NUnit client or TestDriven.Net/Resharper which ever is your favorite tool. Make sure you have updated the data base connection string in the ServiceHost config file to point to your local database
