I listened to a podcast this week by Miko Matsumura, Deputy CTO of Software AG. His comments on Governance were interesting especially the concept of hot and cold parts of the architecture. Some things like policies should remain "cool" and not change often. Other parts such as how you combine your services into applications should be relatively "warm" and change more often.
The point that jumped out at me was his very concise descript of loose coupling "Loose Coupling has virtualized endpoints". No further definition was given.
This must be a bit of a Software AG thing. John Michelsen, also of Software AG says
…virtual endpoints are a great idea as you think about the scalability and the loose coupling we want in a SOA.
This is better explained in John's posting "An Intro to SOA and Virtualization" but all this virtualisation seems to be is getting rid of hard coded URLs. This does not seem terribly revolutionary and is certainly not synonymous with the concept of loose coupling that is, according to some writers, the whole reason behind the benefits of SOA.
Before I discount this as an overly narrow vendor view I would like to explore the concept a bit more deeply. If I look down my ever-increasing list coupling types I can see a number of properties of service interfaces. I define and endpoint as being a service interface then we can see an endpoint has having the following properties and we can see some corresponding coupling types:
|Endpoint Property||Coupling Type (From previous posting)|
|Interface Time||Queue Coupling|
|Processor Location||Distributed Coupling|
|Data Field Order & Presence||XML Message Payload Coupling|
The only property that may need some explanation is "Interface Time". This is the time that a message leaves from or arrives at a service interface. If no queuing is involved then the only delay between the message leaving from a sending service and arriving at the receiving service is some network latency. If a queue is involved then the delay uncouples the sending time from the receiving time.
The concept of an endpoint does not have much meaning except where messaging is involved. There are some types of coupling in the messaging world that are not covered by the concept of virtualised endpoints. Coupling based on process state (including synchronous coupling) and coupling introduced to manage process control, such as transaction control is not easily expressed in terms of endpoint properties. Logical coupling where service behaviour changes significantly based Boolean or enumerated field values passed in the message also is not covered as an endpoint property.
The "Virtual Endpoint" concept turns out to be a fairly useful. We have some types of coupling that are only dependant on endpoints (or service interfaces) and others that depend more deeply on the implementation of the services or the interpretation of the messages being passed. Virtual endpoints are not the whole story when it comes to loose coupling but are part of it.