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/

Jboss ws + jboss esb : WS embarqué dans un esb ET autodefini en EBWS

VALABLE POUR JBOSS ESB 4.5
Pour faire cohabiter des webservices
* embarqué dans un war (par exemple utilisé dans une action de JBOSS ESB via SOAPClient) lui même embarqué dans le fichier esb
* et ceux générés automatiquement avec EBWS (un webservice endpoint sur l'ESB est défini automatiquement quand on défini les contract sur <actions> d'un service ESB)

Il faut intégrer dans le web.xml en plus des webservices qu'on aura défini ceux qui seront générés automatiquement.


<servlet>
<servlet>
<servlet-name>MonWS</servlet-name>
<servlet-class>fr.com.MonWS</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>MonWS</servlet-name>
<url-pattern>/MonWS</url-pattern>
</servlet-mapping>



<servlet>
<servlet-name>NOM-CATEGORIE_NOM-SERVICE</servlet-name>
<servlet-class>esb.ws.NOM-CATEGORIE.NOM-SERVICE.Implementation</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>NOM-CATEGORIE_NOM-SERVICE</servlet-name>
<url-pattern>/NOM-CATEGORIE/NOM-SERVICE</url-pattern>
</servlet-mapping>

</servlet>
<servlet-mapping><url-pattern></url-pattern>
</servlet-mapping>


Le problème vient du fait que la fonctionnalité EBWS génère son propre war qu'il embarque automatiquement dans le fichier ESB. On se retrouve avec deux war et deux fichiers web.xml. Celui qu'on aura défini masquant celui généré automatiquement.


Pour vérifier la publication de tous les webservices : http://localhost:8080/jbossws/services

PaP - Créer un client d'un WebService sous forme d'objet COM en VB.NET

[- Avec une utilisation minimale de Visual Studio.Net] [- Il est conseillé d'utiliser la console lancée depuis "Invite de commandes Visual Studio.Net", car les variables d'environnement sont configurées (path,etc..)] Objectif : créer un composant COM grâce à VB.NET jouant le rôle du client du webservice 1.Environnement URL du fichier descriptif (fichier wsdl) du webservice: http://www.site.com:8080/mywebservice?wsdl 2.Génération d'une classe "proxy" en vb.net Cette classe jouera de rôle entre l'application utilisatrice du composant COM et le WebService. En mode console, utilisation de l'outil du SDK.Net nommé "wsdl" : wsdl /language:VB /out:ProxyWebService.vb http://www.site.com:8080/mywebservice?wsdl /language:VB -> génération d'une classe en VB.NET /out:ProxyWebService.vb -> nom du fichier généré Si pour une raison de configuration de proxy, vous obtenez un message d'erreur, recopiez le fichier wsdl en local avec l'extension .wsdl et utilisez : wsdl /language:VB /out:ProxyWebService.vb C:\dev\fichierWSDL.wsdl 3.Création d'un objet COM en VB.NET Suivre l'article suivant : [PaP - Objet COM en VB.NET] Sauf pour les étapes 3,4,6,7 étape 3 : Importer - Ajouter au début de maClasse.vb (avant le namespace) Imports Microsoft.VisualBasic Imports System Imports System.ComponentModel Imports System.Diagnostics Imports System.Web.Services Imports System.Web.Services.Protocols Imports System.Xml.Serialization (en réalité ceux qui sont dans ProxyWebService.vb) étape 4 : Méthodes - Modifier la déclaration de la classe maClasse En ajoutant tous les attributs de la classe ProxyWebService ainsi que la déclaration de son héritage à la classe maClasse Conserver : ComClass(maClasse.ClassId, maClasse.InterfaceId, maClasse.EventsId) Ex : <System.Diagnostics.DebuggerStepThroughAttribute(), _ System.ComponentModel.DesignerCategoryAttribute("code"), _ System.Web.Services.WebServiceBindingAttributeName:="WSSoapBinding", [Namespace]:=http://www.no.com/ws), _ System.Xml.Serialization.SoapIncludeAttribute(GetType(Attribute)), _ ComClass(maClasse.ClassId, maClasse.InterfaceId, maClasse.EventsId)> Public Class maClasse Inherits System.Web.Services.Protocols.SoapHttpClientProtocol .... End Class - Insérer les méthodes de la classe ProxyWebService dans maClasse - Insérer dans le namespace monNamespace du fichier maClasse.vb, les éventuelles autres classes du fichier ProxyWebService.vb directement en dessous de la classe maClasse - Si une configuration de proxy web est nécessaire Dans la méthode New() : (ou dans une méthode Init(..) qqconque) Dim URLToByPass() As String = {".*"} ' RegExp d'URL ne devant pas passer par le proxy Dim objProxy As New System.Net.WebProxy("http://proxy:81/", True, URLToByPass) ' l'argument 'True' indique que les adresses locales ne doivent pas passer par le proxy. Malgrè tout il vaut mieux quand même préciser URLToByPass objProxy.Credentials = System.Net.CredentialCache.DefaultCredentials Me.Proxy = objProxy étape 6 : Importer - Au début du fichier Assembly.vb,ajouter Imports System Imports System.Attribute Imports System.Reflection Imports System.Runtime.InteropServices étape 7 : Compiler la DLL - En mode console, en se plaçant dans le répertoire du projet set assemblies=System.Web.Services.dll,System.Xml.dll,System.dll[etc..] mettre ici toutes les autres références éventuellement nécessaires Il faut déterminer dans quelle DLL sont incluses les déclarations de type Import. On peut se servir de Visual Studio par exemple, en ajoutant une référence à la bibliothèque importer (menu "Références" dans l'explorateur de solutions) et consulter la propriété "Chemin d'accès". - Compilation : vbc *.vb /out:bin\nomFichier.dll /target:library /r:%assemblies%