Architecture and Design

1 Comment

Microsoft has announced that the little cross-platform, cross-browser cousin of Windows Presentation Foundation will be called Silverlight. This technology which was first announced at PDC05 was codenamed "WPF/E".


Tim Sneath has the best list so far of the features and power of this "Flash killer" technology. Microsoft doesn't ever call Silverlight a Flash killer, but the overlap in feature set is so large, that it cannot be viewed as anything other than a direct Flash competitor.


However, I do believe that Silverlight leapfrogs Flash in a couple of ways. The programmability and ease of use is better than Flash. You can build Silverlight sites using just Notepad if you want. The direct integration of the Silverlight DOM (Document Object Model) with JavaScript in the browser and the ability to create Silverlight UI elements on the fly with the createFromXaml method is a killer feature.


Tim Sneath mentions a secret number 10 feature on his list:



"Ah... #10. I can't reveal this yet - there's a big surprise up our collective corporate sleeve that will be announced at MIX. I hate to hold back on you, but anticipation is part of the pleasure, as my mother used to tell me as a child when I was waiting impatiently for Christmas to come!"


Could this be the .NET programmability that was previously speculated about? Soma spills some more details in his announcement:



"As I mentioned, this Silverlight announcement at NAB is only part of the story, the rest will be unveiled at MIX including details about how Silverlight is a core component of Microsoft’s broader .NET platform."


I commented previously on Robert McLaws' blog that I didn't think that Microsoft wasn't going to release a lightweight crossplatform CLR for Silverlight programmability. But I also speculated that Microsoft was working on a bigger crossplatform CLR based on the .NET Compact Framework.


What I am pretty sure about, is that Microsoft will announce ASP.NET controls that will allow you to very easily integrate Silverlight on your web pages and to expose dynamic data as XAML to Silverlight controls. I.e., AJAX on steroids UI-wise.


Adding ASP.NET to the mix shows that there is no direct need for a CLR on the client in order to enable C# or VB.NET programmability: coding in C#, compiling to IL and converting that IL to JavaScript on the fly! Prototype efforts by Nikhil Kothari with Script# show that this is quite possible. Check out Nikhil's example.

[Update: The electronic version (in Dutch) is available online now.]


My article on developing interactive TV-websites using ASP.NET 2.0 has been published in the Dutch .NET Magazine #16. I mentioned that I was writing this article in January and I made the deadline.


If you are subscribed to this magazine, you received issue #16 last Friday. The electronic version (in Dutch!) is not online yet, but it should appear in the near future. All previous issues are available here.


The typesetting process has caused a few minor issues that I would like to rectify here:



  • The byline of code example 1 reads "WMC.browserbestand om Windows Media Center mee te herkennen". This should be "WMC.browser bestand etc." I.e., it's a file with the .browser extension.
  • In the "ASP.NET 2.0 browser sniffing" section, the line "Daarin kun je bestanden plaatsen met de browserextensie." should read "Daarin kun je bestanden plaatsen met de .browser extensie".

If any other issues are discovered, I'll update this post.

1 Comment

As announced on Tom Hollander's blog, the Microsoft Enterprise Library 3.0 will include a new application block: the Policy Injection Application Block.


Enterprise Development Reference Architecture (EDRA)


Edward and me noticed a striking similarity with an earlier effort by Microsoft Patterns and Practices. For some other people who have been following the P&P guidance for some years now, this similarity didn't go unnoticed as well. For example in the post: Can anyone say Shadowfax?


"Shadowfax" was the codename for the Enterprise Development Reference Architecture (EDRA) released by Microsoft in 2004.


One of the important goals for EDRA was the separation of business logic from cross cutting concerns in enterprise applications. This was implemented by providing a pipeline of pre- and posthandlers that could be inserted declaratively using configuration in XML format. Messages would pass through this pipeline before reaching the business logic. The response would go back through the pipeline as well. EDRA handlers could inspect and even alter the messages flowing through the pipeline.


One of the other important goals for EDRA was the ability to physically separate the service interface from the service implementation. As in distributing these layers across different tiers and across security boundaries.


Our business unit at LogicaCMG followed and evaluated this effort in 2004 and even used it in some projects. We especially liked the fact that this was a ready-made framework for "policy injection". We made some extensions for cross cutting concerns not originally included in EDRA. Previously, we worked on a home-made framework that was based on .NET remoting extensibility to configure cross-cutting concerns. Although architecturally sound, it was far from complete because it still had a long way to go to fulfill our vision.


EDRA also included an early prototype of the Guidance Automation Toolkit to help framework users with building an EDRA based service. This was known as the "Microsoft IPE Wizard Framework". Check out this blog post from Daniel Cazzulino to see the EDRA wizard framework in action.


Eventually we reluctantly decided to drop EDRA. Some of the reasons for this were:



  • The EDRA wizards were hard to extend.
  • You had to mess with a big XML file to configure handlers.
  • No proper .NET 2.0 support.
  • No WS-* support.
  • No support for calling out into other services from the service implementation.
  • No big adoption in the worldwide .NET community. Not a lot of publicly available handlers.
  • No clear path towards Windows Communication Foundation. The internal messaging structure was not based on SOAP.

Especially the last reason was probably the biggest reason why Microsoft decided to stop the P&P effort on EDRA. The 1.1 release was announced to be the final release.


The Microsoft Enterprise Library has become far more successful with respect to adoption world-wide than EDRA. There are several EntLib extensions freely available. I've contributed my RollingFileTraceListener to the greater EntLib community. According to the feedback I got, this extension has been really useful for several people and companies. Microsoft has realized the lack of this functionality in the Enterprise Library and EntLib 3.0 will include a similar rolling file trace listener out-of-the-box.


EDRA is still being used by some companies. One of the largest implementations is the Commonwealth Bank of Australia CommSee Solution that is based on EDRA. Microsoft is still using this as a reference case. For instance, there was a presentation on CommSee at LEAP2007 in Redmond.


I disliked the idea that EDRA pushed you into the direction of distributing the service interface and service implementation across different tiers. Both layers had to be realized in managed code using EDRA, so the service interface could also just call the service implementation in process. Remember the first law of distributed computing: "Don't distribute!" (unless you have to).


Of course, it was great that you could distribute service interface and service implementation. But not all applications need this.


So in my opinion it is better to have different frameworks that cleanly support these orthogonal concepts:



  • Separating business logic from cross cutting concerns.
  • Separating service interface from service implementation across physical tiers.

Proseware


By the way, a sample application that was commissioned by Microsoft to provide guidance on how to build distributed systems never saw the public light of day. It was the Proseware application designed and build by newtelligence's Clemens Vasters. I never got a clear answer from Richard Turner, the responsible program manager at Microsoft, for why it would not be released. But I think it was because of internal Microsoft politics: Proseware was too close to the release of WCF and might be perceived as conflicting guidance (too close turned out to be two years!).


Proseware included a great idea to improve the reliability and scalability of web services. By using one-way messaging for both requests and response. That way you can use queuing inside your service to handle heavy loads and to automatically retry failed attempts at processing messages (for example when a database is temporarily unavailable) without bothering the service clients with having to retry. To achieve this, a web service interface would be a very thin facade around an MSMQ transactional message queue. The web service would only return a fault when the message could not be placed onto the queue (highly unlikely). The message would re-enter the queue if the service implementation failed at processing it so it could be processed again. A response from the service implementation would be send using a one-way message to the recipient specified in the WS-Addressing ReplyTo header in the original request. Note that this recipient does not have to be the original caller! It could well be a different service and the response message is really a new request. Check out this blog entry for more details on Proseware.


Eventually, we will all leave the world of developing and calling synchronous services in distributed systems, but that may take a while 😉 Anyway, sorry for this digression, enter the Policy Injection Application Block.


Policy Injection Application Block


The new Policy Injection Application Block (PIAB) wisely focuses on just the separation of business logic from cross cutting concerns. Windows Communication Foundation is the way to go for distributing your system, i.e., for building connected systems.


The PIAB shares the idea of a pipeline of pre- and post handlers processing messages. It uses the MarshalByRefObject and TransparentProxy infrastructure that was originally designed for .NET remoting to transparently insert policies when they are enabled. The client just thinks it is calling the business logic object directly. Take a look at the pictures in Tom's blog entry to get a better idea of how this works and read Edward Jezierski's blog post.


You might also be interested in the comments posted to Tom's announcement. Several people are concerned about the performance impact that inserting policies will have on your code. This is caused by the technical implementation that Microsoft has chosen to insert policies (or should they be called aspects? ;). As I haven't looked into detail at the new block, I do not have a firm opinion on this matter yet.


The transparent aspect of the policy injection does conflict with the wisdom put into WCF. WCF follows one of the important tenets of service orientation: "Make boundaries explicit". Don't fool the client into thinking they are just performing a local method call, because the performance and reliability characteristics are entirely different. WCF achieves this explicitness by using DataContracts and ServiceContracts. It does not expose everything by default, you have to opt-in. It also makes you more aware that you should not use chatty interfaces across service boundaries.


One of the comments to Tom's blog post states that the overhead of just having a PIAB policy injection could mean that the mere act of calling a method is 50 times slower than a direct method call. If this is the case, you should be well aware and design your objects accordingly: don't implement chatty interfaces!


The future will tell if the PIAB will be more successful than EDRA at enabling the separation of business logic from cross cutting concerns in .NET enterprise applications.

1 Comment

Bruce Eckel has an interesting post on hybridizing Java with Flash. He notices the trend in the Java world to replace Java-based GUI frameworks (AWT, Swing, etc.) for Java apps by Flash.

Incidently, I came across one such app yesterday evening when I installed PowerSnap. The UI indeed was somewhat snappy. This application claims it can keep your locally stored photographs in sync with those posted on Flickr.

Of course, the major benefit of using Flash over UI technologies as WPF is reach. WPF only runs on a subset of the Windows platforms. PowerSnap is working on a Mac version which should be relatively easy because Java and Flash are available on the Mac.

WPF/E is nice and will be cross-platform but I think it will be confined to the browser in v1. Currently the WPF/E engine can only be scripted using JavaScript.

Maybe in future versions it can be used for the GUI layer of a standalone cross-platform .NET application. Microsoft is quietly working on versions of the CLR that will run on other platforms so that WPF/E can be "scripted" using C#. The work done by the .NET Compact Framework team already proves that this is possible. This CLR runs on devices like SmartPhones, PDAs and the Xbox 360.

RJ has already blogged (in Dutch) about Tuesday's sessions of LEAP here at the Microsoft campus in Redmond, WA.

Let me add that I was pleasantly surprised by the lack of product pushing by the Microsoft architects. The LEAP sessions in Barneveld (NL) were much more focussed on Microsoft products. They were mainly on the pros and not the cons of those products.

The sessions here in Redmond gave nice high-level overviews of a couple of topics that we as architects face in today's IT world.

The G-word seemed to be forbidden (apart from Gmail) but all-in-all Microsoft gave a balanced picture of software as a service.

The session by Jack Greenfield on Software Factories was the best of the day. I was already familiar with Microsoft's vision and strategy and the Sofware Factories Initiative. Hearing the man with the vision speak himself on this subject adds a lot to this.

On Thursday we can attend a workshop that goes into more depth on software factories and where Microsoft will show off early bits of the future products in this space. We have to sign a Non-Disclosure Agreement (NDA) before attending that session, so we can't blog about it.

1 Comment

When you create a Windows Communication Foundation (WCF) service proxy class for a service by using svcutil.exe, it creates a proxy that derives from System.ServiceModel.ClientBase<TChannel>. This class implements IDisposable so you think you can use your proxy safely in a C# using statement and get guaranteed clean-up in the face of exceptions.

However, the System.ServiceModel.ClientBase<TChannel> class can throw exceptions from its Dispose method, because it calls its Close method. This can happen when it is in a faulted state. In that case you have to call Abort for clean-up. Most times you are not interested in knowing whether the Dispose fails or not and you just want to have guaranteed clean up of any resources held by the proxy.

Check out this discussion on the WCF forum for why Microsoft implemented the dispose in this way.

To prevent you from writing a lot of code to accomplish this clean-up, I have written a generic ServiceProxyHelper class that does it for you. You can download it here or view the code below. It only swallows expected exceptions in its Dispose method but it always cleans up by calling Abort.

The idea is that you derive a class from my ServiceProxyHelper<TProxy, TChannel> class. Insert your proxy class (that should derive from ClientBase<TChannel>) name for TProxy, and the service interface name for TChannel. The helper class wraps the proxy and doesn't directly expose its methods. From your derived class you can use the protected Proxy property to get access to the service proxy. You should add methods to your derived class that delegate to the proxy.

For our project we added convenience method to the derived helper that create request messages and unpack response messages. So our helper methods have a different signature than the methods on the proxy class itself.

This code is provided "AS-IS" without any warranties. You can change it to fit your needs.

 
using System;
using System.Collections.Generic;
using System.ServiceModel;

namespace LogicaCMG.ServiceAccess
{
    /// <summary>
    /// Generic helper class for a WCF service proxy.
    /// </summary>
    /// <typeparam name="TProxy">The type of WCF service proxy to wrap.</typeparam>
    /// <typeparam name="TChannel">The type of WCF service interface to wrap.</typeparam>
    public class ServiceProxyHelper<TProxy, TChannel>: IDisposable
        where TProxy : ClientBase<TChannel>, new()
        where TChannel : class
    {
        /// <summary>
        /// Private instance of the WCF service proxy.
        /// </summary>
        private TProxy _proxy;

        /// <summary>
        /// Gets the WCF service proxy wrapped by this instance.
        /// </summary>
        protected TProxy Proxy
        {
            get
            {
                if (_proxy != null)
                {
                        return _proxy;
                }
                else
                {
                        throw new ObjectDisposedException("ServiceProxyHelper");
                }
            }
        }

        /// <summary>
        /// Constructs an instance.
        /// </summary>
        protected ServiceProxyHelper()
        {
            _proxy = new TProxy();
        }

        /// <summary>
        /// Disposes of this instance.
        /// </summary>
        public void Dispose()
        {
            try
            {
                if (_proxy != null)
                {
                    if (_proxy.State != CommunicationState.Faulted)
                    {
                        _proxy.Close();
                    }
                    else
                    {
                        _proxy.Abort();
                    }
                }
            }
            catch (CommunicationException)
            {
                _proxy.Abort();
            }
            catch (TimeoutException)
            {
                _proxy.Abort();
            }
            catch (Exception)
            {
                _proxy.Abort();
                throw;
            }
            finally
            {
                _proxy = null;
            }
        }
    }
}

1 Comment

Even though I blog a lot about installing things and trying out new Microsoft technology, my day job is being an application architect.

Today, I would like to state I am an Agile Architect.

Sam Gentile has a wonderful blog post titled Being an Agile Architect. I quote:

(...) Agile Architects CODE ALL THE TIME and SIT WITH THE WHOLE TEAM and not on the mount. We use Agile Modeling. We use Simple Models with Sketches, Whiteboards, Pair Programming rather than Rational Rose UML models because the value-add is the business value we generate in code (Software Is Your Primary Goal) not some UML diagram. I am an Agile Architect.

So Agile teams don't be afraid of us. After all we're guides on the same journey.

Hopefully Matthijs, the developer on the team for our Rabobank TV project, can agree that I practice what I preach 😉 At least on that project.

During my holiday, another project will start for which I proposed the high-level application architecture. That was a document containing a lot of words but 0% code. Nevertheless still pretty down to earth, and nothing like what Architecture Astronauts produce. My favorite piece from that post by Joel Spolsky:

Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all. 

These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing.

Microsoft's Rico Mariani has two very interesting posts that shed some light on when to prefer structs (value types) and public fields over classes (reference types) and properties. He explains why it is a good thing to break Microsoft's Design Guidelines (partially enforced by FxCop) in certain situations.

If you have some time to spare, go read the first post to ponder on the questions he asks. Then check out the comments made to that post. Finally, read Rico's answers to the questions in the second post.

If you want to cut to the chase, go right to the second post.

1 Comment

Bruce Eckel wrote about the impossibility to implement mixins in Java using generics. This made me think back to my C++ days and if and how this can be done in (future versions of) C#.

Let me first start with a problem statement. Say you want to adorn a class with a timestamp. Meaning when you create an instance of such class, you want to automatically have it stamped with the time of its creation. You want any instance of that to have a read-only Timestamp property of an appropriate type (say System.DateTime in C#).

There are a couple of cases to consider:

  1. You author both the behavior and the classes and just want to save on typing duplicate code.
  2. You want to author timestamp behavior for a library. Consumers of that library can mixin the behavior to classes they author.
  3. You consume existing classes you cannot change and you want to add the timestamp behavior to them.

Let’s start with the most straightforward approach. Just whip up an abstract base class called Timestamped and derive your classes from it.

      public abstract class Timestamped

      {
            private DateTime _timeStamp = DateTime.Now;

            public DateTime Timestamp
            {
                  get { return _timeStamp; }
            }
      }          

      public class TimestampedPerson: Timestamped
      {
            ...
      }

 

Of course, the usual drawbacks apply. The CLR, and thus C#, doesn’t support multiple inheritance, so this precludes you from deriving your class from other base classes. Also it doesn’t work for existing classes.

Say you have an existing Person class:

      public class Person
      {
            private string _name;
            private int _age;

            public Person(string name, int age)
            {
                  _name = name;
                  _age = age;
            }

            public string Name { get { return _name; } }

            public int Age { get { return _age; } }
      }

Since you cannot derive from Timestamped you can add the behavior by deriving from Person.  You might hope to solve this in C# 2.0 once-and-for-all using generics. Just declare the following generic type:

      public class Timestamped<T> : T
      {
            private DateTime _timestamp;

            public Timestamped()
            {
                  _timestamp = DateTime.Now;
            }

            public DateTime Timestamp
            {
                  get
                  {
                        return _timestamp;
                  }
            }
      }

 

So you can now have a Timestamped<Person>. Unfortunately generics in .NET 2.0 do not allow you to derive from a bare type parameter. Also you would run into the problem of how to construct an instance. Person does not have a default constructor and Timestamped<Person> does not have a constructor that takes a string and an int and passes it along to the base class constructor Person(string name, int age). You could add such a constructor to Timestamped<T> but then it would no longer be generic. Even if this would be possible, what if the Person class was sealed? This precludes you from deriving from it.

Note that C++ templates do allow you to derive from the type parameter. C++ does suffer from the constructor problem. Nevertheless this is a widely used approach for mixins.

Extension methods

What about extension methods? In C# 3.0 it will be possible to add methods to existing classes. Olaf Conijn noted that this is similar to mixins. Because there are no extension properties announced as of yet for C# 3.0, I have to use a GetTimestamp method instead of a Timestamp property. So what about:

      namespace Stamp
      {
            public static class TimeStampExtension
            {
                  public static DateTime GetTimestamp(this object o)
                  {
                        return DateTime.Now;
                  }
            }
      }

 

If you now include using Stamp in your code, every object gains the GetTimestamp method. So I could write:

                  Person jan = new Person("Jan", 30); 
                 
Console.WriteLine( jan.GetTimestamp() );

 

But it is also pretty clear that this doesn’t give us what we want. The GetTimestamp method returns the time at which it is called. It has no way of knowing at what time the Person  instance on which it was called was created. The reason is that extension methods cannot add state to an object. So this rules out extension methods for this type of mixin.

I have seen other approaches for mixins in C# using a whole lot of proxy and interception magic, but I think this just looks ugly.

It’s not clear to me if there is more that hasn't been announced for C# 3.0. I hope Microsoft will find a way to make mixins first class citizens in the language.

Today I found the time to get my hands dirty on C# 3.0 and LINQ. At PDC05 I went to a couple of sessions on these topics and I read the excellent whitepaper on the LINQ project by Hejlsberg and Box. But I was too busy attending other sessions to try out the hands-on-labs. The hands-on-labs are available for download as Word documents containing instructions.

During download and installation of the C# LINQ Tech Preview I read a most excellent blog post by Ian Griffiths on Expression Trees. If you are interested in C# 3.0 go read it, if you haven't already done so! It talks about the parts of C# 3.0 that impressed me the most.

After the installation of the C# LINQ Tech Preview I hit a little snag. The new project templates for LINQ didn't show up in Visual Studio. An investigation with File Monitor showed that the templates were installed in a subfolder of My DocumentsVisual Studio 2005TemplatesProjectTemplates. It turned out the user setting for the user project templates location in Visual Studio pointed to the wrong location. It pointed to a subfolder of My DocumentsVisual StudioTemplatesProjectTemplates (so without the 2005 in the name). I have installed a lot of CTP and beta builds of Whidbey in the past and this folder probably changed sometime ago. I didn't notice this problem before, because WinFX installs its project templates elsewhere.

So now I am all set to start experimenting. I also want to check out VB 9.0, because of its support for dynamic typing and XML. I am impressed by anonymous classes and extension methods in C# 3.0. They alleviate some of the need for dynamic typing. But is it enough?

And I also want to check out Atlas and Windows Workflow Foundation. Sigh, so much to explore, so little time...