Microsoft RFID Platform in Australia

Over the last 3 months I have been putting the building blocks in place to ready ourselves to take our RFID platform to market here in Aus. It’s been a fascinating experience so far, and will continue to evolve considerably.  The global strategy is being driven by a great colleague of mine in Redmond called Anush – and he’s coming to Australia in August!!

For those that don’t know, we are releasing BizTalk 2006 R2 shortly, and this release has significant new investments around RFID capabilities. We made a public annoncment of this back in June 2006 last year at http://www.microsoft.com/presspass/press/2006/jun06/06-06EtEBusinessProcessPR.mspx Essentially……

 

New BizTalk RFID Functionality Delivers Advanced RFID Device and Data Management Along With Unprecedented Partner Support

The R2 release of BizTalk Server will integrate BizTalk RFID, a new set of technologies that will reduce the complexity associated with the management of intelligent RFID device hardware by connecting real-time RFID events to relevant supply-chain processes and back-end business applications.

“RFID is getting increasing traction as a critical enabling technology for supply-chain visibility and security and asset management. RFID allows companies and government organizations to respond to key business events in real time and transform or optimize their processes based on enhanced visibility to activities in the physical world,” said Peter Regen, vice president of Global Visible Commerce at Unisys. “With BizTalk Server 2006 R2 and Unisys’ Global Visible Commerce solutions, organizations will be able to make better decisions by knowing exactly what goods and assets are where, and do so with a low-cost, scalable solution for managing data, devices and integration.”

BizTalk RFID is a robust set of technologies with open APIs and tools to cost-effectively build vertical solutions and configure intelligent RFID-driven processes. It includes the following:

Device abstraction and management capabilities to help customers manage and monitor devices in a uniform manner. This “plug and play” architecture allows customers to leverage the investments in standard or nonstandard devices by providing a uniform way of managing their device infrastructure.

An event processes engine that enables customers to create business rules and manage the choreography of event pipelines for RFID events

Tight integration with Microsoft Visual Studio%u00ae and open APIs that allows developers to quickly integrate RFID events with existing business applications, or create their own custom solutions

Support for industry standards and an extensible architecture with advanced deployment and monitoring tools that IT professionals can use to meet service-level commitments and reduce long-term costs

Pricing and licensing details for BizTalk Server 2006 R2 have not been announced, as Microsoft is gathering customer and partner feedback before finalizing them.

There is a new Microsoft.com site dedicated to RFID at: http://www.microsoft.com/biztalk/technologies/rfid/default.mspx

Keep ahead of the game……!

Locating Airports – Google or Local Live? Neither.

I was delighted to find out that Local Live is able to search by airport codes. Google Maps also has this feature for some time, I don’t know for how long, as such small updates aren’t usuallyannounced,so it’s not clear who was first and who just caught up. Anyways, it was interesting to see how each maphandles this task. Apparently, both pretty much suck, but each in its own lovely way. Local Live can search by three character FAA airport code, i.e. DFW is the identifier for Dallas-Fort Worth International. Don’t try to search for this airport using four characters ICAO identifier (KDFW)-you will end up inWest AfricaIf you’re heading to Moscow Sheremetyevo (UUEE) it will toss you to another side of African continent (why do they think that all unknown locations must be in Africa?). You will have better luck with IATA identifier for this airport – SVO..

Google Maps, in turn, will reliably point to DFW using either code. But what if you’re looking for something smaller than bunch of 12,000ft runways? Google Maps is pretty comfortable with many smaller airports although you’ll have more chances with four letter identifiers. For example, it won’t find GKY (Arlington Municipal Airport) or GPM (Grand Prairie Municipal) but will locate them using KGKY and KGPM. At the same time, other airports like Addison (ADS) or McKinney (TKI) can be located using three characters FAA identifier. But all fails if one needs to find small airports. Google Maps won’t help finding T31/KT31 (Aero Country) or any other similar down to the earth airport (that’s where, as we all heard, real pilots fly J ). Will Local Live do better? No. KT31isidentified as an airport by Live engineand T31 is foundon the southeast edge of Texas inPort Isabel, TX instead of just north off Dallas! It just shows that Local Live uses basic and an awfully outdated airports database (Port Isabel was reassigned from T31 to PIL in 1998).

Of course, these sources weren’tintended for flight planning, that’s what FAA publications are for. The question is whether adding a feature just for the sake of itself justifies the erroneous and confusing information it serves. Online map providers in the race against each other often forget that main feature of the map must be reliable map and location information. Andby the way, good sites to locate airports: www.airpnav.com, www.skyvector.com.Smooth landings!

Wow… Radio 2.0… This blew my mind!

Check the keynote video below for a demo (about half an hour in)…


A number of sessions are starting to become available for download at http://sessions.visitmix.com… check them out!


Nathan Dunlap’s – “ZAP!, WHAM!, KAPOW!: Windows Presentation Foundation and the Next Generation of Online Comic Book Reading” session is great!


Subscribe to the RSS session feed so you know the instant more sessions become available for download.


Tags: MIX07

BizTalk Performance – Useful technique to baseline your infrastructure

I’ve recently been doing some performance tuning work for a customer.  The customer wanted to achieve a throughput of 100 messages per second on their solution.  The message flow was quite straightforward so it should have been achievable.  Unfortunately when I turned up on site they were getting less than 5 messages per second throughput!


The hardware used for the BizTalk Servers (of which there were 2) was very new (Dual proc, dual core machines with plenty of RAM 🙂 ) but the performance was still not there.  It became clear that we were not going to get the improvement through ‘incremental’ changes.


The difficulty in these scenarios is that there is no standard ‘benchmark’ that you can use to compare your system to. This is because your combination of BizTalk components (Orchestration, Messaging, custom components, etc) and hardware is unlikely to have been tested.  In this case it was not clear whether the problem was been caused by the custom code or the hardware.


Therefore to ‘bench mark’ the system I set up a simple pass thru pipeline receive location and a pass thru pipeline send port (which subscribed to all messages on the inbound receive location).  I then used Loadgen to load the system with 3KB messages at a rate of 500 per second (at this time we had one BizTalk box started, with a separate SQL Server with SAN attached storage). On modern hardware the BizTalk engine should be capable of easily achieving 500 messages per second in this scenario.  When the test was run on the customers environment we were getting less than 50!!


 By this time we had set up a duplicate system using similar hardware in Microsoft’s netlabs (which we use to replicate customers environments for Proof of Concepts and Performance Labs). We were easily getting 500 messages per second in the netlab, therefore the issue had to be with the customers environment.


 In this scenario the SAN should be your first point of investigation, the SQLIO tool can be used to bench mark your disk configuration, this tool is produced and used by MIcrosoft Product Support Services (PSS).  Running this tool indicated that the SAN was not the culprit (the results from SQLIO were broadly the same as the environment we had in the netlabs).  Further investigation eventually indicated that it was the speed of the BizTalk disks that was the culprit for this problem!  The Avg Disk Writes per second physical disk performon counter was the counter ultimately used to determine this.  In the netlabs we were getting approximately 2000 writes per second, the customer was only getting 200!


 Replacing the disks in the BizTalk Server massively improved performance and the customer is now well on their way to achieveing their numbers.


 The ultimate point of this post is that:


a) You should performance test your solution early – many people try for the ‘finger in the air’ approach but this rarely turns out well in my experience


b) You should bench mark your environment using simple BizTalk Content Based Routing and pass thru pipelines, if you are not able to achieve a minimum of 250 messages per second in this scenario, perform further analysis to determine what the hardware bottleneck is.