Picking up where we left off in the Service Bus Introduction, this post will walk through a Relayed Messaging sample in order to highlight how the AppFabric Service Bus could be utilized to build Hybrid applications.  In addition to the basic sample, I will also demonstrate how to provision a BizTalk Server 2010 Receive Location on the Service Bus.

I recently had the honor of delivering a presentation entitled "Build Hybrid Applications Using the Azure AppFabric Service Bus" at the Richmond and Philly.NET Code Camps.  Virtually no one in either of the sessions had any previous experience with Windows Azure or the components of the AppFabric.  In this series of blog posts, I will expand upon the presentation in an effort to introduce the AppFabric and take a deeper dive into the code and practical application of the Service Bus messaging patterns.

During my past BizTalk engagements, I have had the opportunity to work closely with my clients in developing flexible and maintainable applications.  One of the most common issues that I come across is the misuse of some of the shapes available within the Orchestration Designer.  By misuse, I simply mean to say that many BizTalk developers will drag and drop shapes into an orchestration to implement the business process, but do not take into account the implications of doing so.  More often than not, the result of selecting the wrong shape for the job is not seen until the application is tested or even worse, the production environment.  One of the primary reasons that BizTalk is used is the opportunity to build loosely coupled, flexible and scalable applications.  By choosing the wrong shape, many developers will wind up doing exactly the opposite, thus setting the application down the course of tight coupling and brittle implementation. 

Back in April, there was an interesting article quoting Ron Jeffries et al on InfoQ looking at code reuse from an agile perspective. The conversation steered toward explaining reuse as a concern that is very expensive, looking at it from a top-down, “enterprise”-wide lens.

But is code reuse a black and white issue? My contention is there are varying degrees of reuse that are often neglected on a microscale within an even moderately-sized project. If the code you produce isn’t going to be reused, is it even going to be looked at? These are similar problems with similar solutions.

As discussed in an earlier posting, creating a Domain Model is critical to a successful SOA implementation. But how do you effectively utilize this model within your code base as you start to develop applications that are in tools or languages that do not manipulate the XML directly?