IBM releases OSGi and JPA beta frameworks for WebSphere

Discussions

News: IBM releases OSGi and JPA beta frameworks for WebSphere

  1. IBM announced the open beta of WebSphere Application Server feature packs for OSGi and JPA. The feature packs are product extensions that provide lightweight application frameworks for WebSphere V7. The company said they will allow organizations to realize many of the benefits found in open-source frameworks in a standardized, WebSphere-integrated fashion. Specifically, the feature packs provide standards-based implementations of the OSGi Blueprint service specification and Java EE 6 JPA 2.0, along with the ability to assemble, deploy and manage applications as a collection of versioned OSGi bundles. To learn more or participate in the open beta visit: https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/wasfposgiajp/
  2. I just wanted to give it a try as a developer : Websphere 600MB Fixpack 7 600MB Update Installer 80MB Feature pack 80MB All manual downloads+installation to even be able something to start. Compare to glassfish embedded which is single jar file startable directly from your eclipse without any plugins. Another JPA impl is ok, I did not compare to hibernate/toplink. But I double developers using now hibernate for developing will use openjpa in production. OSGI for enterprise application deployment ? I am more then confused. Which enterprise application really needs osgi ? Which concrete problems will OSGI blue print services solve it to me comparing to standard ear deployment. Please point to real problems I cannot really solve with ear packaging. Webpshere is so huge, I just do not see its advantages that are worth the complexity.
  3. Another JPA impl is ok, I did not compare to hibernate/toplink. But I double developers using now hibernate for developing will use openjpa in production.
    Just to clarify, I believe the comment should read, "But, I doubt developers using Hibernate now for developing will use OpenJPA in production." If developers are currently using Hibernate "classic" (non JPA programming model) to solve a problem, then I tend to agree. Why change just for the sake of change? But, if a developer is looking to utilize a persistence framework standard like JPA, then they can use OpenJPA for their development environment as well as utilize it in production via their WebSphere environment. WebSphere's JPA solution is built upon the proven OpenJPA open-source solution. Any application developed via the OpenJPA project will continue to execute as-is when the application moves to the WebSphere environment.
    OSGI for enterprise application deployment ? I am more then confused. Which enterprise application really needs osgi ? Please point to real problems I cannot really solve with ear packaging.
    A common problem solved in different ways by different servers is over the use of common libraries - often from 3rd parties - by multiple applications. A portable solution is to include the libraries as utility jars in each EAR that needs it. That works but it becomes complex to administer in large-scale deployments. There are server-specific mechanisms for deploying and associating libraries outside an EAR with enterprise applications but these aren't portable and can't easily be validated at deployment time. Then what do you do when a library you use has dependencies that conflict with some other module in your application? Deploying your applications as a set of OSGi bundles and involving a repository for versioned bundles in the deployment process greatly simplifies things. AppServers like WAS and GlassFish use OSGi internally; now WAS is offering OSGi modularity as an option for deploying and managing application modules too. You can stop there or go further and exploit capabilities of the OSGi platform in your applications. For example the OSGi services model is an excellent way to provide application extensibility and the Blueprint model offers a simple declarative way to use it.
    Webpshere is so huge, I just do not see its advantages that are worth the complexity.
    Both of these Feature Pack technologies are built upon Apache open-source projects. If you want to experiment with these features outside of the full-blown WebSphere environment, please visit the corresponding Apache projects: http://incubator.apache.org/aries/ http://openjpa.apache.org/
  4. JPA : What I wanted to say is that developers now using JPA with Hibernate or Toplink as providers will need really good reason why to switch to openJPA. Their applications are well tuned and tested for one provider , having openJPA as default provider on WAS now is not enough to switch. But it is really great now we are having 3 very good implementations. OSGI : First, yes I understand the 'benefits' OSGI has comparing to single classloader hierarchy in ear. But such a flexibility is needed in a really huge application with many modules from different vendors. Yes, osgi provides a platform for such many modules, many vendors deployment possible. But now market does not work like that. Vendors are producing the applications , not the modules. It is too complicated to assemble the applications from many modules and vendors. The dependencies conflict is only one of many other issues. Btw : One concrete question : I remember on was 6.1 , it was a problem to 'override' JSF implementation for our application. Will OSGI deployment model in WAS solve this problem easy ? Which other application server will provide similar feature to WAS regarding the osgi ? I appreciate that this features packs are build upon apache open source projects and one can try it even in j2se.
  5. But it is really great now we are having 3 very good implementations.
    Well, at least 4, you miss http://www.datanucleus.org/ Guido P.S. If you run a query for a base class with DN, you can safely do instanceof on the returned objects to check for a specific subclass