# Wednesday, September 29, 2004

I was suprised to see COM's IUknown interface makes an appearance in the WS-Transfer specification.  If you look at the second example the WS-Addressing MessageID is 00000000-0000-0000-C000-000000000046 the GUID for IUknown. 

posted on Wednesday, September 29, 2004 8:39:26 PM (GMT Daylight Time, UTC+01:00)  #   
# Tuesday, September 21, 2004

As David Gristwood and Mike Shaw note, on October 4 in London there’s a free Microsoft Technical Briefing Day with sessions on IT security with Steve Ballmer presenting a keynote at the end of the day.  Rafal Lukawiecki, a security guru and one of the top-rated speakers from TechEd Amsterdam, will be presenting on Threat Modelling as well as XP SP 2.  There’s also a session that I’m particularly interested in on practical lessons learnt with WSE 2.0 on the UK Government Gateway project:

In February this year, a new release of the Government Gateway went live using WSE2.0 to deliver WS-Security, WS-Trust and WS-Policy for UK cross-government authentication and authorisation. With over 4 million users, the Gateway's authentication and messaging facilities provide the backbone of the e-government agenda - and also one of the biggest WS-* implementations to date, coded in just 8 weeks. Find out the good, bad (and ugly) of using WS-Security - hot tips on what makes for good design, and what pitfalls to avoid.

You can register for the event here.

posted on Tuesday, September 21, 2004 7:45:52 PM (GMT Daylight Time, UTC+01:00)  #   
# Thursday, September 16, 2004

I’ve been head-down coding for several weeks (not quite to the ‘having other people feed me’ stage, but close).  I’m currently working on a VB.NET 2003 API for a large product and am missing refactoring tools.  To make up for it, I’ve been improving my regular expression skills and using Visual Studio's Search and Replace dialogue.  The VSEditor blog has a lot of good content on this feature (including a three part series).  The search and replace dialogues (both regular and the ‘in files’ versions) have a nice drop-down that displays the regular expression characters along with a description of what they do.

It’s a poor replacement for decent automated refactoring tools but it has made my life considerably easier over the last few weeks.

posted on Thursday, September 16, 2004 10:41:28 PM (GMT Daylight Time, UTC+01:00)  #   
# Tuesday, August 31, 2004

Gregor Hohpe weighs in on the WS-AlphabetSoup debate with a new ‘ramble’ that provides some guidance on how to approach the WS-* standards.  He recommends focusing on the intention behind the standards (benefiting from the knowledge and experience of the specification authors) and using them as a checklist for designs. 

Instead of focusing on [the details of the standard], look at what problem the standard is trying to solve. More likely than not, it is a problem that you are going to have when you go to implement your architectural vision. For example, not knowing where SOAP messages come from and where they are going makes debugging and diagnostics very hard. Not being able to reliably send asynchronous messaging is likely to result in a brittle and not very scaleable "RPC-over-the-network" model.  … I propose to many of my clients to use the WS-* standards as a checklist for their designs. I generally do not recommend they use WS-Addressing or WS-ReliableMessaging (or at least not right out of the gate). I do, however, challenge them by asking, "What is your strategy to track messages in case of error?" or "How do you intend to support asynchronous messaging?" The answer has sometimes little to do with Web Services. For example, the answer to reliable asynchronous messaging might be to use JMS or MQ or another middleware [e.g MSMQ] that ensures guaranteed delivery of asynchronous messages. And that's OK.

I like Gregor’s last point that sometimes the best current solution may not be web services.  This highlights that concept services, or applications based on principles of service orientation, do not have to use web services.  It’s important not to let the WS-* hype and churn delay the creation and deployment of service-oriented systems today. 

 

posted on Tuesday, August 31, 2004 11:24:36 PM (GMT Daylight Time, UTC+01:00)  #   

Microsoft announced on Friday that Indigo is all set to ship in 2006, with the planned support for Windows XP and Windows Server 2003.  This is great news.  With Whidbey shipping next year, with improved ASMX support (see Christian’s series), and WSE 3.0 some time between now and Longhorn it looks like there’ll be plenty of reasons to keep targeting Windows as the platform of choice for developing service-oriented applications.

posted on Tuesday, August 31, 2004 10:30:10 PM (GMT Daylight Time, UTC+01:00)  #   
# 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)  #