Jesse Ezell Blog

Cue the Scoble Tears

"Cue Scoble tears. This is one hell of a technology from Microsoft Research that I think will have a huge impact on how amateurs and hobbyists write music. The technology and software prototype is called MySong.

In a nutshell, the software records your singing (preferably in tune) through a microphone, and it systematically generates an instrumental accompaniment for your song. The quality is even comparable with a professional accompanist, not to mention the cost and time involved."

[1] http://www.istartedsomething.com/20080229/mysong-microsoft-research-singing-sound-a-lot-better/

Abstraction: A Condom for Your Code

"Why should you put a 10 foot pole between yourself and technology?

Well, because Microsoft (or insert vendor of your choice here - they’re all equally guilty of this) tend to deprecate (as in kill) the technology they evangelised just last year/month/week.

Microsoft Sql Server Notification Services are the latest victim.

I hope you don’t have any application code tied to that technology." [1]

Here is yet another example of why you need proper abstraction. When designing your application's layers, expose as little of the implementation details as possible.

For example, if you are going to be using Windows Workflow Foundation to handle the workflows for a complicated system, that is fine... but try not to expose the workflow instance or activities directly to clients. If for some reason you need to ditch Workflow Foundation, you don't want to have to rewrite every component that utilizes workflow for it's operations. Instead of a method like this:

void ShipProduct(SequentialWorkflowActivity shipmentWorkflow);

Have a method like this:

void ShipProduct(IProductShipmentProvider shipmentProvider);

Behind the scenes, you might create a framework for handling these shipments using Windows Workflow Foundation, but keep the implementation details behind the scenes instead of exposing them to your callers. Then, not only are your clients protected, but your server code is protected as well. If at some point you decide that you really need to be using Biztalk for your workflow, you can start using Biztalk immediately for new implementations without rewriting all your current workflows first.

This also applies to communication with external systems. If you need to interact with an external system, provide a service that accepts data in a format that your system is familiar with, let the service implementation deal with mapping between your data structures and the external system's data structures. This way, you are free to roll out fixes to your communication or support for new systems without rolling out anything else.

[1] http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist

Using WCF endpoints with SQL Reporting Services

Consuming WCF endpointpoints with SQL Reporting Services can be difficult. Most of this difficulty is for two reasons:

1) SQL Reporting Services XML and web services support is slightly better than a piece of crap.

2) Documentation for the XML query provider in SQL Reporting Services blows.

One of the big problems with SSRS is that you can't just point it to a WSDL document and have it generate a proxy. In fact, the way you use web service data is virtually the same as querying off a static XML document. However, it is possible to get the two working together. Here are the steps:

1) Expose your WCF service using BasicHttpBinding.

2) Select XML data source and enter the url of your service, ie. http://myserver.com/service.svc

3) Enter the XML for your query:

<Query>

<Method Name="MyMethodRequest" Namespace="http://tempuri.org/">

   <Parameters>

       <Parameter Name="Param1"><DefaultValue>ABC</DefaultValue></Param>

   </Parameters>

</Method>

<SoapAction>http://tempuri.org/MyService/MyMethod</SoapAction>

</Query>

 4) Make sure your WCF proxy is set up properly to work with SSRS:

[MessageContract(IsWrapped=true)]
public class MyMethodRequest
{
    [MessageBodyMember]
     public string Param1;
}

[ServiceContract]
public interface MyService
{
   [OperationContract]
   MyMethodResponse MyMethod(MyMethodRequest request);
}

Notice a few things. First, you will want your request to be wrapped. By default, the method name in your SSRS query must match the class name of your request. If you want to change your wrapper name, that is ok, but make sure to keep the wrapper name / namespace in sync with the Method element in SSRS. If you specify a custom action on your OperationContract, make sure that the soap action matches that action.

If you get an error message when you try to connect, remember these two things:

1) The error dialog has a details button where you can drill down and get more detailed information about the error that occured on the server, rather than the generic useless error it gives you.

2) If the details on the error dialog aren't giving you enough information, enable message tracing on your WCF service. If you aren't familiar enough with the WS specs or WCF to know what is wrong with the communication, create a quick app that calls the service using WCF and then compare a trace between the SSRS call and your sample app.

As a final note, watch out for missing or extra trailing slashes in namespaces and make sure everything is cased properly. One missing or extra slash or one improperly cased character can hose the entire request.

XNA on Zune and X-Box Live

Two pieces of news today in the "damn that's cool" category.

First, Microsoft has announced that you will now be able to use XNA to create games that run on Zune.

Second, XBox live will have a "XBox Live Community Games" section where you can upload your own games for purchase / download / etc.

Both of these are huge.

[1] http://blogs.msdn.com/johan/archive/2008/02/21/games-on-the-zune.aspx

[2] http://blogs.msdn.com/xna/archive/2008/02/20/announcing-xbox-live-community-games.aspx

WCF: Getting ServiceAuthorizationManager and IAuthorizationPolicy to Work Together Properly

When using WCF, you may want to integrate your security model into your application using claim based security. At this point, you will come across ServiceAuthorizationManager, which is responsible for evaluating policy statements to determine if the user is authorized to perform the requested operation. There is an interface, IAuthorizationPolicy, which you can implement to add your own claims to be evaluated by your ServiceAuthorizationManager implementation... there is one problem with this approach: the documentation you will find will most likely tell you to override CheckAccess in ServiceAuthorizationManager. However, if you merely override CheckAccess as in most of the provided samples, you will never see the output of your IAuthorizationPolicy implementation. As it turns out, the default implementation of CheckAccess sets up your security context as expected, but overriding CheckAccess will prevent this setup code from happening. Instead, override CheckAccessCore and your Security Context will be set up properly (the default implementation of CheckAccess sets up the context and then calls CheckAccessCore), or call base.CheckAccess as the first line in your handler to ensure that the basic setup of the security context happens before your code executes. This will save you hours of frustration.

 Why in the world Microsoft didn't just split this up into two distinct methods such as InitializeSecurityContext and CheckAccess is beyond me. Generally Microsoft does a great job of Framework design, but this case seems to be an exception.