jeudi, octobre 29, 2009

Maven 2 : Lifecyle & autres

Option pour lancer une tâche sans les tests :
mvn -DskipTests=true nom_task
(ne lance pas l'exécution des tests, ni leur compilation)

Cycle de vie :
Le cycle de vie par défaut est constitué de tâches successives. En appelant une des taches de ce cycle de vie, toutes les taches précédentes sont exécutées


Le cycle de vie par défaut de maven est le suivant :
  • validate - validate the project is correct and all necessary information is available
  • compile - compile the source code of the project
  • test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package - take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test - process and deploy the package if necessary into an environment where integration tests can be run
  • verify - run any checks to verify the package is valid and meets quality criteria
  • install - install the package into the local repository, for use as a dependency in other projects locally
  • deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects. 

Cycle de vie en détail :

validate
validate the project is correct and all necessary information is available.
initialize
initialize build state, e.g. set properties or create directories.
generate-sources
generate any source code for inclusion in compilation.
process-sources
process the source code, for example to filter any values.
generate-resources
generate resources for inclusion in the package.
process-resources
copy and process the resources into the destination directory, ready for packaging.
compile
compile the source code of the project.
process-classes
post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources
generate any test source code for inclusion in compilation.
process-test-sources
process the test source code, for example to filter any values.
generate-test-resources
create resources for testing.
process-test-resources
copy and process the resources into the test destination directory.
test-compile
compile the test source code into the test destination directory
process-test-classes
post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test
run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package
perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package
take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test
perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test
process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test
perform actions required after integration tests have been executed. This may including cleaning up the environment.
verify
run any checks to verify the package is valid and meets quality criteria.
install
install the package into the local repository, for use as a dependency in other projects locally.
deploy
done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

lundi, octobre 12, 2009

Webservice : style et encoding

Intro:
Le style et l'encoding qui caractérise un webservice définissent la façon dont un message SOAP sera construit en fonction de la wsdl.

Style : RPC ou Document
Encoding : Literal ou Encoded
Autre : Wrapped Document Literal



Type :
RPC/Encoded :
- Le message SOAP ne contiendra pas le nom de l'opération en tant que racine à l'intérieur du <soap:body>
- Le message SOAP doit contenir des attributs xsd définissant le type de chaque élément
(exemple : xsd:int)
- No WSI-Compliant
- Validation XSD peut aisée car le schéma XSD est éclatée dans la wsdl

RPC/Literal :
- Le message SOAP contient le nom de l'opération en tant que racine à l'intérieur du <soap:body>
- Le message SOAP ne contient pas des attributs xsd définissant le type de chaque élément
(exemple : xsd:int)
- WSI-Compliant
- Validation XSD peut aisée car le schéma XSD est éclatée dans la wsdl

Document/Encoded :
N'existe pas

Document/Literal
- Le message SOAP ne contient pas le nom de l'opération en tant que racine à l'intérieur du <soap:body>
- Le message SOAP ne contient pas des attributs xsd définissant le type de l'élément
(exemple : xsd:int)
- WSI-Compliant partiellement. Dû au fait qu'une des restrictions de la norme préconise de ne faire apparaitre dans le <soap:body> qu'un seul élément racine. Alors que le Document Literal ne fait pas figurer de nom d'opération et n'a donc pas d'élément racine dans le <soap:body>
- Validation XSD aisée

Wrapped Document/Literal
- Le message SOAP contient le nom de l'opération en tant que racine à l'intérieur du <soap:body>
Il s'agit en réalité d'un contournement du type Document/Literal. L'élément racine n'est en réalité pas vraiment le nom de l'opération comme dans un type RPC/Literal, mais est un wrapper qui porte le même nom que l'opération. (Ce qui revient au meme in fine!)
- Le message SOAP ne contient pas des attributs xsd définissant le type de l'élément
(exemple : xsd:int)
- WSI-Compliant
- Validation XSD aisée


Notes :

- Historiquement, le RPC-Encoded fut le premier à apparaitre et est le plus populaire.
Il permet d'écrire des wsdl les moins complexes
- Le type RPC-Encoded présente à machines équivalentes des performances moindre qu'un type Document/Literal
- Le type Wrapped Document Literal est une amélioration du type Document/Literal en paliant à ses défauts.


Source :
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
http://www.ibm.com/developerworks/webservices/library/ws-soapenc/

mardi, octobre 06, 2009

JBoss esb et JBoss Remoting gateway (jbr)

Pour chaque service ESB, une ou plusieurs gateway sont définies.

Pour une gateway HTTP attachée a un provider JBR définissant un bus HTTP, il faut a chaque fois déclarer un nouveau port.

Ce qui peut etre problématique (ouvrir de multiple port HTTP, par service ESB)

La version 4.6 de Jboss ESB ne prend pas en charge un routage basé sur l'url (type JBossWS)

Ce sera peut être pris en charge dans la version 4.7
https://jira.jboss.org/jira/browse/JBESB-1557

En attendant, voici une implémentation d'un nouveau ListenerGateway, qui prend en charge un routage basé sur l'url passée, l'authentification http, etc :
http://www.jboss.org/community/wiki/HTTPGatewayListenerConfiguration