Miis for The Sopranos

Are you a fan of the Sopranos and the Nintendo Wii? Well, you can have your very own Soprano Mii!

You'll need to download the Mii Contest channel on your Wii first. Then go to the posting plaza and search for the Mii by its number.

These are the Mii numbers for the Sopranos characters;
Tony Soprano - 9576-3170-7808
Christopher Moltisanti - 9425-9802-3171
Silvio Dante - 7698-5483-7517
Paulie 'Walnuts' - 7857-3261-9685

Enjoy!

New home for the BizTalk Script Adapter

The BizTalk Script Adapter has a new home at www.thinkscape.com, my employer's website.

Download the BizTalk Script Adapter.

The Script Adapter used to be hosted on Got Dot Net. But Microsoft have ceased support for the site.

Thinkscape have been kind enough to host the adapter, and even better, they will be providing support and working on enhancements - and it's still free!

Don't believe the SOA hype, its a sequel

Why I continue to read articles on SOA I don't know, because more often than not the articles bug me. What bugs me? The hype that is whipped up around it.

One common theme around SOA is the benefits from reuse; if you have done something once, why do it again? Sounds logical... at first glance. This is the main driver for the hype; its an easy sell to an executive who doesn't understand technology. Everyone appreciates that doing a job once is cheaper than doing it twice.

However, if only it were that simple. A common mistake is to think that reuse is simple. In fact, with SOA, reuse is doubly hard than something that is commonly reused in IT; the API (application programming interface). How many times has your company produced a common API to be used throughout the organisation only to find barely a handful of projects actually making use of it; most having gone their own way because they found the API difficult to use, or doesn't include a feature they need, or the feature that they do need could be weeks away from being implemented, or that a new version of the API has just been released and they now have to recode their application to be compatible with it, or there are so many versions of the API in use it is difficult to support them all.

SOA is in the same boat as an API and suffers from all the same issues. But, it has an additional complication; whereas each application will have its own copy of an API, there will only be one instance of a SOA service. This causes issues such as competing for the resources of that service instance and that any downtime of the service instance means affecting every dependent application. What if your service is 99% reliable but the application wanting to use it needs 99.99% reliability? What if you need to take the service down for maintenance yet applications dependent upon it don't have the same maintenance window? How are you going to release a new version of the service and migrate existing applications across when the application teams refuse to change because it works perfectly well at the moment?

Well, reuse is certainly possible. We reuse things all the time in our work lives and home lives; but there are a whole bunch of things that we could reuse but we don't because it simply doesn't make sense. The same applies to software, and SOA. Jump in with your eyes wide open!

Browsers Just Another OS

Interesting reading what Mozilla have planned for Firefox version 3.0 and beyond in this article for CIO.com: Firefox 3.0 Opens Door to Web Apps, Mozilla Says

It is becoming apparent that in order for online applications to go to the next level and truly be successful, they will require a much greater level of cooperation from the browsers. Coincidentally, I only just posted a comment on Michael Jung's blog on the problems that online applications must overcome, namely they are Internet connection dependent.

But if browsers are going to become more specialised and offer similar services that an operating system does, then aren't they just another operating system? And with that in mind, what is the point of downloading an operating system (a browser) to run on an operating system (Windows, Linux, Mac etc.)? Will browsers become THE operating system that runs on your computing device whether that be a PDA, smartphone, or PC?

And with that in mind again, and going off at a complete tangent, how exactly would that threaten Microsoft's monopoly Michael? They have beaten off many OS competitors over the years.

Reuse or Misuse?

I am sticking my neck out here for flaming, but here we go - reuse drives me mad! Or more to the point, the complete misuse of reuse.

A case in point is the hype surrounding SOA. Can any two people actually agree on what SOA is? No. But it seems that they can agree that its benefits are from reuse. Oh please!

Reuse is hard. A lot of time reuse doesn't offer any benefits, it doesn't make any business sense. Reuse for the sake of reuse leads to overly interdependent business applications and blurred boundaries of ownership and responsibility.

Seeing as I am a crap writer and don't want to bore you I'll point you to an article that gets across the point far better than I: Is SOA Another Fake Path to IT Agility?

Reuse? Reuse this - Thwack!!

Visual Message Instance Creator - BizTalk Needs One!

Scott Colestock has highlighted an important point that often causes me consternation with BizTalk: creating a new message instance from scratch in an orchestration. I generally hard code the skeleton xml and load it up in to an XML document then assign the attributes using promoted properties or xpath (see Scott's post on how it is done).

What would be really nice however, is to have a visual way to construct message instances. Here we are dropping shapes on to orchestrations in a very visual way only to disrupt this harmony by having to handcraft xml and embed it within an expression shape!

But what I find really frustrating is that BizTalk is so close to having a visual message instance creation tool already available out of the box; its the mapper. If Microsoft could just tweak the mapper, as explained below, it would be so easy and a far more natural way to create message instances.

1. It should be optional as to whether a source schema is required on the left hand side. In many cases when creating a new message you just don't need one
2. There should be a new functoid to access message context properties. Drop one on to the pallete, indicate which context property you want and then link it to an element on the destination schema
3. There should be a new funtoid to access orchestration variables. This would be used in a similar way to the context property functoid above
4. Some other functoids would be useful such as "static value" functoids where a value can be hard coded in to it

This way it will be possible to visually construct a new message instance without the need of having a source message instance to seed it. These message instance definitions should not be stored in a separate xml file, as the maps currently are, but stored within the orchestration xml file instead. This would help to keep them self contained within the orchestration and reduce the number of files created in your project. Even better would be a new orchestration shape to represent them. Simply double click it and your message instance creation definition would open up.

Because BizTalk is managing the definition it can also do error checking on it. So when you change the destination schema BizTalk would know about it and flag it up as an error. This would at a stroke eliminate those awkward hard to find bugs when using handcrafted xml.

BizTalk Script Adapter

After finding myself in several similar situations where I needed to get a job done quickly with BizTalk but it just wasn't playing ball, I decided to do something about it. I developed a send adapter for BizTalk that integrates with Windows scripts.

Because scripting is so easy and fast, I find that for certain tasks, productivity can go through the roof using the Script Adapter. Simply develop a script (say using VBScript) and implement a procedure called OnMessage where all your code goes. Then, when BizTalk receives a message and forwards it on to the Script Adapter it will load your script and call your OnMessage procedure. Simple as that.

For a two way send, just return a string value from the procedure. The Script Adapter converts the string in to a message and returns it BizTalk.

Be warned, this is a first release. Consider it a beta. So I would appreciate feedback on it.

You can get the Script Adapter at my employer's website, Thinkscape: Download the BizTalk Script Adapter.

[Update 2007-07-30 - Note that the Script Adapter was previously hosted at Got Dot Net but Microsoft has closed the site down. Thinkscape have been kind enough to host the adapter, and even better, they will be providing support and working on enhancements - and it's still free!]

Note that on installation of the Script Adapter there is a choice to install it for Everyone or Just Me. Sometimes I have found that selecting Just Me can cause issues when you come to register the adapter with BizTalk (something to do with registry access permissions I think). Therefore to be on the safe side install it for Everyone

There is a guide included with the installation that walks you through setting up the samples. That should hopefully clue you up enough to develop your own scripts for the Script Adapter.