| QUESTION & ANSWER |
Paul Fremantle on coding SOA and data integration |
 |
By Rich Seeley, News Writer
18 Dec 2007 | SearchSOA.com |
|
|
How many standards does service-oriented architecture (SOA) need? Are there standards SOA could live without? What's working in SOA development and what's not? In the second part of this interview with Paul Fremantle, co-founder and vice president of WSO2 Inc., takes a coder's eye view of SOA. While he's led Web services standards development, he muses that some specifications, most notably service component architecture (SCA), may be getting off track because they reflect the views of vendors and architects who have gotten too far removed from the practical problems of coding. But he also praises work being done by W3C to deal with the problem of XML mismatch by fostering better coding practices.
Read Part 1
What's your take on the pending standards for SOA such as Service Component Architecture?
Paul Fremantle: I'm very doubtful about SCA to be honest. We had discussions about adding SCA support to [Apache] Synapse as a way of configuring Synapse. I'm very happy to do that. I think it's a good idea in the sense of offering choice to customers, but I haven't really had any users bugging me to add SCA support to Synapse, saying: "I really need this." I'm wary that SCA is something that's being driven by vendors and not by customers.
Some analysts have said SCA doesn't have anything to do with SOA, or at least isn't critical to SOA. How do you see it?
Fremantle: The problem I have with SCA is that of the architect that doesn't do any coding. That happens at large companies. The architect becomes removed from the code base. Working in open source, you don't get to do that. You have to write the code. You don't have people reporting to you, so you can say "Write code," and they have to go write the code. You either have to persuade people to write code or you have to do it yourself. Thing about SCA is it's targeted at the architects and not the coders.
Is it a case that things like REST are trying to make things simpler while other things like SCA are making things more complex?
Fremantle: That's true. I hate to say it, having worked on a lot of the Web services standards, that's true as well with Web services standards. They end up making things too complex. I think that fundamentally that happens when people get away from writing code. They lose that direct connection with what's pragmatic and what's useful. I'm a little concerned that SCA has moved away from that. SCA has a lot in common with Spring. But Spring is very much driven by users and customers and developers writing code. And I'm not convinced that SCA is.
In terms of standards for SOA would you say there is a basic core you need or is that making it too simplistic?
Fremantle: I think that's very hard to say from a standards perspective. The fact is that different people have different requirements. For a lot of the world, XML over HTTP is it. That's what they need. But in some cases you need XML Schema and WSDL. There are cases where people say SSL isn't good enough. And I think WS-Security is a good answer if you're one of those people. If you need digital signatures then WS-Security is the right concept. It just depends who you are. If you are Boeing then obviously you have a completely different set of requirements than if you're Yahoo. So it's a hard question to answer in the abstract.
A small proportion of people do need WS-Security, WS-Secure Conversation, WS-Reliable Messaging and WS-Policy to do SOA. And then there is a larger group of people who would be happy with just SOAP and WSDL. Then there are people who are happy with just REST.
So is it a case-by-case basis?
Fremantle: Yes. Or maybe it's a spectrum. There's a core that's applicable to a very large number of people. Then as you add extra stuff you need certain additional standards.
Are there roadblocks you are seeing impacting SOA implementations?
Fremantle: I would say the biggest challenge still continues to be the mapping between XML and existing code, the data binding problem. It's not really insurmountable. It's not a major roadblock, but on every project we do that's the one thing that will cause a hiccup.
Is that mostly in terms of bringing legacy applications into an SOA?
Fremantle: It happens with Java code, which I don't count as legacy yet. Fundamentally there's a mismatch between an XML document and a programmatic way of thinking. It's the problem of how do I get this Java Bean to map into this XML. It's a problem that people put on the Web services space and especially the SOAP space, but it actually applies just as much to the REST space. Because, fundamentally, even in REST you have to take your XML and use it somehow.
Is there any help for that?
Fremantle: There is a W3C data binding working group led by Paul Downey [chief Web services architect at British Telecommunications plc] dealing with this issue. It's a great project and it's very undervalued.
So you have some optimism that this W3C working group will come up with something that will help?
Fremantle: There's a test suite. They collected hundreds of examples of schema. They test against those schemas. That's helped a lot because it's encouraged people to improve their compliance. It's collected useful patterns. They've noted which patterns are basic and which patterns are advanced. So I think as people come to know about this work it will encourage people to improve the code. It also gives them something where they can go look at their schemas and their data definitions and say am I sticking with the basic patterns or am I straying into the advanced group. And if I'm straying into the advanced group, I'd better have a good reason because it's likely to mess me around in the future.
|
|
|
|
