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

SOA...Where to start ???

We know, SOA is all about services. With lot of hype around SOA, intiatives/projects started by organizations and leading vendors throwing their products as the perfect solution for SOA, the question remains... Where to start ...

Here is my way of looking at it.....................

We all know, SOA is not about projects, not about products and not about creating webservices... it is about having an architecture style in the enterprise that revolves around business services. Implementing business processes that are nothing but a set of business services coupled loosely to realize a business use-case.

And,my first task is to build/implement business services and then the processes....Hold on...How can I identify these business services??First, identify the key business processes and model them.Most steps and activities would be nothing but business services. Now that you have the list of business services with you along their contracts (schemas- business documents that are exchanged by these services).You can then look at the existing implementations (there can be more than one) in the enterprise/applications that can realize these business services. You may have to wrap some existing implentations or create new implementations of these services. Here we can take the advantage of an ESB for all its features like message transformation, routing, messaging,service mapping etc.

Now that the services are ready for consumption, create a repository/registry to store the metadata about these services (ex. Contracts, Policies etc). You can automate the whole service lifecycle management and the policy enforcement. Some vendors in this area can be of help and now a days some of the ESBs come bundled with these features.
Then create loosely coupled business processes by orchestrating these business services. In my view it is essential but not madatory to have a orchestration engine in place to orchestrate these services.You can add additional capabilities like BAM to provide business visibility and associated agility.

Let us not forget that the basic building block of SOA are services and the better we design these services, the more complete/relevant the SOA is and their reusability will give business the desired agility.It requires an enterprise wide effort rather than projects to realize SOA. As organizations work in a set business units that manage their applications/systems and the way IT projects are funded by these business units, it would be a herculian task to start an enterprise wide SOA intiative. It is easy to have all of them buy to these principles, but the real task lies in making them all follow the same path. But with the SOA road-map, governance model in place and projects understanding and following the basic principles of SOA, may be we can climb half the Everest.

ESB (Product Evaluation), What to look for?

Recently, I visited one of the prospects in the retail industry to discuss about an intiative they were taking up to evaluate ESBs. With ample confusion in the industry about ESB, I assumed that they are looking for an off-the-shelf product/platforms claiming to be ESBs(I do not outrightly reject those claims) that can give them the desired benefits.

With an application landscape that consists of number of stand-alone home grown and packaged applications and predominantly point to point batch interfaces(file based) often developed as and when required by business, clearly there was plenty to look forward in terms of creating an Enterprise SOA?(I always restrict myslef from talking about Enterprise SOA with customers as this is not something which is a mere technolgy thing and can be acheived overnight)

But, having ESB in place, ofcourse helps an enterprise to move towards SOA. But, lets not forget that it is only a small part of the whole story. You can easily end up having a non SOA architecture inspite of having the ESB(s) in place that I would discuss in a later post.


So, coming to the point, what one should you look for in these products during evaluation..

- The architectural fit with existing platforms and technology
- Completeness of the stack and ESB features (ex. routing,transformation,service mapping etc)
- Additional features for SOA (ex.Business Process Management, Business Activity Monitoring and Portal etc)

Note: Mere claim by the vendors would not suffice, you have to look for the support details for their completeness..
- Performance (Some kind of benchmarking..)
- Fault tolerance, Management and Monitoring etc