I’m sure you have all followed Richard Seroters interview series where he chat with different experts in the Connected Systems space and find out their thoughts on technology. The turn has FINALLY come to Richard himself, to reveal his experiences with technology.
To tribute his just-released book SOA Patterns with BizTalk Server 2009 and mark his upcoming sessions at the Swedish BizTalk User Group, I’m honored to be the one to publish the “Four Questions” with its original author.
This is the 13th post in the series:
Interview Series: Four Questions With Kent Weare
Interview Series: Four Questions With Mick Badran
Interview Series: Four Questions With Charles Young
Interview Series: FIVE Questions With Ofer Ashkenazi
Interview Series: Four Questions With Ewan Fairweather
Interview Series: Four Questions With Jesus Rodriguez
Interview Series: Four Questions With Stephen Thomas
Interview Series: Four Questions With Jon Flanders
Interview Series: Four Questions With Yossi Dahan
Interview Series: Four Questions With Matt Milner
Interview Series: Four Questions With Alan Smith
Interview Series: Four Questions With Tomas Restrepo
Q: As you pointed out in your book, Reusability and Discoverability are perhaps the most important principles of SOA. How do you put that in relation to Runtime Governance, an area you didn’t cover too much in your book? Is there a pragmatic approach for organizations getting more and more service orientated, without having to invest in software like SOA Software or AmberPoint?
A: Governance is a critical part of any sustained effort to maintain a service oriented commitment within an organization. The best part is, you don’t need to buy any fancy software to start down this path. Not to say that great software suites can’t help you, but as has been mentioned to death, you don’t “buy” SOA: you do it. All the software in the world can’t help you if you can’t get the organizational shift to happen.
What shift is that? Some examples
%u00b7 It’s getting teams to think outside their project scope when designing services. While you don’t want to get bogged down solving the world’s problems every time you build a service, you CAN make a reasonable effort to look at your existing IT landscape and identify whether you are offering a new capability that others may be interested in. If you are offering something new and useful, then you need to design and decompose the service in such a way that it can stand alone and has no embedded dependencies on a given project.
%u00b7 It’s about looking into existing service registries (UDDI, Excel spreadsheets, whatever) for services already in the company portfolio and seriously considering reuse instead of rebuilding your own redundant capability.
%u00b7 It’s thinking about a service lifecycle and realizing that we’re not done with a service once it moves to production. There need to be processes and proactive behavior around versioning, maintenance, service level agreements and onboarding new users.
So “doing SOA” doesn’t have to be some giant effort to start with. It’s perfectly acceptable for it to be a bottom up approach where a set of projects exhibit service oriented behavior and allow these principles to organically spread across an enterprise. Now, at some point you’ll need enterprise investments in a more formal registry, or to build broad strategic services, but those issues don’t have to be solved by each project team.
Q: You have written several articles about ESB Toolkit (aka ESB Guidance); what is your take on “itinerary processing”? Is it useful, and if so in what scenarios?
A: It’s funny (or maybe sad), but I have yet to fully drink the Itinerary Kool-Aid. I like it, I can see use cases, but I need something else to get over the hump and believe that it’s the right fit for many of my day-to-day scenarios.
What are a few use cases I see as applicable?
%u00b7 Any messaging process that has a dependency on runtime endpoint resolution is a good candidate. The Toolkit does this pretty well. Instead of trying to bake this into a custom orchestration, I can model a flow that relies on a wide range of lookup repositories (UDDI, Xpath, BRE, etc) to discover where to send my message.
%u00b7 Subtle processing differences for each vendor message coming into the same receive port. It’s pretty cool that I can use the BRE to choose an itinerary to attach to an inbound message. This way, I could have the same receive port accept messages from a wide range of publishers, and based on some rule-based criteria (message type, content, context), I can attach, at runtime, a particular set of processing instructions. With the late introduction of the “Broker Service’ capability, you can also now inject a bit of routing logic within an itinerary itself. This way, you can start a given itinerary and allow branching paths based on message content or context.
%u00b7 If you have a wide range of artifacts in the BizTalk environment (send ports, maps, etc) and are at a maturity level where you are capable of composing brand new processing flows from existing resources (e.g. mashups), then the Toolkit’s itinerary processing could be compelling. Need to daisy-chain a call between services where the result of one becomes the input to another? If the necessary maps and send ports already exist, you could build this process in 5 minutes. Want to do a scatter-gather where you call a bunch of endpoints and return a resulting blob of data? You can reuse existing endpoint and mash this together quite quickly. If you have a need for service composition and have lots of existing services to choose from, then modeling message itineraries can be a cool way to quickly leverage those services.
Introducing Itineraries to BizTalk Server is all about seeing BizTalk as a set of services that can be composed independent of the BizTalk tooling itself. It’s a fairly powerful way to build loosely coupled messaging solutions and gives architects a higher perspective on the processing model than is currently available with the standard BizTalk tools. With itineraries, I can model message receipt through a countless series of steps.
I don’t know, maybe I just talked myself into being a bigger fan 😉
Q: Low latency, has for a long time been on top of the wish list for many BizTalk developers. Given that Dublin is on its way, is Low latency still as important for BizTalk?
A: I often think of latency in one of two ways: response latency for synchronous callers, and expectations for how long it takes from asynchronous receipt of a message until insertion in a destination system.
For the former, low latency is related to how long a caller has to wait for a response. Whether we have Dublin available or not, some services will go through the BizTalk bus when there are system integrations that only BizTalk can do, or a set of services (pipeline processing, mapping) that are best fits for a BizTalk service. This type of low latency is still critical to achieve as you have someone (or something) sitting somewhere, probably blocked until a response is received, waiting for you. So, in this situation, I’d definitely like to see more options come out of Redmond for doing low latency in BizTalk Server. For services that can be satisfied with a straight WCF/WF implementation, then Dublin looks to be an excellent choice for synchronous callers.
The other aspect of latency (how much time from A to B), is in my experience, often constrained by the destination system itself. If I can process 1,000 messages per second through BizTalk Server, this still means that my destination system has to keep up. If I have a Line of Business application that chokes on that kind of load, then it really doesn’t matter how fine-tuned BizTalk is. So, this simply means that when you get a requirement for a tiny latency between receipt and distribution of a message, make sure to evaluate the destination system(s) and their ability to take the abuse of a high volume publisher. If we assume that we have a system with no limits as to simultaneous and aggressive load, then a WCF/WF service hosted in Dublin may at times be my most efficient solution. However, if I need to leverage the pub-sub pattern and have a diverse range of subscribers, then BizTalk is the right fit. So once again, for the situation where we need enterprise messaging capabilities and our downstream system can handle has much as we can throw at it, we need BizTalk to be even more capable of low latency delivery.
Q [stupid question]: Being a true Seinfeld fan, name one quality you share with each of the cast members of show (don’t forget Newman).
A: I love the fact that we both share a passion for this show about nothing. I knew you were “good people.” Without a doubt, this show had some of the greatest individual characters in TV history. I’m like these characters in the following ways:
%u00b7 Jerry – I'm fairly obsessive about order and cleanliness and often "break even" where things usually work out for me.
%u00b7 George – I like to pretend that I'm an architect (http://www.youtube.com/watch?v=2ZVs7oAHVjg).
%u00b7 Elaine – I don't like people who sidle up to me, and, am not much of a dancer (http://www.youtube.com/watch?v=5xi4O1yi6b0).
%u00b7 Kramer – Not a big fan of clowns and can enjoy the occasional cigar.
%u00b7 Newman – I have a dark/evil/mischievous side that usually comes out in pranks or sarcasm.
%u00b7 David Puddy – I’m a fanatical sports fan for the teams I follow. My day or week is absolutely ruined when my team disappoints me. I am however, NOT a face painter.
%u00b7 The Soup Nazi – I have limited patience for those who can’t follow instructions. This is why I’d last roughly 17 seconds as a kindergarten teacher.
Thank you Richard, looking forward to see you in Stockholm on the 16th of September.