Service Oriented Architecture - what ?

Well, if you are in IT industry, you go anywhere - meeting, conference, online - all you find is talks about Service Oriented Architecture (SOA). While this term is old more than couple of years now, and IT Architects are still planning to design the systems based on services, a lot needs to be done to get to a real services based architecture which is also scalable and managable.

Basically, we know about Components Based Architecture. Every component provides some or other service, and if we take that idea little further, we will be living in a jungle of services and it will be hard to manage these services and any change in one service may need to modify other services, defeating one of the purposes of SOA.

So, we have to think and think hard before getting deep into these services. Creating a service, like a Web Service is no big deal, but getting that service into SOA model is more important.

Normally, what we do to get to SOA -

1. Create services, typically Web Services
2. Integrate services
3. Implement enterprise wide business functions using these integrated services
4. Deploy any new business processes/models using such services

And what are our main concerns, things come into our way:

1. Security
2. Access protocols & interoperability
3. Process flow
4. Workflow
5. Service availability
6. Contract (interface) change between service provider and consumer
7. Service implementation change
8. Service relocation
9. Service access through firewalls
10. Repeated Client side coding related to service access
11. Scalability
12. Performance

Those aware of Enterprise Service Bus (ESB) would think I am going to discuss that, and you are right. Well, ESB promise does fulfil many of these concerns, but ESB itself is quite open, and that is something we can start implementing and add things to it as we forsee issues.

Rest later......