# Thursday, September 30, 2004

Craig Andera discovers Foamhenge, 'a full-scale replica of Stonehenge, only made out of foam' while driving around rural Virginia.  Go and check out his photos

I also find manufactured tourism hilarious.  Australia has an abundance of 'big' things: Pineaple, Lobster, Potato (which looks a lot like a poo), Orange and Rocking Horse, just to name a few.  I've always dreamt that when I retired I'd drive around Australia visiting them.  Imagine my surprise then to find this guy who's already started cataloguing them all:

These truly awesome testaments to things Australian are sometimes unforgettable and inspiring, sometimes tacky and tasteless, often both.

Quality work.  Here's my own photo of the Big Merino, which I read may soon be moved by helicopter closer to the highway:

The Big Merino, Golburn NSW
posted on Thursday, September 30, 2004 4:24:39 PM (GMT Daylight Time, UTC+01:00)  #   
# 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)  #