BrianLoesgen.com

This is the third post in this series. So far, we have seen:

• Post #1: Creating an ESB on-ramp that receives from Azure’s AppFabric Service Bus
• Post #2: Sending a Message from BizTalk to Azure’s AppFabric ServiceBus with a Dynamic Send Port

In this third post, we will see how to use an ESB off-ramp to send a message to the Windows Azure AppFabric ServiceBus. We will actually be doing the same thing as we did in the second post, however, we’ll be doing it in a different way.

There is an accompanying video for this post (as I did with the others too), which you can find here.

The sequence used here is:

1. Message is picked up from a file drop (because that’s how most BizTalk demos start:))
2. An itinerary is retrieved from the itinerary repository and applied to the message
3. The itinerary processing steps are performed, and the message is sent to the ServiceBus
4. The message is retrieved by the receive location I wrote about in my previous post
5. A send port has a filter set to pick up messages received by that receive port, and persists the file to disk

The last two steps are not covered here, but are shown in the video.

In this case, we’re not using an orchestration at all, we’ve specified in the itinerary that all processing happens at a messaging level.

The first part of this is the itinerary selection, which is as shown below. As you can see, I’ve “hard-wired” this receive location, and anything coming through it will get the “ServiceBusTest.OrderRelayNetTcp” itinerary applied to it.

The itinerary itself is also quite simple (this one is slightly different than the one shown in the video, but they are functionally equivalent).

All of the magic happens in the “SetProperties” resolver. In this case I am using a STATIC resolver, however, that just means I have statically specified the values. The settings are being applied dynamically by the itinerary processing components. Note that I have specified we are using the WCF-Custom adapter provider. As was the case with the first two posts in this series, I have installed the Windows Azure platform AppFabric SDK, which gave me some additional bindings that let me relay messages through the ServiceBus. In the second post, we used one of those bindings along with the WCF-Custom adapter by setting some values on a dynamic send port. In this one, we will set the same properties, but do so using the out-of-the-box ESB Toolkit WCF-Custom adapter provider. Each adapter provider registered with the ESB has a UI that can be associated with it, and you get there by clicking the Endpoint Configuration ellipses:

If you compare the values above to what I set in the second post in this series, you’ll see they are pretty much the same.

And…. THAT’S IT!!!!! That is all we have to do in order for BizTalk to send a message to the Azure platform AppFabric ServiceBus using an ESB off-ramp. As you can see from the behavior specified, this is a secured channel (in this case I am using “shared secret”). The actual security part of this is provided with the Windows Azure platform AppFabric Access Control Service, which is tightly integrated with the ServiceBus.

Note also that in this example I used the netTcpRlayBinding, which is a high performance .NET-to-.NET, but also requires TCP/IP ports be open, which could be an issue depending on how locked down your network is.

For my demo purposes, I use the ws2007HttpRelayBinding (also provided with the Azure AppFabric SDK), as that’s over port 80.

In this series of posts I have shown you how to bridge the gap between on-premise and Windows Azure AppFabric ServiceBus using out-of-the-box BizTalk and/or ESB Toolkit components. There is much more that can be done, this is only the beginning. We are entering a really interesting time, and I think that “hybrid” applications, with some part on-premise, other parts off-premise, will become increasingly common. As that happens, having a clean integration solution becomes very important so that we don’t create “Point-to-point Spaghetti 2.0”, a more modern version of the chaos that many experienced integration developers have seen all too frequently.

I hope you’ve enjoyed these posts and videos, and that they help you as you explore the new and exciting world of Windows Azure.

In a previous post, I wrote about how to extend the reach of an ESB on-ramp to Windows Azure platform AppFabric ServiceBus. This same technique also works for any BizTalk receive location, as what makes it an ESB on-ramp is the presence of a pipeline that includes some of the itinerary selection and processing components from the ESB Toolkit. In that post (and accompanying video) I showed how to use InfoPath as a client to submit the message to the ServiceBus, which subsequently got relayed down and into a SharePoint-based ESB-driven BizTalk-powered workflow.

In this and the next post, we’ll look at how to send messages in the other direction, and in this post, I’ll show how to do it using a BizTalk dynamic send port. If you’re used dynamic send ports with BizTalk, you’ll know they’re a powerful construct that let you programmatically sent endpoint configuration information that will subsequently be provided to a send adapter. This is a great way to have a single outbound port that can deliver messages to a variety of endpoints. And, dynamic ports are a key concept behind ESB off-ramps, but more on that later.

The video to go along with this post can be found here.

The sequence used here is:

1. Message is picked up from a file drop (because that’s how most BizTalk demos start:))
2. A BizTalk orchestration bound to that receive port is instantiated
3. The orchestration (in an expression shape) sets properties the adapter will use
4. The message goes to the dynamic send port and is dispatched
5. The message is retrieved by the receive location I wrote about in my previous post
6. A send port has a filter set to pick up messages received by that receive port, and persists the file to disk

The last two steps are not covered here, but are shown in the video.

Our orchestration is proof-of-concept simple, as you may have expected:

In our message assignment shape, first we create and work with the message:

Then, because the outbound port in our orchestration is a dynamic port, we set a couple of properties on that:

And…. THAT’S IT!!!!! That is all we have to do in order for BizTalk to send a message to the Azure platform AppFabric ServiceBus. As you can see from the behavior specified, this is a secured channel (in this case I am using “shared secret”). The actual security part of this is provided with the Windows Azure platform AppFabric Access Control Service, which is tightly integrated with the ServiceBus.

Note the value of the WCF.BindingType (netTcpRlayBinding). This is just one of the ServiceBus-related bindings you get when you install the Azure platform AppFabric SDK. This particular binding is high performance .NET-to-.NET, but requires TCP/IP ports be open, which could be an issue depending on your network.

I’ve always loved the flexibility that the WCF-Custom adapter provides, and here is yet another example. Another team issues an SDK well after the current release of BizTalk, and because we’re all leveraging WCF it makes it trivial for us to take advantage of the new capabilities.

The next post and video in this series will show how to provide message sending capabilities using the components provided with the ESB Toolkit. Stay tuned….

I will be doing a brand-new, never-seen-before presentation at the Code Camp in Fullerton next week. I’m late signing up as I wasn’t sure if my schedule would permit it, but it all looks good, so I’ll do it.

The session will encapsulate some of the cool stuff I’ve been doing spanning the two environments. This will be a powerful (and I would say essential) presentation for BizTalk developers as it highlights some of the new patterns we now have at our disposal. However, I this is also an important session for anyone deploying services to Azure and calling them from on premises, as many will not have an integration background and as such will run into the typical pitfalls that experienced integration devs know to avoid.

I’ve done one post about bridging on-premise to Azure here, and there are more videos working their way through MSDN that should be live any time now. Once they go live, I’ll post accompanying blog posts.

I’ll be presenting at 2:45 on Sat Jan 30th. Hope to see you there if you’re attending this Code Camp.

Title:

Bridging the Gap between On-premise ESB and Windows Azure

Abstract:

Having attained the plateau of productivity, companies worldwide are enjoying the benefits and efficiencies that can be realized through a well-defined and implement SOA strategy. In addition, many are also realizing the business value and agility improvements that come from have an Enterprise Service Bus in place as a messaging backbone to support their SOA infrastructure.

With the recent “go-live” of Microsoft’s Windows Azure platform, intriguing new architectural patterns for distributed applications are being made possible. In this session we will look at what it means to bridge from the on-premise ESB to the Windows Azure platform. In addition, we will cover the value-add that an ESB brings to Azure usage. We will take a pragmatic approach, showing you what can be done today, with the tools available to you right now.

Register at http://www.SoCalCodeCamp.com.