biztalk thoughts

I've been working with BizTalk 2006 R2 for the last few months on a new project and I have to say I'm not a fan. I recognise the advantages of a guaranteed messaging system and business process modelling tool but just can't learn to love it.

As an agile developer who does not use a designer I find the point and click, drag and drop to be anathema to my usual working practices. Rather than develop code you primarily build a set of UI components in a designer to model business processes (using orchestrations), drag and drop links between two schemas (with maps) and provide integration points via administration settings have to be configured and settings tweaked to get the system lined up to integrate the messages.

When it works, it is pretty intuitive - a beginners BizTalk training course sets you in the right direction and you can achieve rather a lot. But where I feel it falls down are the pain points it causes when you want to do something slightly more advanced. Take consuming a java web service as an example - not only was the feasibility spike work for this excruciatingly long but it was frustrating and a severe blow to morale.

I thought the days of empirical trial and error programming were far behind me but that it just what was required with the black box that is BizTalk - when one approach didn't work, we had to think of a new way... trying this led to further pain points and yet another idea of a different direction to go in after searching for similar woes on google.

The kind of thing I'm talking about is generating items via the WCF wizard when pointing at a web service wsdl where 20+ xsd files are created but then won't compile because of incorrect schema locations caused by a namespace split across multiple files. It didn't even work out of the box.

On top of this, using web service references caused mysterious NullReferenceExceptions in the WCF Marshaller classes with very limited stack trace information in the event log.

Not only is this pain energy sapping but it eats into productivity. I'm sure BizTalk experts would have sailed through our problem and could offer us some real insight into how to solve our problem... but most likely only because they have been through the same trial and error process. I'm all for problem solving as that is precisely what we do as developers but building your craft on black box error resolution is definitely not for me.

I haven't had the time to look at other messaging solutions such as NServiceBus, but I hope to do so in the future - relinquishing the fine detail code level control over what I develop is not something I want to buy into and this is precisely what I've had to do with BizTalk.

Posted at at 4:44 PM on Friday, May 29, 2009 by Posted by Justin Davies | 2 comments Links to this post   | Filed under:

implementing the balance code to a webform

I've been exploring context specification driven development in earlier posts (all avilable on this summary page).
In this post I'm adopting my progressive widening strategy so that I can deliver my user story all the way through to the UI and have a working product at the end of my work on that feature.

I therefore need to create a new web project - I name it Plutus.Web and I add a page into a new "Views" folder - Balance.aspx. I add some html code as follows:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ViewBalance.aspx.cs" 
Inherits="Plutus.Web.Views.ViewBalance" %> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 

<html xmlns="http://www.w3.org/1999/xhtml" > 
<head runat="server"> 
    <title>Current Balance</title> 
</head> 
<body> 
    <form id="form1" runat="server"> 
    <div> 
        The current balance is <asp:Label runat="server" id="currentBalanceLabel"/>
, taken on <asp:Label runat="server" ID="currentBalanceTakenLabel"/>. 
    </div> 
    </form> 
</body> 
</html>

With this html I've left room for the current balance to be displayed - both the amount and the date have labels associated with them.
Back in the code behind I now implement the IBalanceView (while first referencing the Plutus.Core project):

public partial class ViewBalance : System.Web.UI.Page, IBalanceView 
{ 
    private BalancePresenter balancePresenter; 
    private Action<Balance> newBalanceAvailable; 

    protected void Page_Load(object sender, EventArgs e) 
    { 
        balancePresenter = new BalancePresenter(this, new MemoryRepository()); 
        balancePresenter.Initialise(); 
    } 

    public void SetBalance(Balance balance) 
    { 
        string balanceText; 
        string balanceDateText; 
        if (balance == null) 
        { 
            balanceText = "0 (no balance has been stored)"; 
            balanceDateText = "(not yet taken)"; 
        } 
        else 
        { 
            balanceText = balance.Amount.ToString(); 
            balanceDateText = balance.Date.ToString("dd-MMM-yyyy"); 
        } 
        currentBalanceLabel.Text = balanceText; 
        currentBalanceTakenLabel.Text = balanceDateText; 
    } 
}

In the Page_Load method I am creating a new BalancePresenter and sending this instance of the Page in whilst creating a new MemoryRepository instance.
I am then calling Initialise() which from the specifications I wrote in the previous posts should call through to the interface method SetBalance().
Within that method I am checking for the presence of a balance and displaying text accordingly.

I make this ViewBalance page my default start page and run the web project to see the results - I get the following text on screen:

"The current balance is 0 (no balance has been stored), taken on (not yet taken)."

I can also amend the implementation of SetBalance() in the MemoryRespository and verify that it brings back the right balance:

public Balance GetCurrentBalance() 
{ 
    return new Balance(10.52, DateTime.Now.AddDays(-2)); 
}

If I rebuild and access the web page again I get the following text:

"The current balance is 10.52, taken on 15-Apr-2009.".

I've now successfully delivered my first story using context specification to deliver as much code as possible outside of the UI.
I've explored how to set up a context for the observations I am making via a "context" delegate, how to have an Act part of the AAA testing syntax via a "because" delegate and how to use the library's extension methods to make the observation code much more descriptive.

In a future post I will move onto a second user story and begin some more complex specifications.

Posted at at 7:45 AM on Friday, May 22, 2009 by Posted by Justin Davies | 0 comments Links to this post   | Filed under: ,

progressive widening

In my series of context specification posts I've been working through a particular user story and writing specifications that drive my production code. Over the next few posts I'm going to explore this story in more detail but wanted to take a quick detour into another topic that is relevant to how I plan to deliver this - that topic is "Progressive Widening".

I came across this concept in a video on InfoQ by Bob Martin entitled "Craftsmanship and Ethics"

In this he describes it as the implementation of a feature right the way through your code base and I'll be attempting to do just this in my context examples so that a working application is available after each feature is implemented.

He describes it as:

"Progressive widening is the practice of adding a small feature to the system - that feature goes from the top of the system to the bottom of the system, all the way from the GUI down to the database.
It's not a very big feature, it's very, very thin; the pragmatic programmers call these things tracer bullets, the extreme programming community calls them spikes."

"We do not implement one task in the GUI, one task in the middleware and one task in the database and we certainly never complete one layer without doing the next layer at the same time."

"Once we have ths system working in a thin little slice, then we then start to widening it - progressively widening it every iteration adding a few more of these spikes, every iteration growing the system all the way from the GUI to the database.
That is progressive widening."

I love this and it's how I write my own personal code at the moment.
In the real world its a bit trickier - I'm working on an integration project that just doesn't lend itself well to thin slices, but we strive to do this where possible. I think its an admirable agile goal.

Posted at at 10:32 AM on Tuesday, May 19, 2009 by Posted by Justin Davies | 0 comments Links to this post   | Filed under:

mocking in context specifications

In a previous set of posts I've explored a user story which has led to the creation of a BalancePresenter class for use in my MVP pattern. I now continue with this development and start this post with a new context - when I initialise a presenter I want it to go and get the current balance from the repository.
I write my specification as follows:

[Observations] 
public class when_initialising_a_balance_presenter : BalancePresenterSpecification  
{ 
    private context c = () => repository.Stub(r => r.GetCurrentBalance())
                                                   .Return(balanceUsedInObservations); 

    private because b = () => sut.Initialise(); 

    [Observation] 
    public void should_obtain_current_balance_from_the_repository() 
    { 
        repository.was_told_to(r => r.GetCurrentBalance()); 
    } 
}

I've set a context for my observations where I want to stub out a method on the mock repository object so that I can return a balance for the new method "GetCurrentBalance". It is using a protected member of the base class that is shown in a moment.

The above code is also using a delegate of type "because" which operates in a similar manner to the context delegate but essentially forms the "Act" part of the Arrange-Act-Assert syntax that this library enables - this delegate is performed before each observation that will be made.

I'm also using a new extension method in the library that wraps Rhino Mock call assertions - "was_told_to" - behind the scenes it uses the AssertWasCalled() method in the mocking framework.

To get this to compile I now need to create placeholder methods - an Initialise() on the BalancePresenter and a GetCurrentBalance on the IRepository. On the MemoryRepository class that implements it I return null.
All have no implementation in them to enable me to run the test, but before I do that I want to look at revising the base BalancePresenterSpecification and I add code as follows:

public class BalancePresenterSpecification : 
            observations_for_a_sut_without_a_contract<BalancePresenter> 
{ 
    protected static Double amount; 
    protected static Balance balanceUsedInObservations; 
    protected static DateTime date;  
    protected static IRepository repository;

    private context c = () => 
    { 
        amount = 15.45; 
        date = DateTime.Parse("01/01/2009"); 
        balanceUsedInObservations = new Balance(amount, date); 

        repository = the_dependency<IRepository>();   
     }; 
}

I've added a context that will run before the creation of my sut (system under test of type BalancePresenter - see earlier posts for more information on this). I've done so in the base class because I know that I will need the dependencies and the balance is future contexts (I'm retrospectively posting this from a later stage in my code where I added it on progressively and see little point in regressing it just for this illustration!).

The library is automatically wiring the BalancePresenter up with its greediest constructor behind the scenes and generating proxies for each dependency required by that constructor.
I'm accessing this proxy class by calling "the_dependency" for the type that I want - IRepository. Under the covers the code for accessing the dependencies looks like this:

static protected Dependency the_dependency<Dependency>() where Dependency : class 
{ 
    if (has_no_dependency_for<Dependency>()) 
          dependencies[typeof (Dependency)] = an<Dependency>(); 

    return (Dependency) dependencies[typeof (Dependency)]; 
}

A dictionary of dependencies are maintained in the base class and if there isn't one present it creates one via "an" which is illustrated below:

static public InterfaceType an<InterfaceType>() where InterfaceType : class 
{ 
    return MockRepository.GenerateStub<InterfaceType>(); 
}

It simply wires up a mock object from Rhino Mocks on my behalf and all I need is that one line - great stuff.

When I run the tests I get a failure, which is the desired effect - I haven't implemented the code in the Initialise method yet. I now do that and it passes the test:

public void Initialise() 
{ 
    Balance balance = repository.GetCurrentBalance(); 
}

I can now add a new observation for my assertion:

[Observation] 
public void should_set_the_correct_balance_on_the_view() 
{ 
    balanceView.was_told_to(v => v.SetBalance(balanceUsedInObservations)); 
}

Again, this uses the "was_told_to" extension method but of interest here is the balance variable I am using in the lambda expression - not only will it verify that SetBalance is called, but it will also do a reference comparison on the argument for me. I can then ensure that the right balance reference is going out to the view. In order to support this I have to modify the base BalancePresenterSpecification:

public class BalancePresenterSpecification : 
            observations_for_a_sut_without_a_contract<BalancePresenter> 
{ 
    protected static Double amount; 
    protected static Balance balanceUsedInObservations; 
    protected static DateTime date; 

    protected static IBalanceView balanceView; 
    protected static IRepository repository; 

    private context c = () => 
    { 
        amount = 15.45; 
        date = DateTime.Parse("01/01/2009"); 
        balanceUsedInObservations = new Balance(amount, date); 

        balanceView = the_dependency<IBalanceView>(); 
        repository = the_dependency<IRepository>(); 
    }; 
}

I have a new protected member of type IBalanceView and I am assigning a value to this in the context by obtaining a proxy dependency for it. To get my code to compile I need to create a placeholder SetBalance() method on the IBalanceView interface.
When I run my tests, predictably it fails and I then implement the code in the Initialise method of the BalancePresenter and my test passes:

public void Initialise() 
{ 
    Balance balance = repository.GetCurrentBalance(); 
    balanceView.SetBalance(balance); 
}

Posted at at 10:24 PM on Wednesday, May 13, 2009 by Posted by Justin Davies | 0 comments Links to this post   | Filed under: ,

context specifications index

I've been writing a series of posts about context specifications so thought it prudent to index all those posts here as a source for all links in the series.

  1. experiments in context specification
  2. first steps into context specification
  3. behaviour specifications
  4. exception expectation
  5. mocking in context specifications
  6. progressive widening
  7. implementing the balance code to a webform
  8. iterative context specification code
  9. more iterative context specification

Posted at at 10:10 PM on by Posted by Justin Davies | 0 comments Links to this post   | Filed under: