The Artima Developer Community
Sponsored Link

Weblogs Forum
Principles of Loosely Coupled APIs

3 replies on 1 page. Most recent reply: Jul 3, 2003 6:55 AM by Carlos Perez

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 3 replies on 1 page
Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

Principles of Loosely Coupled APIs (View in Weblogs)
Posted: Jul 3, 2003 6:55 AM
Reply to this message Reply
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


Channing Walton

Posts: 32
Nickname: channing
Registered: May, 2003

Re: Principles of Loosely Coupled APIs Posted: Jul 4, 2003 4:00 AM
Reply to this message Reply
Everything you describe is a Good Thing.

However, I have seen several examples of systems whose internals attempt to remain as loosely coupled as the interfaces they present externally. They fail to separate the internal private core from public API/services.

For example, the internal (private) system working directly on the XML documents instead of working with objects models (assuming OO) - very, very slow, difficult to work with and a nightmare to maintain.

I believe that the idioms of your chosen language are good for the internal private system components but the external interfaces should be as you have described.

Channing

Chris Dailey

Posts: 56
Nickname: mouse
Registered: Dec, 2002

Re: Principles of Loosely Coupled APIs Posted: Jul 5, 2003 9:36 AM
Reply to this message Reply
I notice you call the table the "Loose Coupling table", but then describe the aspects of loose and tight coupling. I might conclude that you are implying that loose coupling is better than tight coupling.

Loose coupling tends to work by adding a layer of indirection or abstraction. It seems that few people think about the disadvantages of loose coupling and only focus on its advantages. When loose coupling is abused or misapplied, you have unneeded indirection and abstractions, requiring extra setup, inefficiency, extra complexity, and translations between concepts.

Don't get me wrong, as a designer and developer I'm focusing most on internalizing the concepts of coupling and ramifications from it. I feel it's the most important structural aspect of design, and despite the relative simplicity of its basic concepts one of the least well understood.

I do not think loose coupling is the universal truth, however. I think that coupling should be managed, and smart decisions made about it. I do think your table goes a long way to stating the tradeoffs.

Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

Re: Principles of Loosely Coupled APIs Posted: Jul 7, 2003 7:10 AM
Reply to this message Reply
Chris, Channing,

Good points, I've covered that in my arguments in the "Static typing vs Dynamic typing" debate. For reference see: http://www.freeroller.net/page/ceperez/20030426#does_static_typing_destroy_encapsulation

My argument is that for "programming in the small" choose a system like Java, however when you start scaling up to much coarser components, begin to employ a dynamic approach.

Yes, the move to more indirection is just in line with the history of computer science, where almost every language innovation has meant more indirection. However, everything requires balance, knowing when and where to apply indirection is a skill one needs to master.

Flat View: This topic has 3 replies on 1 page
Topic: Learning By Breaking Previous Topic   Next Topic Topic: Wow, XML standards really are simple after all

Sponsored Links



Google
  Web Artima.com   

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