There has been much talk concerning frameworks recently. It seems that almost every opensource project that isn’t an application (and lets be honest, there are very few opensource Java applications) calls itself a framework. This set me to thinking – what happened to calling something an API? When does an API become a framework?
An API is a set of classes and methods (at least in Java parlance), packaged together. They typically provide features for a well defined scope. The Java Standard Edition includes many API’s such as the Collection API or the NIO API. Both are well defined in scope, packaged together and work consistently within themselves. By those terms, frameworks are also APIs. Something like Struts, which we can all agree on is a framework, certainly meets those criteria. So what extra features make Struts a framework?
Probably the key for me is the fact that a framework provides an extendable structure. With Struts for example you extend from the struts-provided base classes and create your own forms and actions. Of late there has been an increasing trend towards so-called ‘light’ frameworks, whose use is almost invisible from the application code’s point of view. Spring and PicoContainer for example use IoC to integrate your own components together, with themselves acting almost invisibly, but they’re still there.
By this reasoning, “Hibernate”:http://www.hibernate.org/ is not a framework (which I don’t think it is), nor is the recently announced “Morena”:http://www.gnome.sk/Twain/jtp.html product (although it bills itself as an “Image Acquisition Framework”). An implementation of the EJB specification arguably is a framework, as is the Servlet API.
Maybe I’m arguing with myself here, but I’m increasingly getting the impression that people are calling things frameworks as it sounds somehow bigger, more expansive, than just calling it an API. Semantics are important!
magpiebrain 
8 Responses to “When is a framework not a framework? When it’s just an API”
Hmmm. How about this:
If you call its code, it’s an API, if it calls your code, it’s a framework.
Gah! I hate that – you spend ages waffling about something, and some smarty pants commentor comes up with a one line quote that says what you meant in a much smater way 🙂
FYI, Hibernate is extensible. You can provide your own ClassPersisters and TransactionFactories.
You’re completely right Rob, blame the fact that I’ve come to the Hibernate party a little late 🙂
Webster’s II definition of frameworks also referenced in the Avalon project, I think does justice to what frameworks should really be–
> A supporting or enclosing structure.
> A basic system or arrangement as of ideas.
and in practical scenarios we always come across requirements for single focus(vertical market) and multi focus(horizontal market) frameworks, hence a framework for a certain project may or may not be a _framework_ for another project. The definition of frameworks cannot be any less or more generic as defined above, for me if I can make use of a piece of code to wrap any external implementation and yet not break the underlying convention of interacting with the products/services across an application than that piece of code is a framework in my opinion. This goes back to the fact that most good frameworks aren’t just built on interfaces but have certain specific contracts that need to be honored which at times makes it difficult for seamless switching/integration.
How about this distinction: if the library limits how you can code, it is a framework.
There is a decided anti-framework leaning in this interpretation, but it is how I think about.
Ray, I’d agree on your point that due to the nature of a framework being something on which application code can be (at least partly) based that framework switching frameworks can be a big job. However both Spring and PicoContainer are definitely frameworks, and yet the application code is not itself bound to the framework – only the inter-component bindings are and they are independent of application code. Avalon like Pico and Spring is also an IoC framework, but it uses type 1 IoC which enforces the use of specific interfaces etc., whereas both Spring (type 2) and Pico (type 3) use reflection instead. I actually have an article coming soon which details this very point…
Brian, that description does seem overly “anti” framework I think. It is probably more correct to say that to work with the framework you have to code in a certain way – that is the bindings to the framework are constrained to work how the framework wants you to work (which thinking about it is probably exactly the point you were trying to make).
I still think Simon gets the award for most succinct description of a framework:
“If you call its code, it’s an API, if it calls your code, it’s a framework.”
According to your definition Hibernate may also be considered as a framework: the extensions would be the concrete data access objects (DAO-s).