Is BizTalk Rocky's "Super-Router"?

While I agree that BizTalk would be a good router here, but I reckon versioning is a tougher nut to crack than just at the message level.
http://www.from9till2.com/#a365ef3a7-4456-4b0d-bbba-74fe1fb5c83e

Besides Aaron, aren't you getting a bit obsessed - I mean maybe BizTalk could make a good alternative to Firefox now too (ducks :).

- David

LOL. You'll have to forgive me. I feel like a little kid with a shiny new toy. :-P

I enjoyed your post and agree that in general versioning entails more than just massaging messages. In fact, in my experience, changes deep within a system are what typically bubble up to impace the message formats over time. Hence, the ability to easily deal with variant-but-largely-similar-messages greatly simplifies the overall landscape and your coupling with external consumers.

Interesting stuff. I agree that BizTalk exhibits some of the features Rocky is looking for.

I blogged on something similar a while back about where I differentiated the routing as early or late binding. Late binding being a deferral of what implementation is actually invoked for a given operation based on what is actually received at runtime. Systems such as asmx support early binding through strong typing. However, I think there are a few points worth mentioning:

There is clear separation between processes (orchestrations) and endpoints in BizTalk. But endpoints are a coupling between Uris and ports. For example, for SOAP this means that a particular uri (vDir) is bound to a particular port of a particular type. This affects BizTalk's own routing flexibility. A consequence of this scheme is that you can't have two ports sitting on the same Uri and therefore can't have a truly flexible router with a fixed (or even dynamic) type set in the way Rocky describes (you'd use multiple ports for the SAME orchestration with different Uris). Of course you can go the XmlDocument-type route but then you must handle the routing yourself maybe with a complex routing orchestration/custom code.

To really push things into the implementation the client should be unaware of the binding as the contract (schema) is the only thing they know, together with the endpoint, which for different versions of the same thing should, I'd argue (like Rocky), be the same for all versions, as opposed to IService.DoWork, IServiceEx.DoWork. Otherwise you've got the API/contract pair issue again.

Because of this, I'm not sure it's really IDispatch either because there is no built-in plumbing support to 'get' the services and make the service call. And arguably IDispatch is a client-side routing feature not server-side, putting all the decisions into the client.

Also, it is the subscription mechanism not the implementation that decides whether to 'drop' incompatible messages. Without going loosely-typed you can't get round this.

Another thorny issue that Rocky kind of alludes to in his 'keep things separate' is about reuse. OO encourages reuse but as Rocky says, this by definition, is a change of semantics opportunity. It's unrealistic for implementations not to reuse where appropriate. But reuse through extension (or restriction) is a change of semantics. It seems the only way to guarantee semantics is to leave the v1 code (WSDL, XSD and implementation) alone. This sounds like the implementation is going to get pretty heavy.

Or maybe I'm way off base here..?

It will be interesting to observe how BizTalk and Indigo will coexist in the future as I would expect that as Indigo grows it will encroach more on the feature set of BizTalk (and vice versa). MS have already announced orchestration support in the Longhorn timeframe and provided with the o/s and there's already an Indigo adapter...

BTS is nice in enterprise scale or above (federation). Will Microsoft provide tools or applications similar to Biztalk but for an application scaled down scenario (i.e. working with SO in an appdomain). BTS makes SO interesting, but way to heavy. I want a BPEL4WS orchestration engine as part of the framework (i.e. a light version of bts). Well, I think BTS is too heavy even for enterprise SOA. Too much EAI retro stuff in there.