Master 2 MIAGE NTDP Nom : Le Prof ! UE « Web Services et SOA
publicité
Master 2 MIAGE NTDP UE « Web Services et SOA », Nom : Le Prof ! Prénom Epreuve écrite individuelle 8 Décembre 2008, durée 45 mns Aucun document autorisé => Finalement, autorisés et semble-t-il utiles !!... Exercice 1 – (barème approximatif : 10 points) traitant essentiellement des Web Services Sous l’apparence de QCMs ces différentes questions devront néanmoins être accompagnées de quelques mots d’explication. Les questions ne sont pas forcément à réponse unique (mais il y en a toujours au moins une de possible !). 1. Un fichier WSDL (ex. toto.wsdl), c’est : a) une classe Java b) un fichier XML c) une page JSP b) uniquement 2. « google Search » ou « Amazon web services electronic commerce » requièrent une clé qui sert à : a) Identifier le web service invoqué b) Identifier l’utilisateur qui accède au web service c) Identifier la machine Internet qui émet l’invocation du web service b) uniquement 3. L’outil Axis d’Apache est : a) Un moteur d’orchestration de processus métier b) Une recommandation du W3C, liée à la technologie des Web Services c) Un moteur (encodeur, décodeur) de messages écrits selon le protocole HTTP d) Un moteur (encodeur, décodeur) de messages écrits selon le protocole SOAP Axis sait recevoir et envoyer aussi bien des demandes d’appels de web services formulées en paquets http, que formulées selon le protocole SOAP (enveloppe SOAP) 4. REST veut dire: a) Une norme du W3C b) Une manière de dialoguer avec un service web au dessus de IP c) Une manière de dialoguer avec un service web via JMS (Java Messaging System) d) Une façon de représenter une adresse d’un service web C’est le b), et plus précisément, c’est le protocole http au dessus de IP 5. Un service web c’est: a) Un processus BPEL b) Un ensemble de paquetages et classes Java c) Une page HTML Page 1 / 7 d) Une page JSP e) Un fichier WSDL b) L’implémentation d’un web service peut effectivement prendre la forme de classes de paquetages Java. Mais aussi peut prendre la forme d’un code écrit en langage BPEL (mais de manière stricte, un web service n’est pas forcément un processus BPEL) Un service web est par contre obligatoirement associé avec un fichier WSDL qui spécifie en fait précisément les informations nécessaires pour pouvoir se servir du service web. 6. Pour publier un service web: a) On doit résoudre ses dépendances vis-à-vis d’autres services b) On doit utiliser le protocole Internet DNS c) On utilise un registre de services web, qui s’appelle d’ailleurs ?? (répondre dessous) ??= UDDI c)uniquement, et plus précisément, les web services (les WSDLs) peuvent être enregistrés dans des registres UDDI (pas des DNS qui sont aussi des registres mais pour d’autre type d’information) 7. Pour utiliser / appeler / être client d’un service web: a) On doit écrire un programme Java b) On doit écrire une page JSP c) On peut utiliser son navigateur web d) On n’a pas besoin de connaître d’URL associée a) on peut écrire un programme java, code java qu’on peut éventuellement insérer dans une page JSP entre les balises <% %> (donc b)) On peut aussi utiliser simplement son navigateur web. Dans tous les cas, on a bien besoin de connaître l’URL (soit on la tape explicitement dans la barre de navigation, soit, on a l’adresse incluse dans le fichier wsdl utilisé par le code Java) 8. Un fichier décrivant un service web: a) Est obligatoirement un fichier xml b) Peut se comparer à une interface Java (au sens « interface Java versus classe Java ») c) Doit contenir une balise xml <deployment> d) Doit contenir une unique balise <service> a) certainement b) Oui en quelque sorte, le service web joue un peu l’équivalent d’une interface Java parce qu’il montre explicitement quelles méthodes (opérations) avec quels paramètres d’entrée et de sortie il faut leur passer. d) aussi (voir exercice 3 par exemple) 9. Un fichier de déploiement d’un service web en utilisant Axis: a) Permet de déployer un code source Java sur le serveur web b) Permet de déployer les classes Java compilées sur le serveur web c) Permet d’exposer tout ou partie de méthodes Java que l’on veut rendre accessibles c) uniquement. Car pour faire le déploiement du code source ou compilé, il faut manuellement copier les fichiers correspondants dans les répertoires adéquats du serveur web. Effectivement, on peut dans allowmethods préciser quelles méthodes publiques de l’implémentation Java l’on veut exposer (* permet de toutes les exposer) Page 2 / 7 10. Un fichier WSDL associé à un service web: a) Expose au plus une opération b) Expose autant de types de port (portType) que d’opérations c) Expose au plus une façon de se binder (binding) à chaque type de port a) non car plusieurs opérations par port sont autorisées. b) oui et non ! car en fait un portType peut contenir plus d’une opération. c) faux, car on a pu voir qu’un porttype peut être associé à plusieurs bindings (http ou soap) Page 3 / 7 Exercice 2 – (barème approximatif : 10 points) traitant essentiellement de SOA 11. Les 3 acronymes SCA, BPEL et JBI signifient respectivement ServiceComponentArchitecture Business Process Execution Language Java Business Integration 12. La spécification SCA définit : a) Une manière d’enchainer des appels de services b) Une manière d’assembler des modules encore appelés composants logiciels c) Une alternative à l’implémentation de services web b) SCA est un modèle permettant d’exprimer les services nécessaires à l’accomplissement d’un service donné par le biais d’une approche type composant logiciel. Ce n’est pas a) car, SCA n’aborde pas la logique d’orchestration (même si un composant SCA peut être implanté en utilisant un programme BPEL) 13. Un bus à services permet de : a) D’assembler des services web b) Transformer des invocations de services émises dans une technologie donnée en une autre technologie c) De publier des services métiers, accessibles via le bus a) pas vraiment, le bus permet d’autres choses (ce n’est pas un moteur d’orchestration, ni un modèle de composants logiciels comme SCA). b) oui, c’est un rôle clé du bus c) plutôt non, car, en soi, un bus à services n’est pas un registre de services (c’est bien plus, au sens où le bus héberge plusieurs choses, éventuellement parmi elles un registre de services internes). En général, ce registre interne peut permettre de retrouver les services à l’intérieur du bus, mais pas à l’extérieur du bus (ce que offre un registry UDDI). Donc, même si un service métier est publié dans le registre interne du bus, il n’est pas visible à l’exérieur. Donc pas publié, et donc pas appelable de l’extérieur. 14. Un workflow (processus métier) est une sorte de programme : a) Dont l’unique rôle est d’invoquer des services web b) Dont la syntaxe est proche de celle de Java c) Dont la sémantique des invocations de services est basée sur des échanges de messages, ou bien sur des appels de méthodes à distance ? d) Qui permet de passer des paramètres en entrée et/ou en sortie Répondre à c), quels que soient vos choix pour a),b),d) La philosophie dans BPEL (et dans les web services d’ailleurs) est que tous les échanges sont basés sur l’échange de messages (même si dans ces messages on peut mentionner des noms d’opérations, en quelque sorte des noms de méthodes que l’on veut déclencher à distance) a) pas seulement, car dans le BPEL, on peut faire des boucles, test, etc. d) oui, on peut passer des valeurs d’entrée et recevoir des valeurs en sortie 15. Une architecture logicielle de type SOA signifie : a) Qu’elle est constituée de modules logiciels décrits dans une unique technologie b) Qu’elle peut faire référence à des applications externes c) Que l’usage d’un bus à services est obligatoire Surement pas a), c’est tout le contraire. Page 4 / 7 Plutôt le b) au sens où ces applications externes peuvent être emballées en tant que service ( via par exemple un service web), et ainsi, rendues intégrables avec d’autres services c) pas du tout : une architecture SOA peut être composée uniquement de web services s’invoquant directement les uns les autres (pensez au TP1 ensemble de fichiers axis08.zip) 16. Les notions d’architecture SOA et de processus métier sont a) complémentaires b) incompatibles Expliquer/justifier clairement votre choix ici : a) car un module écrit en BPEL peut justement jouer le rôle de chef d’orchestre qui dicte à quel moment les services utilisés dans la SOA sont invoqués. 17. Un processus métier écrit en BPEL : a) N’a aucun lien particulier avec la technologie des web services b) S’expose en tant que web service c) Expose ses dépendances vers des services extérieurs b) OUI c) aussi, via les Partner Links (même si les opérations receive dans le BPEL se font sur des ports, eux-mêmes éléments à part entière des Partner Links) 18. Un moteur d’orchestration de processus métiers écrits en BPEL : a) Se charge uniquement de l’interprétation du processus b) Sait invoquer lui-même des services web requis par le processus c) Peut être hébergé en tant qu’élément d’un bus à services a) OUI b) non, c’est justement pour cela qu’on a besoin avec d’un moteur de SOAP et Web Services tel Axis 19. La notion de gouvernance dans le domaine du SOA : a) Relève uniquement de la politique politicienne! b) Aide à inclure la prise de décisions au cours du cycle de vie de services c) Se traduit par des contrats que les services doivent exposer b) Oui c) seulement en partie, cad que lorsqu’on spécifie un service, on détermine aussi le contrat qu’il s’engage à respecter si on veut utiliser ce service en tant que client. Donc le contrat fait partie de la spécification. Et cette spécification est validée durant le cycle de vie du service (au moment où la gouvernance – le gouvernement --décide de développer le service) 20. L’objectif d’une approche SOA dans le monde de l’informatique d’entreprise est : a) De maximiser la réutilisation de code b) De pouvoir intégrer des applications existantes non compatibles a priori entre elles c) De pouvoir mieux surveiller les performances de chacun des services participants à la SOA a) oui avant tout b) oui aussi Page 5 / 7 c) un peu aussi, car, chaque module logiciel est bien identifié en tant que service On peut donc facilement lui associer les informations de monitoring (de qualité de service comme on dit) et ainsi mesurer ses performances, et vérifier qu’il honore son contrat Exercice 3– (5 points) Annoter ce WSDL de vos commentaires : à quoi il sert, comment s’en servir d’un point de vue client, quelles données vont circuler quand on l’utilise, etc <?xml version="1.0"?> <definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/1999/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> <message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePrice"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePriceResult"/> </message> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal" namespace="http://example.com/stockquote.xsd" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="literal" namespace="http://example.com/stockquote.xsd" Page 6 / 7 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> </operation> </binding> <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service> </definitions> Ce service web offre une unique opération : sur envoi d’un message de type GetLastTradePrice, l’opération nommée GetLastTradePrice va s’exécuter. L’URL pour déclencher cette opération depuis un navigateur web devrait http://example.com/stockquote/method=GetLastPrice?tickerSymbol=MonEntreprisePreferee. Le message sera véhiculé par une enveloppe SOAP (on a défini un soap binding). Le type de donnée en entrée est un tickerSymbol prenant une valeur de type chaine de caractères. En réponse, on obtient un price que l’on peut interpréter comme un flottant. Page 7 / 7
