Und überall sitzt die OSGi Service Platform drunter...
2 Comments Published by Christian Ullenboom on Montag, September 29, 2008 at Montag, September 29, 2008.
Unter http://www.earthtimes.org/articles/show/world-leading-enterprise-application-server-providers,541827.shtml und http://www.osgi.org/blog/2008/09/impressive-press-release.html führen die Autoren auf, wie beliebt mittlerweile OSGi als Basis für Java EE Container ist. Peter Kriens führt folgende Container auf:
- IBM Websphere. They started in 2006 and aggresively moved their code on OSGi. Obviously it helped that IBM has committed itself to OSGi since day -1.
- Oracle WebLogic. Formerly known as BEA weblogic. BEA was one of the first companies public touting the advantages of OSGi, clearing the road for others.
- Paremus Infiniflow. Paremus has pioneered the use of OSGi in highly distributed application servers allowing the system to scale to unprecendented heights.
- ProSyst ModuleFusion. ProSyst is the key provider of OSGi technology in the embedded worlds but originated from the development of a J2EE server. They are now back in this market with an offering based completely on OSGi.
- Redhat JBoss. JBoss already worked with a microkernel approach but recognized the advantages of a standard two years ago.
- SAP Netweaver. Well, they are not yet based on OSGi, but they clearly see their future based on the OSGi specifications and are becoming more and more active in the OSGi Alliance.
- SpringSource Application Platform. The company that simplified Enterprise development with their Spring Framework decided to create their own offering in the application server market completely based on the OSGi specifications.
- Sun Glassfish. And last, but definitely not least, Sun decided to use OSGi in the JEE reference implementation Glassfish. They clearly take OSGi extremely serious nowadays since they also hired Richard S. Hall. It is so good to see Sun back at the OSGi Alliance.
Interessant sind zwei Feststellungen:
- In der Regel geben die Container die OSGi-Implementierung nicht nach oben weiter, abstrahieren also von den Internas. Nur einige Produkte erlauben, auch selbst OSGi-Bundles anzumelden.
- Java EE und das SpringFramework sind beides Nutznießer der OSGi-Plattform. Man kann nun fragen, ob man sich überhaupt noch mit OSGi selbst beschäftigen muss, wenn etwa GlassFish oder http://www.springsource.com/products/suite/applicationplatform gute Abstraktionen bieten.
Labels: Java EE, Open Source, Spring
Fuer mich ist in der Tat die Fragestellung interessant, wann die grossen Anbieter von OSGi basierten Application Servern die OSGi Schnittstelle fuer ihre Partner und Kunden oeffnen.
Spring hat dies bereits getan mit ihrer Spring Dynamic Modules Loesung und von OSGi Seite aus, scheint es nur noch eine Frage der Zeit zu sein.
Eines der groessten Probleme im Enterprise Bereich ist die Trennung oder Abschottung von Anbieter und Kunden Bundles. Es muss dabei verhindert oder minimiert werden, dass Bundles von Kunden oder Partnern die Verfuegbarkeit und Zuverlaessigkeit von den Application Server Bundles gefaehrden.
Die Enterprise Expert Group in der OSGi Alliance befasst sich mit genau diesen Themen und arbeitet an Loesungen.
Stay tuned, interesting things are coming soon.
Tim Diekmann
co-chair Enterprise Expert Group, OSGi Alliance
Ich merke vielfach letzter Zeit. Das man immer mehr weg von Container- zu Komponenentenparadigmas übergeht.
Ich persönlich denke auch, dass Container wie JBoss oder Glassfish aber auch Tomcat. Garnicht mehr notwendig sind.
Die Querschnittsfunktionen kann man einfach per AOP lösen. Mit Hilfe von IOC und DI erhält man die Möglichkeit saubere und Komponentenorientierte Architekturen auf innerhalb einer Schicht zu entwickeln. Zusätzlich mit OSGI werden sie dann auch tatsächlich "physisch" zu unabhängigen Services.
So erhält der Entwickler tatsächlich die Möglichkeit seine Architektur nach seinen Anforderungen zu bauen, anstatt nach der Infrastruktur eines Containers.
Viele Grüße
Rafael Sobek