The Artima Developer Community
Sponsored Link

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.

Advertisement

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:

  1. Avoid changing or extending the interface methods.
  2. Control change by using a dictionary interface.
  3. Calls should return documents not objects.
  4. Avoid binary compatability.
  5. Don't confuse an API with a contract.
  6. Version the contract.
  7. 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.

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.

This weblog entry is Copyright © 2003 Carlos Perez. All rights reserved.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use