'. '

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.
-
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.
+
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]] parser. Often the implementation was hidden behind the facade of SAX or [[DOM]] [[API]]. Such parsers also package their copy of the [[API]] (as providers of [[vendor library]] are supposed to do).
-
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 close [[proximity]] of the vendor of the implementation and the [[API]] (as they are packaged together) leads to so called [[Final interface]] design: [[TBD]]
-
 
+
-
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.
+
-
 
+
-
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.
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.
Talk about: [[ModularLibrary]] with 1-N and N-M proximities.

Revision as of 19:56, 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 parser. Often the implementation was hidden behind the facade of SAX or DOM API. Such parsers also package their copy of the API (as providers of vendor library are supposed to do).

The close proximity of the vendor of the implementation and 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