Manageability Pro
Principles of Loosely Coupled APIs
by Carlos Perez
July 3, 2003

Summary
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
Typing	Static	Dynamic
Synchronization	Synchronous	Asynchronous
References	Named	Queried
Ontology (Interpretation)	By Prior Agreement	Self Describing (On The Fly)
Schema	Grammar Based	Pattern Based
Communication	Point to Point	Multicast
Interaction	Direct	Brokered
Evaluation (Sequencing)	Eager	Lazy
Motivation	Correctness, Efficiency	Adaptability, Interoperability
Behavior	Planned	Reactive
Coordination	Centrally Managed	Distributed
Contracts	By Prior Agreements, Implicit	Self Describing, Explicit

Talk Back!

Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Carlos Perez adds a new entry to his weblog, subscribe to his RSS feed.

Digg |

del.icio.us |

About the Blogger

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.


	Web Artima.com