Stefan can you tell us a little bit about yourself and what you're working on?

I'm founder and principal consultant at a company called innoQ, which is a consulting company based in Switzerland and Germany and I basically try to help our customers in achieving their goals in regards to SOA , MDA and other technology topics. We're a technology consultant company and that's where my main interest lies in.

You write a lot about SOA on your blog and you write from a developer's perspective. What does SOA mean to developers?

I think to developers it means that they should not forget a lot of the things they have learned but that they should use them from a different perspective. I think a lot of the knowledge that you acquire when you do distributed programming or component based programming is still applicable when you do SOA, but you have to make sure that you accept there are some differences and that you have to acknowledge that these different view points and you need to incorporate and distil the best of them into how you approach the subject.

You talk about different styles for SOA. What are these styles?

In my view they are rooted in the background that you have when you approach the SOA problem. First one is when you come from a CORBA background or from a distributed objects background you're very much used to specifying interfaces in some sort of IDL and you generate stubs and skeletons, proxies from that. And then you have a lot of convenience because you have simple Java, C++ or C Sharp interface, whatever your language of choice is, and you can use those proxies to interact with the services, you can have half of the implementation generated for you. The problem that I have with that style is that it creates a very tight coupling between one specific version of the interface, one snapshot at a particular point in time, and an actual implementation in your programming language. Any change you make to that interface is going to break those proxies at least in any implementation that I know. Once you make any change, even changes that you expect to be non-breaking - like adding an attribute to some XML where you don't expect anybody to care about - will actually break down everywhere; and you have all the problems that people are used to having from technology such as CORBA and DCOM and RMI, which is that you have to roll out, to update all your consumers together with the provider. I think there's something to be said for this style which I call RPC style, which is that it is very convenient, but it has got its problems. The next one, which comes from the people who have been doing MOM or from those who have been exchanging documents in B2B scenarios, is more document or message oriented. Here the emphasis is not so much on the interface, but more on the message. It's also on the type of the message, the message schema; it's not a problem but it is treated as a message. You do not generate stubs and skeletons, you don't tie your implementation to a particular message version, but you handle the message as something different than a local method call, it's a different thing. It's obvious that I like this style better than the first one. The third one which I think it's underestimated is the REST style, the resource oriented style, which is the architecture of the Web which proves that it's working pretty well. You care about the message but actually what you care about more is the resource. You identify things that you interact with and you do have an interface but it's a uniform interface so that each of the resource is interacted with in the same way. Those are the three styles: RPC, message oriented and REST/resource oriented style.

Isn't REST oriented style still a message oriented style?

This is more a matter of giving the right word to these things. I think it's different. When you take a look at the way people do messages they actually view the message as the important thing transported from one place to the other; the message contains all of the information that you need to process it. If you're doing REST, the resource and the method you use to access the resource plays a significant role. REST is a usually based on HTTP, HTTP is not a transport protocol is a transfer, it's an application protocol. So this is not an implementation detail that you're using HTTP, if you're doing REST. It's very significant and there's a pretty big difference between doing a POST to some resource and putting a message in some queue.

When is it appropriate to use which style?

It depends. There are cases where using the RPC style is a good thing, because if you have a lot of code that already works you can easily generate interface descriptions from existing Java, if they have the right granularity, if they arre the boundaries that you want to expose. That's an easy way to do this. We had a project where the only aim of using web services was to bridge the .NET/Java gap. That's a scenario where it worked pretty well and it basically fulfilled all the requirements. I think if you really want to have really loosely coupled nodes that communicate and survive a minor update in some interface version, then it is much more appropriate to use a message oriented style. If you're going on the Web I think that REST is the way to go because that's what everybody accepts and supports and there's not much value in doing different stuff if you're really doing internet scale services.

The REST versus SOAP debate has been raging off for quite a while. What's your take on that?

First of all I think it's a misnonmer. I don't think it should be a REST versus SOAP debate because those things are not mutually exclusive; you can very well use SOAP in a RESTful way. I think it should really be a debate maybe between REST folks and the WS* folks. There is this huge bunch of standards and competing standards and things that call themselves standards although they are not. All these great mess that the industry has got itself into creates a huge drive to go back to the basics, to the perceived simple stuff that actually works. I think the debate should be between the complexity of doing everything on top and the simplicity of basically using what is proved to be working for quite some time.

In your blog you discuss confusion about what king of infrastructure you need for Service Oriented Architecture. What is your advice there?

I think if you ask a vendor the answer is pretty clear because what you need is their product. For a vendor I think is pretty hard to avoid trying to sell you a product because that's their business and it's totally understandable they will try to sell you some ESB product, some middleware stuff, some magical integration infrastructure that will do anything for you. I think that if you really want to do SOA this is something that you should rather avoid than seek out. What you should do is to make your endpoints aware of the fact that they are being exposed as services. It's not a good idea to try to hide this fact in the infrastructure. Your EJB that has been used in a tightly coupled scenario is not going to magically become a service just because you put some adaptor in front of it that puts angle brackets around the remote method invocations. I think there's a semantic difference between a service and a remote interface used in a tightly coupled scenario. Of course there are products that help you when you do SOA. You can use Web Services stacks like Axis, like commercial products, Systinet, ... .NET I think it's a very good solution, if you're working with that kind of technology. I think accepting the idea that you can actually buy a SOA from somebody is definitely the wrong way to go.

What does a Service Oriented Architecture look like and what is commonly thought of one, but it's not a Service Oriented Architecture, in your opinion?

I'm coming back again to that style thing. I think the important thing is that if you're really talking about SOA, this is something that you do on a company scale; this is not something for one particular application. You can maybe build an application in a service oriented way but I think that's one technology decision that doesn't have that much impact. I think it's far more interesting to talk about how can a company or a division inside a company approach this thing. All these styles that I mentioned are from a 10.000 feet view just details. If you look at a SOA it's more about managing the services that you have, it's about having the descriptions, having the metadata, knowing the policies, knowing where to look for stuff and where to find stuff, knowing when something becomes alive, when something dies again; this is all about management and administration. If you look at an RPC based architecture that is very well managed, it might qualify as a SOA and it's fine with me. I'm not happy with the technical solution, with the technical path being taken but it still qualifies as a SOA for me. Still, if I have a choice, if there's no other pressing factor that forces me to do otherwise, I would base it on SOAP, I would definitely use SOAP, XML, I would make XML messages a first class citizen in that approach and I would very much try to achieve a loosely coupled message oriented scenario, possibly using REST, depending on the other factors involved in such a company.

But people can use Web Services, but that's not necessarily Service Oriented Architecture, that's a point to point integration solution. What actually qualifies as Service Oriented Architecture?

One of the problems in this industry is that there is no clear definition. You cannot look it up. You can go to Wikipedia, you can see what is written there but it's just as ambiguous as everything else, so you're not going to get a really good answer from anybody. You're not going to get one from me either. I can give you my personal opinion and the aspects that I think are important for a SOA. I think a very important thing is that the driving factor has got to be services, as it's the main construction element. If you're talking about applications, about components, about modules and subsystems you're missing something. You should be talking about services and you should structure your whole landscape by using services as the primary abstraction mechanism. That's a difference against lumping functionality together in applications in a different manner. I think services in a SOA need to be accessed in a message oriented way. These are not remote method invocations. That doesn't necessarily mean that you cannot do request/response, that's a fine interaction pattern, but what you send is messages, what you receive is messages, that is, in my opinion, a very important point. The last point is that those messages should be self-descriptive. I'm strongly advocating that XML is an essential part in a SOA. It doesn't matter whether it's REST or RPC or messaging, I think XML is a very important thing. You can be using self-descriptive messages using other technology. But if you want to do it in Java what you have to be sending over the wire is key value maps. If you're doing that it's semantically the same thing, but most people don't do that because there's a perfectly good technology for doing that kind of stuff and that's XML, and you should be using it.

Why SOA? Why now? What's actually new?

From a technological perspective I don't think there's that much new there. You were able to do messaging ages ago; you are able to use XML for quite some time now, that's not the new and exciting stuff. What I think is exciting is the fact that it creates, or at least that it is perceived to create the opportunity to align business and technology. The whole architectural discussion about aligning your businesses along services has reached a management level where technology usually doesn't play any role. When you talk about services at that level, you're not talking about any of those styles, you're not talking about any technological decision, but you're thinking about your business in terms of services; you have to find the right services, you have to find them at the right granularity, you have to think about ways to price them, to create incentives for people to create or consume them. There are lots of business aspects involved here. It's the first time that the management level actually making those decisions, that the people who actually do the business, really believe in this. This is not exactly news either. When there was object oriented computing, people said "we finally have a way of modelling the real world", when there were components, people said "now we have a way to build business components and everybody can participate". I think this SOA thing it is the first time that business people start to see some value and they actually start to believe it. This is creating such an amount of drive behind the whole approach, that this is really different not so much from a technical perspective but more from a business perspective.

What does the future look it? What is a SOA-enabled world going to look like 2 or 3 years from now?

I don't know if it's going to be 2 -3 years, I'm more sceptical, I think it more like 5 or 10 years. In my view, what a company should do today or what they're starting to do today is that they think about themselves as service providers, they think about their business units as service providers and they start to decouple the functionality, the services provided within a company. This is very much in line with the way the business world is moving today, because companies are merging all the time, companies are being acquired and are being sold again and split and merged and combine the new and exciting ways. I think a good prophecy is that we're going to have a world where services are going to be combined to create new value added services regardless of company boundaries; company boundaries are going to become more and more irrelevant. You're not going to be able to distinguish between another division within your company that provides some service for you and an external partner that provides services. And why should you care? You just want to consume that service to provide your service to someone else.

There's a lot of talk about Enterprise Service Buses and how they are an essential part to SOA. Even open source has them now. What is an ESB and do you think it's an essential part of a SOA?

If you want to know what an ESB is I think you'll find different answers there as with many of those acronyms. I think a reasonably well-accepted definition is that an ESB will help you connect systems using different technologies to a central service oriented infrastructure so that a lot of the technical tasks are taken over by the ESB product for you so you can rely on it to provide you transformation, routing, adaption of different protocols and all of this WS- * mess, this is all going to be handled by the ESB. That's an attractive proposition for people who want to introduce SOA and who actually might believe they it's a good idea to buy an ESB product to get rid of all the problems. I don't think that's necessarily the case. I think that relying on a vendor to provide you with a SOA is a sure receipt for getting into the same problem that you ran into with the EAI vendors. I think you should be in control of your SOA and an ESB product should be used with care and you should make very sure that you don't become dependent on the ESB vendor, but only dependent on the standards that this ESB vendor should support. If you do that, fine. What I also see is that ESBs move into the endpoints; it is trend that I see now: people now call an ESB, what was called SOAP-stack or a web service stack. It's just names and if people want to do that it's fine with me; some of these stacks have value and it's reasonable to do them, but I really strongly believe that you should not rely on a single vendor strategy and believe that you can buy your SOA from anyone. I think an interesting trend is JBI, Java Business Integration, which is starting to come up; maybe that will bring some new drive into this.

What is Java Business Integration (JBI)?

I think it's the worst named spec in all of the JSRs. It's not as much of business integration is rather about specifying a standard for ESB vendors to interoperate. As an application programmer, as a business developer, you're not very likely to ever get in touch directly with JBI. JBI essentially standardizes the middle layer in the architecture that pretty much every middleware stack follows. There's a bus in the middle with different transport down below and you have different functionality sitting on top of that. The JBI spec is pretty new, it's at version 1.0 about to be released as we speak and obviously with a spec that is so new there's a lot of open and underspecified stuff, but I think it has value because if it takes off it's going to allow you to combine JBI components that you purchased from different vendors into a solution that matches your needs; you can take your BPEL engine from one vendor and you can take your WS-I compliant binding component from another vendor and you can plug them together and hopefully things should work out. I think the problem that JBI might have is one of acceptance. The biggest vendors, IBM and BEA, did not participate, or did particpate but dropped out, so they do not currently support JBI which is a big barrier towards its acceptance.

Why do you think they didn't want to support it?

I think there are different reasons. For IBM they have a different strategy. From the SOA perspective the problem is the J in its name, so it excludes half of the world, most significantly the .NET world. And IBM has invested a lot of time and effort in cooperating with Microsoft and with BEA in creating interoperability based on the wire standards; introducing a significant standard that has a J in its acronym is probably not in their best interest. I'm not sure about BEA's real motivations, but I can only provide guesswork. I think it's similar to, if I remember correctly, the EJB 2.0 first draft where there was this notion of a persistence manager that you could buy from a different vendor and plug into your application server; that was killed out somehow in the final 2.0 version and there was never a market for creating different persistence engines to plug into your app server. Maybe that's the same reason - why would a vendor want to give a customer the opportunity to combine components from others, what's the business motivation for doing that.

So can you tell us about a recent SOA project that you've worked on and what were your experiences with it?

A thing that kept me busy for a while now is very big SOA project at a very large logistics company, a company operating worldwide which has decided to standardize on SOA as its main enterprise wide integration strategy integration architecture. We're currently building on top of JBI, so we're actually involved with that in a real production scenario, we're trying to finalize stuff so we can actually go into production with that thing. There's a strong architectural vision; we have decided to implement much of the functionality that you want your service oriented infrastructure to provide in the form of services themselves, so we have a registry service, transformation services, we have invested a lot of time and thoughts into management of services. This is going to become one of the largest SOA platforms in Europe and probably even in the world. I hope I will be able to talk more about it next year. Other than that, most of our customers are still in an area where they need to be educated about SOA, where they need to find out whether there's any value. Most of them start small which I think is a very good decision, given the fact that a lot of the projects created with a strategic vision and with lots of money have failed miserably. I think it's a good idea to start from the bottom up and maybe build the first point-to-point scenarios, always keeping in mind that you need to have an architectural vision that exceeds that to arrive at something that you actually want to have in the long run.

What does this company actually use SOA for? How are they realising benefit from it?

They actually used it in the first place to solve simple integration problems and to solve those integration problems which they could have solved using any sort of integration technology, they started their first services in a call center application and within the next integration project they were already able to reuse significant investments they had built in the form of services. This is how you would want it to be, you start building the first stuff, where you actually pay you a lot more than you get in return, but as more and more projects move towards this architecture you benefit from having services already.