Exercice 1.C

référence :

http://static.springsource.org/spring-ws/sites/1.5/reference/html/tutorial.html

Web Service :

Contract Last : on écrit d'abord le code Java et sur base de cela on génère le contrat après (WSDL)

Contract First : On écrit d'abord le contrat (WSDL) et on génère du Java à partir de là.

Rappel sur les dates :

ISO 8601 format : yyyy-mm-dd

D'une manière générale le XSD deviendra le Data Contract (qui définira le payload) :

Voir le rappel sur les XSD et le XSD final généré :

Une fois le data contract terminé on passe au Service Contract : Le WSDL

En général Spring WS sait générer le WSDL pour nous automatiquement

WSDL abstract parts : (doc xml utilisé pour localiser et décrire des webservices)

1. definitions :<definitions>
   - namespaces
   - types <wsdl:types><xsd:schema xmlns>
   data type definition : décrits les types des paramètres impliqués dans le message
   </xsd:schema></wsdl:types>
2. on définit le message : <wdsl:message>
   xsd décrivant la forme du message (data contract). Un peu comme les paramètres d'une fonction
   </wsdl:message>
3. On décrit un porttype :
   <portType>
   décrit les opérations et les message impliqués
   </portType>
4. Binding : on associe le message à un port type comme opération (le porttype sera utilisé dans le binding)
   <binding>
   protocoles et format de données
   </binding>
   </definitions>

Exemple : portType

<message name= »getTermRequest »>

<part name= »term » type= »xs:string » />

</message>

<portType name= »gloassaryTerms » />

<operation name= »getTerm »>

<input message= »getTermRequest » />

<output message= »getTermResponse » />

</operation>

</portType>

Dans ce cas de figure glossaryTerms peut être comparé à une librairie de fonction (ou classe?)

En gros le portType se comporte comme une classe accessible via le web.

Request-response est le mode de fonctionnement le plus commun.

Les autres types sont:

• One-way : pas de réponse attendue (uniquement input est défini
• Request-response : web request classique (stateless) : input / output
• Solicit-response : l'appli va attendre la réponse (statefull?)
• Notification : le serveur envoie un message mais n'attend pas de réponse

Le binding :

deux attributs :

• name : nom du binding
• type : pointe sur le port (une instance de porttype)

Le binding contient l'élément : soap:binding (style et transport)

• style : rpc/document
• transport : HTTP (mais pourrait-être autre chose : JMS)

Rmk on ne définit pas transport comme étant HTTP mais :

http://schemas.xmlsoap.org/soap/http

Le soapbinding contient l'élément opération :

définir l'opération que le portType expose

c'est là que l'on définit les requêtes http qui permettrond l'appel ex :

http://www.sdlg.be/exos1c/getAnova

Il faut aussi spécifier les types d'entrées sortie : ex:literal

WSDL concrete part

on effectue un

• binding qui indique au client comment invoker l'opération
• service qui dit au client où la trouver (le binding sera utilise dans le port du service)

Voir le tutoriel pour explications complémentaires :

On crée le projet via Maven2

mvn archetype:create -DarchetypeGroupId=org.springframework.ws -DarchetypeArtifactID=spring-ws-archetype -DarchetypeVersion=1.5.9 -DgroupId=be.sdlg.ws -DartifactId=anovaWS

On obtien un répertoire src/main/webapp

Le servlet spring-ws est automatiquement crée et les requêtes redirigés vers lui.

3.6 Implementing the endpoint

Remarque sur les documents XML

Mieux vaut utiliser un name space lorsque l'on déclare un élément :

<ELEMENT xmlns= « http://www.sdlg.be/web/myapp/schemas »>

</ELEMENT>

Utliser plutôt

AnovaRequest (éviter les – car conversion vers Java class)

Web services en Spring WS 3

Spring WS repose JAX-WS car X-Fire et JAX RPC sont devenus obsoletes

Utiliser Spring service exporter (Web Service Last Contract) : Spring va construire le WSDL après que le service ai été défini.

Construire un Web service last contract avec Spring 3

Il faut utiliser le bean SimpleJaxWsServiceExporter

@WebService (serviceName="AnnovaService")
public class AnovaServiceEndPoint extends SpringBeanAutowiringSupport {

@Autowired
AnovaService anovaService;

@WebMethod
public AnovaTable getAnova(List response, List regressor ) {
return anovaService.getAnova(response, regressor);
}
}

Dans le fichier sybil-servlet.xml

<bean class="org.springframework.remonting.jaxws.SimpleJaxWsExporter" p:baseAddress="http://localhost:8888/service/" / >

Ce bean publie automatiquement les pojo contenant l'annotation @WebService
l'adresse de base est /localhost:8080/AnovaService

Consommation de web service par les clients:
ProxyBeanFactory => crée un objet client à partir du WSDL
(La partie message du WSDL décrit les types de données, les types complexes sont défnis via des types xsd: simples)
(Le portType décrit les différentes opérations supportées)
=> Le proxy bean crée par le ProxyBeanFactory va simplement invoker les méthodes sur le serveur distant, comme les types de données sont connus, il est tout à fait possible pour le ProxyBean de recréer les classes correspondantes...

Toutefois, si l'on définit un classe de type AnovaTable, il serait tout de même bon d'avoir sa définition complète côté client pour pouvoir utiliser ce type de données ailleurs dans l'appli...

Là il est possible d'utiliser JDom ou mieux JAXB pour populer ces classes.

Sécuriser les accès au Web service: 

utiliser JaaS (Java authentication & authorization Service) : (à mettre à jour)

Rappels sur XSD

Dans le cadre de la partie C ( Exposer un Web Service qui renvoit une table ANOVA) de l'exercice précédent proposé, il est peut-être bon de faire un petit rappel sur les schémas XML:


Rappel de XML (Extended Markup Language):
XML                    Base de données       Programmation Orienté Objet
Xml Schema          Table Structure Class
Xml Document      Table Data         Instance (Object)

Un schéma ou fichier .xsd permet de définir la structure du contenu d'un document XML. Il existe différentes approches: DTD (Document Type definition), XSD,  XDR 
DTD:  compliqué et pas basé sur XML
XDR:  propriété de Microsoft (on oublie)
XSD : relativement répandu et sera notre choix:
caractéristiques:
- xml based
- support inheritance
- ability to define its own type (Complex-type)
- specify data types for element & attributes

1) Schema : Pour pouvoir utiliser un document pour valider d'autre document il faut qu'il soit lui même validé !


<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

...

</xsd:schema>

Notre document devra donc suivre la structure et les types décrits dans www.w3.org/2001/XMLSchema

2) Element: spécifie le type d'informations
argument :
@name : nom de l'info ex: name="RESPONSE"
@type : refère à un type simple ou complexe
@minoccurs : par défaut 0 mais peut forcer 1 ou n occurrence de l'élément pour que le doc xml soit valide
@maxoccurs : nombre d'occurence max, pour dire que c'est indéfini ou utilise maxoccurs="unbound"
@ref : allows to refer an element defined in an othr xsd don't forget

3) Complex Type
ATTENTION les simpleType ou complexType peuvent être globaux ou locaux.

Element containing other child elements or attributes


spécifie l'ordre dans lequel doivent se suivrent les éléments apparaissant dans le doc XML. Si l'ordre n'est pas respecté le validateur va gueuler.




<xsd:sequence>
</xsd:sequence>
spécifie l'ordre dans lequel doivent se suivrent les éléments apparaissant dans le doc XML. Si l'ordre n'est pas respecté le validateur va gueuler.

<xsd:complexType>
<xsd:extension base="xsd:Employee"> <!-- permet de faire un véritable héritage d'élement -->
</xsd:complexType>


4) Simple Type
User Defined type: crée à partir d'un type de base:
Principaux types de base (primitve types) supporté par XSD
- xsd:string
- xsd:int
- xsd:date
- xsd:datetime
- xsd:boolean
- xsd:float
- xsd:double

Il est possible de créer un "simple type" sur base d'un type primitif et de lui ajouter des restrictions (ex: valeur interdites via une regexp)

<xsd:simpleType name="ssnumber"> <xsd:restriction base="xsd:string"> <!-- hérite de xsd:string--> <xsd:length value="11" /> <xsd:pattern value="\d{3}\-\d{2}-\d{4} /< <!-- securité sociale --> </xsd:restriction> </xsd:simpleType>ou

<xsd:simpleType name="emp-type"< >xsd:restriction base="xsd:string"> <!-- hérite de xsd:string--< <xsd:enumeration value = "fulltime"/> <xsd:enumeration value = "parttime"/> </xsd:restriction> </xsd:simpleType> En XSD on appelle les différentes restrictions: "enumeration, length, pattern" sur un type de base, des "Facets"

5) Documenter un schéma:

<xsd:annotation> <xsd:documentation> <!-- donne des infos sur les fonctionalités pour lesquelles les éléments sont définis --> &lt/xsd:documentation> <xsd:appInfo> <!-- donne des infos sur l'application qui utilise les éléments--> </xsd:appInfo> </xsd:annotation>

Voilà à la prochaine apparition nous verrons comment:
- valider un document XML par rapport à son xsd
- concevoir directement des classes java à partir d'un xsd