The Application: Resource Tier
The application is a simple request/response chat or bulletin board application. Hence the resource tier is a table in a database. In this case I've used SQL Server 2005. Here's the script to build the table (it's also in the downloadable sample code
/****** Object: Table [dbo].[IndigoChat] ******/
/****** Script Date: 02/08/2006 20:46:54 ******/
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
CREATE TABLE [dbo].[IndigoChat](
[MsgID] [numeric](18, 0) IDENTITY(1,1) NOT NULL,
[MessageText] [nvarchar](max) COLLATE
[MessageOwner] [nvarchar](max) COLLATE
[MessageTimeStamp] [smalldatetime] NULL,
CONSTRAINT [PK_IndigoChat] PRIMARY KEY CLUSTERED
([MsgID] ASC) WITH (IGNORE_DUP_KEY = OFF)
The preceding script creates a database table that contains an ID for the message, the text of the message, the name of the message owner and the timestamp when the message was sent. As this is a simple example, the message text is simply a large nVarChar
data type, as is the author (Message Owner) of the message. In a real system this would be a lot more sophisticatedthis is just to demonstrate the concepts.
The Application: Data-access Tier
|Figure 2. Creating a New Service: The figure shows the dialog where you can elect to create a new Windows Communication Foundation Service.|
The data-access tier is a Windows Communication Foundation service. If you've installed all the latest bits for WinFX, including the Visual Studio.NET add-ins, you'll simple be able to click File> New Web Site and get the dialog shown in Figure 2
|Author's Note: The Windows Communication Foundation is part of WinFX, hence the terminology.
Electing to create a new WinFX service results in a new Visual Studio.NET project that contains a bunch of files. The ones that you are interested in initially are service.svc
and its associated code file: service.cs
, found in the App_Code
The methods that you'll implement on this new service are:
- GetBackChat. This method reads all messages in the message archive after and including a specific message ID. When users connect to the chat system, their current state includes their most recently downloaded message ID. This function downloads the rest of the messages in the archive to them.
- InsertMessage. This method allows a user to insert a new message.
- GetMostRecentMessageID. This method gets the ID of the most recently posted message in the system. By comparing that ID to the most recent ID that users have in-state, you can determine whether they are up to date.
Remember that this service is part of the DAL that talks to the resource tier on behalf of the business logic. The client does not interface with the service directly. In this example, the InsertMessage
function requires knowledge of who is sending the message. It is part of the functionality of the business logic tier to establish that identity. In a real-world situation, the business logic tier would do much more, for example, checking permissions to see if a specific user can actually write to the chat database or just read from it, or in a multi-room environment, determine which rooms a user can access.
The WCF-based data-access tier is implemented as a service, and thus the API needs a service contract. This contract is defined by the IChatResource interface and implemented by the ChatResource class as shown in Listing 1
It is key that this layer must provide reliability. But as you can see in Listing 1
, there is no code that implements any form of reliability. So how do you achieve it?
This is the magic of WCF. Reliability characteristics (along with Transactability and Security as you will see later) can be implemented declaratively, through configuration rather than in code. The ServiceModel handles the rest. As shown below, the data-access tier service gains its reliability characteristics because of the configuration settings in its Web.config
file. The settings that establish the use of WS-Reliability are highlighted.
And that's all it takes to implement WS-Reliability for this service. In the download
you will find a text file (HttpSniff.txt
) that contains sniffed HTTP packets for a session using this application. Check out the SOAP packets for communication between the business logic tier and the data-access tier and you will see WS-Reliability in action. Pretty neat, huh?
You can see these from section #15
onwards in the HttpSniff.txt
file included in the downloadable code
. You should also take a look at the schema declarations for http://schemas.xmlsoap.org/ws/2005/02/rm
, which is the schema for WS-Reliable Messaging. This schema defines the soap tags with the "<r;
" prefix in the message, and if you compare these tags, such as <r:indentifier>
you'll see that you are implementing the reliability specification without coding explicitly for it.
Here's an example: