MSDN Magazine - January 2009 - (Page 54)

Figure 5 Declarative WCF Service <ServiceContract x:Name="ICalculatorContract" Community Technology Previews (CTPs) roll out, Microsoft will deliver a developer-friendly designer experience for working with the XAML definition. In addition to the declarative service support and the WCF-based activities mentioned earlier, the .NET Framework 4.0 comes with several other lower-level WCF improvements. Some of these features make it possible to manage workflow services with the new “Dublin” extensions. These features include improved configuration, message correlation, durable duplex communication, durable timers, and Event Tracing for Windows (ETW) tracing integration. Other capabilities that add value when hosting your services in a managed environment include standard control endpoints and auto-start. You will hear more about these features in the months ahead. The Need for “Dublin” Now that you have the service contract defined in XAML, the next step is to define how you want to project the contract onto the wire. The .NET Framework 4.0 introduces the concept of a contract projection to separate the logical contract definition from the representation of the messages that are sent and received. This allows you to define a single-service contract that can be projected differently to support different messaging styles. For example, you can have one contract projection for SOAPbased messaging and another projection for REST/POX messaging, but both are based on the same logical service contract. Here’s how you can define a SOAP contract projection for the service contract just defined: In the real world, another challenging aspect of working with WCF and WF is figuring out where to host your services and workflows in a server environment. For WCF, the answer is usually pretty easy—the most common choice is IIS and the Windows Process Activation Service (WAS) in Windows Server 2008. Today, the combination of IIS and WAS provides several key features including process activation in response to incoming messages, process monitoring and health management, process recycling, CLR AppDomain integration, built-in security, and some basic management capabilities made available through IIS Manager and Windows PowerShell cmdlets. These combined features typically make IIS/WAS the right choice for hosting WCF services in a server environment because most folks don’t want to build that kind of stuff themselves. Although IIS/WAS provides a foundation for hosting WCF applications, it falls short in a few important areas. Its biggest shortcoming is in the area of service manageability. IIS/WAS doesn’t really provide any WCF-specific service management capabilities such as service tracing, monitoring, and diagnosing running service instances. For example, an administrator cannot currently list all the WCF services that are configured in IIS—it’s not possible to query the status of all the hosted services. IIS/WAS also Migrating Workflows to .NET 4.0 the new .NEt Framework 4.0 activity programming model required some significant changes to the core WF runtime. As a result, custom activities designed for the .NET Framework 3.0 and 3.5 won’t be able to run within a .NET Framework 4.0 workflow host without some special care. To facilitate interoperability, the .NET Framework 4.0 comes with a special Interop activity that makes it easy to wrap a custom .NET 3.x activity within a .NET 4.0 host. This approach doesn’t work for all .NET 3.x activities—it specifically does not work for root activities. Hence, when moving to Visual Studio 2010, you’ll need to redesign your workflows using the new workflow designer (because it has also changed extensively), then you can wrap custom .NET 3.x activities using the new Interop activity within your new workflow definitions. .NET 4.0 and “Dublin” With this contract definition and projection in place, you are able to implement the service logic in XAML. The root element for the XAML service definition is Service. The Service element holds the contract and projection definitions in the Service.KnownProjections child element. The service implementation goes in the Service.Implementation element (which is a declarative workflow). And finally, the service’s endpoint configuration goes in the Service.Endpoints element. Figure 5 shows the complete declarative service definition in XAML. One downside at this early stage is that there is no visual designer to help in building services declaratively. I hope that as the 54 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.