| QUESTION & ANSWER |
Annrai O'Toole on the challenges SOA faces in 2007 |
 |
By Rich Seeley, News Writer
05 Jan 2007 | SearchWebServices.com |
|
|
Annrai O'Toole, CEO of Cape Clear Software Inc., talks about the challenges SOA architects and developers will face in the coming year and how they might overcome them.
With SOA implementation going full-tilt in 2007, developers and architects will face questions that were not even issues last year when they were doing pilot projects. Will performance meet enterprise requirements? How reliable will it be? How is this going to scale up to handle thousands of services? Is it going to be worth the money? Annrai O'Toole, CEO of Cape Clear Software Inc., offers his take on these questions and offers some answers in this interview. Read part two.
How have you seen SOA evolve in the past year?
Annrai O'Toole: What we've seen in '06 and what we think we'll see in '07 is a lot of mainstream enterprise SOA development. There has been lots written about it. We're seeing a huge amount of adoption among our customers this year. They are saying: "This SOA stuff looks pretty good. We've played around with it. Now, we're using it in anger." So the questions we're being asked are things like how scalable can you make it? How reliable can you make it? How big a system can we actually build using SOA and an ESB? There are a whole new set of next generation problems. We've bought the religion now we want to see how far we can push it in terms of enterprise class scalability.
What are the challenges in moving to the next step?
O'Toole: There's quite a few of them. I'd put them into three major buckets. One is performance. SOA is a great idea. But now we're trying to pump millions of messages and build thousands of services. Can they actually deliver the performance we're looking for? So performance is one bucket. Making that happen is going to require a lot of pretty sophisticated clustering for SOA. That's non-trivial.
After performance, what's the next challenge?
O'Toole: The second bucket is reliability and availability. We've heard people say: "What happens when sets of services disappear because the machine crashes or there's a network outage? Does the system keep on running or does it fall over in a mess?" That's a particularly hard challenge.
And what's the third challenge?
O'Toole: The third bucket I see is related to the first two but on a slightly different level, which is explaining the business benefits of all this SOA stuff for end users. Because as you start to build very large scale projects with SOA, there are bigger investments, and people really want to understand what the business payoff is.
So how do you see these three challenges being addressed?
O'Toole: I think you're going to see an increased emphasis on good design. I researched performance recently, so I did a Google search to see what's best in class. How do people describe performance? Relational databases have been around for 30 years now. The type of thing you need to do to optimize database performance begins with normalizing your data. It's all basic stuff. So I think you're going to see lots of focus on building really good SOA architectures that really are capable of scaling. Secondly, there's going to be clustering. What we're seeing is people building their SOA on multiple servers. That's a real maturity. I remember in the app server days when clustering became the big thing. So good design and clustering are going to be two of the solutions for performance.
Are there key elements that are needed to produce good architecture for performance and the second challenge, scalability?
O'Toole: The broad principles of that are well understood. It must be coarse-grained services. They must be loosely coupled and asynchronous. Those three basic principles are still the keystone of what SOA is all about. People still manage to make mistakes. But if you start off with those three architectural principles, you can't go far wrong.
So is it really a matter of just sticking to the basics?
O'Toole: In all technologies, there are never any magic bullets. What people have gone through here are the initial stages of understanding what SOA is all about, how to apply it and how to make it work. As they've gone through that they found it's a very useful thing and they are trying to take it to the next level. And, they've found that if you stick to the basic principles of SOA, you'll get a system that will scale.
You mentioned clustering, where does that fit in to meeting these challenges?
O'Toole: There's a particular new challenge in clustering that we have to deal with in SOA. In the Web tier when we scale up app servers, we basically did stateless clustering with occasionally state involved. There were a couple of techniques we had to learn, but we figured that out. We needed to use load balancers and we got that to work pretty well. The challenge with SOA is the type of applications that people are building are stateful. Because what people are using SOA to do is model business processes, which by definition are stateful things. So this is a much more complicated level of clustering than simple IP load balancing that we did with app servers. So getting that right and getting that to scale is very difficult. At Cape Clear we've been focused on a technique called "server affinity," which is a way to get very high levels of stateful clustering that will scale up to potentially millions of services.
Along those lines, what needs to be done to ensure reliability?
O'Toole: They are related because what you get with clustering is the ability to have multiple copies of a service running in parallel so that if one fails, you can rollover to another one. But there's a lot more complexity here because you're handling application state. So if one element of a cluster fails, you've got to be able to re-hydrate that application state on a new server somewhere in the cluster. That's non-trivial. You've got to be able to provide continuous availability in SOA.
What about the third major challenge, making sure there's a payoff for the business?
O'Toole: Before you start getting to these issues where people are looking at the scale of the systems they're going to build, they've got to justify the investment. The line between the SOA-ESB stuff and the applications people are building is getting blurred. Applications are generally easy to build investment models on because it's pretty easy to see what the payback is in terms of how it generates new revenue or how it improves existing revenue streams. I think what you're going to see in 2007 is continuing blurring between the application layer and the SOA layer. And I think that's good because applications are more meaningful to customers, while the low-level infrastructure is less meaningful. People tend to think the low-level infrastructure should somehow be free or pretty cheap. So we think that how SOA will address the business return issue is that it will become indistinguishable from the application layer.
So will developers and architects need to talk about the application and its business value rather than getting down into the bits and bytes?
O'Toole: Exactly. Furthermore, the other theme that is bolted into this is that SOA is becoming much more linked to application business processes and less about the low level Web services stack. The whole debate about SOA in 2007 is going to move to talking about the business process layer and the applications it can enable. That's good because it's SOA moving up to talking about what it's doing for the business and the type of applications you can use it for, rather than focusing on the standards involved or the low level plumbing.
|
|
|
|
