Tony Sneed's Blog

When I teach my DevelopMentor course on Entity Framework 4.0 and WCF Data Services, I use the Express Edition of SQL Server 2008 R2, but I have need for the SQL Profiler tool, which comes only with the full version and is needed to inspect what SQL is sent to the database. In addition, the setup folks often have a hard time getting the permissions right.  So I wrote a script that first installs just the tools from a trial version of the Developer Edition, which include both SQL Management Studio and SQL Profiler.  Then I wrote another script that installs just the database engine of SQL Express, adding the BUILTIN\Users account to the sysadmin role, which would enable users to to do various admin tasks such as attaching a database.

Here are the steps for these installations:

Developer or Standard Edition of SQL Server 2008 R2:

Trial Edition: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=de21dffd-4c6c-4963-b00c-5153cf7e41dd

– Click on the Eval X86 Executable link to download SQLFULL_x86_ENU.exe.

– Execute the file to extract contents to an installation directory, then run the following from an admin command prompt:

setup.exe /FEATURES=Tools /Q /INDICATEPROGRESS /ACTION=Install /INSTANCENAME=MSSQLSERVER /BROWSERSVCSTARTUPTYPE=Automatic /AGTSVCACCOUNT=”NT AUTHORITY\NETWORK SERVICE” /IACCEPTSQLSERVERLICENSETERMS

– This will install only the tools for SQL Server, including SQL Profiler.

SQL Server 2008 R2 Express Edition (database engine only):

http://www.microsoft.com/downloads/details.aspx?FamilyID=8b3695d9-415e-41f0-a079-25ab0412424b&displaylang=en

– Execute SQLEXPR32_x86_ENU.exe, then after the main screen is shown, copy the contents of the temporary directory to an installation directory. Run the following from an admin command prompt:

setup.exe /FEATURES=SQLEngine /Q /INDICATEPROGRESS /ACTION=Install /INSTANCENAME=SQLEXPRESS /BROWSERSVCSTARTUPTYPE=Automatic /AGTSVCACCOUNT=”NT AUTHORITY\NETWORK SERVICE” /SQLSYSADMINACCOUNTS=”BUILTIN\Users” /IACCEPTSQLSERVERLICENSETERMS

– This will install the database engine and add BUILTIN\Users to the sysadmin role

The complete list of SQL Server installation commands is available here.

O’Reilly has a program that provides online access to books that have yet to be published.  It’s called “Rough Cuts” and allows you to read chapters as they are written but before they are cleaned up for final publication, and it provides a discounted price for online and print editions.  Given the nature of technology and the speed of change, I find early access to be quite valuable.   Here are two books listed that I recommend ordering in their Rough Cuts version:

Programming Entity Framework Second Edition by Julia Lerman.  This includes coverage of Entity Framework 4.0 with samples in C#.

Programming WCF Services Third Edition by Juval Lowy, which covers new features in .NET 4.0.

Someone recently asked me this question:  When a company that has been using 2 tiers wants to move to n-tier, what are the considerations for choosing WCF and STEs [or Trackable DTOs] vs. WCF Data Services?

This is a great question because it relates to a recent re-alignment of what used to be called “ADO.NET Data Services” (code-named Astoria) under the umbrella of Windows Communication Foundation (WCF), as well as the renaming of .NET RIA Services to WCF RIA Services.  I’m going to steal an image from the .NET Endpoint blog, because it shows how each programming model rests on top of the infrastructure provided by WCF.

The two bottom layers should be quite familiar to anyone who uses WCF, but the diagram could mistakenly lead you to the conclusion that the programming model section is independent of the underlying Service Model and Channel layers.  The truth is that RIA Services rests on Data Services, which is turn sits on top of Web HTTP Services (aka REST), which is tightly coupled to HTTP as a transport and XML, Atom or Json as a format.  Only SOAP Services (leaving Workflow Services aside for the moment) can be used with any format and transport protocol.

Practically speaking, what this means is that there is a fork in the road when it comes to deciding how to implement an n-tier application architecture.  WCF SOAP Services (that is, traditional WCF) offers the most flexibility when it comes to selecting an underlying transport.  For example, I may want to use a NetMsmqBinding with clients and services that are occasionally connected.  The other way to go is to select a REST-based programming model, which leverages the universality of the HTTP protocol and uses a URI addressing scheme.  If flexibility concerning the transport layer matters to you, then traditional SOAP-based WCF services are the way to go.

Another differentiating factor is that WCF SOAP Services tend to be operation-based, while REST services are said to be resource-based.  That means clients are effectively going to call methods on a SOAP service, while client of a REST service are going to send HTTP requests (mostly GET’s) to a URI and expect to get some resource in return, usually a blob of XML, probably in a syndication feed format such as ATOM.  From an architectural perspective what this means is that service operations will be inherently more constrained than resources that are freely accessible.  Whether that’s good or bad depends entirely on your point of view.  If you want to design a service that is more tightly locked down, then you’ll most likely prefer a traditional WCF service.  On the other hand, if you want to freely make your data available to clients (especially clients that may not understand or care about SOAP), you would get more bang for your buck with a REST-based service.

Traditional WCF services are also going to allow you a more advanced level of security (for example, message-based or federated security), and can offer reliable messaging and transactional services.  That’s because WCF supports the WS-* SOAP protocols that have evolved over the last several years.  On the other hand, you may not need or want any of those features.  If your client is mainly an AJAX web app, or even a Silverlight rich Internet app, then REST-based services are all you need, and you can benefit from tight coupling with HTTP.

From reading this post so far, you might get the impression that I favor traditional WCF services over REST-based services.  And if we were only talking about a service programming model, you might be right.  But Microsoft has done a lot of work on the client-side programming model for Data Services.  All you have to do for a .NET client is simply write a LINQ query, and Data Services will translate it to a URI sent to the service.  The resulting XML is used to populate client-side entities, which are change-tracked.  Heck, it even supports batch updating and concurrency control. Sweet.  And WCF RIA Services strives for RAD n-tier development for Silverlight apps, with support for end-to-end data validation and a whole bunch of other goodies.  In addition, these higher-order programming models allow you to blend in an operation-based approach by adding methods to your data service.

So I suppose your choice between SOAP and REST services will depend a great deal on the architectural objectives dictated by your application requirements.  Alas, there’s still a role for the architect in all of this. 🙂

Additional Resources:
White Paper on RESTful Web Services with WCF 3.5
Scott Hanselman Interview with Pabro Castro on OData
Open Data Protocol (OData)
WCF Data Services Team Blog
Entity Framework 4.0 and WCF Data Services 4.0 in Visual Studio 2010

I’m a self-admitted control-freak.  And when I add a service reference to a project pointing to a WCF service that exposes metadata, I would like more control over the code-generation process.  Not long ago I had a specific need to to this when creating a client-side T4 template for my Trackable DTO’s project with Entity Framework 4.0.  Instead of relying solely on “Add Service Reference” in Visual Studio to generate client-side POCO classes, I wanted to generate the classes myself, hooking into a change-tracking mechanism and injecting data binding code.

The way that Self-Tracking Entities in EF4 accomplishes this is to add a class library project with a T4 template the inspects an entity data model (edmx file).  The problem is that this class library assembly must then be referenced both by the service and the client, violating a tenet of service-oriented applications to share contract and schema but not class or assembly.  That way, the client could be completely ignorant of the persistence stack used (in this case Entity Framework), and there could be a cleaner separation of concerns.  The WCF service could use a data access layer (DAL) to abstract away persistence concerns, and the client could make use of a change-tracker that the service would have no interest in referencing.

And so I needed to generate client-side entities with data contracts using a T4 template that could read service metadata exposed as WSDL.  The way to do this would be to create a WsdlImporter referencing data contracts from a service.  The result would be a CodeCompileUnit, which I could reflect over using the CodeDom to generate class and member definitions.

private CodeCompileUnit GetMetadataCodeUnit(string mexAddress,
    long maxReceivedMessageSize, Type collectionType)
{
    Binding mexBinding = GetMetadataBinding(mexAddress,
        maxReceivedMessageSize);
    var mexClient = new MetadataExchangeClient(mexBinding);
    mexClient.ResolveMetadataReferences = true;

    var metadata = mexClient.GetMetadata
        (new EndpointAddress(mexAddress));
    var sections = metadata.MetadataSections
        .Where(s => s.Identifier.Contains("datacontract.org"));
    var metaDocs = new MetadataSet(sections);
    var wsdlImporter = new WsdlImporter(metaDocs);

    var schemaImporter = new XsdDataContractImporter();
    schemaImporter.Options = new ImportOptions();
    schemaImporter.Options.ReferencedCollectionTypes
        .Add(collectionType);
    schemaImporter.Import(wsdlImporter.XmlSchemas);
    return schemaImporter.CodeCompileUnit;
}

The GetMetadataBinding method creates a custom binding with a transport element that has been configured with the specified max received message size.

private Binding GetMetadataBinding(string mexAddress,
    long maxReceivedMessageSize)
{
    Uri uri = new Uri(mexAddress);
    BindingElement element = null;
    switch (uri.Scheme)
    {
        case "net.pipe":
            element = new NamedPipeTransportBindingElement();
            ((NamedPipeTransportBindingElement)element)
              .MaxReceivedMessageSize = maxReceivedMessageSize;
            break;
        case "net.tcp":
            element = new TcpTransportBindingElement();
            ((TcpTransportBindingElement)element)
              .MaxReceivedMessageSize = maxReceivedMessageSize;
            break;
        case "http":
            element = new HttpTransportBindingElement();
            ((HttpTransportBindingElement)element)
              .MaxReceivedMessageSize = maxReceivedMessageSize;
            break;
        case "https":
            element = new HttpsTransportBindingElement();
            ((HttpsTransportBindingElement)element)
              .MaxReceivedMessageSize = maxReceivedMessageSize;
            break;
        default:
            break;
    }
    if (element != null)
    {
        Binding binding = new CustomBinding(element);
        return binding;
    }
    else
    {
        return null;
    }
}

Here is a link to a simple Console app that tests the WsdlImporter code.  And here is a link to a project that implements it as a T4 template.

Enjoy.