Wednesday, January 18, 2006
SOA: How Granular Would You Like Your Service Today?
I had a very interesting conversation and whiteboard exercise with a collaborator yesterday regarding SOA. While I'm sold on the overall concept, including web services, I continue to fret about how a lot of these architectures are going to be actually built, and its not all the problem or fault of the hype-ridden vendor and consultant community.
It's easy to cut corners in just about anything, and EA is no exception. One of the issues I had was a basic tenet of SOA stating that appropriate interfaces are coarsely-grained and therefore useful in a wide variety of applications and interface scenarios. All well and good so far.
The issue with coarsely-grained interfaces is the temptation lots of folks have to regurgitate the distributed systems/client-server model of fine-grained interfaces, achieving tighter coupling. This is particularly prevalent in RPC/COM-model software with rigid APIs. My fear is that for various reasons, particularly time-pressure, developers will cut corners and code right down into huge complexities that are difficult and expensive to maintain after deployment, not to mention non-reusable elsewhere within the overall architecture.
Architects should pay particular attention to the fact that while building web services and establishing a SOA isn't particularly difficult from technical standponts, proper orchestration will be critical to overall success. While there will always be some needs for fine-grained services within an organization, one of the keys of good architecture is to carefully control when they are built, and how they are to be orchestrated and controlled in the production envronronment.
There are a number of WS-* standards that address policies, context and transaction management, and orchestration. From what I'm seeing in actual practice so far, lots of organizations are promoting and/or developing SOAs as a collection of web services without much work or thought into how these beasts are going to coordinate and function in live production environments. I think that we'll either be in for "SOA 2.0," that is, these architectures (and services, and code) will need to be automatically refactored one or more times to account for major coordination and granularity issues, or some organizations will abandon the concept because "it didn't work the way we expected it to"
Which are very good reasons that architects pay close attention to such matters and resist the temptation to relive their days as developers by writing code for some sundry accounting or inventory application because they need to 'get closer to the development teams."
It's easy to cut corners in just about anything, and EA is no exception. One of the issues I had was a basic tenet of SOA stating that appropriate interfaces are coarsely-grained and therefore useful in a wide variety of applications and interface scenarios. All well and good so far.
The issue with coarsely-grained interfaces is the temptation lots of folks have to regurgitate the distributed systems/client-server model of fine-grained interfaces, achieving tighter coupling. This is particularly prevalent in RPC/COM-model software with rigid APIs. My fear is that for various reasons, particularly time-pressure, developers will cut corners and code right down into huge complexities that are difficult and expensive to maintain after deployment, not to mention non-reusable elsewhere within the overall architecture.
Architects should pay particular attention to the fact that while building web services and establishing a SOA isn't particularly difficult from technical standponts, proper orchestration will be critical to overall success. While there will always be some needs for fine-grained services within an organization, one of the keys of good architecture is to carefully control when they are built, and how they are to be orchestrated and controlled in the production envronronment.
There are a number of WS-* standards that address policies, context and transaction management, and orchestration. From what I'm seeing in actual practice so far, lots of organizations are promoting and/or developing SOAs as a collection of web services without much work or thought into how these beasts are going to coordinate and function in live production environments. I think that we'll either be in for "SOA 2.0," that is, these architectures (and services, and code) will need to be automatically refactored one or more times to account for major coordination and granularity issues, or some organizations will abandon the concept because "it didn't work the way we expected it to"
Which are very good reasons that architects pay close attention to such matters and resist the temptation to relive their days as developers by writing code for some sundry accounting or inventory application because they need to 'get closer to the development teams."
