DisclaimerThe words and opinions expressed here do not represent the opinions or views of my employer or anyone associated with me in any way.
Tag Archives: Service Bus
I will be speaking at the Richmond Code Camp on Saturday, October 6, 2012. The event is taking place on the campus of University of Richmond and you can find all of the details for the event here. My presentation … Continue reading
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.
Before I publish the next post on Relayed Messaging, I thought I would take this opportunity to share some lessons learned yesterday about the AppFabric Service Bus billing.
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.
The reports of my death are greatly exaggerated. ~Mark Twain (or BizTalk Server)
For the past 5 years or so, various technologists have been predicting or even proclaiming the untimely demise of Microsoft BizTalk Server. Usually these predictions come in the form of blog posts espousing the new hotness whether it was a new product from Microsoft or a competing product claiming it was a better middleware solution than BizTalk. Oddly enough, the chatter ramps up the loudest shortly after Microsoft releases a new CTP of technology X that may be tangentially related to an existing product like BizTalk. The problem with all of the proclamations is that they never seem to come from the Microsoft Product Development groups or BizTalk MVPs. I am not an MVP, but I do consider myself to be plugged in to what is happening with BizTalk. With that in mind, I would like to briefly take a look at the current state of BizTalk’s life and put an end to the urban legend.
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. In this post, I am going to highlight two of the most often misused shapes, Call Orchestration and Start Orchestration, explain when they should be used and provide an alternate technique to overcome their shortcomings.