Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Enhance Your Multi-tier Applications with the Windows Communication Foundation

By making simple modifications to XML-based WCF configuration files, you can add security, transactability, and reliability to multi-tier applications nearly instantly.


advertisement
n the previous articles in this series, you received a primer on the Windows Communication Foundation, before moving on to look at the fundamental aspects of the framework insofar as security, transactability, and reliability were concerned. The logical next step is to look at an example of a real-world system (albeit cut down for brevity) that demonstrates these principals in practice. A typical real-world system is built on an n-tier architecture; each tier has a specific role to play. Typically, when an application developer is implementing these tiers, they have to spend considerable time developing many of the non-business logic aspects of the tier, such as reliability, transactability and security. Each of these are fundamental aspects of the Windows Communication Foundation that developers can quickly and easily implement, thus letting them spend more time implementing business logic.

Figure 1 shows a typical four-tier architecture. At the top is the resource tier, usually involving a database or similar information engine. Directly beneath this is a data-access layer (DAL) that abstracts access to the raw resource layer. This abstraction strengthens architectures, removing the brittleness that is associated with tightly bound resource tiers. If, for example, the middleware or front end layer of your application is tightly bound to SQL Server 2000, upgrading to SQL Server 2005 may involve tinkering with a existing code that contains your core business logic. Using a DAL, however, a service abstracts the database behind it. A Web service is an implementation-independent abstract entity that defines its underlying logic. WCF services are no different. Therefore, it makes a lot of sense to abstract the resource tier behind a Web service; and if you ever need to change the resource tier, you would simply create a new service that binds to the same contract as the original, and all of the business logic that is "underneath" the Web service—namely your core business and presentation logic will be unaffected.

 
Figure 1. Application Tiers: The figure shows desirable characteristics for each tier in a typical four-tier application design.
Configuration, Configuration, Configuration
When building an abstract interface to the data and resource layer reliability is key. Before the dawn of WCF, developers would have had to have written many hundreds, if not thousands of lines of code to ensure that the interface between the business logic and the data-access layers were reliable. Code to ensure that the payload was delivered accurately, in the correct order, without falsification is paramount. With WCF, you can concentrate on implementing your business logic, and let the framework handle the reliability concerns, based on standard WS-Reliability algorithms. You simply configure the endpoints of your service for reliability and the ServiceModel takes care of the rest. In many cases you'll want this layer to be transactable too, safely handling large amounts of data. Again, in WCF you can handle transactability simply through configuration.

The presentation layer, in turn has to communicate with the business logic layer. In this case, security is important, as the presentation layer is exposed to many users, not all of whom you want to have accessing your core business logic. In the loosely coupled world of services, you would need to implement security algorithms by hand, or use technology such as WSE 3.0. With WCF, this is all abstracted away from you. You write your application to do what it needs to do, and security is handled for you in the ServiceModel. You simply need to configure it. This article walks you through the process to build a very simple and lightweight application that exhibits the above architecture. You will see where, step by step, you can add security to the interface between presentation and business logic, and reliability between the business logic and data access. You'll look at the SOAP messages being passed between them, and from here glean the raw power that is at your disposal when using the Windows Communication Foundation!





Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap