In this part, I will continue the implementation of the middle tier by publishing a WCF service, and if you want some background, please see the previous parts:
Part 1 was a general introduction Part 2 outlined the architecture (tiers, etc) Part 3 showed the benefit of loosely coupled tiers (distribution, cloud, etc) Part 4 started the implementation by creating the entity data model (using ADO.NET Entity Framework) Part 5 published the entity data model as a data service (using ADO.NET Data Services) Part 6 implemented the business domain (using the data service) The implemented architecture is published on CodePlex in a project called KISS Architecture, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, I suggest you keep the source code handy to check out more details.
It's time to create the service, and I do that by creating a new project of type "WCF Service Application" and name it Kiss.Service. First I add a reference to the Kiss.Domain project, and then I rename the automatically generated interface to IOrderService.cs. I change its code to...
namespace Kiss.Service
{
[ServiceContract]
public interface IOrderService
{
[OperationContract]
List<Customer> GetCustomersByCity(string city);
[OperationContract]
Customer GetCustomer(string id);
[OperationContract]
void UpdateCustomer(Customer customer);
}
}
...and make sure all references to it is refactored (there are a number of places, like in the Web.config file). Then I rename the generated service class to OrderService.cs and update its (references and) code to:
namespace Kiss.Service
{
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class OrderService : IOrderService
{
private OrderDomain orderDomain = new OrderDomain();
public List<Customer> GetCustomersByCity(string city)
{
return orderDomain.GetCustomersByCity(city);
}
public Customer GetCustomer(string id)
{
return orderDomain.GetCustomer(id);
}
public void UpdateCustomer(Customer customer)
{
orderDomain.UpdateCustomer(customer);
}
}
}
This is the actual implementation of the service that implement the interface mentioned above, and each method simply use the domain class to do its work. The decoration (attribute) of the service class is needed to make the service available for a Silverlight 2 client. Even if no such client exist for Windows Mobile yet, this is a good measure to prepare for the future.
Another similar measure is to include two more files in the service project, and the first is clientaccesspolicy.xml and the second is crossdomain.xml. The purpose of these files is to make the service available for applications that make cross domain calls, and the first is specific to Silverlight and the second is used by Flash applications, among others. Here is a sample clientaccesspolicy.xml file...
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*" />
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
...that allow any client to access the service. A final measure that is necessary for both Silverlight and Windows Mobile WCF clients is to make sure that the service use the basicHttpBinding, and here is an extract of the Web.config file:
<system.serviceModel>
<services>
<service behaviorConfiguration="Kiss.Service.OrderServiceBehavior" name="Kiss.Service.OrderService">
<endpoint address="" binding="basicHttpBinding" contract="Kiss.Service.IOrderService">
In the next part, I will start implementing the Windows Mobile client.
Subscribe