| | h1. Portable Runtimes |
| | |
| | IBM's Billy Newport has posted a couple of interesting blog entries: |
| | * [Portable runtimes with defacto standards or standard APIs?|http://www.devwebsphere.com/devwebsphere/2006/06/portable_runtim.html] |
| | * [Redhat should have bought interface21 instead of JBoss|http://www.devwebsphere.com/devwebsphere/2006/06/redhat_should_h.html] |
| | |
| | | One of his main points is that features should be implemented as portable runtimes. The point is to package features as a component that can be added to a variety of runtimes. For example, he has worked extensively on [ObjectGrid] and the [On Demand Router], both features of [WebSphere XD|WebSphere Extended Deployment] but which can also run separately. They can run in any J2SE 1.4 or JavaSE 5 environment, including J2EE 1.4, including not only [WebSphere Application Server] but also non-IBM J2EE servers. |
| | | One of his main points is that features should be implemented as portable runtimes. The point is to package features as a component that can be added to a variety of runtimes. For example, he has worked extensively on [ObjectGrid] and the [OnDemand Router], both features of [WebSphere XD|WebSphere Extended Deployment] but which can also run separately. They can run in any J2SE 1.4 or JavaSE 5 environment, including J2EE 1.4, including not only [WebSphere Application Server] but also non-IBM J2EE servers. |
| | |
| | Thus you can add these features to whatever server or container your application is already running in; you don't need to upgrade to a new version of JavaEE or a new release of [WAS|WebSphere Application Server]. This makes adding the feature much easier and disruptive to the overall development process. |
| | |
| | h2. The Costs of Standardized APIs |
| | |
| | Billy goes on to say criticize the costs of developing standardized APIs (aka [Technology Standards]): a significant time commitment by a committee of API developers, the need to develop a reference implementation (RI) and compatibility test kit (TCK). Then vendors duplicate effort independently creating duplicate implementations which are often so similar that they don't produce unique value. He sees this as often being a significant waste of time and effort. |
| | |
| | He points to Spring as an example of a portable runtime that hasn't been bogged down by the needs of developing a standardized API. Its injection capability doesn't implement a standardized API, but is simple and works well, so why would one need any other implementations? Why spend the time and effort to develop a standardized API and redundant implementations when one implementation is sufficient for everyone? |
| | |
| | h2. Standardized API and Implementation |
| | |
| | Billy makes a lot of good points. |
| | |
| | It seems to me a good precedence for how to handle this situation are the Apache Xerces and Xalan projects for parsing XML and executing XSL. They implement the Java API for XML Processing (JAXP) API. (See the [JAXP FAQ|http://java.sun.com/webservices/jaxp/reference/faqs/index.html].) JAXP includes hooks to specify the implementation classes; J2SE 1.4 includes the Apache classes to implement the API. So you have a standard API available, but if you don't like it, you can easily replace it with any other implementation of JAXP. |
| | |
| | Similarly, Apache Tomcat implements the JavaServer Pages (JSP) spec. As explained in [JavaServer Pages - Apache Tomcat|http://java.sun.com/products/jsp/tomcat/], Tomcat is part of the J2EE SDK as well as many vendors' J2EE app servers. Again, the JSP engine is often Tomcat but can be any JSP implementation. |
| | |
| | So I think standardized APIs are still important, but like Billy says, it's also helpful to have a standard implementation of the API. The standard implementation can usually be a portable runtime that can be added to any server and enables vendors to avoid duplicate implementations. Yet when a vendor sees an advantage in a better implementation, they can implement the API and replace the standard one. I think that's the best of both worlds. |
