This week I gave a presentation to the Sydney BizTalk User Group on (Biz)Talking to the Cloud. I showed how we can quickly and easily configure a BizTalk Receive Port to consume services hosted in the cloud. In the demo, we configured BizTalk to participate in a multicast events scenario.

I have been playing further with BizTalk and Cloud services and in this post I will demonstrate how to expose BizTalk Orchestrations to the Cloud. To make it easy for you to build this on your own environment, I have used the now famous (or infamous) EchoService as the basis of this demo. This allows you to use the existing Microsoft .NET Services SDK sample to call the BizTalk Orchestration through the cloud.

Before You Begin

1. Sign-up to Microsoft .NET Services and create your Solution.
2. Download the Microsoft .NET Services SDK and install on your BizTalk Server 2006 R2 development environment.
   Note: Nothing more is needed as far as BTS is concerned. I am pleased Microsoft is making good on ensuring developers can use existing skills and technologies to get started with cloud services. Furthermore, we can be fairly comfortable that playing around with this stuff is not going to break or render our existing dev environment useless. Credit where credit is due.

BizTalk Development

In this step we will create a simple orchestration that receives a generic message, pulls the "echo" text out, creates the response message, and sends it back out the two-way port. I have used System.Xml.XmlDocument types avoiding the need to create schemas and simplifying the demo.

1. In Visual Studio 2005, create a new Empty BizTalk project.
2. Go ahead and set your Assembly Key File and BizTalk Application project settings. (I called my BizTalk App BizTalk Services as we will see later on)
3. Add a new Orchestration to the project.
4. Create the following messages:
   

Name	Type
msgRequest	System.Xml.XmlDocument
msgResponse	System.Xml.XmlDocument



5. Create the following variables:
   

Name	Type
strText	string
strResponse	string
xmlDoc	System.Xml.XmlDocument



6. Add the following shapes to the design surface
   
   
   
7. In the Message Assignment shape enter the following code to construct the response message:
   

// Retrieve the text sent in the request
strText = xpath(msgRequest, "string(//*[local-name()='text'])");

// Construct the response
strResponse = System.String.Format("<EchoResponse xmlns=\"http://samples.microsoft.com/ServiceModel/Relay/\">
                                      <EchoResult>{0}</EchoResult></EchoResponse>", "BizTalk: " + strText);

// Create the response document
xmlDoc.LoadXml(strResponse);

// Assign the response message variable
msgResponse = xmlDoc;

8. Now add a Two-Way port setting the port Binding to Specify Later and the Type Modifier to Public.
   Note: As we will be binding to a physical receive port, operation names are not important here.
9. Wire up the port operations and don't forget to set the Activate property of the Receive shape
10. Build and deploy your project.
    

BizTalk Application Configuration

In this step we will configure a WCF-Custom receive port to expose our newly created orchestration to the cloud.

1. In BizTalk Server Administration Console, navigate to the BizTalk Application you just deployed to (mine was called BizTalk Services).
2. Create a new Request-Response receive port.
3. Add a new receive location and set the Transport type to WCF-Custom.
   
   
   
4. Configure the WCF-Custom adapter.
5. Set the EndPoint Address to:
   
           sb://servicebus.windows.net/services/[your solution name]/EchoService/
   
6. Set the Binding Type to NetTcpRelayBinding
   Note: This is one of the new bindings added when you installed the Microsoft .NET Services SDK
   
   
   
7. On the Behaviors tab, add a new behavior extension called transportClientEndpointBehavior to the EndPointBehavior node.
8. Set the credentialType to UserNamePassword and enter your solution credentials on the UserNamePassword element of the ClientCredentials node.
   Note: If you are using Windows CardSpace instead, set the transportClientEndpointBehavior to use it here instead.
   
   
   
9. Click Apply and verify no errors occurred with your WCF-Custom adapter configuration.
10. Click OK to close the Adapter configuration dialog.
11. Set the Receive Handler to your BizTalk Server Application host.
12. Leave the Receive and Send piplines as PassThru (as we are not requiring xml parsing of the messages we are sending and receiving).
13. Click OK to save the new receive location.
14. Do likewise for the receive port.
15. Now, configure your orchestration bindings and start the BizTalk application.

Verify the Service is Exposed to the Cloud

In this step we will browse to your Microsoft .NET Services service registry feed and verify your service is exposed to the cloud.

1. Launch Internet Explorer and browse to the following URL:
   
        http://servicebus.windows.net/services/[your solution name]/
   
2. You should now see your service endpoint listed in the Atom feed.

Test Your Solution

1. In Windows Explorer, navigate to the samples folder under the install folder for Microsoft .NET Services SDK
   Note: If you installed to the default folder it should be C:\Program Files\Microsoft .NET Services (Nov 2008 CTP) SDK\Samples
2. Locate the ServiceBus\GettingStarted\Echo sample and open your flavour of choice (C#/VB)
3. Build the Solution using VS 2008
4. Run the Client.exe
5. Enter your Solution name and password.
6. Enter some text to send to your service.
7. Verify the service response includes BizTalk: <your echo text>
   
   

What did we just do?

Using only the new WCF features that were installed in the Microsoft .NET Services SDK we were able to configure a request-response receive port in BizTalk that exposed our orchestration to the cloud. This is very cool .

At the very least, we could do away with the orchestration binding and just configure the receive port to drop messages into the BizTalk MsgBox. We then use content based routing to route the messages off to our existing orchestrations.

Think of the times you wanted to expose your BizTalk services to customers and clients outside your organisation, but had to jump all those hurdles the IT infrastructure team seams to magically come up with.

This is just the beginning...

Having just travelled down this unpaved and, at times, rocky path I thought I might share my experience to those with similar travel plans.

1. Sign up to Windows Azure to get access to the Azure Services Developer Portal

—http://www.microsoft.com/azure/register.mspx

2. Setting up the dev environment

—Vista 32 bit or Windows Server 2008

—Visual Studio 2008 SP 1

Time saver tips:

- I tried both installing to Win XP and Win Server 2003 but, no dice.

- I tried installing Windows Azure Tools on VS 2010. No good.

- Actually read the Help Documentation

3. Download the SDK bits

—http://www.microsoft.com/azure/sdk.mspx

—Windows Azure SDK

—.NET Services SDK

—SQL Data Services SDK

—Windows Azure Tools for Visual Studio

For those wanting stop-overs in more exotic locations like Microsoft .NET Services or SQL Data Services, you will need to register for these services separately and obtain an invitation code (took almost 2 weeks for mine to hit the inbox). This will give you access to those service portals and allow you to setup your Solution. One Solution per invitation is allowed.

For those less adventuress, you can just setup your dev environment and play with Windows Azure locally using the new Development Fabric simulated cloud environment.

Happy Travels

Putting together BizTalk integration solutions can be complex and tricky at times. Debugging them is an art in itself. While onsite recently, I found myself (on more than one occasion) having *words* with BizTalk.

One example that tested our relationship (BizTalk and I) was an orchestration decision shape that appeared to be misbehaving. I had three branches in the decision shape, each branch testing the existence of a node in the message being processed using the xpath() function. For Example:

xpath(msgRequest, "string(count(/*[local-name()='root']/*[local-name()='parent']/*[local-name()='child' and code='some value']))") == "0"

Tip: use Dan Sharp's Xml Viewer to retrieve the correct xpath to use in these statements. BizTalk schemas will give you them to, but Dan's tool has some nice features thrown into the bargain

One branch rule tested for a zero node count, another for exactly one, and the Else rule branch to handle multiple occurrences of the node. During testing and debugging we found the else branch was always being used despite the messages satisfying one of the other rule conditions (over different tests). Repeated checks, breakpoints, and logging soaked up 20 minutes or more and had me demanding satisfaction by challenging BizTalk to a duel with pistols at dawn.

It was then, a bright beam of light breached the false ceiling above me and shone down in all is splendour. No, this was not a helping hand from god, but rather from a colleague working with me. Picking up on my frustrations, he calmly stood, moved over to me, and placing a soothing hand on my shoulder, utters two words that have changed my life...Kane Theory. I eagerly implemented a quick change (as guided by Kane Theory teachings) and my problem was solved! More cases arose during the project and each of them resolved with ease using this mystic and elegant theory.

Ok. That's a bit dramatic, but I am considering a professional self-help book exploring the practical uses of Kane Theory and wanted to get some practice in.

So what is Kane Theory?

Although only a novice in its teachings, I am fortunate to receive guidance from the enlighten one himself. Kane Adams (his real name used here to protect reveal his identity)  explains it in terms of Yin & Yang, Karma, and the Force. Reflecting on this I can best describe it as a derivative of keep it simple stupid (KISS).

In the example above, we declared an orchestration variable (System.String) to store the result of the xpath function in an Expression shape before entering the Decision shape. We then used the variable in the rule expression for the comparison. Eg:

strNodeCount == "0"

By powers understood only to the enlighten one, this worked a treat and we could all break for a quick cup of the worst coffee ever brewed. (Sceptics might argue that it has to do with the way the XLANG engine performs explicit type conversions during the comparison operation...but they would say that wouldn't they!)

As for the enlighten one himself:

Some say he is a direct descent of John Adams, author of the mystical theory of political architecture and founding father of the new Empire (there's the link to the Force we needed).
Some say, he meditates to the haunting chants of mid-level public servants.
We know him as The Stig!

Had a strange error appear last week when using the WCF LOB Adapter for Oracle and spent an hour of my life I will never get back. When attempting to connect to an Oracle DB we kept getting the following error:

ORA-12154: TNS:could not resolve the connect identifier specified

This occurred when we:

1. Tried to generate metadata in our BizTalk project using the Add Generated Items wizard.
2. Tried to generate metadata in a Class Library project using the Add Adapter Service Reference wizard.
3. Connect to an Oracle DB using the Oracle Explorer.

We had all the latest versions/patches of the Oracle client and WCF LOB Adapter (Oh, yeah. Thanks Oracle for packaging patches in easy to consume 1GB downloads...love your work!!)

We could however, connect to Oracle using the Oracle SQL Developer Tool. So we knew something was happening (or not happening inside of VS).

It turns out the issue relates to the install directory of VS2005. In our case it was

C:\Program Files (x86)\...

This triggers an *undocumented feature* in the Oracle Data Provider for .Net (ODP.NET) so that applications with a parenthesis in their (exe) path fail to connect to the server.

The solution was to uninstall VS2005 and reinstall using a different install directory *one that did not have (x86) in it*.

... I know, I did not want to believe it either, but if you want to save yourself time and hair try this solution first.

When developing applications, at some point in the dev cycle we want to know how the system will perform under load. In BizTalk RFID land it is no different. In fact, in BizTalk RFID implementations we often deal with devices capable of raising hundreds of reads every second. So how do we go about testing these?

I'm a big fan of using physical devices during development rather than device emulation, but when it comes to load testing we need to present hundreds of tags to the reader and no matter what I try I just can't get the work experience kid to act fast enough! But instead of using a emulated device, what if we could raise tag read events programmatically and have our RFID Process consume them? Surely then we could get enough events to constitute a decent load test.

So how do we go about pushing tag read events through our RFID process in code?

We do this using the BizTalk RFID management API's, namely the ProcessManagerProxy. In just a few lines of code we can connect to the RFID process we want to test and "submit" a tag read event to the event pipeline. To get up and running with this you will need to add the following references to your project: (all can be found in %RFIDINSTALLDIR%\bin)

• Microsoft.Rfid.Design.dll
• Microsoft.Rfid.ManagementWebServiceProxies.dll
• Microsoft.Rfid.SpiSdk.dll
• Microsoft.Rfid.Util.dll

Then, in three lines of code you can create your tag read event, connect to your process, and submit your event for processing;

// Create the tag read event to submit
TagReadEvent tag = new TagReadEvent(  HexUtilities.HexDecode(strTagID), 
                                      TagType.EpcClass1Gen2, 
                                      HexUtilities.HexDecode(strTagData), 
                                      strTagSource,
                                      DateTime.Now, null, null );
                                                                     
// Connect to the local RFID server
ProcessManagerProxy proxy = new ProcessManagerProxy("localhost");

// Submit event to the event pipeline
proxy.AddEventToProcessPipeline( strRfidProcessName, tag, strLogicalDeviceName);

And that's it.

For my needs, I created a quick Win forms app that retrieved a list of registered tag id's from a SQL DB and submitted them to my RFID process at configured intervals:

I added a few variables to adjust the interval between tag read events, the number of events to submit each interval, and the number of duplicates to send for each tag id. These variables (used when looping through the set of tag id's) combine to give me a good approximation to a real, high volume environment.

Firing up good old perfmon and adding the RFID:Process counters, I ran through a number of test configurations to make sure my RFID process performs well under high load. (Note: the RFID process you are monitoring must be running before you can add the counters). Of most interest is the Tags In Queue counter. This tells me when my process is not performing well and tags are being queued up waiting to be processed (not good in real-time processing systems). We want this to be flat-lined most of the time.

Another good idea is to use the SQL Sink EH component while testing. After running your tests you can simply and easily calculate event processing latency by executing the following T-SQL query against the tagevents table in the RfidSink DB.

SELECT AVG(DATEDIFF(ms, sinktime, tagtime)) FROM tagevents;

A while back, Mick posted about a great article on MSDN around performance and capacity planning for BizTalk RFID. Some goodness in that article so check it out as well.

Ever seen some of those videos of mobile phones frying popcorn? Mick posted some a few days ago and my wife and I thought we could use a snack while we watched a movie last night.

We tried to "cook" a small number of popcorn kernels using two Sony Eriksson K610i's, a connected Bluetooth headset, and an old Motorola E386 (similar setup to that in the videos from Mick). The K610's have a SAR rating of 1.01 (as reported on the SAR Shield web site)

The result...we went hungry. And we did leave the calls open for a minute or two, stopped and started calls, even sent picture messages from one handset to the next. I don't think they emit nearly enough RF to pop the kernels. It takes the microwave (895W) a few minutes to do the job, we would have to have the phones (~0.7W) in talk/data mode for over a day to get close to that amount.

20 minutes wasted. Luckily we have one of those mobile plans were we get free calls between our phones.

That got me thinking....we need more power.

So I hooked up three UHF long range RFID antennas and placed some rather nervous looking kernels in the middle. At 2W each, it still would of taken around 5 hours to get some popcorn. These puppies can read tags at 10m (even through walls as I discovered) but excite a popcorn kernel, they can not...we need more power.

What I need is one of those "lasers"

Who wants steak!

While working on a BizTalk RFID project we (Mick, Rahul, and I) wanted to explore whether we could use Silverlight (SL) to display tag read events as they are captured. As usual in these scenarios, I started writing wonderfully creative cheque's my graphic design skills could not cash. Eventually I put together an acceptable looking SL page with a couple of animated user controls to represent the received tag read events and counters.

The trick was how do we notify the SL application of the tag read event. At first we went down the client polling route and that worked out fine, but we really wanted something akin to duplex communications in WCF. That is, we want the service to push data out to the client when the service receives the event.

At the time we were working with SL 2 Beta 1 and quickly realised two constraining factors

1. Silverlight only supports http based WCF bindings.
2. Security restrictions prevent the SL application from creating callback listeners.

Luckily for us Tech.Ed 2008 in the US was running and the team at Microsoft announced Beta 2 with support for a polling duplex communications model. After decoding the beta documentation , and some help from learned blogger's, we cracked that puppy and got a Silverlight 2 Beta 2 version working.

Here is a outline of the WCF bits of the Silverlight solution.

• Create a new "Silverlight" flavoured WCF service containing both a service contract and a client callback contract (a duplex service).
  
  
  
• Implement the SubscribeToEvents operation ensuring you set a reference to the client callback channel. This is how we send events back to the SL application.
  

  // Obtain a reference to the client callback channel
  _callback = OperationContext.Current.GetCallbackChannel<IDuplexServiceCallback>();

• Implement the client callback. In our case, when the WCF service receives a tag read event from BizTalk RFID, we create a new message instance containing the event data and invoke the client callback method NotifyEvent()
  

  // Construct NotifyEvent message
  Message message = Message.CreateMessage(MessageVersion.Soap11, "Silverlight/IDuplexService/NotifyEvent", xmlEventData);
  
  // Push event to client
  _callback.NotifyEvent(message);
  
  

• Create your own service host and custom binding that uses the PollingDuplexBindingElement located in the new System.ServiceModel.PollingDuplex assembly in the SL 2 Beta 2 SDK (the one in the ..\Libraries\Server\Evaluation folder).
  
• In the SL application we create a duplex polling receiver class (see the Silverlight documentation for details) and use the PollingDuplexHttpBinding class to create factory and channel objects to send a message to the service. We then start a message receive loop to listen for messages sent by the service.
  
• Received events are then routed to the SL Page class. In our SL Page class we create instances of user controls for each event received and update some running counters.

I did feel some pain around the WCF message formats (see point 3 above). At first I got the message action wrong, but no exceptions were thrown at all warning me of this...the SL application just sat there waiting for the callback. You have to make sure the message action here matches the callback operation exactly. That is, <ServiceContractNamespace>/<ServiceInterface>/<Operation>.

As this is just a POC, I'm sure it will completely change (more than once) as it matures into production ready code, but I thought I might share what we are doing around Silverlight, WCF, and BizTalk.

Also, Dan Wahlin has a great post detailing how to push data to a Silverlight application using WCF duplex services. Much of his work was used to understand how to put all these Silverlight and WCF pieces together. Thanks heaps Dan.

I have been an advocate of VMware Server (v1.0) having used it for the past three or so years now as my virtual development platform. The performance, networking, and user experience have all been good enough. I have accumulated a decent library of platforms, server products, developer tools, and client environments that I can call upon whenever needed. I especially liked the USB support which came in handy when working with RFID devices.

Recently I got around to installing the latest version (v2.0 beta) ...oh dear .

Ok, it was only beta but it lost all the attributes that I mentioned as good points above. Performance was noticeably poorer (perhaps beta related), the revamped networking might be ok after a training course, and most importantly the user experience was totally shite. VMware moved away from the remote console being a Rich UI application (that had its faults but got the job done well enough) to a browser-based console. Why? I thought the industry has have moved on from this already .

So, I have finally conceded to (and coped a few ha-ha's from colleagues) to move my virtualisation platform over to Windows Server 2008 Hyper-V. No small job as I will have to convert (rebuild) all my VM's. In the meantime, I am running Virtual Server 2005 R2 on the laptop to "ease" myself into the new platform.