Monday, January 8, 2007

SOA Pros and Cons


  • involve business more closely and directly in defining business process
  • closer allignment of actual business requirements with software specs
  • processes / services more adaptive to changes in business requirements due to extra abstraction of business process composition layer. previously application logic was hardcoded to -business logic/requirements which kept on changing
  • re-use of business logic in the form of services at the macro / enterprise level
  • integration within enterprise, across enterprise is based on standards for service description, service implementation stack, service registration and lookup, service invocation


  • issues with services being stateless (at times business logic mandates service should be stateful)
  • issues with performance due to technology stacks for implementation and due to statelessness as well
  • standards for transactionality, coordination of services within an orchestrated process, are still evolving, currently a service can be assured of transactionality only within itself, there is no standard transactional behaviour support at the level of a process
  • service interaction is still popularly based on RPC-like request-reply paradigm, which is not as conducive to loose coupling as are event based interactions with an intermediary like a queue
  • not enough importance is given to the removal of hidden coupling introduced between services due to sharing of persistent data

No comments: