Vendor library

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
The simplest kind of [[library]] with a non-trivial [[proximity]] between the author of the [[API]] specification and author of the implementation is so-called [[vendor library]]. This kind of [[library]] is based on standardized specification. Usually multiple vendors with similar functionality sit down and agree on a specification. Each of them then provides their own different implementation. This was the case for [[EJB]], [[JAX-RS]], [[OSGi]] and possibly many others. On the other hand, it is almost always the case that there is only a single implementation of such specification in a running system.
The simplest kind of [[library]] with a non-trivial [[proximity]] between the author of the [[API]] specification and author of the implementation is so-called [[vendor library]]. This kind of [[library]] is based on standardized specification. Usually multiple vendors with similar functionality sit down and agree on a specification. Each of them then provides their own different implementation. This was the case for [[EJB]], [[JAX-RS]], [[OSGi]] and possibly many others. On the other hand, it is almost always the case that there is only a single implementation of such specification in a running system.
-
{{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|SAXParserFactory}} are one of the most well-known examples of a [[vendor library]]. Especially in beginning of 21st century, people were trying to provide many different implementation of ''SAX'' and [[DOM]] parsers hidden beneath the common [[API]]. All such parsers however also packaged their own copy of the [[API]] (including the ones provided by the [[JDK]] itself) which worked, while one had just one such combo on in own application, but caused linkage problems when [[JDK]] continued to distribute [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).
+
The [[API]] for [[XML]] processing in [[Java]] (with entry points in {{JDK|javax/xml/parsers|DocumentBuilderFactory}} and {{JDK|javax/xml/parsers|SAXParserFactory}}) is one of the most well-known examples of a [[vendor library]]. Especially in the beginning of 21st century it was a common hobby among many programmers to write own implementation of an [[XML]] usually hidden beneath SAX of [[DOM]] [[API]]s.
 +
 
 +
All such parsers however also packaged their own copy of the [[API]] (including the ones provided by the [[JDK]] itself) which worked, while one had just one such combo on in own application, but caused linkage problems when [[JDK]] continued to distribute [[DOM]]2 and there were modern parser and applications trying to use [[DOM]]3 (which contains incompatible interfaces from [[ProviderAPI|provider point of view]]).
All of this can be mitigated if one has good runtime support for [[modularity]] and this may be the reason why the [[vendor library]] seems to be very popular in [[OSGi]] world. The [[API]] part can request proper implementation and the [[OSGi]] container will select the right one. Especially with [[OSGi]]4.3 capabilities this seems very easy to specify and achieve.
All of this can be mitigated if one has good runtime support for [[modularity]] and this may be the reason why the [[vendor library]] seems to be very popular in [[OSGi]] world. The [[API]] part can request proper implementation and the [[OSGi]] container will select the right one. Especially with [[OSGi]]4.3 capabilities this seems very easy to specify and achieve.

Revision as of 19:41, 8 May 2012

The simplest kind of library with a non-trivial proximity between the author of the API specification and author of the implementation is so-called vendor library. This kind of library is based on standardized specification. Usually multiple vendors with similar functionality sit down and agree on a specification. Each of them then provides their own different implementation. This was the case for EJB, JAX-RS, OSGi and possibly many others. On the other hand, it is almost always the case that there is only a single implementation of such specification in a running system.

The API for XML processing in Java (with entry points in DocumentBuilderFactory and SAXParserFactory) is one of the most well-known examples of a vendor library. Especially in the beginning of 21st century it was a common hobby among many programmers to write own implementation of an XML usually hidden beneath SAX of DOM APIs.

All such parsers however also packaged their own copy of the API (including the ones provided by the JDK itself) which worked, while one had just one such combo on in own application, but caused linkage problems when JDK continued to distribute DOM2 and there were modern parser and applications trying to use DOM3 (which contains incompatible interfaces from provider point of view).

All of this can be mitigated if one has good runtime support for modularity and this may be the reason why the vendor library seems to be very popular in OSGi world. The API part can request proper implementation and the OSGi container will select the right one. Especially with OSGi4.3 capabilities this seems very easy to specify and achieve.

The close proximity of the vendor of the implementation with the API (as they are packaged together) leads to so called Final interface design: TBD

After visiting OSGiCon I can see the value of this category, but yes, I have to admit I feel uneasy. But that is OK, people are supposed to feel uneasy when they have to accept new ideas.

Talk about: ModularLibrary with 1-N and N-M proximities.

Retrieved from "http://wiki.apidesign.org/wiki/Vendor_library"
Personal tools
buy