vendredi juillet 10, 2009

Top reasons why GlassFish v3 is a lightweight server

I have been involved in helping a couple of consultants put together a presentation on the future of app servers and one thing that struck me was that in the resulting slides, they equated lightweight appserver with the use of the Spring framework. Using Spring in WebSphere doesn't make any lighter. I don't think that deploying an archive with 90% being runtime qualifies as lightweight (hence the SpringSource tc and dm server offerings), but I also think that painting every application server as being monolithic and heavyweight is a gross caricature, so here are my top reasons why GlassFish *is* a lightweight application server.

#1 • Download size
For some people download size matters. For them and for everybody else, GlassFish v3 downloads start at 30MB for the web profile (get it here). The updatetool will then help you scale up or down from there. Of course you can also start with the "a la carte" approach and go even lighter (20MB for a functional RESTful+EJB31 server). Some others are fighting hard to fit on a single DVD or CD.

#2 • Pay for what you use
With the extensible architecture of GlassFish v3, services and containers and brought online only when artifacts using them are deployed to the runtime. Deploy your first WAR and the web container will take a couple of seconds to start. Deploy your second webapp in a fraction of a second. Remove the last webapp and the web container will not be restarted on subsequent server restarts. Some people call that on-demand services.

#3 • Fast (re)deployment
Beyond incremental compilation (which most IDE's offer nowadays) and deploy-on-change (simply save the source and reload the web page), the time to (re)deploy an application is key to a developer's productivity. The GlassFish team has spent time optimizing that process to offer sub-second redeploy time for simple applications. GlassFish v3 also offers the preservation of sessions across redeployments which is a pretty safe operation (new class-loader, new application) and costs less than 5 seconds to recreate a Spring context (for instance with the jpetstore demo on my laptop), and even less on traditional JavaEE webapps. This is all built into the product with no configuration or add-on required. Check out this recent (and short) screencast for an illustration.

#4 • Startup time
Even in the days of (fast) redeploy, startup time still matters to both developers and operations. GlassFish v3 starts in about 3 seconds with a warm felix cache. Starting the web container is about an extra 3 seconds. Deploying individual applications depends largely on their size and complexity but let's say that it starts at around 100ms and should not go beyond 30 seconds. Starting GlassFish v3 with Apache Roller already deployed (not exactly the lightest webapp there is out there) will cost you about 20 seconds.

#5 • Memory consumption
One might think the OSGi nature or the application server introduces an unwelcome memory overhead. For an application servers like GlassFish v3, that certainly isn't a problem as a base GlassFish v3 runtime is using less than 20MB (another "side effect" of the modular & extensible architecture) and a non-trivial application only 50MB of heap (as reported by visualvm). Not quite small enough to run on a feature phone, but that may well happen sooner than we all think, especially when using the Static mode (no OSGi) and the embedded api.

#6 • Spring *and* OSGi
No need to choose between standard JavaEE, Spring, and OSGi. You can have all of the above in a single integrated product. In fact you can even use the unmodified OSGi-fied Spring DM version of the framework, and make it available at the expense of a couple of clicks in the update tool. The HK2 layer in GlassFish v3 is abstracting OSGi away and manages to have GlassFish retain its lightweight feel while allowing for Java EE components to inject any OSGi-based declarative services at the expense of a standard @Resource annotation. I don't know if you think this lightweight but I certainly find this to be an elegant integration.

#7 • Open Source
GlassFish is open source, so you can make it whatever you want, even a heavyweight monster if you so decide! Certainly the barrier to entry for using GlassFish is very lightweight.

But the real question is - is GlassFish v3 lightweight for you(r application)?
Whatever the answer is, I'd love to hear your comments and experience!

vendredi juin 12, 2009

GlassFish v3 a la carte screencast - Part 2

In the first screencast, I installed a minimal GlassFish v3 from a small bootstrap (IPS toolkit), created a domain and started the server. This entry will actually do something useful with GlassFish and two containers: Java Web and Spring.

The Spring DM (OSGi) part of the demo is described in Jerome's GlassFish V3 Extensions, part 3 : Spring, Java EE 6 and OSGi blog entry. In the screencast, the manual install of the Spring bits is replaced by adding a new repository definition (a local one) and installing a single package from there. For the rest, the demo demonstrates how to extend GlassFish without using any GlassFish API and how to invoke an OSGi bundle service without using any OSGi API - the servlet injects the service by name using a standard @Resource annotation. Note that Jerome's most recent blog entry covers OSGi Declarative Services for a somewhat simpler approach.

The screencast was done using the dev/ repository, so your experience may vary as the boundaries of the IPS packages and their dependencies are still being worked. Also, instead of the default Felix console briefly shown, you could use the web console described by Sahoo.

The full-size (and offline) video is available here (15MB, video/x-m4v).
The next screencast will show how one can seamlessly add more GlassFish v3 features to obtain a "full" Java EE application server and still benefit from the modular architecture in terms of pay-as-you-grow (startup time, load-on-demand, memory consumption, ...).

lundi mai 25, 2009

GlassFish @ Java AppServer Day (Genova)

I was lucky to visit Genova last week for the Java AppServer Day organized by the local JUG. I tend to blindly trust the organizers of JUG-initiated events and this event was yet another good reason to keep on doing this.

The event had exactly 100 attendees and the format was 30-minute sessions with a round-table at the end. I went first and focused on GlassFish v3 since this was mostly a developer audience and clearly had no time to also cover the clustering/operations side of GlassFish in half an hour. I did try to do as many demos as possible around startup time, dynamic startup/shutdown of services, Deploy on save in NetBeans, Session preservation across redeploys with a non-trivial application, extending GFv3 with a Spring container (available right from a local update center repository) to demonstrate OSGI-based GlassFish v3 extensibility as detailed in Jerome's latest blog entry.

JBoss' Alessio (Web Services lead) alluded to JBoss 5.1 being very close to being released (and indeed it has been since). Now waiting for the supported version ;) He also mentioned OSGi as being a priority for the next releases. Of course having Oracle in the room made the exercise quite interesting. I met Paolo, an Oracle "veteran" and a likely future colleague :) and got to listen to an Oracle middleware presentation (I hadn't seen one in ages and certainly not since the BEA integration). Paolo focused on the operations side (which arguably WebLogic does fairly well) including Coherence, JRockit and Work Manager. Finally Alef, a SpringSource founder (but no longer an employee) focused on OSGi and dmServer. I think his presentation was more didactic than mine on the OSGi front, but our demos certainly felt very similar.

Thanks to Paolo and the rest of the organizers, this was a great event, I wish I could have stayed a bit longer, the city looks beautiful!

samedi septembre 20, 2008

Modèles open source, Spring, JavaEE, ...

A l'heure ou les changements dans le modèle de support SpringSource créent la polémique, je retombe sur cette présentation mise en ligne par FaberNovel il y a exactement un an sur les modèles économiques des projets du Libre. Avec un an de recul, voici qq réflexions :

• Open Source et profits ne sont pas antinomiques (Libre et Gratuit ne sont pas synonymes).
• Il y a plusieurs moyens de tirer un profit commercial d'un projet open source.
• Celui qui dit avoir trouvé le seul vrai modèle qui peut fonctionner a tord.
• License (OSI bien entendu), copyright et gouvernance sont trois axes différents mais complémentaires..
• N'en déplaise à certains, la méritocratie à la Apache n'est pas le seul moyen de faire du Libre (MySQL, JBoss, etc...).
• Qu'un contrat de service rajoute des fonctionnalités avancées et un accès à des patches ne me parait pas choquant (reste à définir "avancées").
• Que le fix qui a servi à faire le patch ne soit pas immédiatement intégré dans la projet (trunk) est discutable.
• Que l'on rende des fonctionnalités existantes payantes est plus condamnable.

Enfin plus précisément sur la cas Spring, je ne peux que conseiller JavaEE comme alternative, non pas cette fois-ci pour des raisons techniques, mais bien parce que c'est là la seule façon de ne pas être lié à un fournisseur unique. On a tendance à oublier cette propriété fondamentale de tout standard.

jeudi mai 01, 2008

Any announcements left for JavaOne?

It really seems that this year, announcements are happening before JavaOne.
Here's what I have so far (I'm sure I missed some, adding as we go):
• GlassFish v3 does OSGi
• NetBeans 6.1 released
• Spring Application Platform
• Java 6 on the Mac (late, but still faster than JBoss on Java EE 5 ;)
• OpenJDK 6 in Fedora and Ubuntu
• Embedded GlassFish
• XWikiWorkspaces

Hum, I'm wondering if they were all planned long in advance or somehow related one to another...
Anyway, plenty more to come at JavaOne I'm sure. Full speed ahead!

lundi février 05, 2007

JAX-WS 2.1, la pile Web Service qui déchire (ceci est un blog pas un communiqué de presse)
JAX-WS 2.1 est désormais disponible. Il s'agit, comme pour GlassFish v2 (le serveur d'application Java EE 5 Open Source), d'une version de maturité qui simplifie l'expérience de l'utilisateur, augmente la flexibilité du framework tout en améliorant ses performances. Un vrai programme de campagne!

Le Web Services ne sont pas nécessairement lents si l'on utilise la bonne architecture (le plus difficile à faire) et la bonne implémentation (ça change rapidement). Qu'il s'agisse de Web Services ou d'autres technologies, les benchmarks sont intéressants dans le cadre d'un développement en intégration continue pour l'équipe qui développe la technologie, mais comme il n'existe pas de standard en la matière (SPEC ou autre), tout résultat doit être interprété avec précaution. Ils ne sont pas tous pour autant suspects, simplement il n'est souvent pas possible de comparer des résultats de benchmarks distincts. Ceci étant dit, ces derniers jours, les piles Web Services Java ont été à la une.

Ce fut tout d'abord la société WSO2 (l'essentiel des développeurs d'Axis 2 chez Apache) qui a publié des résultats comparants Axis 2 et XFire de Codehaus. La réponse (fleurie) du camp XFire ne s'est pas fait attendre (si vous ne connaissez pas le BileBlog, attachez vous au fond, pas à la forme :).

Avec la sortie de JAX-WS 2.1, c'est le tour de l'équipe GlassFish JAX-WS (qui y travaillait depuis longtemps) de publier ses chiffres JAX-WS contre Axis 2. Ces tests ont été effectués sur le même matériel, la même partie cliente pour Axis 2 comme pour JAX-WS 2.1 et les résultats affichent clairement un avantage compris entre 30% et 100% en faveur de GlassFish JAX-WS :


Comme il en est question dans les commentaires du billet ci-dessus, les tests ont été réalisés avec Java 5(_10). L'utilisation de Java 6 (disponible depuis décembre 2006) semble augmenter les performances de GlassFish de 7%-10%. Quoi qu'il en soit, les options de tuning de la JVM sont beaucoup moins nombreuses que dans le test de WSO2.

Dans tout benchmark Web Services, la partie binding est un sous-ensemble important. JAXB 2 (le standard intégré dans Java EE 5 et utilisé par JAX-WS) a eu beaucoup de succès en peu de temps (il ne date que de début 2006) grâce à sa flexibilité, sa performance et son adoption par JBoss, BEA et d'autres encore qui reprennent l'implémentation de GlassFish à l'identique dans leurs produits. Axis 2 ne permet pas (encore) d'utiliser JAXB 2 si bien que les tests ont été effectués avec XMLBeans (technologie Apache d'origine BEA) dont les performances de sérialisation/dé-sérialisation sur des données volumineuses et complexes est très bonne.

Si l'on compare ces résultats à ceux de WSO2, tout d'abord, on constate l'utilisation de ADB dont je n'avais pas entendu parlé auparavant et qui semble avoir des limitations sur le support des schemas XML. De quoi se poser la question : "que se passe-t-il quand mon contrat WSDL défini indépendamment de toute structure de données se met à utiliser des schémas non-supportés par ADB?". En supposant que Axis 2 soit nettement supérieur à XFire comme le suggère le test WSO2, il est étonnant de voir un nombre de transactions par seconde aussi inférieur à ceux constatés par l'équipe JAX-WS (environ 4 fois meilleures) sur la même technologie Axis. Y aurait-il une limitation du listener HTTP de Tomcat qui en justifie (la machine n'était peut-être pas chargée au maximum ce qui est pourtant plus important que de saturer le réseau gigabit...)? Ici, les tests ont été effectués avec Grizzly.

JAX-WS 2.1 est la version intégrée dans GlassFish v2 dont la beta ne saurait tarder et dont la version finale est attendue avant la JavaOne. Ceci permet d'utiliser dans un seul produit intégré non seulement la pile JAX-WS 2.1, mais aussi son extension naturelle WSIT qui propose le support de nombre de spécifications WS-* (sécurité, fiabilité, optimisation) comme l'indique ce tableau et une inter-opérabilité validée avec la technologie Microsoft .Net 3.0 (WCF).

Enfin, ces résultats ne sont pas définitifs :
- même si des messages relativement conséquents ont été échangés dans le benchmark JAX-WS 2.1, les technologies MTOM/XOP (optimisation inter-operable) et FastInfoset (encore plus performant mais moins inter-opérable) n'ont pas été utilisées. On peut espérer améliorer encore les résultats obtenus.
- une fois que XFire et Axis 2 deviennent conformes à JAX-WS (le travail est en cours), il sera intéressant de refaire des tests qui s'appuyent tous sur le même modèle de programmation.
-  il serait intéressant de comparer tous ces résultats Java à des tests comparables coté .Net.
- ceci me fait pensez au serveur Systinet? Qu'est-il devenu ?
- les seuls tests qui comptent sont les vautres.

L'intérêt de JAX-WS 2.1 n'est pas limité à la performance et propose des évolutions intéressantes pour le développeur comme c'est décrit dans ce billet (intégration Maven, Web Services avec état, intégration dans différents serveurs d'applications ou encore avec Spring ne sont que quelques exemples). Pour tester JAX-WS 2.1, vous pouvez télécharger les binaires autonomes depuis http://jax-ws.dev.java.net ou bien télécharger GlassFish v2 M4. Dans les deux cas, la documentation complète et à jour se trouve ici.

( févr. 05 2007, 11:04:31 PM CET ) Permalink

Why JAX-WS 2.1 isn't a dot release (ok, technically it is :)
JAX-WS 2.1 is final. Much like GlassFish v2, this release is about removing rough edges, focusing on usability, extensibility, and increasing performance.

Web Services are not slow when used wisely which boils down to choosing the right architecture (hardest part) and implementation (things change often). Performance benchmarks are interesting certainly for internal teams to track progress in a continuous build mode, but since there's no industry standard benchmark (ala SPEC) at this point, any such benchmark results should be taken with a grain of salt. It doesn't mean they're wrong, just that you can't do straight comparison of results across benchmarks. With that in mind some Web Services-related benchmarks popped-up lately discussing the main Java Web Stacks various merits...

First, four days ago, the WS02 guys (the main force behind Axis 2 as I understand) published a benchmark comparing Axis 2 and Codehaus XFire. It didn't take long before the XFire camp replied (via the BileBlog).

Now the GlassFish JAX-WS team is releasing their own numbers (testing started long before WSO2 published their results) vs. Axis 2. Theses tests use the same hardware and the same driver talking to Axis 2 and JAX-WS 2.1 and show better results across the board, from 30% to 100% better than Axis 2 :


As discussed in the post comments, the JAX-WS 2.1 benchmark is using Java 5(_10). A move to Java 6 improves GlassFish's performance up by 7-10%. The VM tuning certainly has less options than in WSO2's tests.

Obviously, in any Web Services benchmark, the binding part plays a great role. JAXB 2 (the standard Java EE 5 API used by JAX-WS) has really been kicking butt in terms of flexibility, performance and adoption (JBoss, BEA and others are using it straight out of GlassFish). Axis 2's support for JAXB is not ready yet, so the test was run using XMLBeans which shows good sustained marshalling/unmarshalling performance on bigger and more complex data sets.

Contrasting this with the WSO2 results, I had never heard of ADB before, I don't know how many people are using it, but it seems to have schema limitations which begs the question of what to do when the contract-first approach with generic data (a protocol needs to be data-independant) starts using XML Schema which break ADB? Also, admitting Axis 2 beats XFire in the WSO2 test, the Axis TPS figures seem pretty low compared to what the JAX-WS team measured on Axis. Maybe the server utilization isn't high enough (more important than saturating the giga-bit network IMHO) and they're hitting some Tomcat (HTTPd ?) listener limitation. GlassFish has Grizzly.

Note JAX-WS 2.1 is the version integrated into GlassFish v2 which will be shortly in beta and final before JavaOne. This will package up into a single product the JAX-WS 2.1 implementation together with it's natural extension WSIT which brings many WS-* specification implementations (as shown here) and great Microsoft WCF interop.

Of course, these results are by no means final :
- while some fairly big messages were exercised in the JAX-WS 2.1 benchmark, MTOM/XOP (more interoperable) and FastInfoset (better performance) were not used. These could help achieve even better results.
- when XFire and Axis 2 get to JAX-WS conformance (they both have plans), it will be interesting to compare them all using the same programming model.
- it would also be interesting to see how these numbers all compare to .Net.
- this all reminds me of Systinet's Web Services engine. Whatever happened to it?
- test with your own messages/payloads/architecture/load, this is the only benchmark that matters.

JAX-WS 2.1 not only about performance, it's also about developer ease of use (Statefull Web Services, Maven integration, integration with multiple application frameworks including Spring just to name a few). See this blog for more info. Want to test-drive JAX-WS 2.1? Download the standalone bits from http://jax-ws.dev.java.net or get GlassFish v2 M4. In both cases, extensive and up-to-date documentation can be found here.

( févr. 05 2007, 11:03:41 PM CET ) Permalink Comments [2]