La consommation de web service n’est donc pas prévue dans la configuration et le profil MIDP que nous allons utiliser pour développer notre client sur téléphone mobile. Il nous faudra donc faire appel aux APIs optionnels prévus pour l’accès au web service. Ils sont définis par une spécification (Java Specification Requests) de la Java Community Process : il s’agit du JSR 172.
Ces packages sont au nombre de deux, regroupés (dans l’outil de développement Sun Wireless Toolkit) dans le fichier j2me-ws.jar.
Ils apportent les fonctionnalités suivantes, indispensables à la consommation de web services.
- La possibilité d’invoquer des services à distance. Il ‘agit d’un sous-ensemble de l’API JAX-RPC du J2SE.
- La possibilité d’utiliser des parseurs XML. On travaille ici avec un sous-ensemble de l’API JAXP du J2SE.
Il est de plus à noter que ces APIs apportent la possibilité de développer une application J2ME fonctionnant en consommateur de services. En aucun cas ils ne permettent à un téléphone mobile par exemple d’être un fournisseur de WS.
Tout comme évoqué dans la section consacrée à la présentation des WS en général, on se retrouve le cas de figure où l’on doit développer une application cliente, avec sa logique métier, son interface utilisateur, sa gestion de la persistance, et y ajouter ensuite une interface d’interaction avec le WS.
Ici aussi on devra générer à partir du document WSDL du web service une classe « stub » qui encapsule cette interaction avec le service, classe qui sera instanciée par la suite et qui sera chargée d’invoquer le service.
Dans le cas du J2ME, les outils Axis d’aide à la génération de classes dédiées à cet effet ne sont pas utilisables. Par contre, le Sun Wireless Toolkit que nous utiliserons pour développer la partie mobile du projet fournit un Stub Generator qui joue le même rôle.
Nous y reviendrons dans la partie développement.
