Day 3 – What’s New in WCF 4

Configuration is improved and is now similar to ASP.NET. 

• Convention over configuration allows default endpoint configurations to be created by the framework.  Those default endpoints will be very helpful for simple scenarios where you want to get going quickly without the overhead of the configuration.
• Empty binding names are defaults at the top of the config hierarchy.  Nice!
• Behaviors now follow config inheritance rules, just like ASP.NET configuration.
• Config-based activation.  SVC files are no longer required and can be replaced by config entries.  This is really cool if you have a lot of SVC files to manage.  As a result, you can replace 20 SVC files for example with a single config file.

Monitoring WCF Apps.

• AppFabric is integral to monitoring.  Search for Windows AppFabric to get an overview of this new product from Microsoft.  A dashboard is integrated into the IIS 7 console.  This is really nice and makes it easier to visualize than monitoring WCF performance counters in perfmon.  This does not replace specialty tools like Avicode Intercept Studio or BMC AppSight, but is better than nothing.

Message Pump as a Service.

• RoutingService is a new feature.  You host it like any other service.  It supports RequestReply, sessionful RequestReply, One Way, sessionful , and sessionful Duplex.  You build a message filter table that get evaluated at runtime.  The RoutingService then performs the actions as specified by matching filters.
• The filter table can be replaced at runtime to respond to network changes for example.
• Using a Routing Service enables scenarios like:
• Protocol bridging. Examples: net.tcp to basic http; soap 1.1. to soap 1.2.
• Security bridging.
• Alternate endpoints.  You can use this for failover routing.   This one got applauses.  Very cool!

Discovery

• Ad-hoc discovery.  Clients can multicast probe messages to discover services on the network.  Probe match messages are sent to the client in multicast.  The scale is limited by the transport being used.
• Managed discovery.  A discovery proxy receives unicast hello messages from clients.  Probe multicast messages are intercepted by the discovery proxy.  Disco proxy sends unicast messages to the clients that send out probes, at which points those clients now switch to unicast messages to the proxy. 
• New classes to look for.  ContractDescription, DynamicEndpoint, ServiceDiscoveryBehavior, AnnouncementService, UdpAnnouncementEndpoint, FindCriteria, and EndpointDiscoveryMetadata.
• Demo.  Client was able to respond to a service being taken down and re-discover where else it could go and start using a backup service that was brought online before taking down the primary service.  This was really cool!

It seems to me that managed discovery is the better model for enterprise discovery of services.  I can see applicability of discovery in the projects I am currently working on and simply the hub-and-spoke model we are currently using.

It is interesting to me that this functionality is similar to what BizTalk can perform with some ESB toolkit.   I can’t wait to see what models are going to emerge and what role BizTalk will play in a WCF 4 environment.

The demos on this got many applauses from the audience. 

Day 2 at the PDC – Impressions from the keynote

Well, Microsoft never disappoints on the second day of the keynote.  I was wondering why breakfasts had been suppressed and the traditional Universal Studios party taken away.  This morning’s keynote gave the answer.  All PDC attendees are receiving a brand new laptop, custom configured for developers.  NICE!!!!

Now on to my favorite talk.  Scott Guthrie spoke and showed Silverlight 4.  I no longer have an excuse to delay getting up to speed on Silverlight.  As far as business applications are concerned, there is a concerted effort to address typical concerns of business applications in Silverlight 4.  It is now available as a beta, and was announced as planned on being released first half of 2010.  Silverlight 4, here I come!

PDC08 – Day 1 Recap

Quite a few sessions were offered throughout the day.  I picked a few based on my interests, and wanted to share my take on some of my favorite sessions today (Monday 27 October 2008).

• Scott Henselman’s session (TL49 Microsoft .NET Framework: Overview and Applications for Babies).   This session was based on a set of demos centered around the BabySmash application; it ties into the current food court offerings of the .NET framework, and also included some elements of upcoming .NET 4.0 features.  OK - so what was so likeable about Scott’s delivery?  Well, he is used to speaking to audiences; after all, he hosts the Henselminutes podcast.  The other thing I really liked: he comes from the point of view that he is a develop who knows C#, but he is not an expert on Silverlight 2, the MS surface, or WPF for that matter.  And it is with this premise that he makes a convincing point that these technologies are not that hard to pick up.  Granted, he had some “insider” help.  Still, I could not help but think that he was rather convincing and effectively acting as an evangelist.  Great demos tying in a number of technologies, from WPF to Silverlight, and yes, even the Surface with its touch capabilities.  Thanks a bunch, Scott.
• Phil Haack on the ASP.NET MVC framework, with a segment on StackOverflow.com by Jeff Atwood (PC21 ASP.NET MVC: A New Framework for Building Web Applications).  This was a real good session too.  I have to admit I had not gotten a chance to look into ASP.NET MVC much, and this session filled my knowledge gap in no time.  I came to appreciate the ASP.NET MVC framework as another food vendor in the cafeteria; yes, it does not intend to replace the web form model, it only intends on providing an alternative model.  Effectively, this is an additional tool in the toolbox.  Use the Phillips head when you need a Phillips head.
  • Here is what I liked about it:
    • The developer has to know how HTTP works.  Not a bad thing in my book.  I have seen too many developers make mistakes in web forms because of their lack of understanding of HTTP.
    • It is naturally “search engine optimized” because of its alignment on REST principles.
    • Developers have to embrace HTML and in fact have complete control over the HTML being emitted.  I think Phil Haack’s analogy about transmissions is not bad at all.  Think of web forms as an automatic transmission, and think of ASP.NET MVC as a manual transmission.  Not a bad analogy indeed.
  • Here is where I think it falls short today:
  • Lack of support for bi-directional data binding.  In my experience, developers spend too much time pushing data into the UI and coding the events for the changes made to the data by the user.  Better bi-directional data binding is needed.  So it’s not there in ASP.NET MVC, but it is there in ASP.NET 2.0 and is also there in Spring.net.  As far as I understood during the session, however, bi-directional data binding is planned in future versions of the ASP.NET MVC framework.

Well, that’s it for day 1.

PDC 08 Keynote – A Lukewarm Mood

Well,

Here I am at my third PDC (I attended PDC03 and PDC05), and I have to say that the mood at the keynote was the most lukewarm I have seen in the last 3 PDCs.  Perhaps it had to do with the topic: cloud computing.  Not that developers don’t care about it, but I think it tends not to be foremost in developers’ minds.  Now I think of the operations people I work with, and I think they would be impressed in the advances that are being made in manageability within the Microsoft platform.

It’s eratly in this PDC, but my take on this so far is that we are in a transition PDC.  Developers are still absorbing or getting educated on a large number of technologies like ASP.NET MVC, LINQ, Silverlight 2.0, etc… This PDC might jsut be incremental, showing a glimpse of the direction in which Microsoft is heading, with opportunities for feedback from the developer community.

The rest of this week will tell.

.NET Assembly Versioning Lifecycle

While it may seem that versioning assemblies in .NET can be a black art, it really isn’t.  The difficulty lies in the lack of guidance in this area.  In fact, I had to read many blogs to put together an approach on a project I was working on a few years (see Suzanne Cook’s excellent blog post “When to Change File/Assembly Versions“). 

I recently moved to a new project and found that this guidance is still helpful.  As a result, I decided to share it because it is still something that is not discussed much, yet it plays an important part of the configuration management of a .NET application.

Version Attributes
The .NET framework makes available three (3) separate version attributes:

• AssemblyVersion.  As discussed in Assembly Versioning, the .NET runtime uses the assembly version number for binding purposes.  It is used for .NET internal purposes only and should not be correlated to the product version.
• AssemblyFileVersion.  Instructs a compiler to use a specific version number for the Win32 file version resource. The Win32 file version is not required to be the same as the assembly’s version number.
• AssemblyInformationalVersion.  “The attribute defined by this class attaches additional version information to an assembly” for documentation purposes only.  It is text-based informational version and typically corresponds to the product’s marketing literature, packaging, or product name.  This data is never used at runtime.

Example:
[assembly: AssemblyVersion("3.0.0.0")]
[assembly: AssemblyFileVersionAttribute("3.0.2134.6636")]
[assembly: AssemblyInformationalVersion("3.0.1")]

Version Formats
Version formats are suggested for the assembly version (AssemblyVersionAttribute), the file version (AssemblyFileVersionAttribute), and the “product number” (AssemblyInformationalVersionAttribute).

Assembly Version Format
Version information for an assembly (set by using the AssemblyVersion attribute) consists of the following four values, as described in the Version Class in the .NET framework documentation.

• Major Version. “Assemblies with the same name but different major versions are not interchangeable. This would be appropriate, for example, for a major rewrite of a product where backward compatibility cannot be assumed.”
• Minor Version. “If the name and major number on two assemblies are the same, but the minor number is different, this indicates significant enhancement with the intention of backward compatibility. This would be appropriate, for example, on a point release of a product or a fully backward compatible new version of a product.”
• Build Number.  “A difference in build number represents a recompilation of the same source. This would be appropriate because of processor, platform, or compiler changes.”
• Revision.  “Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. This would be appropriate to fix a security hole in a previously released assembly.”

The assembly version number is used internally by .NET and should not matter to anyone outside of the development team.

File Version Format
This is the actual file version (set by using the AssemblyFileVersionAttribute attribute) and it satisfies the following goals:

• It correlates the product binaries to the source files from which they were compiled (as long as labeling is performed in the source code control database)
• It allows for the re-creation of older builds.
• It clearly identifies upgrade and bug fix releases.
• It clearly identifies which version of the source code is in production.

The File Version could follow this format:

• Major Version. This is the internal version of the product and is assigned by the application team.  It should not change during the development cycle of a product release.
• Minor Version. This is normally used when an incremental release of the product is planned rather than a full feature upgrade.  It is assigned by the application team, and it should not be changed during the development cycle of a product release.
• Build Number. The build process usually generates this number.  Keep in mind that the numbers cannot be more than 5 digits.  One scheme for generating this number is what I call the ‘YearDaysCounter.’  The first 1-3 digits pertain to the day of the year on which the build is being performed.  It has the advantage of being sequential, going from 001 to 365 as time progresses through the year. The last 2 digits pertain to the iteration of the build for a particular day and thus allow a range of 01 through 99.
• Revision. This could be assigned by the build team and could contain the reference number of the migration to the production environment.  When it is not known yet, a 0 is used until the number is issued.

Product Number Format
This is the product number that is communicated to stakeholders outside the development and build teams (e.g. Application XYZ is on release “3.0.1”).  It follows the simpler 3-part format <major>.<minor>.<maintenance>.  The following guidelines are useful in changing the product version number:

• Major Release.  Increment this number when major functionality is being released.
• Minor Release.  Increment this number when alterations or enhancements to existing functionality is made and changes the end user experience.
• Maintenance Release: Increment this number when bug fixes are released or performance enhancements are made that exclude functionality changes or material ‘look and feel’ changes to the user interface.

Like the assembly version number, the product version number should be changed after going to production.  It is set by using the AssemblyInformationalVersion attribute.

Using the Enterprise Library Validation Block with WCF Asynchronous Operations

I was recently surprised to find out first hand that the Enterprise Library Validation Block throws a somewhat obscure exception: ArgumentNullException(“operation.SyncMethod”) when the WCF AsyncPattern is employed.

By debugging into the Enterprise Library source code (EntLib 3.1), I came to understand that the Validation Block was coded to handle synchronous service operations only (using the FaultContract<ValidationFault> attribute on the service operation signature .  In our case, some of our operations also implement the asynchronous pattern and we have Begin and End method pairs for each.

While I was aware that one-way operations do not allow faults to be returned, I was’t sure about asynchronous service operations (implemented as asynchronous on the service side).  I checked the .NET documentation and was able to confirm that FaultContract<T> is supported on service operations implemented asynchronously using the AsyncPattern property.   A difficult to find comment exists in the documentation of the FaultException(TDetail) Generic Class: “The FaultContractAttribute can be used to specify SOAP faults for both two-way service methods and for asynchronous method pairs.”  See http://msdn.microsoft.com/en-us/library/ms576199.aspx.

With this information in hand, I reasonned that I should be able to modify the validation block.  I made the code changes, ran the NUnit tests included in the validation block, and employed the modified assembly on our asynchronous service operations.  I made modifications to ValidationParameterInspector.cs and ValidationBehavior.cs.  The scope of the modifications included the following methods:

• ValidationParameterInspector.ValidationParameterInspector
• ValidationParameterInspector.BeforeCall
• ValidationBehavior.HasValidationAssertions

Note that the modifications apply to both EntLib 3.1 and EntLib 4.0.  The modifications are included below:

Changes to ValidationParameterInspector.cs

/// <summary>

/// Constructor to initialize <see cref=”InputValidators”/>.

/// </summary>

/// <remarks>

/// When the operation is a <see cref=”OperationDescription.BeginMethod”/> because it implements the

/// the <see cref=”OperationContractAttribute.AsyncPattern”/>,

/// it will cause the <see cref=”InputValidators”/> to have empty validators for the

/// <see cref=”AsyncCallback”>callback</see> and <see cref=”Object”>state</see> method

/// arguments.

/// </remarks>

/// <param name=”operation”>The <see cref=”OperationDescription”/> of the operation.</param>

/// <param name=”ruleSet”>A <see cref=”String”/> naming the ruleset to be used.</param>

public ValidationParameterInspector(OperationDescription operation, string ruleSet)

{

// Check the synchronous method of the service first. If the operation implements the

// OperationContractAttribute.AsyncPattern property, set the method to the BeginMethod.

MethodInfo method = operation.SyncMethod;

if (method == null) method = operation.BeginMethod;

 

foreach (ParameterInfo param in method.GetParameters())

{

switch (param.Attributes)

{

case ParameterAttributes.Out:

case ParameterAttributes.Retval:

break;

default:

inputValidators.Add(CreateInputParameterValidator(param, ruleSet));

inputValidatorParameterNames.Add(param.Name);

break;

   }

}

}

 

/// <summary>

/// Performs the validations.

/// </summary>

/// <param name=”operationName”>A <see cref=”String”/> containing the name of the operation.</param>

/// <param name=”inputs”>

/// An <see cref=”object”/> array containing the input parameters of the method and expected as described on

/// the operation, and thus excluding input parameters resulting from the service’s implementation of the

/// <see cref=”OperationContractAttribute.AsyncPattern”/> property.

/// </param>

/// <returns>null</returns>

public object BeforeCall(string operationName, object[] inputs)

{

ValidationFault fault = new ValidationFault();

// Because there could be fewer inputs than inputValidators, iterate

// through the inputs to run the corresponding validations. This accounts

// for asynchronous methods where the callback and state are defined in the

// method but are not exposed outside the boundary of the service.

for (int i = 0; i < inputs.Length; ++i)

{

ValidationResults results = inputValidators[i].Validate(inputs[i]);

AddFaultDetails(fault, inputValidatorParameterNames[i], results);

}

 

if (!fault.IsValid)

{

   throw new FaultException<ValidationFault>(fault);

}

 

return null;

}

 

Changes to ValidationBehavior.cs

/// <summary>

/// Returns a <see cref=”Boolean”/> to indicate whether or not an operation has validation assertions.

/// </summary>

/// <remarks>

/// If the method implements the <see cref=”OperationContractAttribute.AsyncPattern”/> property,

/// the BeginMethod is used instead of the SyncMethod because the SyncMethod is null.

/// </remarks>

/// <param name=”operation”></param>

/// <returns></returns>

private bool HasValidationAssertions(OperationDescription operation)

{

if (operation == null) throw new ArgumentNullException(“operation”);

 

// Check the synchronous method of the service first. If the operation implements the

// OperationContractAttribute.AsyncPattern property, set the method to the BeginMethod.

MethodInfo methodInfo = operation.SyncMethod;

if (methodInfo == null) methodInfo = operation.BeginMethod;

 

return methodInfo.GetCustomAttributes(typeof(ValidatorAttribute), false).Length > 0 ||

   HasParametersWithValidationAssertions(methodInfo.GetParameters());

} 

 

I created a copy of this post on CodePlex.  See http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=31493.

WCF, Conditional Compilation, and language differences

Perhaps you might have defined WCF message contracts lately, and you want to be explicit about the encryption level you require for your message parts.  I am taking the example of a message contract, but really my point is applicable to any element to which you wish to apply the EncryptionLevel enumeration.

In C#:

[MessageHeader(Name = "Environment", MustUnderstand = true
#if !DEBUG
                     , ProtectionLevel = ProtectionLevel.Sign
#endif
)] 
    public String Environment
    {
        get { return _environment; }
        set { _environment = value; }
    }

In VB.NET:

#If CONFIG = “Debug”
    <MessageHeader(Name:=”Environment”, MustUnderstand:=True)> _
    Public Property Environment() As String
#Else
    <MessageHeader(Name:=”Environment”, MustUnderstand:=True, ProtectionLevel:=ProtectionLevel.Sign)> _
    Public Property Environment() As String
#End If
         Get
             Return _environment
         End Get
         Set(ByVal Value As String)
            _environment = Value
         End Set
    End Property 

As you can see, there are some key differences in how attributes are specified using conditional compilation:

• In C#, I can toggle parts of the same attribute on and off.  In VB.NET, I must repeat the entire attibute (no parts allowed by the compiler).
• Because of line continuation constraints in VB.NET, the line following the line being continued must be included inside the conditional compilation block.
• Using VB.NET in Visual Studio (2005 or 2008), it is not clear which part of the conditional compilation is “active” based on the selected configuration.  In C#, the inactive block is grayed out.

Keep in mind these “consequences” as you proceed with WCF attributes in the language you write with.

Services and Smart Clients

I was reviewing the Commonwealth Bank of Australia Case Study (http://msdn2.microsoft.com/en-us/architecture/bb190159.aspx) and comparing it with my own experiences developing two smart client applications using the Smart Client Software Factory and the Service Factory from Patterns and Practices.

One item in particular resonated loudly: it is the premise that services can be either private or public.  Public services are intended for broad consumption and interoperability is key.  Private services are services intended for consumption by the presentation tier and thus are tightly coupled.  Private services may or may not consume public services.

I very much agree with this premise.   In fact, I have struggled with designing services intended for a UI while trying to adhere to principles of service design.  This validates my own experience and is a helpful framework for structing SOA discussions.

 What about your own experiences?  Do you agree with this premise?

Mobile workers’ best friends

I read quite a few trade magazines, and every so often I read a segment on mobile workers and telecommuting.  While VPN has made it more easy to stay connected with the office, there are a couple of “best friends” that have worked well for me.

The first one is Remote Desktop Connection.  Once I have the VPN established, I often use Remote Desktop Connection to access my PC at work.  This is great because it’s like being in the office.  I have access to all my applications and data in one easy step.

The other “best friend” I have developed lately is my Western Digital 250 GB 2.5″ external hard drive.  Using Virtual PC 2007, I created a virtual hard disk on my external HD.  I then built my virtual machine like I would a physical.  The advantage is that I can carry my virtual machine in my pocket and fire it up from any computer that has Virtual PC 2007 and a USB 2.0 port.  At one point, I was pursuing having a bootable thumb drive; having a Virtual PC hard disk on my external HD has turned out to be quite a welcome substitute.

Visual Studio 2008 Beta 2 and the Smart Client Software Factory

Well, it wasn’t exactly without some pain, but I got to where I thought I should get, and that is I installed the Smart Client Software Factory – May 2007  (SCSF) in Visual Studio 2008.

Here is a helpful resource in getting this done: http://staff.southworks.net/blogs/ejadib/archive/2007/08/27/How_2D00_To_3A00_-Smart-Client-Software-Factory-_2800_SCSF_2900_-_2600_-Visual-Studio-Orcas-Beta-2.aspx.

Nonetheless, it took a while to get there.  Here are the issues I ran into and the configuration that ultimately worked:

• I used Virtual PC 2007 to do this in an isolated environment.
• My first virtual PC was Windows XP with Service Pack 2.  I downloaded and installed Visual Studio 2008 Beta 2, Professional Edition, and could not see the Smart Client solution when creating new projects.  This seemed odd so I installed the source code of the SCSF.  I proceeded to enable Guidance Package Development and ran into type load exceptions here there and everywhere.  Not good…  I researched and tried many different approaches, but nothing worked.
• Then, talking with a friend made a lightbulb go off in my mind.  What if the particular edition of Visual Studio had an impact?  After all, this is a beta 2 and there are bound to be some issues.  So I proceeded to download Visual Studio 2008 Beta 2, Team Suite Edition, on a prepackaged virtual hard drive (see http://www.microsoft.com/downloads/details.aspx?FamilyID=3b72271c-e996-4989-898d-72d684966ce6&DisplayLang=en).  The OS in this virtual machine is Windows Server 2003 SP2. I performed the same SCSF installation steps as before, and, SUCCESS.  It worked.  I even exercised most recipes to make sure this was valid.  And it was.

Conclusion: SCSF can be used with Visual Studio 2008 Beta 2, and presumably, with Visual Studio 2008 RTC once it’s available.  Note that I have not tested making an installed from the SCSF source, so I cannot ascertain that it could be modified under Visual Studio 2008.