Category: Four Questions

Q: At the just-completed Microsoft PDC conference, we saw a wide range of new technologies announced including Azure, Oslo, and Dublin. Given that you have a real job and can’t play with technology all day, which of the just-announced products/frameworks do you expect to spend the most time with, and why?

A:  I will undoubtedly try to spend as much as I can looking at all of the above as I sincerely believe they are all pieces of a big change that is coming to how software is developed and run; of course, you are quite right, and it is rather unlikely that anyone with a day job will be able to spend enough time learning all of these, and so I think I will probably focus initially at the Azure platform and the services built on top of that.

The main reason is that out of the various technologies announced during PDC and the weeks leading to it, I believe that the Azure platform is the one with the highest impact on how software is architected and designed; also, if my understanding is correct (and there are not concrete statements on this one yet) it is the .net services and bit of the Azure platform that will be the first “out of the door” while there is still some time before we could consider using Dublin or Oslo in a production environment.

If I have a little bit more time left (or maybe “offline” time) to spend on anything else Oslo’s “M” would be what I’d spend it on. I find this (defining modeling and textual dsls) a fascinating area and I really want to look deeper into this; it kind of doing my head in at the moment, just trying to grasp the concepts and potential they carry, but I have a feeling that for some of us this can make a big difference in how we work (and help others work).

Last I would add that I’m already looking at some of the Geneva aspects, mostly the Geneva Framework (formerly known as “Zermatt”) and think this will also become a very common component in the enterprise environment.

Q: You and I were recently chatting about a PDC pre-conference session that you attending where Juval Lowy was trying to convince the audience that “everything should be a service.” Explain what he meant by that, and whether or not you agree.

A:  It would be pretentious of me to try to explain Juval’s ideas, so let’s just say I’ll try to convey some of the points I’ve taken from his talk…

Basically Juval argues that WCF is a lot more than just a “framework for developing services” much like .net is more than just a “framework for developing web services” as it was once presented; he argues that WCF services have so much “goodness” that it would be silly not to want to use them for every class developed and he goes on to give quite a few examples, here are a couple of examples (he must have had over half a dozen)– Take the timeout default behavior in WCF for example – with WCF every call to a service operation has built in support for timeout, so if the method’s implementation takes forever (because of a deadlock situation for example, or simply an endless loop) the caller would receive a timeout exception after the configured time; this is a great feature, and to implement it in custom code, while possible, will take some effort (on the client side); to implement it around every method call seems unthinkable, let alone in every client out there.

Another example that Juval goes through is tracing – with WCF you get built in tracking for each method call, including correlation of multiple logs (client and server for example etc) and the trace viewer provided with the framework; how much effort would it take you to build that into your code? with WCF you simply get it for free through configuration; quite neat.

Juval goes on to list many such benefits like Fault tolerance , built-in performance counters, security, reliability, transactions, versioning tolerance etc. I will not repeat all of it here, but I hope you get the point; Juval actually goes as far as suggesting that every class should be a service – including type once known as primitive types such as String and Integer (they are already classes in .net, and now Juval suggests they could benefit from being a service)

That was pretty much Juval’s point of view as I understand it; as for my perspective – do I like his idea? I certainly think it’s a great a food-for-thought exercise; do I agree? Not completely. It is true that WCF incorporates a lot of goodies, and I love it, but – and there’s a big but – it comes with a cost; it comes with a performance cost, which Juval tries to play down, but I think he’s taking a rather convenient stand; it comes with a complexity cost – WCF is not simple, especially when you start to combine things like security, reliability, transactions, instance management; do we want/need all that complexity in every class we write? I doubt it.

Many of the benefits Juval lists really only apply once you’ve decided you want to use services; if I’m not using services – do I need reliable messaging? Do I need security? It’s easy to argue for WCF once you’ve decided that you need to run everything as a service, which I guess is Juval’s starting point, but if you’re not in that thinking mode (yet?), and I am certainly not – then you might think he has gone just a little bit too far 🙂

Now – I was never interested in looking too far into the future, I’m pretty much a now-and-there-and-around-the-corner type of guy who argues that it’s important to know where things are going but in my day to day job I need to give my client’s solid advice on what they can (and should) do now. Looking into the future performance is certainly going to be less of an issue, and I’m sure WCF management will improve significantly (Dublin is already a great step in the right direction) so we might end up very close; but that’s not present tense.

It is worth noting that I do not at all disagree that we will be seeing a lot more services; we’ve already seeing a lot of enterprises and ISV’s adopt SOA architecture of one flavor or another, and the cloud services/platforms will only add more capabilities in that space, so I don’t want to play down the role of services and WCF in enterprise IT, I just think this will still be, for the foreseen future at least, another tool in the toolbox, albeit a major one.

Q: As we now know that BizTalk Server has a new lease on life (i.e. releases planned after 2009), what types of engine-level changes would you like to see? In your opinion, what would make BizTalk messaging even more robust?

A:  I should probably start by saying that I truly believe that BizTalk is, and has been for a while now, a very complete and mature product, and while there are clearly a few quirks and rough edges, the good definitely out-weighs the bad… I suspect it was not by chance that you have asked me to focus on engine-level changes – most of the stuff I have “on my list” is related to user experience – both developer and administrator, there are less things that I believe need changing around the engine, but here are a few examples –

One thing I would have like to see is the management database thinned a little bit – I don’t think, for example, that the entire schema is needed in the database (which makes deployment of updates harder); I would imagine that this could have been reduced in scope to store only xpaths related to promoted/distinguished fields etc.

I also think, as both me and Mike Stephenson talked about in the past, that it would be a good idea to get rid of the compiled-pipeline concept and instead make it a configuration artifact, such as send ports for example; at the end of the day all a pipeline is just a set of components and their properties, represented as xml; sounds familiar? Doesn’t it feel suspiciously like a binding file element?

While I don’t know if you would consider the above as engine-level changes (I think they could be considered as such), the next one certainly is –

Better support for low latency scenario; several people have mentioned this in the past – BizTalk is great (no! really!) but it seems to be positioned a little bit in the middle – it’s not the best tool for large batch files processing (ETL is the technology of choice there), but with the latency introduced by multiple message box hops it is hard to position it in low latency scenarios; I know that Dublin is getting into that space, but I think Microsoft will do well to add in-memory pub-sub support to BizTalk to better support low latency scenarios.

Others on the list – Somebody clever (not mentioning names!) once suggested giving better control over (orchestration) instance throttling, I completely second that. Also nice to have would be the ability to run a map on a typeless message (XmlDocument) – let my xslt figure out which template to run .

Not much to ask, is it!?

Q [stupid question]: If you work in the same office for quite a while, you may tend to let your guard down and ask questions or make comments that you wouldn’t typically say to strangers. Everyone’s had those awkward moments such as congratulating a woman on her pregnancy when no such congratulations were in order. Or, my new personal favorite, someone walking into your office and saying “Last night I had a wildly vivid, erotic dream and you were in it!” What is your example of a terribly awkward “office” conversation?

A:  Unfortunately finding embarrassing moments is not very hard, here’s one from the far history , I just hope I can correctly paint the scene –

Quite a few years ago, let’s just say – before BizTalk was invented – I did a relatively small project in Sydney, Australia. The client was a lingerie company wishing to build a web application to compete with Victoria’s Secret very successful ecommerce web site, and I was called to the flag to build that.

The owners of the company, if my memory serves me right, were a couple of playboy type guys (with most of the staff seem to be either ex-models or models-to-be) and once or twice a week they would come over to our dev shop, accompanied by one or two such assistants, to discuss the current status and any open issues around the development and design.

I can’t remember what it was now, but there was this one thing they kept asking for time after time which made absolutely no sense – not from a visual design or usability perspective, not from an architecture perspective, and, as these things often go, it was also very hard to achieve technically; and so we constantly had debates in those meetings about whether and how we should implement this requirement. In one of those meetings they kept going on and on about this thing, while me and my Australian colleagues (yes – worth stating that was not at all alone in my reluctance to implement this) were trying to explain why it was so difficult to implement, but mostly, why it simply does not make sense as a feature on the web site. Eventually, being quite young and inexperienced (and Israeli, some would say) I got into a slightly too heated debate about it and eventually lost my cool and said, rather loudly, something like – “I only have two words to say– I can’t”.

On its own – it’s not too bad (although now I know that such discussions are often doomed to failure from the beginning, but I had much less experience back then :)), but, and here’s the hard thing to explain perhaps, stupidly, I was trying at the time, with a fair bit of effort, to assume an Australian accent. Being Israeli, brought up on American television and having been in Australia for just about 3 weeks at the time, it did not go too well as you can imagine, and mostly it screwed up any chance I could have to be understandable, and that’s when not in a way-too-heated- debates; and so what I said and what they heard were two completely different things (I’m sure you can guess what they had in mind). Being the playboy types that they were they were certainly not going to let this one slip and so I they were having a laugh at my expense for the rest of that meeting (and the rest of that week in fact); much to my embarrassment.

At least it made me stop trying to assume any accents, and with me working all over Europe, then landing in the north of England and now living just outside London I would say – good thing that I did, it’s all messed up as it is!

Q: Tomas, you’ve consistently been out in front of many Connected Systems technologies such as BizTalk Server and WCF.  What Microsoft technologies are on your “to do” list, why, and how do you plan to learn them?

A:  That’s really a tough question to answer. There’s just so much stuff coming out of Redmond these days, and, to be honest, it’s still to early to tell yet how much of it is going to “stick” and what might be abandoned down the road in favor of something else.

Sometimes learning a new technology in depth can be quite time consuming, so you want to be careful when choosing what to invest your time in. What I’m currently trying to do is follow a few rules:

• Try to be aware of “what’s out there” and at least know what it does and what it is good for.
• Figure out which things are interesting enough (or show enough potential) to dig into a bit deeper. Not enough to master them, but enough to know the big concepts behind them and how to apply them.
  These are stuff you play with a little bit, and would consider good enough to start a POC with them if the need arises and then dig into them big time when you start a project with them.
• Stuff that’s really important that you want to really spend a lot of time tinkering with them and mastering them.

I think there are some interesting things out there worth keeping an eye on. For example, I don’t do much web development these days, but if I had to, I’d immediate dig deeper into the ASP.NET MVC framework. I’m already familiar with Castle’s monorail and somewhat with rails and other similar technologies, so it should be easier to get started.

I’m also definitely looking forward to some of the stuff in Oslo. Obviously the core framework and WCF stuff is going to be pretty interesting there. I’ve been keeping an eye on the cloud services (BizTalk Services) stuff as well, but I’m really waiting there for a project idea that really demands those capabilities before spending more time with them.

Certainly there’s a lot of things that will be coming out in the next one-two years such as the updates to the big products (SQL, Visual Studio and so on), and those will get their fair share of time when the time comes.

Q: In your experience, what is your criteria for deciding between either using (a) a broker such as BizTalk Server between systems or (b) directly consuming interfaces/services between systems?

A:  I think this is one case where there are both technical and non-technical reasons for making this decision.

On the technical side I very much try to start questioning whether any kind of mediation is required/desired and whether BizTalk is the right kind of tool for that job. In particularly, I’d look into the latency and performance requirements, the protocols being used for the services and the amount of data that needs to be transferred between systems.

Part of this is looking to see if, for example, the project is in a low-latency scenario or perhaps if it’s really a set of bulk data processes more suitable to something like SSIS.

Another thing to look for is whether you need the kind of capabilities that BizTalk offers. For example, would the interface be better served with Pub/Sub support? Would the Pub/Sub support in BizTalk be enough, or does it require heavier duty pub/sub with thousands of subscribers and possibly transient (non-persistent) subscriptions?

BizTalk has some great support for some kind of messaging scenarios, but it also has limitations that can constrain your solution heavily. Sometimes you can clobber your project needs into BizTalk by extending the product in different ways (thank goodness for its extensibility!), but it’s not always the best option available.

On the non-technical side, a few aspects that matter are: Does the client already own a BizTalk license they can use? If not, can the project/client budget take assume that cost? Sometimes it can be negotiated, but other times it’s just not an option. Besides the raw cost of licensing, there are of course knowledge aspects, like, does the company have people already familiar with the technology?

In other words, I’ve found that the non-technical aspects of the use/don’t use BizTalk aren’t too different from the kind of aspects you’d consider for acquisition of any new technology. That said, BizTalk does pose it’s own challenges on an organization because of it’s complexity.

That said, I do try to be very careful to avoid looking at the world with technology-tainted glasses. It’s important to approach a new project with an open mind and figure out what the best technology to solve the client needs are, instead of starting with a given technology (BizTalk, in this case) and try to cram the project requirements into it whatever the cost. Sometimes the non-technical aspects of the project might suggest/impose a technology decision on you, but even in that case it’s important to take a step back, breath deeply and make sure it’s the best option available to you.

Q: You’ve been working with a variety of non-Microsoft technologies lately.  What are some of the interoperability considerations you’ve come across recently?  Share any “gotchas” you’ve encountered while getting different platforms to play nicely together.

A:  No matter how you look at it, interoperability isn’t easy, and you can’t take it for granted. It’s something you need to keep very much in check every step of the way and verify it time and time again.

Certainly Web Services (of both the SOAP and REST varieties) have helped here somewhat, but not all interoperability issues come from the lower-level transport protocols; sometimes the application / service interface design can have a bit impact on interoperability.

One rule I try to follow is to design for interoperability. For example, if I’m designing a new service interface, I want to know who my clients are going to be; what technology they are going to be using and what constrains they might have.

Sometimes, the best option you can take is to stick to the basics: simple works. That’s actually one of the beauties of REST architectures. As long as you’ve got an XML parser and an HTTP client, you’re in business, and HTTP is known well enough (and has such a good tooling around it for development and diagnosis) that it really helps a lot.

Basic SOAP is also pretty good nowadays, if used correctly. The WS-* specs, like WS-Security and friends are pretty important in some scenarios. They are published standards, yes, but getting interoperability isn’t as easy as with plain SOAP and rest, because they are very complex specifications.

For example, if you’re using message-level encryption, and you run into trouble, then raw protocol level interception won’t help you at all to diagnose the issue; you really need tooling support on your SOAP stack for this (WCF’s is pretty good).

Once you get into using X.509 certificates for encryption/signing or even just for raw authentication, things can get hairy pretty quickly. Mostly this is because a lot of people don’t quite understand how X.509 certificate validation works, and common problems arise from invalid certificates, certificates installed to the wrong store, or just because someone forgot to deploy the entire certificate trust chain.

By themselves, they are not though problems to solve, but diagnosing them can be very challenging at times because the tooling isn’t always very good at reporting the right reasons for failure. Anyone who has been stuck with a “Error validating server identity” kind of error can attest to that 🙂

WS-Security specs also have the pose another challenge, and it’s that there are multiple versions of those specs out there, and sometimes you find yourself using one version with your partner using another. You have to be very careful in specifying and validating the right protocol version.

Q [stupid question]:  Everyone has that one secret pet peeve that makes them crazy.  I’ll admit that mine is “mysterious stickiness.”  I shudder at the thought of touching a surface and coming away with a unwanted adhesive.  Ugh.  Tell us, what is something that really drives you nuts?

A: Cockroaches. I hate cockroaches. They give me the creeps.

Seriously speaking, though, I think that my main problem is that I can be very impatient about the little things. Stuff like getting short delays from things can drive me crazy (a stuck keyboard or mouse can really go out of this world).