Last night I had the pleasure of catching up with fellow RD Ingo Rammer for dinner at the Cinnamon Club here in London.  Ingo is a thoroughly nice guy and I had a great time chatting with him about the usual suspects (Remoting, Enterprise Services, WSE and Indigo) as well as presentation skills. 

In this prized addition to my photo blog roll Ingo is showing me the 'Ingo Rammer Signature Photo' pose (which I suspect may be a trademark, though he was kind enough to allow me to attempt to copy it).

It was also nice to catch up with IanG, Sebastien and Ingo's fiancée Katja.

I've been blog-lite while I prepared and then gave my Indigo presentation to the London .NET User Group.  The audience seemed to enjoy it and I had a good time presenting it.  Some quick points:

• The selling point of the Indigo Service model is that it is simple and easy to use.  The benefits for developers is that they get all the benefits of enterprise-quality features such as transactions, reliable messaging and security without having to write any code.  Letting Microsoft do the plumbing allows developers more time to write code that focuses on solving complex and interesting business problems.
• I took on board Clemens' experience and started talking about the 'why' of distributed technologies before delving into how Indigo works.  Luckily this group was very switched on.  I got some good questions about the performance of Indigo across AppDomains/Processes/Machines.
• Someone asked me to provide some background on why Enterprise Services are a better choice than Remoting for communicating between components on the local machine.  Clemens' has some more information on it here and here. 

Doing a presentation where you don't have the current version of the software to demo is a challenge (the PDC Indigo bits are from an older, M4 build, which has been substantially refactored in the now-being-coded M5 build, so there's not a lot of value in showing demos with the PDC bit).  In order to get some code samples I had to transcribe screen shots from the PDC videos (difficult since Steve Swartz didn't use word-wrap in Visual Studio).  I'm filled with (even more) respect for Don Box and Steve Swartz's presentation skills after realizing they managed to do four Indigo presentations at the PDC without even compiling, let alone running any of the applications.

Given the PowerPoint dependence and Clemens' reports on the complexity of the topic I decide I'd have to resort to audience bribery.  I drew on my experience in TheatreSports and brought several bags of Minties from the Australia Shop at Covent Garden (to my horror I discovered today that they are made in New Zealand!) and threw them to the audience whenever I detected the signs of PowerPoint-induced lethargy.

Pair programming with Jamie Cansdale at ThoughtWork's London Geek Night last Wednesday highlighted how much I like this practice.  Geek Night is basically an open night for developers who want to work on projects (ranging from open source development, to personal hobby projects or just for those who want to experience pair programming).  Jamie and I were working on creating a Visual Studio Add-In to remove unused 'using statements' in C# files (essentially, to replicate the 'Imports Tidy' functionality provided by C# Refactory that Scott Hanselman says is almost worth the price of the add-in alone).

Here were the things I enjoyed about Pair Programming:

• Knowledge sharing.  The knowledge transfer ranges from ways of using Visual Studio ("what did you press to get that?") to how to structure unit tests ("would you split that into a second method?") and features of the object model ("how can I find the assembly that defines this type?").  Even in a short session there's a great amount of knowledge that can be transferred.
• Continuous development speed. When sharing the 'driving' seat it means that it's possible to keep developing at a constant rate.  When I develop on my own sometimes I find it hard to keep going once I've achieved a certain milestone.  In Pair Programming it's possible to sit back for a while and let the other person drive.
• It makes you braver. Pair programming provides courage to start having a go even at complex problems.  It's easier to get started attacking a problem using two heads at the same time.

We started out by discussing how to implement the functionality.  Jamie was arguing for a brute-force but fool-proof mechanism of using a regular expression to search through the code, comment out any using statement that it finds and dynamically compile the code to see if it generates an error.  I was itching to write my own stripped-down C# parse that could scan through the source code and understand the using statements (including the alias keyword and nested statements).  To settle the stale-mate by switching our focus from the implementation to the functionality.  We decided to write the tests first (yes, XP is a simple set of practices but it's easy to get off track).

The beauty of writing the tests first was that the tests were independent of the implementation.  After writing a couple of tests it became clear that Jamie's approach was likely to be 'the simplest thing that worked' in the two hours that we had.  The best part was that we were able to achieve a working implementation inside this time!

I'm still eyeing off the SharpDevelop open-source C# editor, which as C# parsing code which I'm tempted to use (or maybe it's time to get into Mono), but for now I'm sold on the value of pair programming and test first development.

John Udell has written an article on WS Alphabet Soup based on his discussions with John Schewuck, an architect on the Indigo team.  Here are the interesting points:

• Indigo may ship before Longhorn to enable people to provide developers with access to the functionality provided by the newer WS-* specs.  I know the message from the PDC was Whidbey < Indigo <= Longhorn, but I guess haven't really considered it will come before Longhorn (I thought this was what WSE was for since Indigo is a 'baked in' part of the .NET Framework).  Not that I'd complain if it came earlier.
• There are a lot of Web Service (WS-*) specifications, but this is a good thing because they are composable.  You only need to implement the specifications you need.  The alternative would be a single specification that tries to do everything.
• The WS-* specs are inventing a lot of what has been provided before in DCOM and CORBA.  As Don Box says, 'The entire motivation for defining SOAP was to get the industry out of the "you need my runtime to talk to me" business that DCOM and Java RMI so happily got us into in the 1990's.'
• The advantage of using SOAP as a message description format  is that it provides extensible SOAP headers ("an accordion-like construct").  Previous network communications protocols was their dependence on fixed-offset dependencies that broke if you had to extend or modify the packets.
• Microsoft is wise to spend time worrying about the usability of its APIs.  This was my initial reaction at the PDC - 'Wow, they have done a lot to make this really easy for developers'.
• The key to reducing the cognitive overload caused by the specifications is an easy programming model (this acknowledges the reality that not everyone gets as excited as John Bristowe about a new specification).  Indigo's use of attributes in the Service Model is a major plus here.  How awesome is it to be able to write code like this to add WS-Security (signing, encryption), WS-ReliableMessaging and WS-AtomicTransaction support:

[Service]
[Security(Disabled=false, 
 SecurityProfileName="MyDynamicProfile",        
 ClientAuthentication=UsageMode.Required,
 IntegritySupport=UsageMode.Required,
 ConfidentialitySupport=UsageMode.Required)]
[ContextPropagation(typeof(ITransaction)]
[Connection(DeliveryAssurances.Full)]
public class MySecureReliableTransactedService
{
    [ServiceMethod]
    [Authorization(Role="Clerk")] 
    public void CreditAccount(string acc, decimal amount)
    {
        …
    }
}

The Loosely Coupled blog also has more commentary on the interview with John.

Matthew Adams left a comment on my last post disagree with my characterisation about services being more to do with messages as opposed to remote procedure calls (RPC).   It was a good question that I thought was worthy of a lengthier response.

What I was suggesting in the original post is that overtime there will continue to be a move towards services that use messages, and in particular SOAP messages based on the XML Infoset, rather than RPC style calls over time.  SOAP because it gives a broader reach for interoperability because of it's lowest common denominator approach and associated standards.  Messaging because it gives more flexibility in terms of what is sent and the message exchange patterns that are supported. 

The Great SOA Definition Debate
I've been trying to get away for getting into a debate about what services are, mainly because I haven't found a useful definition of service that says more than 'it's a great idea to have blocks of code that do something' and when designing these blocks of code, encapsulation and loose coupling are good practices.

By Matthew's definition a service is something that can do something, at a particular addressable location on a particular protocol, with a particular message format, in a such a way as the consumer doesn't have to care about how that something is done.

Using this definition of a 'service' it is true that the service doesn't have to be implemented as a 'message' end-point.  It is possible to implement these 'services' in ASMX web services, in-process .NET classes and remotable objects.  The problem is that these choices can impact the amount that the consumer has to know about the way the service is called, if not how it is implemented.

Don's Definition of Services
I like Don Box's definition of a service as a 'program that you communicate with using messages'.  These messages are SOAP messages based on the XML Infoset (a logical view of an XML document - angle brackets and text representations may or may not be involved).

The beauty of using SOAP messaging is that it is a lowest-common denominator of solving the problems involved with providing a service:

• How do we address the service, which protocol should we use to talk to it? (WS-Addressing)
• How do we describe the format of the messages that are sent and received? (SOAP)
• How do we describe the format of the contents of these messages (WSDL, XML Schema)
• How do we describe the pattern of the messages that are exchanged? (WSDL)
• How do we describe the other characteristics we need to successfully talk (WS-Policy)

What's wrong with RPC end points?
My main issue with RPC end points is interoperability and flexibily.  RPC-style calls to RPC-end points in Matthew's terminology calls can do all of these things, but they are more likely to do it in a less-interoperable way that requires greater knowledge of the underlying platform, protocol or programming model (for example you may need to agree on the binary representation of the parameters used in the procedure call which may mean sharing DLL's or worse, an entire development platform).

Of course any remote procedure call can be thought of as just a particular kind of message.  So it's possible to create services that are based around RPC-style calls made within a message (which is how ASMX web services work today).  Within web services there are two types of SOAP message format - RPC and document.  As Yasser Shohoud points out in his article RPC/Literal and Freedom of Choice, RPC formatted SOAP messages are just a subset of the document formatted (I'd argue message-based) SOAP messages .  As he says, ASMX web services show it's possible to use a document style message format but with an RPC programming model.

[Update: See Shawn Smith's post on this topic.  In the last section of this post I wasn't very clear about the distinction between SOAP message formats and message exchange patterns.  My point was that it is a better idea to implement more flexible approaches to both the message format and the message exchange patterns because the more flexible approach can accommodate the more rigid approach.  In this sense the SOAP Document format can accommodate the SOAP RPC message format and the asynchronous message exchange patterns can accommodate RPC message exchange patterns (synchronous request/reply).

Ultimately, it's not worth getting too fussed up about this as both the ASMX and Indigo programming model will support you whichever way you'd like to work.  You can write services based around asynchronous messages or using synchronous request/response (stop-and-wait) RPC-style calls.  As I said at the start of this post, over time I believe there will be a movement away from synchronous RPC calls towards asynchronous messaging.]

As preparation for my Indigo presentation at the London .NET User Group next Monday, I thought I'd write a couple of posts about Indigo, starting with 'The Road To Indigo'.

Indigo is a new technology that represents on the unification of existing distributed application technology.  It takes Remoting, Enterprise Services, Web Services and Microsoft Message Queue and combines them into a single area of platform-level technology.  In fact, Microsoft has literally taken all of the teams responsible for these technologies and put them in the same building.  Instead of thinking of Indigo as a completely new technology, think of it as the next version of all the existing approaches where all of the best features of each are combined into a single managed-code programming model.  Here's a diagram showing the progression of these technologies:

 

Indigo takes the best features of each approach and makes them available in one location.  If you're developing ASMX and Web Services today you can't  take advantage of reliable messaging (as in MSMQ) or transactions and object pooling (as in Enterprise Services) across web services calls.  With Indigo it is possible.  If you're an Enterprise Services developer today it's difficult to take advantage of flexible versioning provided by schema or being able to describe requirements using policy files (as you can in web services with WSE).  Indigo makes it possible to take advantage of all of these features.

Indigo also lets you chose the way you want to build applications without tying you in.  Indigo supports and encourages building service-oriented applications using messages based on SOAP.  However, Indigo still supports you and provides features even if you want to create distributed applications using a distributed component approach using remote procedure calls.  Choosing one approach over the other doesn't mean giving up features such as message-level encryption or transactions.  As Ingo Rammer says, Indigo recognises that you shouldn't be locked into 'a specific programming model, a serialization model, a transport model, or even just a serialization format'.

Combining the features of these four different technology areas into a single programming model is great news for developers.  We get the best features from each previous approach while only having to learn one programming model!  There's no more complexity about which technology or programming model to use for a particular distributed application scenario. It's the same programming model whether it's a peer-to-peer application on a hand-held device, right up to a secure, reliable and transacted message queue behind a massive online retailers.  

For those times when the platform needs to be extended, Indigo also provides an excellent extensibility model.  Even in this case there's only one extensibility model to learn.

Indigo brings us closer to Microsoft's long-term aim of helping developers spend less time on the plumbing and more time on the application code.

Two pieces of news have made this Valentine's Day a geek day of love.

• JetBrains, the creators of IntelliJ have released an ealy build of their C# tool, ReSharper which I have been waiting for.   Luke Hutteman has a good review of the features (and info on how to access the download site, which currently isn't handling new registrations).
• Erik Sink announces the release of Vault 2.0 which includes a free Single User Edition.

Bruce Williams from the Indigo team has a nice walk through of the the XML elements in WS-Eventing.  When you strip away all of the namespaces and XML noise, it's a nice, understandable piece of work.

I like WS-Eventing because it's another tool in the architecture toolbox.  To me it suggests the end of polling in web service applications.  In some of the applications I've worked on today the client has had to poll the webservice to check for updates.  With eventing the client will be able to wait to be told if something has changed, rather than pestering the server like a kid in the back of a car on a long road trip asking 'are we there yet?' all of the time.   It's much more efficient to wait and be notified than constantly having to poll to check if something has changed.

I'm not 100% sure about how large corporates will handle security will work across the Internet and corporate firewalls.  For the client to receive the notification they have to have an open port that the notification service can send to.  Perhaps a solution is to use an approach like the MSDN SoapMail sample, where messages were returned to some central location, like a mailbox, which is polled by another service that picks the message up and forwards it to the client.  Perhaps the answer lies in the Security Considerations area of the spec which suggests the notification should be signed with security tokens.

Some random notes from last night's Tuesday Extreme Club:

• Jamie Cansdale, an all-round very clever guy, came along for the first time and got a chance to receive thanks from many of the people that had used his NUnit Addin. We had a great chat about Mono, Rotor and the strengths of .NET being a formal standard as well as having a share-source implementation.
• Joe Walnes from ThoughtWorks about message-oriented development, the decorator design pattern, how Aspect Oriented Programming could be thought of as generic decorators.  He also spoke of his joy after achieving his life aim of becoming the owner of a blow-up a bouncy castle (apparently only £250 including generator)
• Joe also mentioned Prevayler that basically removes the need for a data store with projects that use less than 2GB.  The simple idea is that the entire memory space can be persisted to disk.  Each action performed on the model uses the Command pattern to write out a transaction log that can be replayed if the system goes down between persistent writes.  This allows for easy replication of systems between machines as well as meaning that programs don't need a database.  A very simple, but potentially powerful idea.  For small applications, do I really need to struggle with a database, or could I manage it with in-memory objects?
• Tim McKinnon told the story of the invention of Mock Objects. The Pragmatic Programmers have a useful list of 7 reasons why you would want to use Mock Objects. For Steve, the most important was being able to test relationships between objects.
• Tim gave a great overview of the problems with Visual Studio .NET.  Basically it takes to long to locate the right piece of code. His question was why can't use hyperlinks to navigate around the code (Reflector does this brilliantly) or even a Find Type dialogue box that allows you to type in the name of the type you are looking for with IntelliSense.
• Chris Stevenson was at his last meeting before doing the 'reverse-outsource' and moving to India to join the ThoughtWorks team there.  Can't wait to read about it in his blog.

I spent this afternoon watching Scott Guthrie present ASP.NET and Visual Studio .NET Whidbey to a packed audience out at Microsoft UK's Campus at Thames Valley Park.   ASP.NET 2.0 does so much out of the box that it's almost threatening to a developer - It's been a long time since I was this scared about a technology!   See my complete notes of the presentation slides and demo here.

When's ASP.NET Whidbey going to be available?
The aim is to ship a Beta in June and for RTM in Q1 2005.   There will be a 'go live license' that will let people put Beta 2 into production, later this year.  The Beta in June will be a public beta and it will be possible to download ASP.NET and Visual Studio Whidbey.  The build that Scott demonstrated with was from last Monday when he said they achieved 'Code Complete.  So they are now in that long stabilisation phase. 

Cooler applications in less time (even for enterprise applications!)
The key message is that ASP.NET allows you to create cooler applications in a fraction of the time it takes today. This sounds very 'marketese', but based on what I saw demoed it's very true. The hardest thing is that there have been plenty of demos like this before - from FrontPage and Visual InterDev. It used to be the case that you'd walk away saying 'good demo, but it will never work on a serious enterprise site'. But this time they've got the architecture right. Databinding to plain objects makes it possible to do proper 3-tier development. The Provider model means that there are interfaces at nearly every level that you can implement or override (apparently they'll ship the source code to the existing providers to make this easier).

It will be interesting to see how ASP.NET 2.0 works in real world situations.  Many of the features demonstrated like the login and authorisation and the paging and sorting of data are things that I've developed in the past so I know that they can literally take weeks to develop.  Now they are simple drop-and-drag and configure scenarios.  Also, since many of these ideas, like the data grid are now on their third or fourth iteration (I remember Visual InterDev 6.0 and it's 1.0 style implementation - urgh!) they have had time to develop to the point where they (look like) they are really going to work in the wild.

What a demo!
Out of the box Scott built a site with full security (login control, password reset and email page), customisable content using Web Parts, master-detail data pages (with paging and sorting enabled with simple checkboxes) using data binding in both 2 tier (direct to the db) or 3 tier scenarios (just plain public methods returning IEnumerable - no need for an interface or attributes!), easy internationalisation, support for navigation files (including treeviews and bread crumb trails) and Master Pages with Skins for easy site-wide look and feel manipulation. It truly does raise the bar about what will be expected as minimum website functionality in future.

The Full Notes
To save clogging up the aggregators and my front page, I've put my 3,500 word 'summary' of the slides and presentations here.

In summary I'd say that Scott is a great presenter.  He did a morning session on the basics, then the session I attended.  He spoke from 2pm to past 5pm and hung around until we were thrown out of the building to ensure that everyone's questions were answered.  It's obvious that he's pumped about the product and the platform that he's been instrumental in creating for developing web applications.