This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: ESBs and location transparency
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I wanted to clarify what I meant by location transparency in my comments on Grady's post. Jim made this crytal clear with his comments on the topic:
"location transparency in service-oriented systems is the thin end of the wedge in terms of making the distributed system mistakenly appear as if they are centralised systems"
So, here's my attempt to reconcile location transparency and SOA:
Given that you have designed your solution as a group of autonomous services, and each service can be separately, and remotely deployed, then in the case where one service needs to send a message to another service, we would like the sending service not to require knowledge of the physical location of the receiving service.
Since the term "location transparency" has been done to death, let's call this, maybe "spatial coupling". If the calling service is required to know the location (as in where the service is located in the service "space") of the called service, we can say that it is spatially coupled to it. This complements nicely the term "temporal coupling" that describes the level of coupling that arrises from sychronous/asynchronous communication patterns between those services.
So, the value an ESB gives us is to decrease the spatial coupling between our services.
Previous Topic
