David Pallmann's Blog: WCF

Service Pass-Through in Neuron ESB

Wed, 07 May 2008 01:37:39 GMT

Service Pass-Through in Neuron ESB

Today I’d like to talk about how you can connect your services (and clients) to pass message traffic through an ESB, rather than directly connecting to each other. We call this “service pass-through”.

Why Service Pass-Through?

Before getting into how this is done, let’s explore why you might want to.

Loosely-coupled routing. Imagine you have a client that interacts with a service (Figure 1a), but now you have a requirement to involve a third program that also needs to know about the information the client is exchanging with the service. How do you bring this third system into the mix? A conventional answer is to either make the original service a client of a new service (Figure 1b); or make the original client a client of two services (Figure 1c).

Figure 1: interconnecting services in code is not loose coupling

Neither of these answers is very satisfactory because they force you to tightly couple your routing. If you are a fan of SOA and value loose coupling in other areas of your work, this tight coupling of how your services are linked should offend you.

In contrast, if your client and service are have an ESB interposed between them (Figure 2), the ESB can share information with other messaging parties. This approach helps keeps your services pure, context-free and reusable, as you don’t have to add program code to link services together.

Figure 2: passing service traffic through the ESB easily accommodates additional parties.

Mediation of differences. You might have clients and services that can’t interact directly because they aren’t quite compatible, due to differences in transport, security model, message format, or semantics. You can connect each of them to an ESB, however, and the ESB can then interconnect them, mediating between their differences.

Figure 3: Mediation bridges differences in protocol, security model, message format, semantics

Workload Sharing. The ESB can work with multiple instances of services and share workload across them. You can freely add services instances or take them away while running; workload distribution automatically adjusts.

When Worlds Collide. You can get services and non-services to work together. Neuron interconnects easily to services and clients using WCF. Neuron also interconnects to non-services such as legacy system and line-of-business systems using adapters. Once joined to the ESB, these programs can interact even though there be huge gap between the technologies they are use and when they were created.

Auditing and Compliance Monitoring. You may want to keep an audit of your messages in order to show compliances with state, federal, or industry regulations. If your messaging traffic flows through the bus, the bus can take care of the rest.

Figure 4: Both services and non-services can work cooperatively

The Mechanics of Service Pass-Through

When you define a service to Neuron (usually by importing metadata), one or more service endpoint definition(s) are created. By itself, a service definition is nothing more than an interesting record in a repository. I blogged yesterday about how you can use this repository to create WCF clients based on central configuration.

Things get more interesting when you authorize service-pass through for your service definition. You can enable service pass-through for the client-side and/or the service-side, as shown in Figure 5.

Figure 5: A service definition with client- and service-side pass-through enabled

Enabling client-side pass through causes Neuron to create a client connector, which is a hosting service for clients. This hosting service looks just like the client’s actual target service, with the same binding and security model. The only difference is that you point the client to a different address on the ESB Server. Client-side pass- through maps incoming client messages to an ESB topic and to a publisher. As client messages are received, the ESB publishes those messages on a topic. Any party with a subscription to that topic receives a copy of the message. This works for both 1-way and request-reply messaging.

Enabling service-side pass through causes Neuron to create a service connector, which is a client to the service used by the ESB Server. This client has a matching binding and security model for the service it is connecting to. The service connector is mapped to a topic and a subscriber. As messages are received over the ESB, the service connector passes them on to the service. Replies from the service are passed back over the bus to the originating client.

For true client-service pass-through, you would enable both client-side and service-side pass-through. In some scenarios, you may choose to only enable one side or the other.

Notice that in service pass-through, you aren’t asked to modify your client and service in any way, other than to change the address the client points to.

Service pass-through the ESB avoids tightly-coupled routing and keeps your services more modular and reusable. It allows for mediation between program differences and allows services and non-services to interact.

Data Binding a Grid View to a WCF Service with Paging and Sorting Support

Wed, 17 Oct 2007 18:56:57 GMT

I've recently done some real-world project work with data binding against WCF services, including supporting grid view controls with paging and sorting, and thought I'd share my experiences. I started off using the ASP.NET GridView Samples on MSDN and this gave me a big head start.

Project Background

First, some background. In a recent project, a 2-tier ASP.NET web site was being refactored to include a 3rd tier of WCF business services. The original design had a web presentation tier and data tier only. The ASP.NET pages used LLBLGEN (a popular ORM) for data access. In the new design, the goal was to add a business services tier and not use the ORM at all in the web pages. Rather, the web pages would call business-oriented service methods with operations tailored to make it easy for the web pages to work with. The ORM code was moved to the service tier. The result is a better arrangement of software layers, simpler code, and exposes much of the project's code assets for reuse elsewhere in the company.

All well and good, except the web site uses data grid views extensively. The majority of the pages show information in Telerik RadGrid grid views, with paging and column sorting. The original implementation simply used the Object Data Source (ODS) that came with LLBLGEN, with paging end sorting enabled. Users were free to navigate through result pages and sort columns any way they wanted to interactively. The LLBLGEN ODS would do the appropriate things to pass just the data needed, sorted appropriately. The problem this posed in the refactoring is that we wanted the presentation tier to be very unaware of the implementation details encapsulated by the business services. Yet we needed to provide users with the same interactive behavior they were already used to.

A lengthy philosophical discussion ensued, where various strategies were considered. Whatever approach we chose, we were going to be doing this over and over for many kinds of business entities, so we wanted to get it right the first time. How should business services be designed when user-directed paging and sorting are needed? One possibility we considered was to have services return a complete result set, but keep a snapshot of the result set at the presentation tier, perhaps in session state. Then paging and sorting would work off of that "local" data snapshot. We quickly rejected that approach, at least for this particular customer and project, because customers can perform searches yielding perhaps thousands or tens of thousands of matches and may only glance at one or two pages of the results. Given that behavior, we couldn't justify transferring the full result set to the presentation tier. Next we considered the alternative path of maintaining the notions of paging and sorting in our service contracts. It took awhile to decide how we felt about passing parameters like start row, max row count, and sort column name to a business service method, but we are now convinced this is a good and correct thing to do when your consumer is an interactive control along the lines of a grid view. This is the approach we adopted.

Grid View Control Data Binding

Binding a grid view control to the object data source is simple. The object data source is declared, including specifying the names of key methods.

<asp:ObjectDataSource ID="ContactsDataSource" Runat="server" TypeName="Contoso.Services.ContactServiceDataSource" SortParameterName="SortExpression"
SelectMethod="SelectRecords" EnablePaging="True" SelectCountMethod="TotalRecordCount" >
</asp:ObjectDataSource>

Binding a grid view control to the object data source is simple. The GridView element's DataSourceID attribute identifies the ODS. We also turn on paging and sorting of the grid by seeting the AllowPaging and AllowSorting attributes to true.

<asp:GridView ID="ContactsGridView" AllowPaging="True" BorderColor="White" BorderStyle="Ridge"
CellSpacing="1" CellPadding="3" GridLines="None" BackColor="White" BorderWidth="2px" PageSize="20"
AutoGenerateColumns="False" DataSourceID="ContactsDataSource" Runat="server" AllowSorting="True">
<FooterStyle ForeColor="Black" BackColor="#C6C3C6"></FooterStyle>
<PagerStyle ForeColor="Black" HorizontalAlign="Right" BackColor="#C6C3C6"></PagerStyle>
<HeaderStyle ForeColor="#E7E7FF" Font-Bold="True" BackColor="#4A3C8C"></HeaderStyle>
<Columns>
    <asp:BoundField HeaderText="Contact ID" DataField="ContactId" SortExpression="ContactId"></asp:BoundField>
    <asp:BoundField HeaderText="Group Name" DataField="GroupName" SortExpression="GroupName"
DataFormatString="{0:c}">
      <ItemStyle HorizontalAlign="Right"></ItemStyle>
    </asp:BoundField>
    <asp:BoundField HeaderText="Group Since" DataField="GroupSince" SortExpression="BusinessEmail"
DataFormatString="{0:d}">
      <ItemStyle HorizontalAlign="Right"></ItemStyle>
    </asp:BoundField>
    <asp:BoundField HeaderText="Business Phone" DataField="BusinessPhone"></asp:BoundField>
</Columns>
<SelectedRowStyle ForeColor="White" Font-Bold="True" BackColor="#9471DE"></SelectedRowStyle>
<RowStyle ForeColor="Black" BackColor="#DEDFDE"></RowStyle>
</asp:GridView>
<i>You are viewing page
<%=ContactsGridView.PageIndex + 1%>
of
<%=ContactsGridView.PageCount%>
</i>

Object Data Source

To create an object data source with paging and sorting turns out to be pretty straightforward. You implement a select method that accepts a start row, max row count, and sort column name parameter. In the code listing below, SelectRecords is the method and there are 4 overloads. The client control will call the most appropriate based on whether features like paging and sorting have been enabled. SortRecords calls FetchData in this code, which is responsible for fetching the requested information and returning it in the form of a dataset. FetchData calls a business service method. The service method has both search criteria parameters (a contact ID in this case) as well as the start row, max row count, and sort column parameters. By simply adopting the Object Data Source model down through the service tier, we end up with small and simple code.

We decided to return the results in a dataset so that we could reuse this technique in a lot of different settings. Not everyones likes the idea of combining datasets and services, but I've found it to be very useful in scenarios where your services and clients are all internal to the same organization.

Just returning a page of results isn't quite enough to make things work, as it turns out. Controls such as the grid view control or the Telerik Rad Grid control can't intelligently show you the number of pages available without knowing the total record count, so it's necessary for a service call to return both a single page of results but also the total record count of the selection. We handled this by making the result dataset contain the page of result data in Tables[0] and the total record count in Tables[1]. The second table contains just one value in a single row, the total record count. The method TotalRecordCount is called to get the total record count.

/// <summary>
/// Object Data Source - calls contact service methods to collect contact data, with paging and sorting support.
/// </summary>

public class ContactServiceDataSource
{
// Copy of last result set. Table 1 is result data, Table 2 contains record count.

private DataSet SelectionDataset = null;

// Retrieve page of results.

    public DataTable SelectRecords()
    {
        return SelectRecords(int.MaxValue, 0, string.Empty);
    }

    public DataTable SelectRecords(int maximumRows, int startRowIndex)
    {
        return SelectRecords(maximumRows, startRowIndex, string.Empty);
    }

    public DataTable SelectRecords(string SortExpression)
    {
        return SelectRecords(int.MaxValue, 0, SortExpression);
    }

    public DataTable SelectRecords(int maximumRows, int startRowIndex, string sortExpression)
    {
        SelectionDataset = FetchData(maximumRows, startRowIndex, sortExpression);
        return SelectionDataset.Tables[0];
    }

// Fetch data.

    private DataSet FetchData(int maximumRows, int startRowIndex, string sortExpression)
    {
        ContosoContactClient contactClient = new ContosoContactClient("ContosoContactService");
        DataSet results = contactClient.GetGroupContactsByContactId(ContactId, startRowIndex, maximumRows, sortExpression);

return results;
}

    // Return total record count.

    public int TotalRecordCount()
    {
        try
        {
            if (SelectionDataset == null)
                return 0;
            else
                return Convert.ToInt32(SelectionDataset.Tables[1].Rows[0].ItemArray[0]);
        }
        catch (Exception ex)
        {
            LogException(ex);
            return 0;
        }
    }

Service Contract

The service contract operations that are consumed by an object data source include the parameters for start row, max rows, and sort column. The implementation code, of course, has to make good on these criteria. This is fairly easy to do with a SQL Server Stored Procedure or, in the case of this project, an ORM like LLBLGEN.

    [ServiceContract]
    public interface IContosoContactService
    {
        [OperationContract]
        ...

        [OperationContract]
        GroupContactCollection GetGroupContactsByContactId(int contactId, int startRow, int rowCount, string sortColumn);
    }

I won't go into the mechanics of the service method implementation here, as it was done by another developer and is ORM-specific. Without an ORM you would have a SQL Server stored procedure pull the results, then pass back just the total record count and the requested page worth of result data.

The end result of all this is that we've moved the project to a 3-tier service-oriented application design without losing the interactive capabilities (grid paging, sorting) or the efficiency of data movement we had in the past. Although it took a bit of puttering the first time around, the Object Data Source approach is straightforward and the code we've ended up with is small and simple.

WCF Tips #7 - Clients

Wed, 26 Sep 2007 03:31:38 GMT

David Pallmann’s WCF Tips #7 - Clients

Clients

Use a Robust Client

Tip: Don’t use generated proxy clients, which make no provision for recovering from errors. Use robust client code that retries failed communications on time-out and re-created proxies on communication failures.

Rationale: Generating a WCF client from metadata is easy and gets you started quickly. Unfortunately, this code does not handle errors. In real-world solutions, WCF clients need to do the following:

· Retry on minor failures: A minor failure such as a time-out should not abort processing; a limited number of retries is in order before giving up on an access. Code a small (and configurable) retry count and re-issue invocations after minor failures.

· Recreate proxy on major failures: A major failure such as a faulted communication object should result in re-creation of the proxy to the service, then a retry as described above.

WCF Tips #6 - Instrumentation

Wed, 26 Sep 2007 03:30:55 GMT

David Pallmann’s WCF Tips #6 - Instrumentation

Instrumentation

Enable Metadata Reporting

Tip: WCF services can be self-describing by automatically generating metadata. This is not enabled by default , so remember to enable metadata reporting in your service configuration.

Rationale: Service metadata is what allows clients to easily generate proxies. There are few reasons to suppress metadata other than some extreme security scenarios. As a general rule, enable metadata reporting for your services.

What if I Don’t? Would-be consumers of your service won’ t be able to generate client proxy code. Some may choose not to use your service as a result.

How to do it:

Enable WMI Instrumentation

Tip: WCF is richly instrumented to report status information via Windows Management Instrumentation (WMI). This is not enabled by default, so remember to enable it in your service configuration.

Rationale: Enterprises frequently invest in monitoring tools to track the health and activity of systems and applications. Windows Management Instrumentation (WMI) is a popular way to report such information and is support by a wide variety of monitoring product such as Microsoft Operations Manager and HP OpenView.

What if I Don’t? Enterprise monitoring will be largely blind to the existence and health of your services.

How to do it:

<system.serviceModel>
<diagnostics wmiProviderEnabled="true" />
</system.serviceModel>

WCF Tips #5 - Infrastructure

Wed, 26 Sep 2007 03:30:00 GMT

David Pallmann’s WCF Tips #5 - Infrastructure

Infrastructure

Right-Size Your Infrastructure

Tip: Make use of some service infrastructure, and size it right. In particular, make up for areas WCF doesn’t provide strong support for, such as loosely-coupled routing and centralized management.

Hint: The extremes of no infrastructure at all and a bloated infrastructure are to be avoided.

Rationale: If a company is seriously pursuing SOA, there are going to be a lot of services and clients eventually. There is going to be a need for some infrastructure to complement the business services. UDDI directories, message brokers, and Enterprise Service Buses are all examples of SOA infrastructure. With good SOA infrastructure in place, the configuration of services and their interconnections can be managed centrally at the enterprise level.

SOA infrastructure services should be as thin as possible (a “thinfrastructure”), expanded as needed, and build solidly on service standards. Infrastructure services can serve purposes such as these:

· Directory of services

· Message router

· Message transformation

· Rules service

· Workflow host

· Integration adapter

· Activity monitor

What if I Don’t? You’ll lose the flexibility to provide good change management. Failure to provide any SOA infrastructure eventually results in a set of clients and services that work together as initially designed but can’t easily be changed individually.

Use a Discovery Mechanism to Locate Services

Tip: Find other services using a discovery mechanism, such as a directory.

Rationale: The default way WCF clients identify services is to define their endpoints in an application configuration file. This can become unwieldy if there are a large number of services and clients in use. A better approach is to have clients locate services through a discovery mechanism.

Possible discovery mechanisms include the following:

· Direct Discovery: Use a protocol such as WS-Discovery over UDP. A client broadcasts a search request and matching parties respond. Because we don’t have this capability in WCF yet, this is not a recommended technique.

· Registry Discovery: Service information is contained in a registry, such as a UDDI registry or a custom “locator service”. Clients query the registry to find an appropriate service to talk to.

· Mediated Discovery: Services and clients interconnect through an intermediary, such as a Message Broker an Enterprise Service Bus (ESB). The intermediary puts clients and services together.

What if I Don’t? If each client and service has to be configured locally, you’re going to find it difficult to view or modify your configuration from an enterprise-level perspective.

Use a Loosely-Coupled Routing Mechanism

Tip: Avoid tying services together directly. Use a configurable routing mechanism to connect clients in a loose-coupled fashion.

Rationale: WCF is a great technology that champions loose-coupling, but it makes no provision at all for loosely-coupled routing. If a service in turn becomes a client of additional services, you have a tightly coupled situation. Instead, each service should exist on its own as a truly reusable component. The interconnections between services should be handled by a flexible router. Routing can be accomplished by an Enterprise service Bus, or a Message Broker such as BizTalk.

What if I Don’t? You’re going to run into the classic point-to-point problem, where it becomes more and more expensive to integrate and manage systems. Help them find each other with a good discovery mechanism.

WCF Tips #4 - Configuration

Wed, 26 Sep 2007 03:29:00 GMT

David Pallmann’s WCF Tips #4 - Configuration

Configuration

Challenge the Default Settings

Tip: Learn the appropriate knobs to turn to make WCF perform for you. Don’t assume the defaults are best, in many cases they aren’t. Specifics are addressed in several related tips.

Rationale: Some of the default settings in WCF are great. Some of them aren’t. Some of them, in the name of being secure out-of-box, prevent you performing useful work!

What if I Don’t? Your production deployments will fail.

Examples:

· Instancing: the default is Per Session, but you’re better off writing stateless services.

· Bindings: default quota settings severely limit message size, depth, and complexity.

· Service Hosting: default settings limit the number of concurrent clients and sessions.

Choose the Right Binding for the Right Purpose, then Fine-Tune it

Tip: Use the correct binding for your endpoints. First choose the right general binding. Then fine-tune the binding for its purpose.

Rationale: A binding is a pre-packaged profile that controls a great deal about how communication will take place. The key characteristics of a binding are transport and security model, but there is much more under its control. The choice of binding also affects reliability, transaction support, and quota settings such as maximum message size.

It’s first and foremost important to select the right general binding. The importance of these factors will point you to the right binding to use.

1. Desired interop level.

2. Desired security model.

3. Desired reliability.

4. Desired transport.

5. Desired transaction support.

Secondly, you should fine tune your binding. Just because a binding supports your preferred security model, reliability level, or transaction capability doesn’t mean those things are enabled by default. Get acquainted with your binding’s properties and configure their values to fit your needs.

What if I Don’t? You’ll get the luck of the draw. Fortunately, it’s easy to change your mind about bindings down the road.

Example: A service is being created that must be accessible by a partner company. The partner company only has experience with

Configure Bindings to Enable Doing Real Work

Tip: Override the debilitating default properties of bindings so that you can get real work done.

Rationale: In the name of shipping “securely by default”, WCF Services have great limitations on the amount of work they can perform. To get real levels of work done in the enterprise requires overriding many default values. Some of these values are in the binding properties, while others are found in the ServiceHost object. There are limitations on message size, string size, XML depth, array length, and other areas that will make calls fail if not set to real-world values.

Of course, these limits were set with good intentions such as preventing denial of service attacks. Don’t override the binding properties with values larger than you need.

What if I Don’t? You’ll run into limitations at runtime, such as not being able to support large or complex messages.

Example: Here’s an example of overriding binding properties. This example is in code, but you can perform the equivalent in your XML configuration file. Be sure to use reasonable values for your needs, not Int32.MaxValue as shown. Refer to the documentation for the precise meaning of these properties.

NetTcpBinding binding = new NetTcpBinding();

binding.ReaderQuotas.MaxDepth = Int32.MaxValue;

binding.ReaderQuotas.MaxStringContentLength = Int32.MaxValue;

binding.ReaderQuotas.MaxArrayLength = Int32.MaxValue;

binding.ReaderQuotas.MaxBytesPerRead = Int32.MaxValue;

binding.ReaderQuotas.MaxNameTableCharCount = Int32.MaxValue;

binding.ReaderQuotas.MaxStringContentLength = Int32.MaxValue;

binding.MaxReceivedMessageSize = Int32.MaxValue;

binding.MaxConnections = 1000;

WCF Tips #3 - Service Hosting

Wed, 26 Sep 2007 03:27:56 GMT

David Pallmann’s WCF Tips #3 - Service Hosting

Service Hosting

Select a Service Hosting Method that Best Suits Your Needs

Tip: Consider IIs and non-IIS hosting for services rather than just using the method more familiar to you. Leverage IIS hosting if you need its features (such as health monitoring) and your customers are willing to deploy IIS. Use direct hosting, such as in a Windows Service Application, if more appropriate. Note: the author hosts WCF services in Windows Services nearly all the time.

Rationale: Previous Microsoft communication technologies tend to have a single hosting model, but WCF services can be hosted either in IIS or by the developer’s own code (essentially from any managed code environment). Developers should be aware of their hosting options and use the most appropriate one for their scenario.

IIS-hosted services provide a number of compelling features, including automatic activation, health monitoring, process recycling, compile-on-demand, and the ability to update the application or its config while still running. IIS also makes it easy to accomplish some things that are hard to do in code, such as supporting SSL. However, IIS also has some limitations. Not all customers are willing to deploy it. You are limited to the HTTP/S transport (unless using IIS 7.0). And the periodic process recycling that IIS/ASP.NET undergoes can sever a client’s session and security content unexpectedly.

Hosting a service yourself gives you more control over the lifetime of the service, but at the expense of the aforementioned IIS feature s unless you have an alternative implementation. Many developers and I.T. personnel find using a Windows Service Application more attractive. Neudesic provides a universal service host implemented in a Windows Service Application container, written by Chris Rolon.

What if I Don’t? You may be taking the hard way if you aren’t familiar with all of your options.

Examples:

· A service is being created that is public-facing and must use HTTPS. The developer chooses to host the service in IIS because it is easiest to set up the SSL certificate that way.

· A service is being created that has a dependency on several other services running on the same machine. The developer decides to host the services in Windows Service Applications so that the Windows Service Controller can enforce the dependencies.

Configure ServiceHost to Enable Doing Real Work

Tip: If hosting your service directly, configure your ServiceHost object. Override the debilitating default properties so that you can get real work done.

Rationale: In the name of shipping “securely by default”, WCF Services have great limitations on the amount of work they can perform. To get real levels of work done in the enterprise requires overriding many default values. Some of these values are in the ServiceHost object, while others apply to the binding of endpoints.

Of course, these limits were set with good intentions such as preventing denial of service attacks. Don’t override the ServiceHost properties with values larger than you need.

What if I Don’t? You’ll run into limitations at runtime, such as not being able to support more than 10 clients at a time.

Example: The author routinely initializes a ServiceHost object this way:

// Set throttling permissions to allow many concurrent service connections.

public static void SetServiceHostThrottle(ServiceHost host)

{

ServiceThrottlingBehavior throttle;

throttle = host.Description.Behaviors.Find<ServiceThrottlingBehavior>();

if (throttle == null)

{

throttle = new ServiceThrottlingBehavior();

throttle.MaxConcurrentCalls = 1000;

throttle.MaxConcurrentInstances = 1000;

throttle.MaxConcurrentSessions = 1000;

host.Description.Behaviors.Add(throttle);

host.CloseTimeout = TimeSpan.FromSeconds(1);

}

WCF Tips #2 - Service Class Design

Wed, 26 Sep 2007 03:26:36 GMT

David Pallmann’s WCF Tips #2 - Service Class Design

Service Class Design

Separate Service Interfaces from Service Implementation Classes

Tip: Separate your service implementation class from your service interface definition, and put the implementation in its own class away from other code. Use the same names for both but prefix the service interface with an I.

Rationale: The core reason for using service orientation is that the public contracts can be maintained while the internal implementation is replaceable. Although WCF allows you combine a service contract and its implementation in the same class, doing so undermines this principle. Instead, treat both service contracts (interfaces) and implementation classes as important but separate entities. The relation between the two is explicit in the code (the service class x implements Ix), and also implied by their similar names (Ix is the interface implemented by x).

What if I Don’t? You’ll tie your interfaces to their implementations, defeating the primary reason to use service orientation. At some point you’ll need to reimplement something and regret it.

Example: A service is needed to track time clocking. The service contract is defined as interface ITimeClock and maintained in its own source file, ITimeClock.cs. The service implementation is defined as class TimeClock and maintained in its own source file, TimeClock.cs.

Consciously Select an Instancing Model

Tip: Make an up-front decision about which instancing model you will use (per call, per session, shared session, singleton) and specify it in a ServiceBehavior attribute, even if you are using the default instancing model of per session. Keep the instancing model clearly in mind as the class’s members are defined, backed up with comments where necessary. Base the decision on what will work best for your service implementation.

Rationale: WCF instancing is easy to specify and easy to change, using a ServiceBehavior attribute, but the code has to be written with a particular instancing model is mind. The consequences of changing instancing models without changing the code as to match can be severe. For example, a class member variable can be a global value or a client-specific value depending on the instancing model.

What if I Don’t? Your code likely won’t work correctly. Regrettably, this may not be immediately apparent until you have enough concurrent traffic.

Example: A developer creates a service, neither specifying an instancing model nor giving thought to one. Initial testing of the service with a single client appears to pass with flying colors. Later, when there are multiple clients accessing the service, serious problems arise because the use of class instances, member variables , and static variables was not in accordance with a specific instancing model.

Avoid Stateful Services

Tip: Where possible, avoid session state. Favor the Per Call or Singleton instancing modes. Stateful services should be the exception and stateless services the rule.

Rationale: Stateless services are far more versatile as a reusable software component. They are easier to scale, tend to have simpler implementations, and can be used in a broader set of contexts.

Be willing to make an exemption when you need to. Stateful services are sometimes necessary, which is why WCF supports them--but they should be the exception, not the rule.

Write Thread-Safe Code

Tip: Write thread-safe code, so your service can take advantage of multiple-thread concurrency (the default behavior). If it is not possible to write thread-safe code for some reason, be sure to set concurrency mode to single.

Rationale: There are few reasons today to write application code that is not thread-safe, and WCF’s default concurrency mode expects this. Use appropriate synchronization mechanisms to access shared resources. Multiple concurrency and thread-safe code will provide your service with the best performance, especially in a setting many clients.

What if I Don’t? Your code will run unsafely and/or inefficiently.

Avoid Lengthy Service Operations

Tip: Avoid lengthy service operations that may time out before they have completed executing. This is primarily a concern with 2-way operations where a client is awaiting results.

Rationale: WCF service operations can time out, and there are time-out settings on both the service-side and the client-side. You really have no good way to know how much time there is for your code to run before a time-out occurs somewhere, and once you venture past 30 or 60 seconds you are pushing your luck. A time-out is especially difficult to handle on the client-side of things. Did the service get the client’s request and process it or not? All the client knows is that a reply didn’t come back in time.

Approaches: If a service is returning a result list that may potentially be quite large, consider one of these solutions:

· Scope the Results. Design the service operation to allow input parameters that set a limit on the size of the results, such as a date range or a maximum record count.

· Results Chunking. Enforce a maximum result size and return a partial list of results. Provide a mechanism for the client to request additional chunks of the results.

· Deflate the Results. Return a subset of result fields to keep the size small, and offer a method to retrieve detail for select row(s).

WCF Tips #1 - Service Interface Design

Wed, 26 Sep 2007 03:23:51 GMT

David Pallmann’s WCF Tips #1 - Service Interface Design

Service Interface Design

Design Service Contracts that are Themed and Indivisible

Tip: Ensure service contracts have a theme (purpose). Avoid combining unrelated service operations in the same contract; only include operations that contribute to the theme. This is also a SOA best practice.

Rationale: A service interface is supposed to be indivisible—that’s why we use the word contract. If a service contract has a purpose or theme and all of the operations in the contract contribute to that theme, the contract design is likely to be strong and survive. In contrast, throwing many unrelated operations into the same service contract under a weak premise, such as “all the public services my company exposes to partners”, is not likely to stand the test of time.

What if I Don’t? The longevity of your service contracts may be compromised.

Examples:

· A bad example is a service whose theme is “Data Access”: this is far too vague a purpose for a service and invites every operation method that reads or writes to find a home here.

· Another bad example is a service whose theme is inventory control but contains operations for both inventory control and truck delivery routing. Although the theme is reasonable, the operations do not all contribute to the theme, threatening to fracture the service into multiple services down the road.

· A good example is a service whose theme is order placement, and whose operations pertain only to creating, updating, canceling, or inquiring the status of orders.

Design coarsely-grained methods

Tip: Your service should favor coarse methods that are called less frequently as opposed to granular methods called frequently. In other words, think chunky. This is also a SOA best practice.

Rationale: Invoking a WCF service operation has unknown expense. Factors affecting expense include transport, distance, security model, encoding, reliability level, and transactability. Therefore, the best practice is to always assume service invocations are costly and seek to minimize them.

What if I Don’t? Overhead will increase, possibly substantially.

Example: Your service needs to provide an operation for retrieving the transaction history of a client. A bad approach is to require a separate call to retrieve each individual transaction record. A good approach is to provide the full history as the result of a single call. An even better approach is to allow the scope of the results to be specified by the caller (such as a date range).

Take Advantage of One Way Operations

Tip: Use the most efficient messaging pattern for each operation. Don’t return a result if there is no use for it. Specify the asynchronous IsOneWay=true setting for an operation if a client doesn’t need to wait for the operation to complete.

Rationale: By default, a service operation is accessed in a request-reply pattern, and a client blocks after making a request until a reply has been received. This is true even if the return type of the method is void. However, service operations that don’t return a value can also be marked one way which allows a client to continue without waiting for a reply.

Example: Your service contract includes an operation named Archive which takes some time to execute. There are no results to return the client. You mark the operation IsOneWay=true so the client can initiate the operation without having to wait for its completion.

Use Data Structures Familiar to your Consumers

Tip: Use data types in service operations that are familiar to your clients.

Rationale: Often the designer of a service will have some notion of who the consumers will be. While this may be a diluted concept in the case of a public service open to the Internet, that is the exception rather than the rule. The majority of services are designed for consumption within a department, within a company, or within a company’s value chain or industry. Leveraging this knowledge results in a service contract design that is more natural to its consumers.

What if I Don’t? You’ll create unnecessary work for your consumers.

Example: A developer designs a service that will allow uploading of application forms. Because the intended consumers are in the health service industry, the developer supports an XML structure that is commonly used in the health care industry rather than inventing a new structure.

Maintain a Service Catalog

Tip: Create a catalog of available services and keep it up to date. This should include some machine-readable elements such as WSDL/XSD metadata, but also some human-readable documentation. Data structures should be defined and explained.

Rationale: If SOA is being seriously pursued in an organization, awareness of the services exposed by various projects is critical. A central catalog provides a single go-to place to learn about available services.

What If I Don’t? The left hand won’t know what the right hand is doing.

WCF Sample: Peer-to-Peer Digital Whiteboard

Tue, 08 Aug 2006 17:35:06 GMT

To read the original article with downloadable code, go to http://www.NetfxExperts.com/wcf.Whiteboard.aspx

A WCF-based Digital Whiteboard sample originally appeared in Chapter 15 of Programming Indigo and has been rewritten for the July CTP. Whereas the original used duplex communication and routed communication through a central server, this version uses WCF PeerChannel and requires no server.

The sample is a WinForms client. Multiple parties can participate in a meeting, and there can be any number of meetings. Once you join a meeting, you can apply lines, rectangle, circles, and text to the whiteboard. You can also send chat messages to others in the meeting.

This application does require a resolver service to be running, which all peers use to enter/leave the peer-to-peer conversation mesh. Use the custom peer resolver from the SDK sample.

Design Patterns in WCF: Service Locator

Mon, 07 Aug 2006 22:53:07 GMT

Read original article with downloadable code on NetfxExperts.com

The Service Locator design pattern is a service that serves as a registry of other services. With a Service Locator, clients for services can make dynamic inquiries to locate a target service instead of relying on their own local configuration.

The simplest implementation of Service Locator might look up a service by a single characteristic, such as a name, and return its address. Far more useful is the ability to look up a service based on multiple properties and to return not just address but other connection information such as contract, binding, and security model.

The Service Locator code example is implemented with WCF (July CTP) and allows for multiple properties of services, including those below. The list of properties can be easily extended.

environment - a deployment environment, such as 'staging' or 'production'.
zone - a subdivision of an environment, such as 'intranet' or 'dmz'.
contract - the name of the interface the service implements, such as 'IPurchasing'.
address - an endpoint address for the service, such as 'http://server15/purchasing/'.
binding - the binding profile to use to access the service, such as 'wsHttpBinding'.
security - the security mode to use to access the service, such as 'Windows' or 'None'.
reliable - whether or not reliable messaging is enabled ('True' or 'False').

The sample stores the service information in an XML file, but it would be a simple matter to use a database or some other repository. The sample hosts the Locator Service as a Windows NT service.

Service Definitions
Servie definitions are stored in XML entries as shown below. An outer serviceDefinitions element contains n service elements. The child elements of each service element define the names and value of properties describing the service. To add new elements, simply insert additional child elements in the XML. However, be sure to keep the collection of properties consistent among all services.

<?xml version="1.0" ?>
<serviceDefinitions>

  <service>
    <environment>Staging</environment>
    <zone>Intranet</zone>
    <contract>IInventory</contract>
    <address>http://staging-server/Inventory/</address>
    <binding>wsHttpBinding</binding>
    <security>Windows</security>
    <reliable>False</reliable>
  </service>

  <service>
    <environment>Staging</environment>
    <zone>Intranet</zone>
    <contract>IShipping</contract>
    <address>net.tcp://staging-server/Shipping/</address>
    <binding>netTcpBinding</binding>
    <security>Windows</security>
    <reliable>True</reliable>
  </service>

  <service>
    <environment>Production</environment>
    <zone>Intranet</zone>
    <contract>IInventory</contract>
    <address>http://server1/Inventory/</address>
    <binding>wsHttpBinding</binding>
    <security>Windows</security>
    <reliable>False</reliable>
  </service>

  <service>
    <environment>Production</environment>
    <zone>Intranet</zone>
    <contract>IShipping</contract>
    <address>net.tcp://server2/Shipping/</address>
    <binding>netTcpBinding</binding>
    <security>Windows</security>
    <reliable>True</reliable>
  </service>

</serviceDefinitions>

The Locator Service

The sample implements a service with two service operations: ListAllServices, and FindService.

ListAllServices returns property information for all defined services. The properties are returned as an array of ServiceProperty, a simple structure with a key (name) and value. The client can examine the returned connection properties such as address and binding to learn where and how to connect to a target service.

FindService returns information on services that match criteria specified by the caller. To specify criteria, the caller submits an array of service properties. For example, a client searching for a service in the Production environment that implements IOrderEntry would specify two service properties. ("Environment", "Production") and ("Contract", "IOrderEntry").

Sample Installation and Setup

Download the LocatorService.zip file and extract its contents to a folder.
Open LocatorService.sln in Visual Studio 2005
Modify the service's App.Config file to reflect the name and location of the XML file that will contain service definitions. As downloaded, this file is c:\ServiceDefinitions.xml.

<applicationSettings>
  <LocatorService.Properties.Settings>
    <setting name="ServiceDefinitions" serializeAs="String">
    <value>c:\\ServiceDefinitions.xml</value>
    </setting>
  </LocatorService.Properties.Settings>
</applicationSettings>
Build the solution.
Install the Locator Service from a command line by navigating to the service's project output path and entering the command installutil LocatorService.exe.
Using Control Panel > Administrative Tools > Services > Services, start up the service and set its Startup Type to Automatic.