# Friday, August 27, 2004

Christian Weyer shows how to host WSE’s SoapReceiver within EnterpriseServices.  This came up while we were watching Keith Ballinger do a code-driven presentation on WSE messaging.

The demo was illustrating using SoapReceiver within a Windows Form application, which highlights that SOAP messages can be received inside any .NET assembly.  While this demo makes the point (and suggests some interesting application designs, such as having a user interface app host a service and listen for messages, as John Cavnar-Johnson mentions in the comments), this may not be an appropriate hosting situation, esepcially if you want it to run the application on a server, without user intervention.  Don Box has a great series on the major hosting options within .NET (IIS, DCOM/ES and Windows Services) and the advantages and disadvantages of each.  Christian’s question was ‘Can I host SoapReceiver within a ServicedComponent?’ 

Here’s my version of a solution to this problem, with all the steps you need to get to the spinning balls.  The server code looks like this:

using System;
using System.EnterpriseServices;
using System.IO;
using System.Net;
using System.Reflection;
using Microsoft.Web.Services2.Addressing;
using Microsoft.Web.Services2.Messaging;
[assembly : AssemblyKeyFile("keys.snk")]
[assembly : ApplicationName("WSE Hosting Example")]
[assembly : ApplicationActivation(ActivationOption.Server)]
[assembly : ApplicationAccessControl(false)]

public class WSESoapService : ServicedComponent, IProcessInitializer
{
      #region IProcessInitializer Members

      public void Shutdown()
      {
            Logger.LogMessage("Shutdown");
      }

      public void Startup(object punkProcessControl)
      {
            Uri uri = new Uri("soap.tcp://" + Dns.GetHostName() + ":4545/");
            EndpointReference epr = new EndpointReference(uri);
            // Add our WSE SoapService to the static collection of receivers,
            // giving the address we want to listen on and the CLR type that
            // will receive this message.
            SoapReceivers.Add(epr, typeof (MyService));
            Logger.LogMessage("Startup");
      }

      #endregion
}

// Here's our service that will receive messages
public class MyService : SoapService
{
      [SoapMethod("ReceiveMessage")]
      public void ReceiveMessage(string message)
      {
            Logger.LogMessage(message);
      }
}

internal class Logger
{
      internal static void LogMessage(string message)
      {
            // Log the messages to a file.
            StreamWriter writer = new StreamWriter(@"c:\wsemessages.txt", true);
            writer.WriteLine(message + "," + DateTime.Now);
            writer.Flush();
            writer.Close();
      }
}

To compile this code, save it in a file called WSESoapService.cs, then use the following command lines (assuming that you’ve got the Microsoft.Web.Services2.dll in the compilation directory since csc.exe wont look in the GAC for assemblies):

sn –k keys.snk
csc /target:library WSESoapService.cs /r:Microsoft.Web.services2.dll
regsvcs WSESoapService.dll

Then go to the computer manager and start the WSE Hosting Example COM+ application.

The client code looks like this:

using System;
using System.Net;
using Microsoft.Web.Services2.Addressing;
using Microsoft.Web.Services2.Messaging;

public class App
{
      public static void Main(string[] args)
      {
            Uri uri = new Uri("soap.tcp://" + Dns.GetHostName() + ":4545/");
            EndpointReference epr = new EndpointReference(uri);
            MySoapClient proxy = new MySoapClient(epr);
            proxy.SendMessage("Here's a message");
            Console.Write("Message Sent!  Press any key to continue ...");
            Console.Read();
      }
}

// Proxy class to call the SoapReceiver Service
internal class MySoapClient : SoapClient
{
      public MySoapClient(EndpointReference epr) : base(epr){}

      public void SendMessage(string message)
      {
            base.SendOneWay("ReceiveMessage", message);
      }
}

Then save this file as client.cs and compile it from the command-line as follows:

csc /target:exe client.cs /r:microsoft.web.services2.dll

posted on Friday, August 27, 2004 1:29:24 AM (GMT Daylight Time, UTC+01:00)  #   
# Saturday, August 21, 2004

Chris Keyser, a new blogger from the .NET Architecture Team, has started a series of posts on the how to use WS-SecureConversation and the SecurityContextToken in a server farm situation.  WSE takes care of making this happen through policy and configuration (as I’ve described before), so you don’t need to worry about the plumbing, but it is an interesting architectural decision about how you handle things in a server farm scenario.

Here’s some background on the ‘plumbing’:

  • The Security Context Token (SCT) is a fast, light-weight security token that can provide message-level secure communication across multiple calls between a sender and a receiver.  It is fast because it uses a shared symmetric key and it can also reduce the size of the SOAP message headers.  It is the basis for the WS-SecureConversation specification.
  • As the WSE 2.0 Security Settings Wizard recommends, using a SCT makes sense in cases where there will be multiple messages exchanged.  This is because the first message exchange is spent on acquiring the Security Context Token from a Security Token Service that issues security tokens.  The client has to send a RequestSecurityToken message to the token issuer.  This message is signed with a token from the sender so that the sender’s identity and credentials can be checked before the SCT is issued in the RequestSecurityTokenResponse message.
  • WSE 2.0 can automatically support Security Context Tokens, setting up an automatic Security Token Service that handles the issuing of these tokens (all through the element in the WSE config section). 
  • The SCT is fast because it uses a shared symmetric key between the sender and the receiver.  This is much faster than using asymmetric (public/private) keys.
  • The SCT can reduce the size of the message headers in two ways.  First, the SCT itself is pretty small, with only on mandatory element, an Identifier.  Second, WSE supports the automatic caching of the symmetric key and the original token (the base token) used to request the SCT so that they don’t need to be sent each time (a reference is just included where it is needed).

The question is, if the symmetric key and the original token are cached between the sender and receiver, how will this work if the receiver is part of a web farm?  Chris mentions three ways to deal with this issue:

  • Pin the sender’s session to a particular receiver within the web farm (here).
  • Store the session in some area that all of the receiver’s within the web farm can reach
  • Place the session information inside the SCT.

I’m particularly interested in the last option.  Both WS-Addressing (in the ReferenceParameters section) and the SCT provide mechanisms for providing extended information to a receiver.  In a sense both can provide ‘cookie’ style state information.  I wonder if Chris has some guidance about which approach to use and when.

posted on Saturday, August 21, 2004 12:07:01 PM (GMT Daylight Time, UTC+01:00)  #   
# Wednesday, August 18, 2004

Here are the code samples I used my webcast on WSE Messaging last Monday.  The webcast will be available for download from this link soon [update: it's available by clicking on the register button and getting through the login page].

 

Here’s the code from the demonstrations.  The major sample – a suggestion service – is based around Keith Ballinger’s talk at TechEd San Diego and my version of this talk at TechEd The sample shows:

  • A Windows Form client that sends a message to an ASMX web service.
  • The webservice logs the message to a file, before sending a one-way message onto another Manager service using WSE’s support for sending SOAP messages over TCP
  • The Manager Service is hosted in a Windows Form client that receives the message using the WSE ISoapInputChannel and its in-memory queue.  This means the messages aren’t displayed until the manager explicitly requests them.  The Manager Service also acts as a publisher of these messages to any service that has subscribed.  The implementation shows a simple Publish/Subscribe model using SoapServer/SoapClient.  When the messages are retrieved from the memory queue they are published to all of the subscribers.
  • The Boss Eventing Service is the final Windows Form client.  It sends a Subscription message to the Manager Service and receives notifications when the Manager Service retrieves a new message.

Other resources I mentioned/recommend:

posted on Wednesday, August 18, 2004 12:08:58 AM (GMT Daylight Time, UTC+01:00)  #   
# Friday, August 13, 2004

Simon Guest lists his top 10 tips for web services interoperability between .NET and IBM WebSphere and BEA WebLogic [via Christian Weyer who comments that things will points will go away with .NET 2.0, see his series 'The web service empire strikes back' for more details]

posted on Friday, August 13, 2004 12:00:59 AM (GMT Daylight Time, UTC+01:00)  #   
# Thursday, August 12, 2004

Last week someone asked me whether the use of destructors in C++ was similar to the try … catch … finally block within C#, since C++ doesn’t have the notion of a finally block.  I hadn’t thought about this before.  A few days later I noticed that Herb Sutter wrote a post stating that:

The C++ destructor model is exactly the same as the [Java] Dispose and [C#] using patterns, except that it is far easier to use and a direct language feature and correct by default, instead of a coding pattern that is off by default and causing correctness or performance problems when it is forgotten

Basically Herb likes the C++ model better because it doesn’t depend on developers having to remember to use ‘using statements’ or call the Dispose method when making use of the code.

The issue is that there’s a lot involved when dealing with IDisposable in .NET.  While the using statement in C# makes it easier to ensure correctness there's still work to do on the implementation side.  As Sean Schade mentions, many developers (mistakenly) think that the garbage collector will automatically call dispose.  Unfortunately this won’t happen unless you write code in your Finalizer that calls the Dispose method.  The MSDN documentation on the Dispose Pattern has all of the steps that need to be considered when writing code that implements or uses IDisposable.  It’s worth a look as this is an important topic to understand in .NET development.

At the same time as all of this there’s been a great thread on the Windows OT mailing list about the IDispose pattern in ADO.NET highlighting many of these issues.

I also read somewhere that there should be some VS Add-in/FxCop rule that can highlight when a Type that implements IDispose has been used without being wrapped in a using statement or being called explicitly.  I think this is a great idea in the situations where it works.  The problem, as Brad Wilson highlights in an OT post, is that it if you use interface-based programming it isn’t always possible to know whether a reference to an interface actually implements IDisposable, without inspecting the concrete Type at runtime, as his sample code demonstrates:

void Foo(IDbConnection conn)
{
  using (IDbCommand cmd = conn.CreateCommand())
  {
  [...]
  }
}

posted on Thursday, August 12, 2004 11:30:39 PM (GMT Daylight Time, UTC+01:00)  #   

Steve Maine writes about my number-one favourite feature of ReSharper:

The other feature I really like is Code Reformatting. Everyone has their own style when it comes to formatting code. For instance, I’m inclined to write void Foo( int bar ), while others on my team write void Foo(int bar). … Since everyone tends to have stylistic instinct that are *just slightly different* than everyone else’s, you can end up with a code base that is formatted inconsistently … Rather than forcing everyone to change their style to conform to a standard, we just configure a default set of Resharper formatting rules and periodically run them on the whole solution. It’s proven to be a big win because it removes distractions, keeps our code looking nice, and doesn’t require anyone to change their own hardwired formatting rules.

This is a great feature and allows everyone on a team to ‘go in peace’ (as Don Box might say).  I also really like the configuration dialogue that displays a before and after sample of code to illustrate what impact the setting will have.

Other enjoyable Code Assistance features
The other features I’m really enjoying are the optimize using directives (saving me from having to implement my own) and the Import Popup.  Resharper notices what project references are set and if it can't resolve a particular Type it searches the references and if it finds a match offers to add a using statement to the top of the file.  Pressing ALT + ENTER adds the using statement without taking the focus away from the the current position in code.  Very, very nice.

My only grizzle, and the reason I wont be spending my dosh on a license just yet, are around the auto-completion methods.  I'm still finding it a struggle to get the same speed with parameter info as with Visual Studio.  I'm also finding the three types of code completion and their associated keyboard shortcuts less intuitive (I'm having to think more) than in Visual Studio (CTRL + space). 

Annoying bold Constants font display bug
Finally there seems to be a bug when using constants, and Enums (which I love).  Resharper displays them using a bold font but doesn't adjust the caret position - so the cursor is displayed four characters or so past the insertion point - making it impossible to type (a difficult-to-overcome usability problem).  Luckily the bold font can be turned off.  Under Tools -> Options - Fonts and Colors - there's a 'ReSharper Constant' Display Type.  You can then remove the checkbox in the Bold box. 

[Update: Scott Hanselman tipped me off that this is a bug - no Steve, it wasn't just you :-) - with variable width fonts in Visual Studio 2002/2003 and not a ReSharper issue.  Googling turned up this statement of the problem which sounds like it will be fixed in Whidbey.  I'd like to apologise to ReSharper, their developers, family members and friends for any distress.  I may now shell out my own dosh on this tool.]

posted on Thursday, August 12, 2004 9:55:22 PM (GMT Daylight Time, UTC+01:00)  #   
# Friday, August 06, 2004

I downloaded Picasa tonight – a free photo management tool that Google recent bought.  Having 12,000 photos from the last three years I’m seriously into digital photography.  I really like Picasa, especially the timeline view of the photographs – similar to the Avalon demos from the PDC keynote – only it works today.

 

posted on Friday, August 06, 2004 12:10:58 AM (GMT Daylight Time, UTC+01:00)  #   
# Wednesday, August 04, 2004
I was pairing with someone last night trying to test the Command pattern which lead to a useful example of using NMock to create a dynamic Mock object to help test it.  Here are some notes on how NMock can be used to create DynamicMock objects based on an interface to quickly create loosely-coupled test code.

The command pattern allows you to wrap a command inside an object so that you can pass it to another object to execute that object.  We were using a simplified version of the pattern where we had a command interface that has an Execute method and a Results property to retrieve the results:

public interface ICommand

{

      void Execute();

 

      string Result{ get; }

}

 

Objects of this type are then passed in as an IList to a CommandExecutor that loops through the commands and calls Execute on each one:

 

public class CommandExecutor

{

      public void Execute(IList commands)

      {

            // loop through the commands and

            // call the command.Execute method

      }

}

So we wanted to write a test that ensured that the Execute method was called on each command that we provided to the CommandExecutor.  Initially we thought about sending through a concrete Command (say a ConcatenationCommand) and determining that the result was what we expected.  However, this would have coupled our design to that particular Command - if we made a change to the results that returned we would have to update our tests.  In this case we aren't concerned about the actual result, just that Execute is called on each command.  The question was how can we test this behaviour without having to worry about a concrete Command or its result?

This is where Mock objects come in (see the original Mock paper or the Pragmatic Programmer's overview).  They allow you to test the behaviour of an object rather than just its outcome.  The idea is to create a 'fake' or stub object that validates the object was used in the way we expected.  In our case we could create a MockCommand that derives from ICommand.  We could provide a boolean property - ExecuteWasCalled - on the class that could be set inside the execute command.

public class MockCommand : ICommand

{

      public bool ExecuteWasCalled;

      public void Execute()

      { ExecuteWasCalled = true; }

      public string Result { get { return "result"; }}

}

While this would work fine, since our needs are pretty simple in this case we could use NMock which provides a way of creating a DynamicMock object based on an Interface.  The DynamicMock exposes a property that can set expectations about the behaviour of an object, such as a particular method being called.  The DyanmicMock object also has a MockInstance method that returns an instance of the Interface. Using this technique saves us having to create a concrete Mock command.  Here's the resulting code:

[TestFixture]

public class CommandExecutorTests

{

      [Test]

      public void ExecuteMultipleCommands()

      {

            // Setup our mock Commands

            DynamicMock cmd1 = new DynamicMock(typeof (ICommand));

            DynamicMock cmd2 = new DynamicMock(typeof (ICommand));

 

            // Set our expectation that the execute method will
            // be called on each command

            cmd1.Expect("Execute");

            cmd2.Expect("Execute");

            CommandExecutor executor = new CommandExecutor();

 

            // Call our execute method on our executor

            // passing in an array of mock commands, using the

            // MockInstance property to create the instances.

            executor.Execute( new ICommand[] {(ICommand) md1.MockInstance, 
                                             
(ICommand) cmd2.MockInstance});

 

            // Use the Verify method on the DynamicMock to

            // ensure that all of our expectations have been met.

            cmd1.Verify();

            cmd2.Verify();

      }

}

 

While I still have reservations about the extent to which MockObjects are useful, I think that NMock and its DynamicMocks are a useful technique to quickly produce loosely coupled test code.

posted on Wednesday, August 04, 2004 10:43:33 PM (GMT Daylight Time, UTC+01:00)  #   
# Thursday, July 22, 2004

If you'd like to understand more about how to do messaging in WSE and would like to see the  three levels of messaging within WSE in action then why not register for my first MSDN webcast here?.  I'm going to be presenting it on Mon 9 Aug at 1PM EST (GMT -8). 

I'll be covering some of the demos from the Keith Ballinger presentation from TechEd San Diego that I presented in Amsterdam, along with some new material.  Here's the abstract:

Using messaging systems to support application functionality allows technical solutions to better match business problems.  WSE 2.0 provides messaging implementations that range from low-level explicit messaging through to high-level, more transparent models.  This webcast demonstrates various messaging levels within WSE including a custom WS-Eventing sample and how message, network addresses, intermediaries and queues need to become first-class citizens of your application. Learn how messaging can enable you to create powerful web services applications that cross machine and network boundaries.

I've put these details on my updated presentations page as well.

posted on Thursday, July 22, 2004 11:35:21 PM (GMT Daylight Time, UTC+01:00)  #   
# Saturday, July 17, 2004

Dave Bettin writes about his experiences doing a user group presentation on Indigo.  His main disappointment was that few attendees seemed to know about Indigo or the existing ASMX web services in .NET.  This got me thinking about how to get the message out about distributed apps, service-orientation and Indigo.  Is it the case that most developers need to be educated about the benefits of scalable, distributed, service-oriented apps or is it that they don't need these approaches to solve their business problems?

Dave's feedback is similar to Clemens' experience earlier in the year, where he spoke of the difficulties selling the relevance of Indigo today before he settled on explaining the 'why' over the how.  Both Dave and Clemens' experienced the same difficulty making the connection between Indigo and developers' jobs today.  Clemens' says that one of the barriers is that people think Indigo is only going to be relevant for 'Big Apps', when in fact it will be important to anyone who builds apps that expose functionality to other apps. 

One argument is that in order to get more interest in Indigo we need to educating developers about the benefits of services and distributed apps and get them to stop writing monolithic apps and start separating the logic across tiers and services.  We need to teach them more about the benefits of the services and distributed application approach, such as scalability.  Sam Gentile touched on this sentiment when he wrote that most .NET developers don't grok distributed computing

The other position regarding evangelising Indigo is mentioned by Alex Lowe in a comment on Clemens' post, is that:

Of course, we know that in the real world there are lots of applications that don't expose functionality to other applications. There are plenty of line of business applications for small and medium businesses that don't require ASMX, Remoting, and in the future Indigo.

Alex also has a summary post on his position where he says that the number of applications that need (and by extension, developers) that actually need to know about how to architect scalable applications is low.  He argues that bloggers are a distorted sample because they represent the group that need to build scalable distributed applications and they are generally well up on things.

I'm interested what other people think.  Is the problem that most developers don't understand the benefits of service-oriented distributed applications or is it that most developers are writing apps that wouldn't benefit from service-oriented distributed applications?  What business application scenarios are most likely to benefit from adopting service-orientation and Indigo?

posted on Saturday, July 17, 2004 12:07:17 AM (GMT Daylight Time, UTC+01:00)  #