Saturday, May 15, 2010

My SOA Mindset

Intention of this article is to demonstrate that unknowingly we replicate a lot of code in enterprise which can actually carefully can be isolated as independent services to form a integral part of SOA Enterprise architecture.

By reading this, may be next time you will have a different outlook on day-to-day code that we write.

Recently I was developing a ASP.Net site that would allow searching of users from Active Directory and adding them to the application after assigning a Role.

This application is for a enterprise that has around 20-30 existing applications in use.

With SOA buzz around, here are few thoughts I have put in..

Why not create a Web service which returns users from Active Directory based on some filter. This web service can then be used across applications and so several applications using such a search would not have individual code to test/maintain. Someday if enterprise wants to move away from Active Directory then all they have to do is change this one web service (instead of applications using them). Also, if there is a new version of AD api with some optimizations then its only one place where we need to change. Clearly creating components as services has benefits.

While assigning roles to the users, again the SOA buzz'd me. I think almost all applications would have users and would have roles, in the enterprise. If we have a common component that assigns roles to a user, and going further does user role management then this common service can be used across enterprise. One big advantage I see is a centralized user repository and single user management module. One can also cache (with dependency) roles and user/roles association (as I guess Role assignment is not a matter of frequent change activity). This provides optimized, enterprise-wide access to User / Role functionality.

2 comments:

  1. To the first point, it's not SOA to be precise. It's termed as loose coupling between disparate components. High cohesion within a component, AD in this case, can be kept off by using such loose coupling. Point two is more of an extended analogy of the former one with a basic tenet of programming, 'avoidance of repetition' at play. A full fledged comprehensive module, that's reusable across the enterprise applications or even, beyond applications of a single enterprise. That's ERP! Not SOA. SOA is a technology. A way to achieve it. :)

    ReplyDelete
  2. >> To the first point, it's not SOA to be precise. It's termed as loose coupling between disparate components. High cohesion within a component, AD in this case, can be kept off by using such loose coupling.

    High Cohesion and Loose coupling are Design principles applicable to Object Oriented Programming. SOA is highly influenced by OOPS.

    >> Point two is more of an extended analogy of the former one with a basic tenet of programming, 'avoidance of repetition' at play. A full fledged comprehensive module, that's reusable across the enterprise applications or even, beyond applications of a single enterprise. That's ERP! Not SOA.

    ERP can use Enterprise SOA to achieve ‘avoidance of repetition’. ERP can use a Service for these purposes.

    >> SOA is a technology. A way to achieve it.
    SOA is a technology which encompasses several basic tenets like Defined Boundary, Policy support, Canonical Protocol, Messaging, etc.. As the title suggests ‘SOA mindset’, you can develop your components as Services and with a service orientation mindset so as to use it across enterprise. It’s not ERP, its not reusability. It’s about thinking in service oriented way.

    ReplyDelete