We all understand that *SOA + Enterprise Services = eSOA* What is so special about the Enterprise services that it propels a SOA based Architecture to eSOA. A superficial look at the Enterprise Services that they are web services – ok – they provide atomic transactions at the correct granular level for us to make it possible to compose any business process. But then if I design my web services at the same level of granularity will that also not be an Enterprise Service? The answer is no (otherwise why write a blog about it!) -- reason for that is Web Services follow Technical Standards while Enterprises Services follow Technical Standards + Business Standards. Coming from a developer mindset, it took me some effort to understand the concept behind the last statement- so I will try to put it in a simpler way (in hope that it will help some!) . Let us talk about 3 friends named - a, b, c (fancy names, yeh!) represented by the three circles below - 
a knows English only b knows German only c knows French only We will compare the situations faced by our three friends – a, b, c with 3 computer applications A, B, C represented by the three circles below 
A is made in Language AX B is made in Language BX C is made in Language CX Now, as a, b, c do not know any common language to talk to each other, how can they communicate with each other? ** They can arrange for interpreters p, q and r. Now, finding friend in this world is as it is difficult, finding them knowing the 2 required languages will be even more difficult. Correspondingly for Applications A, B and C --
a knows English only b knows German only c knows French only We will compare the situations faced by our three friends – a, b, c with 3 computer applications A, B, C represented by the three circles below A is made in Language AX B is made in Language BX C is made in Language CX Now, as a, b, c do not know any common language to talk to each other, how can they communicate with each other? ** They can arrange for interpreters p, q and r. Now, finding friend in this world is as it is difficult, finding them knowing the 2 required languages will be even more difficult. Correspondingly for Applications A, B and C --- We can redesign A and B in language C. That reflects a huge burden on resources , time , money and is no where near any practical approach to make A , B , C talk
- We can make interfaces between the three application, Again, it is difficult as building each interface requires understanding of two systems and two languages but it still seems more feasible than the previous solution and this was the approach that the software industry traditionally followed by making point to point interfaces between softwares..
So finally a, b, c are talking to each other will help of interpreters and the applications are also communicating with each other with help of point to point interfaces
Now imagine that ‘a’ is a studious person and a bit of a showoff! She /He learns a new word and starts using while communicating. Now what? The interpreters ‘p’ and ‘q’ will not only have to learn the new word in English(as ‘a’ speaks English) but also understand what it means in the other language as well.
This was the problem with point to point application interfaces in applications. As software started to improve and change more and more – to support the dynamic business, the point to point interface started becoming a bottleneck.
This need lead to innovation - the evolution of Technical standards and Web Services came into being- which defined a standard way of communicating between applications.
Now data between systems was transferred using XML and hence any application following Web Services Standards was, in more cases than not, able to communicate with other applications. This lead to something like a universal interface among applications.
7 Comments
