Stu Charlton writes about ‘Microsoft, Service and Patents’ concluding that:

Even if Indigo is the all singing, all dancing thing that Microsoft hopes it will be, it doesn't mean people will adopt it en masse and quickly. Firstly, it's a Windows-only technology. That's a big limit to start with. Second, it's very new and rich. There's a learning curve. Third, other vendors are not sitting still. They can and will compete.

His first point, that Indigo may not be adopted because it’s a Windows-only technology, misses the difference between a programming model and the messages that it creates/consumes.  Indigo is a programming model that can send messages, which are based on the WS-* specifications, to any other endpoint that can understand these messages.  Yes, you have to use Windows to program with the Indigo programming model, but given that many other vendors were involved in creating these specifications and participating in feedback and interop workshops (more info here), it is likely that many Indigo applications will be built to interoperate with applications hosted in non-Windows environments.

His second point is that Indigo is a new programming model.  This is true, but viewed another way it is just the combined next version of the existing distributed technology stacks at Microsoft (DCOM, Enterprise Services, MSMQ, Remoting, ASP.NET Web Services, WSE).  Many of the Indigo team were involved in building these existing products.  So it is new, but it is based on a strong foundation of experience developing other distributed technology stacks.  As Steve Swartz comments:

it's important to think about Indigo not as a big change or something new and completely different, but rather as a replacement of infrastructure which you only have to look at if you're the kind of person who likes it, but an evolution of the programming model, a simplification and a unification. [Emphasis mine]

In terms of the learning curve, there’s no doubt that any programming model designed to support distributed computing will be complex. Having said that though, it's interesting to note how much time the Indigo team have devoted to refining the usability of the API to ensure the minimal learning curve for developers.  If you compare what was announced at the PDC with what was shown on the Indigo .NET Show for instance you can see that they've been trying to simplify and refine the model and reduce the number of concepts a developer needs to know in order to be productive.  In fact one of the reasons I’m so excited about Indigo is this focus on designing the programming model with developer usability as a goal.  As Steve Swartz, the Program Manager responsible for the Indigo programming model, describes his role: 

My job is to figure out how to make the whole thing approachable without having to know anything about the [WS-*] specs  … One of my design goals is to make a programmer familiar with any one of those products [DCOM, Enterprise Services, MSMQ, Remoting, ASMX, WSE] look at Indigo and say ah, that's the next step in my product, mine was the winner. So I'd like a .NET remoting guy to be able to walk up here and say ah, this looks very familiar. Similarly with the Enterprise Services and ASP.NET people … What we're trying to do is to bring all those useful things together in one model.

Finally, in terms of the other vendors not standing still and competing - this is excellent.  I would love to see other vendors try and offer a more usable and flexible API to develop WS-* compliant applications – this can only be a good thing for distributed application developers.

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.

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.

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. 

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.

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

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.