Stefan Tilkov,InfoQ SOA consultant on SOA - Interview excerpts

Stefan Tilkov,InfoQ SOA consultant has a very informative interview on SOA

He defines SOA as....

"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."

And his advice for the organizations looking for SOA....

"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."

Defines ESB as...

"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"

About JBI ....

"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."

He goes on to add his views about the the reasons for wide acceptance of SOA in the industry

"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.

What next for EAI/ESB product vendors???

With JBI being widely aacepted by the industry, there is little these vendors, who had been surviving till date providing proprietary stacks, can do other than jumping onto it.

With the loose-coupling and plugability provided by the JBI framework, there are two areas where the vendors can invest in..

- Building a good JBI Container (Meta Container)
- JBI components (Service Engines, Binding Components)

Think of you buying a JBI container from Company A , buy a set of JBI components(ex. Rule Engine, Orchestration Engine) from Company B and buy some other JBI components (ex. FTP, AS2, JMS connectors, are called binding components.. ) from Company C and create the ESB for yourself and put the stepping stones for an SOA Enterprise.

Also the JBI container would provide with management and monitoring interfaces, and can be monitored by any JMX based Monitoring Tool/Interface. Customer would have the flexibility of having the best of breed JBI components and Containers available.

So, the next question is, if we can choose and plug JBI components, do we then prefer buying them when there are quite a few good ones available in the open source.

With open-source projects like servicemix catching the eye of many organizations, there is an interesting duel between these vendors and the open source community in the offing.

Now that the product vendors have very little role to play, organizations should think of creating their ESBs themselves or involve some system integrators who would create product agnostic solutions. Rather than thinking of how best to use the product architecture and work-arounds for feature defficiencies, there would be more emphasis on the solution architecture.

Ofcourse, there can be arguments that JBI is Java specific and there are many critics of Java, who would go any distance to show how java sucks, but, I feel this is a very good stepping stone in the direction of standardization of integration/SOA space. I can visualize Microsoft with its own set of frameworks and competing specifaications/technolgies playing its own game.

AFAIK microsoft is now obsessed with DSL...........................................................