# 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)  #   
# Friday, August 06, 2004

I downloaded Picasa tonight – a free photo management tool that Google recent bought.  Having 12,000 photos from the last three years I’m seriously into digital photography.  I really like Picasa, especially the timeline view of the photographs – similar to the Avalon demos from the PDC keynote – only it works today.

 

posted on Friday, August 06, 2004 12:10:58 AM (GMT Daylight Time, UTC+01:00)  #   
# Wednesday, August 04, 2004
I was pairing with someone last night trying to test the Command pattern which lead to a useful example of using NMock to create a dynamic Mock object to help test it.  Here are some notes on how NMock can be used to create DynamicMock objects based on an interface to quickly create loosely-coupled test code.

The command pattern allows you to wrap a command inside an object so that you can pass it to another object to execute that object.  We were using a simplified version of the pattern where we had a command interface that has an Execute method and a Results property to retrieve the results:

public interface ICommand

{

      void Execute();

 

      string Result{ get; }

}

 

Objects of this type are then passed in as an IList to a CommandExecutor that loops through the commands and calls Execute on each one:

 

public class CommandExecutor

{

      public void Execute(IList commands)

      {

            // loop through the commands and

            // call the command.Execute method

      }

}

So we wanted to write a test that ensured that the Execute method was called on each command that we provided to the CommandExecutor.  Initially we thought about sending through a concrete Command (say a ConcatenationCommand) and determining that the result was what we expected.  However, this would have coupled our design to that particular Command - if we made a change to the results that returned we would have to update our tests.  In this case we aren't concerned about the actual result, just that Execute is called on each command.  The question was how can we test this behaviour without having to worry about a concrete Command or its result?

This is where Mock objects come in (see the original Mock paper or the Pragmatic Programmer's overview).  They allow you to test the behaviour of an object rather than just its outcome.  The idea is to create a 'fake' or stub object that validates the object was used in the way we expected.  In our case we could create a MockCommand that derives from ICommand.  We could provide a boolean property - ExecuteWasCalled - on the class that could be set inside the execute command.

public class MockCommand : ICommand

{

      public bool ExecuteWasCalled;

      public void Execute()

      { ExecuteWasCalled = true; }

      public string Result { get { return "result"; }}

}

While this would work fine, since our needs are pretty simple in this case we could use NMock which provides a way of creating a DynamicMock object based on an Interface.  The DynamicMock exposes a property that can set expectations about the behaviour of an object, such as a particular method being called.  The DyanmicMock object also has a MockInstance method that returns an instance of the Interface. Using this technique saves us having to create a concrete Mock command.  Here's the resulting code:

[TestFixture]

public class CommandExecutorTests

{

      [Test]

      public void ExecuteMultipleCommands()

      {

            // Setup our mock Commands

            DynamicMock cmd1 = new DynamicMock(typeof (ICommand));

            DynamicMock cmd2 = new DynamicMock(typeof (ICommand));

 

            // Set our expectation that the execute method will
            // be called on each command

            cmd1.Expect("Execute");

            cmd2.Expect("Execute");

            CommandExecutor executor = new CommandExecutor();

 

            // Call our execute method on our executor

            // passing in an array of mock commands, using the

            // MockInstance property to create the instances.

            executor.Execute( new ICommand[] {(ICommand) md1.MockInstance, 
                                             
(ICommand) cmd2.MockInstance});

 

            // Use the Verify method on the DynamicMock to

            // ensure that all of our expectations have been met.

            cmd1.Verify();

            cmd2.Verify();

      }

}

 

While I still have reservations about the extent to which MockObjects are useful, I think that NMock and its DynamicMocks are a useful technique to quickly produce loosely coupled test code.

posted on Wednesday, August 04, 2004 10:43:33 PM (GMT Daylight Time, UTC+01:00)  #   
# Thursday, July 22, 2004

If you'd like to understand more about how to do messaging in WSE and would like to see the  three levels of messaging within WSE in action then why not register for my first MSDN webcast here?.  I'm going to be presenting it on Mon 9 Aug at 1PM EST (GMT -8). 

I'll be covering some of the demos from the Keith Ballinger presentation from TechEd San Diego that I presented in Amsterdam, along with some new material.  Here's the abstract:

Using messaging systems to support application functionality allows technical solutions to better match business problems.  WSE 2.0 provides messaging implementations that range from low-level explicit messaging through to high-level, more transparent models.  This webcast demonstrates various messaging levels within WSE including a custom WS-Eventing sample and how message, network addresses, intermediaries and queues need to become first-class citizens of your application. Learn how messaging can enable you to create powerful web services applications that cross machine and network boundaries.

I've put these details on my updated presentations page as well.

posted on Thursday, July 22, 2004 11:35:21 PM (GMT Daylight Time, UTC+01:00)  #   
# Saturday, July 17, 2004

Dave Bettin writes about his experiences doing a user group presentation on Indigo.  His main disappointment was that few attendees seemed to know about Indigo or the existing ASMX web services in .NET.  This got me thinking about how to get the message out about distributed apps, service-orientation and Indigo.  Is it the case that most developers need to be educated about the benefits of scalable, distributed, service-oriented apps or is it that they don't need these approaches to solve their business problems?

Dave's feedback is similar to Clemens' experience earlier in the year, where he spoke of the difficulties selling the relevance of Indigo today before he settled on explaining the 'why' over the how.  Both Dave and Clemens' experienced the same difficulty making the connection between Indigo and developers' jobs today.  Clemens' says that one of the barriers is that people think Indigo is only going to be relevant for 'Big Apps', when in fact it will be important to anyone who builds apps that expose functionality to other apps. 

One argument is that in order to get more interest in Indigo we need to educating developers about the benefits of services and distributed apps and get them to stop writing monolithic apps and start separating the logic across tiers and services.  We need to teach them more about the benefits of the services and distributed application approach, such as scalability.  Sam Gentile touched on this sentiment when he wrote that most .NET developers don't grok distributed computing

The other position regarding evangelising Indigo is mentioned by Alex Lowe in a comment on Clemens' post, is that:

Of course, we know that in the real world there are lots of applications that don't expose functionality to other applications. There are plenty of line of business applications for small and medium businesses that don't require ASMX, Remoting, and in the future Indigo.

Alex also has a summary post on his position where he says that the number of applications that need (and by extension, developers) that actually need to know about how to architect scalable applications is low.  He argues that bloggers are a distorted sample because they represent the group that need to build scalable distributed applications and they are generally well up on things.

I'm interested what other people think.  Is the problem that most developers don't understand the benefits of service-oriented distributed applications or is it that most developers are writing apps that wouldn't benefit from service-oriented distributed applications?  What business application scenarios are most likely to benefit from adopting service-orientation and Indigo?

posted on Saturday, July 17, 2004 12:07:17 AM (GMT Daylight Time, UTC+01:00)  #   
# Tuesday, July 13, 2004

To complement Simon Horrell's MSDN article on messaging with WSE 2.0, I came across this CodeProject article by Roman Kiss describing the three levels of messaging within WSE 2.0 as part of his MSMQ custom transport for WSE 2.0.  This is an excellent bit of detective work (reflectoring, as they say) as there has not been much written about  WSE 2.0's SoapTransport and it's in-memory queue that exist at the lowest level of the WSE messaging stack.

The benefit of the channel/queue model is that the message receiver can retrieve messages from the queue as they are ready to process them, rather than having to process them on demand.

Here's a simple example based on a Windows Forms application that has a button that can be clicked to retrieve messages from the in memory queue and display them in ListBox.

private ISoapInputChannel channel = null;
private void Form1_Load(object sender, System.EventArgs e)
{
   // Get our channel that's listening for incoming messages

   channel = SoapTransport.StaticGetInputChannel(
      new Uri("soap.tcp://localhost:8088/admin"),
      SoapChannelCapabilities.ActivelyListening);
}

private void button1_Click(object sender, System.EventArgs e)
{
   // When we're ready, process the messages off the in-memory queue
   SoapEnvelope message = channel.Receive();
   String messageBody =
      message.GetBodyObject(
typeof(String)) as String;
   
this.listBox1.Items.Add( messageBody );
}

In the Form_Load event the channel is retrieved from the SoapTransport.StaticGetInputChannel method, based on the channel listening on a particular network address (in this case using tcp) with particular capabilities (the options are ActivitelyListening, meaning the channel should create a listener at that address, or None, meaning the channel should connect to an existing listener).  As messages are received they are placed in an in-memory queue managed by this channel.  When the Button_Click event is fired the next message can be retrieved from the channel by calling the Receive() method which returns a SoapEnvelope from which the body can be unpacked.

posted on Tuesday, July 13, 2004 10:11:40 PM (GMT Daylight Time, UTC+01:00)  #   
# Monday, July 12, 2004

Here are some photos and conference highlights from TechEd Amsterdam (completing my backlog of blog posts).  Aside from what I've blogged already, the highlights of the conference for me were:

  • Being there when Don Box spoke for the first time about BOA.  See here for a summary of BOA postings. [update: The concept of Business Oriented Agents (BOA) was a joke designed to send up the hype about the 'next new thing' and the lack of clarity in press reporting about concepts such as SOA.  Unfortunately the joke was not clearly understood and some people are understandably upset about it.  This post was my only reference to it and I apologise if any readers felt mislead.]
  • Hanging out with the other Indigo guys and others who I'd met at PDC and TechEd US.
  • Meeting many people from the UK community at the BoF and Chalk and Talk sessions.  Thanks to everyone that came along and those who had the courage to spend some time on the park bench answering questions and making statements.
  • Increasing my list of UK Microsoft bloggers - welcome Johnny Hall (XP afficionado) and Peter Foot (Compact Framework MVP)

Here are some photos from TechEd Amsterdam, completing my backlog of posts.

Some of the 6,000 drums at the start of the keynote. Delegates enjoying the 3D presentation that finished the keynote.

Pat Helland trying out his Wizard costume in the speaker lounge. Heidi, one of the amazing organising team, showing a way to deal with the size of the RAI conference centre.
A "family photo" of all of the Microsoft Regional Directors at the Staff and Speaker Dinner on Friday. The Boom Chicago Team making fun of the competition for Best Speaker evals between Kimberly L Tripp, Rafal Lukawiecki and Steve Riley

 

posted on Monday, July 12, 2004 11:47:27 PM (GMT Daylight Time, UTC+01:00)  #   

I hosted a lively session on what Service Orientated Architecture really means at TechEd Amsterdam.  While it was a Birds of a Feather session, I decided to run it as a park bench format in order to take advantage of having David Chappell, Michele Leroux Bustamante and John Hooper (blogless MCS UK Architect) come to the session.  Here were some of the interesting discussion points that came up:

  • There was some agreement that SOA is a pragmatic marketing term that unites many existing architectural principles around SOAP. 
  • The closest agreement about a definition for SOA was that it was based around common architectural principles of encapsulation, loose coupling and messaging.
  • There was some discussion about whether asynchronous messaging was a necessary part of service orientation. My feeling is that since you can achieve synchronous patterns over asynchronous communications that having asynchronous messaging capabilities is extremely useful.
  • Although it's possible that these principles could be applied without SOAP, it's the fact that Microsoft, IBM, BEA and others have agreed that SOAP will be the lowest common denominator that is the pragmatic reason behind the current push for SOA.
  • David made a point that service orientation will be whatever Indigo supports when it ships.  Shipping software always wins.  I think there's a lot of merit in this argument, but to the extent that SOA is based on generic architectural principles it is worth considering using these principles in systems that are design today (as Clemens demonstrated all conference).  If SOA principles help solve your business problems today then it's definitely worth starting today rather than waiting for Indigo.
  • Some delegates were suspicious that using Indigo would enable them to interoperate with other systems that didn't use Indigo.  There was some confusion about the idea that Indigo will provide an object model that can be used to develop a system that has the capability to send messages between the systems that are based on interoperable WS-* specifications.
  • The four tenets of service orientation are necessary but not sufficient for a system to be considered a service oriented architecture.  Some people thought they were too technologically focussed because they were tied too closely to XML technologies.
  • David mentioned that the best SOA installation he'd seen was using CORBA several years ago - it had support for finding services, common schemas etc.  Michele backed up the need for shared industry schemas based on some of her experienced.
  • John Hooper was interested in Pat Helland's assertion that services should not share transactions, which led into the difference between WS-Transactions (classic two-phase commit) and WS-BusinessActivity (compensating transactions).
  • A delegate who was learning about the topic came up to the chairs and spoke about what he'd learnt at TechEd.  This was great to hear and generated a lot of discussion.  Clemens' presentations clearly had some impact with many in the audience.

me with David ChappellHere's me with David Chappell after the session.  I've been a fan of his since reading Understanding ActiveX and OLE when I started Microsoft programming.

 

 

 

posted on Monday, July 12, 2004 10:51:11 PM (GMT Daylight Time, UTC+01:00)  #   
# Wednesday, July 07, 2004

Clemens' session on his ProseWare application at TechEd Amsterdam last week was one of the best conference sessions I've seen.  Proseware is "an industrial-strength, robust, service-oriented example application that newtelligence has designed and implemented for Microsoft".  The application clearly demonstrates how to go about building services today with currently shipping technology, reinforcing that there's no need to wait for Indigo to start building service oriented apps!  I'm hoping that we see a public release of these bits soon on MSDN.

Points that grabbed me:

  • Guidance on where to use messaging patterns: Use the OneWay pattern where there is no intelligent immediate reply or no reply is needed, use Request Response pattern where a message asks a question that can be answered immediately (in under a second) and use the Duplex pattern when a message asks a question that can be answered later as the service has capacity (e.g. anything that takes over a second).
  • Clemens showed how to achieving 'near enough' reliable web services with HTTP and services that use MSMQ transactional queues behind the service interface.  If there were any problems placing the message onto the queue then an exception would be returned inside a SOAP fault response.  He optimised this further by using a void response type on the web service method, even though it was not marked as OneWay, so that if there were no problems placing the message on the queue then the web service response message would be small.
  • ProseWare is based around a repository of XML schema files which he uses to dynamically generated the 'message' classes in the application using pre-build steps.
  • All of the service projects shared these schemas rather than having any project references linking to the binaries (services are autonomous).
  • The pre-build step inserts ISerializable attributes onto the message classes so that they can work with Remoting.
  • These message classes are used as the only input parameter to all of the public web service methods.  These classes leverage XML Schema's support for allowing any element or any attributes to come through, which is a powerful way of allowing for future extension to the message.  Dare goes through this in one of his previous posts.  The XML Serialization attributes look similar to this:

[System.Xml.Serialization.XmlAnyElementAttribute()]
public System.Xml.XmlElement[] Any;

[System.Xml.Serialization.XmlAnyAttributeAttribute()]
public System.Xml.XmlAttribute[] AnyAttr;

  • Clemens showed how to use the properties in COM+ 1.5 in XP/2003 to set the home directory for an application, meaning it is possible to use a .NET config file to store the config. He's blogged about this previously here and here.
  • He created his own object pool to create something similar to the ADO connection pooling but for COM+ objects.  He simply pops a component out of the pool and pushes it back when he's done, avoiding the excessive overhead when calling new in a COM+ environment (which has to create the pipeline connections).  He has also blogged about this JIT activation pooling here and here.
  • He mentioned how LRPC, which is used under the covers in ES, is the fastest way to go cross-process on a single machine.  In order to get this benefit you need to use the JIT activation pooling in order to avoid having the performance gains wiped out by the cost of creating ServicedComponents (again, something Clemens' previously blogged).
  • The nice part was that Clemens had done the hard yards and built an application installer that handled created the SQL Server and Windows user and group accounts.  He even showed where he'd found bugs in the OS and how he'd had to work around them.  Information like this is priceless (well, worth a lot of contracting dollars) if you're ever working in a situation where you need to achieve these outcomes.
posted on Wednesday, July 07, 2004 7:49:36 AM (GMT Daylight Time, UTC+01:00)  #