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.