Skip to content

Category Archives for Web services

SOAP

Introduction :

SOAP est un protocole basé sur XML permettant l’échange de messages sur les réseaux informatique. On utilise s’appuie généralement le protocole de transport HTTP ou HTTPS. SOAP est une des briques de la pile des web service ((web service stack :

  • (Service) Protocol de transport : se charge du transport de l’information entre les applications. Généralement, il s’agit de l’un des protocoles suivants : HTTP, SMTP, FTP.
  • (XML) Messaging Protocol : se charge de l’encodage des message dans un format XML permettant d’etre compris par tous les intervenants. Les protocoles généralement utilisés sont XML-RPC, WS-Addressing, et SOAP.
  • (Service) Description Protocol : sert à faire la description de l’interface publique d’un service web. On utilise généralement le format WSDL
  • (Service) Discovery Protocol : centralise les services au sein d’un annuair, afin que tous les services puissent y pousser leur description, ce qui en rend la découverte et l”utilisation plus aisée. C’est généralement l’API UDDI qui est utilisée pour la découverte des services.

)) sur lesquelles les couches plus élevées peuvent s’appuyer.Il existe plusieurs modèles d’envoyer les message dans SOAP, mais le plus fr”quent est le RPC (Remote Procédure Call), dans lequel un des noeuds envoie une requete à l’autre qui lui répond immédiatement. SOAP est le successeur du protocol XML-RPC quoiqu’il emprunte sa méthode de transport et sa structuration à d’autre (probablement WDDX)

Histoire :

A l’origine, SOAP signifiait Simple Object Acces Protocol, ce qui a été changé plus tard en Service Oriented Architecture Protocol. Ce changement s’est fait lorsque ce standard est devenu une recommandation du W3C. Ce protocole a été initialement créé par Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein en 1998.

Transport methods

SOAP se sert d’un protocole de couche application Internet comme un protocole de transport (ce qui lui vaut bien des critiques). Tant HTTP que SMTP sont utilisés come méthodes de transport pour SOAP, sachant que c’est HTTP qui est le plus utilisé, du fait de sa plus grandefacilité d’emploi au sein des infrastructures internet. En particulier SOAP fonctionne très bien au travers des firewall, il peut également être utilisé sur HTTPS en mode d’authentification simple ou mutuelle. Cette facilité est un de ses gros avantages par rapport à GIOP/IIOP qui est généralement filtré par les firewalls. XML a été choisi en raison sa large adoption dans les grandes entreprises, ainsi que pour les développements open source qu’il suscite.

Avantages et désavantages :

Avantages

  • L’utilisationde SOAP est bien adaptée aux filtrages actuels (proxy et firewalls)
  • SOAP permet l’utilisation de différents protocoles. Généralement on utilise néanmoins HTTP.

Faiblesses

  • Du fait de l’utilisation de XML, qui est très verbeux, SOAP peut nuire aux performances, face aux autres middleware de type binaire (type CORBA) dont les communications sont plus concises. Ce problème ne se sent généralement que lorsque les messages sont suffisament importants. Il existe par ailleurs des manières d’optimiser les messages SOAP ((http://en.wikipedia.org/wiki/MTOM))
  • Plusieurs implémentation de SOAP limitent la quantité de données envoyées.
  • Quand on ne s’appuie que sur HTTP (et qu’on utilise pas WS-Addressing ou ESB) les roles des interlocuteurs sont fixes : seule une des deux parties (client) peut utiliser les services de l’autres (serveur)
Written on 26 January 2009 under Architecture Applicative, Débutant, Web services with No Comments

WS-Security (WSS)

WS-Security (Web Services Security) est un protocole de communication permettant d’appliquer des règles de sécurité aux web services. Ce standard, maintenant sous la responsabilité de Oasis-Open et publié en Avril 2004, est issu des travaux joints de IBM, Microsoft, VeriSign et Forum Systems.

WSS contient des spécifications permettant d’implémenter l’intégrité ((l’intégrité de message est assurée en utilisant la Signature XML et des jetons de sécurité, ce qui assure que les messages sont bien provenus de l’expéditeur adéquat et n’ont pas été modifiés en transit.)), la confidentialité (( la confidentialité a pour but de garder les parts d’un message de SOAP confidentiel. On utilise le Cryptage XML et des jetons de sécurité pour cela)) et l’authentification des messages SOAP échangés par les différents webservices. Ces mécanismes peuvent être utilisés (voire combinés) pour une grande variété de technologies d”encryption, WSS détaille l’utilisation de SAML , Kerberos et de différents formats de certificats tel que X.509.

Les spécification WSS apportent donc aux développeurs de services web de sécuriser les echoanges SOAP de bout en bout ((L’intégrité et la confidentialité des services web peut également etre assurée par l’utilisation de Transport Layer Sécurity (TLS), en envoyant par exemple les messages sur HTTPS. Cela permet de réduire significativement les overheads en supprimant le besoin d’encodage des clés et de signature des messages en ASCII avant leur envoi. Le problème majeur de TLS est dans le cas d’utilisation de serveur proxy lors du routage du serveur. Par exemple : un serveur verra la requête arriver du proxy et non du client lui même. Cela peut être évité en posant une copie du certificat client sur le proxy ou en ayant un certificat connu par le serveur permettant de générer une pari clé/ certificat en phase avec le client. Cependant comme le proxy agit sur le message, cette solution n’assure pas une sécurité de bout en bout.)).

WS-Security décrit comment encoder et attacher une signature et des entêtes encryptées aux messages SOAP. De plus cela décrit comment attacher des jetons de sécurité (Usernamen, jetons X509., SAML, REL ou Kerberos ou tout autre clés encryptée) aux messages. Avec WSS, le champ d’action de ces mécanismes peut etre étendu en déplacant des information d’authentification au niveau des requetes aux services web.

Written on 23 January 2009 under Architecture Applicative, Débutant, Web services with No Comments

J2EE 1.4 : Les services standards

Voici une description rapide des services standard J2EE.

HTTP
L’API cliente HTTP est fournie par le package java.net.
L’API server HTTP est fournie par les interfaces JSP et les servlets.

HTTPS
L’utilisation du protocole HTTP sur le protocole SSL est supportée par les mêmes API que HTTP.

Java™ Transaction API (JTA)
L’API Java Transaction API se compose de deux parties :

Une interface de démarcation de niveau applicatif qui est utilisée par les conteneurs et les compensants applicatifs pour délimiter des frontières des transactions.

Une interface entre le gestionnaire de transaction et le gestionnaire de ressources utilisé au niveau de J2EE SPI level (dans une prochaine version)

RMI-IIOP
Le sous système RMI-IIOP est composé d’API qui permettent d’utiliser le style de programmation RMI qui est indépendant du protocole sous jacent, ainsi que d’une implémentation de ces API qui supporte le protocole RMI J2SE (JRMP) et le protocole CORBA IIOP. Les applications J2SE peuvent utiliser RMI-IIOP avec le support du protocole IIOP pour accéder a de services CORBA compatibles avec les normes RMI.

De tels services CORBA sont généralement définis par des composants qui résident en dehors d’un produit J2EE (généralement historique) Seuls les clients applicatifs J2EE doivent définir leur propre services CORBA à l’aide des API RMI-IIOP. Généralement ces objets CORBA sont utilisés pour les appels à d’autres objets CORBA

Les applications J2EE doivent utiliser les API RMI-IIOP (spécialement la méthode javax.rmi.PortableRemoteObject) pour accéder à des composants Enterprise JavaBeans (EJB). Cela permet aux EJB d’etre indépendants du protocole. Par ailleurs les produits J2EE doivent être capables d’exporter les Enterprise Beans en utilisant le protocole IIOP, et d’accéder aux Enterprise Beans en utilisant ce même protocole, comme spécifié dans les normes J2EE.

La possibilité d’utiliser le protocole IIOP est obligatoire pour permettre l’interopérabilité entre les produits J2EE, cependant ces dernières peuvent également utiliser d’autres protocoles.
Java IDL
Java IDL permet aux composants applicatifs J2EE d’invoquer des objets externes CORBA en utilisant le protocole IIOP. Ces objets CORBA peuvent etre écrits en utilisant n’importe que langage et ne pas faire partie de produits J2EE.

JDBC™
L’API JDBC peremt de gérer la connecticvité avec les bases de données. Cette API est composée de deux parties : une interface de niveau applicatif permettant aux composants applicatifs d’accéder aux bases de données et une interface ‘service provide’ permettant d’attacher un driver JDBC à une plateforme J2EE.

Java™ Message Service (JMS)
Le service Java Message est une API standard de messaging qui supporte le point a point ainsi que le modele de publication. Cette spécification demande que ces deux type de messages soient implémentés.
Java Naming and Directory Interface™ (JNDI)
The JNDI API is the standard API for naming and directory access. The JNDI API
has two parts: an application-level interface used by the application components to
access naming and directory services and a service provider interface to attach a
provider of a naming and directory service.
J2EE.2.6.9 JavaMail™
Many Internet applications require the ability to send email notifications, so the
J2EE platform includes the JavaMail API along with a JavaMail service provider
that allows an application component to send Internet mail. The JavaMail API has
two parts: an application-level interface used by the application components to send
mail, and a service provider interface used at the J2EE SPI level.
J2EE.2.6.10 JavaBeans™ Activation Framework (JAF)
The JAF API provides a framework for handling data in different MIME types,
originating in different formats and locations. The JavaMail API makes use of the
JAF API, so it must be included as well.
J2EE.2.6.11 Java™ API for XML Parsing (JAXP)
JAXP provides support for the industry standard SAX and DOM APIs for parsing
XML documents, as well as support for XSLT transform engines.
PLATFORM OVERVIEW 12
J2EE.2.6.12 J2EE™ Connector Architecture
The Connector architecture is a J2EE SPI that allows resource adapters that support
access to Enterprise Information Systems to be plugged in to any J2EE product. The
Connector architecture defines a standard set of system-level contracts between a
J2EE server and a resource adapter. The standard contracts include:
• A connection management contract that lets a J2EE server pool connections to
an underlying EIS, and lets application components connect to an EIS. This
leads to a scalable application environment that can support a large number of
clients requiring access to EIS systems.
• A transaction management contract between the transaction manager and an
EIS that supports transactional access to EIS resource managers. This contract
lets a J2EE server use a transaction manager to manage transactions across
multiple resource managers. This contract also supports transactions that are
managed internal to an EIS resource manager without the necessity of involving
an external transaction manager.
• A security contract that enables secure access to an EIS. This contract provides
support for a secure application environment, which reduces security
threats to the EIS and protects valuable information resources managed by the
EIS.
• A thread management contract that allows a resource adapter to delegate work
to other threads and allows the application server to manage a pool of threads.
The resource adapter can control the security context and transaction context
used by the worker thread.
• A contract that allows a resource adapter to deliver messages to message driven
beans independent of the specific messaging style, messaging semantics,
and messaging infrastructure used to deliver messages. This contract also
serves as the standard message provider pluggability contract that allows a
message provider to be plugged into any J2EE server via a resource adapter.
• A contract that allows a resource adapter to propagate an imported transaction
context to the J2EE server such that its interactions with the server and any
application components are part of the imported transaction. This contract
preserves the ACID (atomicity, consistency, isolation, durability) properties of
the imported transaction.
• An optional contract providing a generic command interface between an application
program and a resource adapter.
J2EE Standard Services 13
J2EE.2.6.13 Security Services
The Java™ Authentication and Authorization Service (JAAS) enables services to
authenticate and enforce access controls upon users. It implements a Java
technology version of the standard Plugable Authentication Module (PAM)
framework, and extends the access control architecture of the Java 2 Platform in a
compatible fashion to support user-based authorization. The Java™ Authorization
Service Provider Contract for Containers (JACC) defines a contract between a J2EE
application server and an authroization service provider, allowing custom
authorization service providers to be plugged into any J2EE product.
J2EE.2.6.14 Web Services
J2EE provides full support for both clients of web services as well as web service
endpoints. Several Java technologies work together to provide support for web
services. The Java API for XML-based RPC (JAX-RPC) provides support for web
service calls using the SOAP/HTTP protocol. JAX-RPC defines the mapping
between Java classes and XML as used in SOAP RPC calls. The SOAP with
Attachments API for Java (SAAJ) provides support for manipulating low level
SOAP messages. The Web Services for J2EE specification fully defines the
deployment of web service clients and web service endpoints in J2EE, as well as the
implementation of web service endpoints using enterprise beans. The Java API for
XML Registries (JAXR) provides client access to XML registry servers.
J2EE.2.6.15 Management
The Java 2 Platform, Enterprise Edition Management Specification defines APIs for
managing J2EE servers using a special management enterprise bean. The Java™
Management Extensions (JMX) API is also used to provide some management
support.
J2EE.2.6.16 Deployment
The Java 2 Platform, Enterprise Edition Deployment Specification defines a contract
between deployment tools and J2EE products. The J2EE products provide plug-in
components that run in the deployment tool and allow the deployment tool to deploy
PLATFORM OVERVIEW 14
applications into the J2EE product. The deployment tool provides services used by
these plug-in components.

Written on 12 January 2009 under Architecture Applicative, J2EE, Moyen, Web services with No Comments

AXIS c’est quoi ??

Tous les développeurs comprennent désormais l’importance des frameworks de développement, ces boites à outils qui permettent de décupler leur productivité. Développer avec SOAP ne déroge pas à la règle, quoique vous puissiez tout coder à la main avec un bon notepad, il est vraissemblable que ces frameworks vous permettront plus de vitesse, de réutilisabilité et d’évolutivité.

Il exites chez apache un tel outil. Sa première version SOAP4J, était un don de IBM. Désormais cet outil s’appelle AXIS et est bien plus qu’une simple réécriture des bibliothèques SOAP d’Apache, il s’agit en fait d’une refonte architecturale. Il a été prévu plusieurs phases dans le développement d’AXIS : 2 mouture en alpha, pour arriver au final à une version 3.0. Les première moutures d’AIX ont été publiées en août et Spetembre 2001.

Lorsqu’elle sera finalisée, cette bibliothèque permettra
1. Le support de SOAP 1.1, au même titre que Apache SOAP 2.2. Par exmple AXIS supportera complément le concept SOAP “mustUnderstand headers” [règles régissant la compréhension des message, pouvant mettre fin aux communication le cas échéants ].

2. d’être moins consommateur et plus rapide que Apache SOAP (grace à son usage de SAX) ( SAX permet un parsing rapide du XML)

3. de s’appuyer sur une couche d’abstraction simple pour les transports de donénes. (i.e., senders et listeners pour SOAP pour plusieurs protocoles tels que SMTP (Simple Mail Transfer Protocol), FTP, message-oriented middleware, …).

4. Générer automaitque les WSDL (Web Services Description Language) de services déja déployés.

5. Le support du déploiement d’EJB (Enterprise JavaBeans) comme services, comme le fait actuellement BEA WebLogic Server.

6. Une meilleure interopérabilité avec l’implémentation Microsoft de SOAP et les services .Net

Written on 06 January 2009 under Architecture Applicative, J2EE, Moyen, Web services with No Comments