Sponsored Link •
Idiomatic java isn't a place to get inspiration on how to build loosely coupled architectures. Even though Java idioms are extremely useful, when you get to "programming in the large" it's a whole different ballgame.
Bill de hÓra has a very good blog entry "Foundations for component and service models". Bill points to an extremely instructive article from OTI (i.e. the makers of Eclipse) about Evolving Java-based APIs. Bill is dead on right when he says that idiomatic java isn't a place to get inspiration on how to build loosely coupled architectures. That seems to jive very well with my thoughts on loosely coupled architectures. Java idioms are extremely useful, but when you get to "programming in the large" it becomes a whole different ballgame.
Bill has a couple of very interesting recommendations:
- Avoid changing or extending the interface methods.
- Control change by using a dictionary interface.
- Calls should return documents not objects.
- Avoid binary compatability.
- Don't confuse an API with a contract.
- Version the contract.
- Don't build an API for data transfer.
Again, its instructive to look at my "Loose Coupling" table to make some comparisons with the list above. Bill's first recommendation appeals to a REST style. This recommendation favors the REST style of using a fixed set of verbs (see "Interface" in table). The 2nd recommendation is the use of dynamic typing (see "Typing" in table). The 3rd recommendation is appeals to coarser grained message passing (see "Messaging" in table). The 4th recommendation is the concept of leveraging a lingua franca .
Now, recommendation 5,6 and 7 are all quite unique. The 5th recommendation says that there's more to interaction that just the API's, rather we should all consider contracts. This of course has been hinted on by all those Web Services choreography initiatives. Being able to introspect the definition of how parties interact is something completely absent in conventional programming. The 6th recommendation is extremely interesting and I would like to see how he goes about doing this. Finally, the 7th recommendation is an appeal to be pragmatic.
With these new recommendations, I think its time to update my original "Loose Coupling" table:
|Tight Coupling||Loose Coupling|
|Interface||Class and Methods||REST like (i.e. fixed verbs)|
|Messaging||Procedure Call||Document Passing|
|Ontology (Interpretation)||By Prior Agreement||Self Describing (On The Fly)|
|Schema||Grammar Based||Pattern Based|
|Communication||Point to Point||Multicast|
|Motivation||Correctness, Efficiency||Adaptability, Interoperability|
|Contracts||By Prior Agreements, Implicit||Self Describing, Explicit|
|Carlos E. Perez has been an object-oriented practitioner for over a decade. He holds a Bachelor's Degree in Physics and a Master's Degree in Computer Science from the University of Massachusetts. He has polished his craft while working in IBM's Internet Division and IBM's TJ Watson Research Center in Hawthorne, New York. He now works for a startup 1/100,000th the size of his former employer. He writes about topics covering emerging aspect and object oriented paradigms, loosely coupled architecture, open source projects and Java evangelism.|