Kerrie Holley has been an integral part of over fifty separate SOA projects in roles ranging from Designer to Chief...
Architect. He holds several SOA patents. In his current role as an IBM fellow, Holley oversees the technical direction of hundreds of SOA projects. His current focus is increasing business flexibility through the use of business rules, BPM, analytics, and of course SOA. Toward that end Holley and his compatriot, Dr. Ali Arsanjani, have written a book called "100 SOA Questions Asked and Answered."
SearchSOA.com got the chance to talk with Holley about the book and ask him some questions of our own. This is the third part of that interview. In Part One, we talked about SOA methods and identifying services. In Part Two, we discussed how agile methods and object-oriented programming fit in with SOA. In Part Three, we're looking at SOA infrastructure, best practices, and the difference between a regular old Web service and a real-deal SOA service.
What are the basic building blocks of SOA infrastructure?
We can look at the infrastructure for SOA in the context of logical or physical. I tend to look at the common building blocks that we all know about.
So we can start with the enterprise service bus. The ESB is a huge building block for SOA because the ESB can become the basis of integration and drive a lot of value. There are some different perspectives on what an ESB is, but those perspectives are important because if we get it wrong, it becomes the same old same old and we stop getting the incremental improvement [that SOA is known for]. But the ESB is just one component. A registry is also important. It's what affords you the ability to find the different aspects of your services.
In the book I organized the infrastructure into types of building blocks. I called one a consumer access layer, I called one a functional layer, and one an operational aspect and when we talk about the operational aspect, I talk about the ESB, but also firewalls and appliances, management to track services as a lifecycle or as a transaction. On the functional side, we have the registry, the services, and middleware. Then we have those aspects that support the various consumer layers.
That's at a very high level, but basically, these are the aspects of the infrastructure that we need to take into consideration. It has to support events, monitoring, and management. It has to support different transports, like REST or SOAP. It has to support different implementation models as well.
What are the aspects of SOA infrastructure that organizations tend to struggle with?
The infrastructure stuff most people understand because it's physical and they can touch it, hold it, and see what it does. So I think most people know very well what those are. But what they don't always get are [the more abstract aspects].
The ESB is a classic example of this. One of the points I make in the book is that you can look at the ESB as an architectural pattern, or you can look at the ESB as a product that you buy, and the difference between the two points is that if you look at it as a pattern, you ask yourself questions about how the pattern is instantiated, fulfilled and realized by products. If you think of it as a product, you may just think "If I buy this product then I will get all these features and functions." This, of course, is not the case. And that's the part that many people don't get.
Another part that people sometimes don't get is that viewing the ESB as a pattern allows a federated implementation where I can have multiple vendor products and a heterogeneous environment … but it's federated in such a way that the consumer only sees one ESB. Even though behind the scenes, it's operationalized through a heterogeneous environment. That's where pattern thinking comes into play, and that's the part that some organizations are just beginning to understand.
So what are some best practices for creating the SOA infrastructure?
One of the biggest challenges is that organizations build out their infrastructure so it's working but it may not be able to handle the demand that they have. So for example, let's say I'm a consumer who wants to use this infrastructure, but then finds out it doesn't include security. So yeah, it's working. But it doesn't work for me because I need a security feature it doesn't have.
Or, I don't actually know how to get on board. How do I get my stuff on this infrastructure. Or, does this infrastructure support my availability requirements. What if I need 99.99% availability, does it have the redundancy to support that, or does it only provide 99.9%? Providing for these customers is one best practice.
One of the biggest things that we've uncovered with SOA adoption is that where organizations are weak in existing IT processes – availability management, capability management, performance management – the adoption of SOA shines a light on that. It brings to light the fact that "Hey, you don't do capacity management particularly well in your organization," so suddenly you've got a SOA infrastructure deployed, but it can't handle the capacity that's running on it. I've got 5 consuming applications and unfortunately it broke when the third one came on board. So that's a best practice: understand how to do capacity management, performance and availability.
Centers of Excellence are a best practice because they can fulfill the short fall an organization might have with skills or operationalizing new technology. Of course, having an implementation checklist that helps the consumer understand what do first and how to get on board, these are important practices for making the infrastructure usable and consumable.