From Code to SOA

Writing code that works in all possible states is difficult. Writing code that not only functionally works in all possible conditions, but can also be easily understood by others and then changed relatively easier, is far more difficult. In the words of martin Flower – “Anybody can write the code that works but only a seasoned professional can write a code that can be easily understood by other human beings”. Far codes to be easily understood by others, it should not have two characteristics – Code scattering and code dangling. Code scattering results when same concern can be is implemented in the code in multiple places. This results when we apply copy paste operation while righting code. Code dangling results when we try to implement multiple concerns (Process logic, Business logic, Glue code for API calls, Data access logic etc...) in the same place . Both code dangling and scattering result in a code which is difficult to understand and hence change. In traditional API and SPI (service provide i/f) based application model, writing code without code dangling and scattering is extremely challenging task . 

We can easily define enterprise SOA with dangling and scattering concepts. We need to replace code scattering and code dangling with concern scattering and concern dangling.   A   service enable enterprise should have each concern implemented in one place via a specific service (No concern scattering across multiple applications). Further, each service should do only one specific concern (For example process service should be focus on one specific concern - process co-ordination and should delegate other concerns to other services (e.g. getCustomerRating for getting customer rating). In a truly service enabled enterprise, for each functionality, there should be only one service and it should be executed in only one place. In SOA.what has really changed is the perspective or viewpoint through we look to  software development, from the perspective of departments and functions to the perspective of an enterprise.Unit of software development has shifted from department/function specific applications to enterprise services which are centralized.  

Below is the example of centralized and shared service - 

 The  advantages of such services are clear 

 Easier to maintain from a centralized location – No concern scattering 

 Easier to extend – No concern scattering and dangling 

 Easier to scale via load balancing 

 Low cost of ownership due to heavy reuse