Présentations Solutions Linux - Securité Web Services

Les supports des présentations de Solution Linux 2008 commencent à poindre ici et là sur les sites et blogs. J'ai loupé celle de Sébastien Lévesque (Linagora) qui traite de "Utilisation de services web sécurisés en Java en environnement Open Source.". Il y est entre autre question de GlassFish v2 (Metro/JAX-WS/WSIT) qui est conforme au Basic Secure Profile (BSP) 1.0 et de son outillage NetBeans 6.0.

( févr. 08 2008, 06:01:00 AM CET ) Permalink

GlassFish aux MS Tech Days à Paris la semaine prochaine

Non rancunier qu'on nous ait piqué notre nom d'événement, je suis aux Microsoft Tech Days lundi et mardi sur le stand de Sun (interop Web Services, virtualisation et bien entendu serveurs x64/x86). J'anime également la session "Interopérabilité des Services Web en environnement .Net et Java via les technologies GlassFish et WCF implémentant les spécifications avancées des services Web (ARC310) "

( févr. 07 2008, 09:41:39 PM CET ) Permalink

Metro 1.0 disponible

Metro, la technologie Web Service de GlassFish (décrite ici) et interopérable avec Microsoft .Net WCF est désormais en version 1.0. Jusque là l'utilisation en production n'était pas recommandée. Cette version qui implémente JAX-WS 2.1 et de nombreux standards WS-* est intégrée à GlassFish v2 (sorti en même temps) mais il est également utilisable dans d'autres contextes:

•  avec Java 6 (standalone): soit en utilisant le JAX-WS fourni par défaut dans le JDK, soit en mettant utilisant Metro (y compris WSIT) dans sa dernière version.
•  dans Tomcat 6, partie JAX-WS et partie WSIT
•  dans JBoss (qui certifie Metro dans ses dernières versions)

L'utilisation au sein de GlassFish apporte des optimisations de performance, une meilleure administration, des outils de test unitaires de Web Service intégré et un management (logging, monitoring) lui aussi intégré dans la console et dans l'administration en ligne de commande. Plus de détails ici. Pour des exemples de déploiements de Metro dans des métiers différents, le blog de Harold apporte des détails intéressants.

( sept. 20 2007, 07:55:00 AM CEST ) Permalink Comments [4]

PRESTO, RGI et journal officiel
Le RGI (Référentiel Général d'Interopérabilité) est au journal officiel. Un pas de plus donc pour ODF, PRESTO dans l'administration française.
( mars 06 2007, 12:35:45 AM CET ) Permalink

javax.ws.rest

What if we took the best of servlets and JAX-WS and made RESTful Web Services a first class Java citizen? Welcome to JSR 311.

( févr. 14 2007, 02:55:54 PM CET ) Permalink Comments [1]

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]

PRESTO, GlassFish, and NetBeans (WS-*)

I spent some time since this summer working on a prototype for the French government. The project is called PRESTO ("PRotocole d’Echanges Standard et Ouvert") and is documented here. The goal is to define a profile (a la WS-I) for a transport protocol based on Web Services for better and more standard interop between ministries and related organisations. In a nutshell, it's about using WS-I Basic Profile, SOAP 1.2, MTOM, WS-Addressing, WS-ReliableMessaging, and optionally OASIS WS-Security.

There was (is) an interesting set of participants and technologies :
- Bull using Apache Axis 2 and ObjectWeb's JOnAS
- Zend relying on WSO2's Tungsten C implementation of Axis 2 to work as a PHP plugin
- Axway working with the Systinet/Mercury/HP web engine (SSJ)
- Microsoft with .Net 3.0 (WCF)
- Sun with Java EE 5 (GlassFish)

More details on Sun's prototype, technology and differentiators are described here (in a nutshell : full Open Source, toolable, and brain-dead simple programing). Everything is now part of GlassFish (as of recent v2 builds) and will be productized in Sun Application Server 9.1.

Absent were IBM, Oracle, JBoss, and BEA for various reasons, mainly because their respective offerings were not ready. Ironically, IBM claims it inspired PRESTO with their WS-RAMP specification (which itself came from two of their customers) but was unable to show any implementation. WS-RAMP seems like it could serve as a basis to a future WS-I profile which could end up being a replacement to PRESTO.

Representing WS02 was Paul Fremantle who's the chair of the OASIS WS-ReliableMessaging technical committee and an Axis 2 commiter. Paul has already blogged about PRESTO here.

The prototype involved working on a common WSDL definition of document/literal one-way and two-way operations and testing the interop of all combinations (with or without MTOM, WS-ReliableMessaging) between all implementations. Coming up with a common WSDL wasn't an easy job and many found out what wrapped doc/lit was all about (although this convention isn't really well documented).

The results are encouraging but not perfect, so the work on both the prototype and the PRESTO specification are still ongoing. The best results are shown with the Sun/GlassFish + Microsoft/WCF combination (100% PASS) showing the value of the engineering work between Sun and Microsoft as part of the Tango project. For the tests with other implementations, the NetTool tunnel was very useful although XML remains XML - a pain to read, a nightmare to debug.

Writing the Sun prototype for me was really a matter of using JAX-WS 2.0 (and the underlying JAXB 2.x binding architecture), understanding the GlassFish WSIT extensions (great tutorial here) and using the NetBeans WSIT plug-in which allows you to declaratively set the MTOM, WS-ReliableMessaging, and WS-Security properties. Writing a flexible-enough testing Swing UI was also fun, but better yet was writing the OpenOffice client demo.

PRESTO has clearly shown some European interest among the 130 attendees in last month's presentation in Paris and clearly fits a need.


( nov. 20 2006, 09:47:00 AM CET ) Permalink