There are a plethora of great technologists in the “connected systems” space, and I thought it would be fun to interview a different one each month. These are short, four question interviews where I ask about experiences with technology. The last question will always be a fairly stupid, silly question that might only amuse me. So be it. I used to do these sorts of interviews when I wrote newsletters for Avanade and Microsoft, so if I happen to reuse a previously asked stupid question, it’s because I liked it, and assume that most of my current readers never saw those old newsletters. I’m a cheater like that.
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).
Hope you all find these interviews a bit interesting or at least mildly amusing.
Richard Seroter's Architecture Musings 
