Web Services. Evolução

Web Services Evolução 1997 A Sun distribui o JDK 1.1 que inclui o Remote Method Invocation (RMI) que define um modelo de computação distribuída usando objectos Java. O RMI é semelhante ao CORBA e ao DCOM mas funciona só com objectos Java. Microsoft desenvolveu o COM+ sucessor do DCOM muito próximo do modelo CORBA. 1999 A SUN distribui o Java 2 Platform Entreprise Edition (J2EE) que integra o RMI e o IIOP tornando mais simples a interoperação de sistemas entre sistemas Java e CORBA. O Simple Object Acess Protocol SOAP apareceu pela primeira vez. 2001 A IBM e a Microsoft propõem as pilhas de protocolos dos Web Services à W3C (World Wide Web Consortium) Wire stack Description stack Discovery stack

Motivação dos Web Services Resolver todo o tipo de heterogeneidade de dados e informação com XML Mensagens codificadas em texto para passar através das firewalls Protocolo muito simples para garantir a interoperação entre plataformas de múltiplos fabricantes Permitir utilizar RPC ou MOM sistemas de comunicação síncronos e assíncronos Usar de forma directa o HTTP e HTTPS como protocolos de transferência de informação Usar URL e URI como referências remotas para objectos Permitir a transferência de todo o tipo de informação desde estruturas de dados a documentos estruturados e informação multimédia. Eliminar a distinção de sistemas para transferência de documentos e sistemas para transferência de dados Dinâmica do Mercado IBM : o produto principal é o Websphere que inclui o SOAP, WSDL, UDDI Microsoft:.NET suporta directamente Web Services mas é muito mais abrangente incluindo uma nova linguagem de programação o C # Sun: SunOne, o suporte da Sun ao Java faz com que esta plataforma é uma das que incorpora a tecnologia J2EE e dos Web services. BEA: Weblogic evolução da plataforma de J2EE Oracle: Oracle 10i Web Service Broker. Incorpora a maioria dos conceitos de Web Services mas como é natural considera a base de dados como o broker entre os clientes e serviços. BPEL server SAP: Netweaver Application server, EAI, Business service architecture

Modelo dos Web Services Service Registry Find Publish Service Requestor Request Bind /Response Service Provider Arquitectura dos WEB services Um serviço de Directório para registo e pesquisa dos serviços UDDI Um protocolo de pedidoresposta para invocação do serviço SOAP Uma especificação da interface do serviço WSDL Páginas amarelas e directório Interacção Contratos

Web services - Composição Descrição da Localização UDDI BPEL4WS WS-Metadata Exchange Componentes Segurança Comunicação Fiável Transacções Coordenação Descrição do Serviço WSDL WS-Policy Mensagem Descrição da Mensagem MTOM SOAP XSD WS-Addressing XML Transporte HTTP HTTPS SMTP extensible Markup Language - XML Resolver a heterogeneidade na comunicação e nos dados de forma universal

Arquitectura de Integração da Informação Em muitos casos a integração procura resolver o problema da troca de informação com múltiplas representações A solução mais simples para este problema é representar os dados num formato canónico que todos sabiam utilizar Os dados originais de cada sistema têm de ser mapeado no formato canónico mas depois podem ser usados por todos que sigam o formato. Esta é a razão da grande importância do XML extensible Markup Language O XML deriva de uma linguagem muito mais antiga para definição do formato de impressão de documentos o SGML. O SGML já tinha sido a tecnologia de base no desenvolvimento do HTML. Essencialmente o XML permite através de etiquetas (tags) associar a descrição do formato aos dados de um documento. Toda a descrição é textual o que resolve muito dos problemas de portabilidade. O XML é uma proposta do W3C e é percepcionado como o substituto dos formatos anteriores de representação de dados como o EDI

Benefícios do XML Tecnologia não proprietária Independente das plataformas o formato é texto Compatível com o HTTP o XML tem uma sintaxe mais restritiva que o HTML, mas pode ser usado como o HTML pelo que passa pelas firewalls Internacional formato texto que usa UTF-8 ou UTF-16 para representar os caracteres Extensível Novas tags podem ser adicionadas por necessidade de extensão. Para evitar duplicações existem name spaces a que um documento pode ser associado. A interpretação das mensagens depende de tags e não de posição do campo na mensagem Permite a transformação automática dos dados - As transformações são especificadas usando XML Stylesheet Language Transformatiom (XSLT) Auto definida A estrutura de um documento XML tem uma meta-descrição com base Document Type Definition (DTD) ou actualmente com XML schema Ferramentas genéricas ferramentas Open Source em Java e ferramentas já existentes para SGML. Exemplo XML Imprimir Texto <H1> Skateboard Usage Requirements</H1> <P>In order to use the <B>FastGlide</B> skateboard you have to have:</p> <LIST> <ITEM>A strong pair of legs.</item> <ITEM>A reasonably long stretch of smooth road surface.</item> <ITEM>The impulse to impress others.</item> </LIST> <P>If you have all of the above, you can proceed to <LINK HREF= Chapter2.xml >Getting on the Board</LINK>.</P>

XML Exemplo Dados <po id= 43871 submitted= 2001-10-05 > <billto> <company>the Skateboard Warehouse</company> <street>one Warehouse Park</street> <sreet>building 17</street> <city>boston</city> <state>ma</state> <postalcode>01775</postalcode> </billto> <shipto> <company>the Skateboard Warehouse</company> <street>one Warehouse Park</street> <street>building 17</street> <city>boston</city> <state>ma</state> <postalcode>01775</postalcode> </shipto> <order> <item sku= 318-BP quantity= 5 > <description>skateboard backpack; five pockets</description> </item> <item sku= 947 TI quantity= 12 > <description>street - style titanium skateboard.</description> </item> <item sku= 008-PR quantity= 1000 > </item> </order> </po> Tecnologia XML Namespaces Permite a unicidade de nomes e resolver colisões. Os Espaços de nomes são normalmente associados a um domínio de aplicação Um nome torna-se único por associação a um URI Xpath Define um mecanismo de acesso a elementos dentro de um documento XML Xlink Mecanismo para indexar outros documentos semelhantes aos hiperlinks do HTML mas mais robusto XSL XML style sheet- documentos XML que definem transformações de documentos em XML DOM - Document Object Model O DOM define os métodos para aceder a um documento XML. Pressupõe que o documento é carregado em memória e que através de uma API se acede aos diferentes elementos SAX - Simple API for XML O SAX é um parser que invoca funções à medida que encontra elementos no documento

Esquema do Documento A especificação de documentos era inicialmente efectuada em DTD Document Type Definition em 2001 foi proposto o XML Schema que estende as capacidades do DTD mas cuja principal vantagem é ter uma sintaxe XML que o DTD não tinha Um parser usando um DTD ou XML Schema pode verificar se o documento está sintacticamente correcto e se está conforme com um determinado tipo A meta-descrição pode ser incluída no documento, mas a utilização mais interessante é poder aceder-lhe através de um URI partilhando-o entre aplicações Comparação XML schema e DTD DTD era anterior ao XML pelo que não suporta bem alguns aspectos da norma como por exemplo os namespaces O DTD tinha por objectivo descrever documentos legíveis por humanos e não documentos para representar dados, por conseguinte faltam-lhe alguns construções para exprimir diversas restrições simples, como por ex.: idade só pode ter um valor não negativo entre 0 e 150 A sintaxe do DTD não é a do XML o que torna mais complexas as ferramentas

XML Schema Define Elementos obrigatórios e proibidos Estrutura hierárquica dos elementos Atributos necessários ou opcionais dos elementos e gama de valores permitidos Referências de parte de um documento a outros elementos do documento Exemplo de uma estrutura de dados em XML <?xml version= 1.0 encoding = UTF-8?> <employeelist> <employee type= contract > <employee_id>75868</employee_id> <name> <first_name>john</first_name> <last_name>doe</last_name> </name> <extn>27304</extn> <dept>1104332089</dept> <email>john.doe@flute.com</email> </employee> /employeelist> employeelist

DTD Simples para o documento employeelist <!DOCTYPE employeelist [ <!ELEMENT employeelist (employee*)> <!ELEMENT employee (employee_id, name, extn, dept, email)> <!ATTLIST emplyee type (perm contract) #REQUIRED> <!ELEMENT employee_id (#PCDATA)> Element emplyeelist consists of zero or more employee elements. NOTE: * = zero or more,? = zero or one, + = one or more Element employee contains elements employee_id, name, dept, and email. Attribute type for element employee is required and must have either of these two values: contract or perm. <!ELEMENT NAME (first_name, last_name)> <!ELEMENT first_name (#PCDATA)> <!ELEMENT last_name (#PCDATA)> <!ELEMENT extn (#PCDATA)> <!ELEMENT dept (#PCDATA)> <!ELEMENT email (#PCDATA)> ]> Element dept. maycontainanyparsablecharacterdata (PCData). XML Schema para o documento employeelist </xml version= 1.0 encoding= UTF-8?> <xsd:schema xmlns:xsd= http://www.w3.org/2001/xmlschema targetnamespace= http://www.flute.com xmlns= http://www.flute.com > <xsd:element name= employeelist > <xsd:complextype> <xsd:sequence> <xsd:element ref= employee minoccurs= 1 maxoccurs= unbounded /> <xsd:seuqence> </xsd:complextype> </xsd:element> <xsd:element name= employee <xsd:complextype> <xsd:sequence> <xsd:element ref= employee_id minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= name minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= extn minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= dept minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= email minoccurs= 1 maxoccurs= 1 /> </xsd:sequence> <xsd:attributegroup ref= employeeattribute /> </xsd:comlextype> </xsd:element> <xsd:element name= name <xsd:complextype> <xsd:sequence> <xsd:element ref= first_name minoccurs= 1 maxoccurs= 1 /> <xsd:element ref= last_name minoccurs= 1 maxoccurs= 1 /> <xsd:sequence> </xsd:complextype> </xsd:element> Namespace declaration <!ELEMENT employeelist (employee*)> <!ELEMENT employee (employee_id, name, extn, dept, email)> <!ELEMENT name (first_name, last_name)>

<xsd:element name= employee_id > <xsd:simpletype> <xsd:restriction base= xsd:int > <xsd:minlnclusive value= 1 /> <xsd:maxlnclusive value= 100000 /> <xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name= first_name type= xsd:string /> <xsd:element name= last_name type= xsd:string /> <xsd:element name= email type= xsd:string /> <xsd:element name= dept > <xsd:simpletype> <xsd:restriction base= xsd:string> employee:_id must be an integer between 1 and 100,000. <!ELEMENT first_name (PCDATA)> <!ELEMENT email (PCDATA) Department must be specified in the form: 999-999-9999. <xsd:pattern value= [0-9]{3}-[0-9]{3}-[0-9]{4} /> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name= extn > <xsd:simpletype> <xsd:restrition base= xsd:string > <xsd:pattern value= [0-9]{5} /> </xsd:restrition> </xsd:simpletype> </xsd:element> <xsd:attributegroup name0 employeeattribute > <xsd:attribute name= type use= required > <xsd:simpletype> <xsd:restriction base= xsd:string > <xsd:enumerator value= contract /> Extension must be specified in the form 99999 (String consisting of five digits). <!ATTLIST employee type (permicontract) #REQUIRED> Utilização do XML São necessários três elementos: XML Schema (document type definition) XML parser (implementando a interface DOM) Aplicação para processar o documento XML Schema XML document XML Parser DOM Application Output

Simple Object Access Protocol SOAP Simple Object Access Protocol - SOAP Objectivo Ubiquitous XML distributed computing infrastructure Características Protocolo de comunicação distribuído permitindo o envio de qualquer tipo de informação entre aplicações Define o protocolo de pedido resposta estrutura das mensagens e da interacção entre cliente e servidor O protocolo de representação de dados baseado em XML. Referências remotas baseadas em URI Protocolo extensível permitindo a incorporação de várias facetas : segurança, tolerância a faltas, através de headers associados às mensagens

Wire stack Visão dos Web Services SOAP Headers Envelope Extensions SOAP XML and SOAP HTTP(S), SMTP, FTP, sockets. XML Messaging Data Encoding Network Protocol Security Manageability Quality of Service SOAP No SOAP toda a informação está incluída dentro de uma mensagem o envelope do SOAP. A mensagem tem um ou mais cabeçalhos (headers) e um corpo (body). Extensões às mensagens são os SOAP headers A heterogeneidade é tratada pelo XML assim como convenções para representar tipos de dados abstractos ou tipos de dados complexos Uma interacções do tipo pedido - resposta Um mecanismo de ligação entre as mensagens SOAP e o protocolo HTTP, o mais usado na Internet, contudo o SOAP pode utilizar outros protocolos de transporte como SMTP Um mecanismo para tratar as faltas SOAP fault Na base estão os protocolos de comunicação que podem ser usados: HTTP, SMTP, FTP, ou API de comunicação como os sockets A segurança pode aparecer a qualquer nível, por exemplo, utilizar SSL na comunicação ou assinaturas digitais nos headers.

SOAP Simple Object Access Protocol SOAP 1.1 Message Structure SOAP Envelope Header Entries [Header Element] Body Element [Fault Element] Define: Modelo de empacotamento SOAP Envelope Mecanismo de serialização SOAP Encoding Rules Chamada de procedimento remoto SOAP RPC Baseado em XML Pode usar vários transportes: HTTP SMTP... Interacções previstas no SOAP one-way Mensagem simples Client Server request-response RPC Notification callback notification-response Client Client Client Server Server Server

Execução simples em Soap É necessário um URL de destino O nome de uma operação Os parâmetros. Os parâmetros são passados por cópia (in e out) Não existem referências para os objectos remotos criadas automaticamente como em Corba ou Java. Informação contextual, como a informação de segurança Exemplo Servidor que disponibiliza o último preço praticado para um produto Função Remota float GetLastTradePrice(string symbol)

Soap - Pedido POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8 Content-Length: nnnn SOAPAction: "Some-URI <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP- ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP - Resposta HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8 Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Physical (Communication Protocol) Message POST /LookupCentral HTTP/1.1 Host: www.lookupcentralserver.com Content-Type: text/xml; charset= utf-8 Content-Length: nnn SOAPAction: Directory/LookupPerson Out-of-message context (target URI) Out-of-message context (SOAPAction) <SOAP-ENV:Envelope Logical SOAP Message xmlns:soap-env=http://schemas.xmlsoap.org/soap/envelope/ SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ /> <SOAP-ENV:Header> SOAP Headers <a: AuthorizationLevel> xmls:a= some-uri > </a:authorizationlevel> In-message context </SOAP-ENV:Header> <SOAP-ENV:Body> <m:lookupperson xmlns:m= Some-URI > <FirstName>Big<FirstName> <LastName>Boss</LastName> </m:lookupperson> </SOAP-ENV:body> SOAP Body </SOAP-ENV:Envelope> SOAPEnvelope +addheader(header:soapheader):void +addbodyelement(element:soapbodyelement):void +getheaderbyname(namespace:string, localpart:string):soapheader message Type:String encodingstyleuri:string bodyelements:vector headers:vector MessageElement +getvalueastype(type:qname):object +output(context:serializationcontext):void Name:String Prefix:String namespaceuri:string Type:QName Parent:MessageElement Element:SOAPEnvelope SOAPHeader +SOAPHeader(namespace:String, localpart:string +SOAPHeader(elem:Element) mustunderstand:boolean actor:string SOAPBodyElement +SOAPBodyElement(elem:Element) RPCParam RPCElement +RPCParam(name:String, value:object) value:object name:string +RPCElement(namespace:String, methodname:string, args:object[]) +getparam(name:string):rpcparam +addparam(param:rpcparam):void methodname:string params:vector

Binding do SOAP ao protocolo de Transporte O HTTP é um protocolo de pedido-resposta pelo que torna o protocolo de RPC do SOAP muito simples. Para outros protocolos tem de se criar um protocolo de controlo do RPC. O HTTP permite que o servidor não tenha estado A confidencialidade da informação pode ser assegurada pelo HTTP/S Binding do SOAP ao protocolo de Transporte O SOAP é independente do transporte e pode ser usado com a diferentes protocolos. Distinção entre a mensagem SOAP e a mensagem de transporte O contexto pode ser passado dentro na mensagem SOAP ou na mensagem de transporte No caso do HTTP a informação de contexto é passada através do URI e do SOAP action Se o mecanismo de transporte não tiver possibilidade de ter informação de contexto como, por exemplo, usando directamente os sockets as soluções possíveis são: Por convenção o porto x corresponde ao serviço Y Usando os headers do SOAP Usando um protocolo mínimo para transferir as mensagens do SOAP

WSDL - Web Service Definition Language Definição do contrato do Serviço WSDL - Web Service Definition Language A Interface Description Language dos Web Services Define o contrato a que o serviço se obriga Foi submetida para norma ao W3C pela IBM e pela Microsoft em Setembro 2000. A definição permite descrever Qual o serviço Que mensagens devem ser enviadas e qual a sua estrutura Como usar os vários protocolos de transporte Onde o serviço está localizado, mais precisamente para que rede a mensagem deve ser enviada A documento WSDL é um documento XML com todas as vantagens que dai advém de extensibilidade (namespaces, xml schema, etc.)

Service Description stack WSFL/ XLANG WSEL WSDL WSDL XML Schema Service Orchestration Endpoint Description Service Interface Service Implementation XML WSDL Web Services Description Language WSDL 1.1 Document Structure WSDL Document [Types] {Messages} {Port Types} {Bindings} {Services} Descreve: O que o serviço faz Operações Onde está localizado Endpoint Como invocá-lo Existem bindings para: SOAP 1.1 HTTP GET/POST MIME

Definições port Type Descreve a interface abstracta de um Web service. Atenção porque o termo port é aqui usado com um sentido totalmente diferente dos sockets, semelhante a interface de Java message assinatura das operações descrevendo o nome e os parâmetros da operação types colecção de todos os tipos de dados usados na especificação. Estes elementos são reutilizáveis porque definem entidades abstractas porttype <porttype name= PriceCheckPortType > <operation name= checkprice > <input message= pc:pricecheckrequest /> <output message= pc:pricecheckresponse /> </operation> <porttype> Descreve o que o Web service faz As mensagens permitem saber a assinatura dos métodos Normalmente um documento WSDL contem apenas um port type por razões de reutilização

Mensagens <! - - Message definitions - -> <! - - A PriceCheckRequest is simply an item code (sku) - -> <message name= PriceCheckRequest > <part name= sku type= xsd:string /> </message> <! - - A PriceCheckResponse consists of an availability structure, - - > <! - - defined above. <message name= PriceCheckResponse > <part name= result type= avail:availabilitytype /> </message> As mensagens podem ser de input, output ou assinalar faltas podem ser usadas nas diferentes operações Tipos de dados <types> <xsd:schema targetnamespace=http://www.skatestown.com/ns/availability xmlns:xsd=http://www.w3.org/2001/xmlschema> <xsd:complextype name= availabilitytype > <wsd:sequence> <xsd:element name= sku type= xsd:string /> <xsd:element name= price type= xsd:double /> </xsd:sequence> </xsd:complextype> </xsd:schema> </types> Tipos utilizados no documento WSDL Os tipos são declarados num XML schema

binding A função do binding é tornar concreto o serviço definindo a forma como funciona Exemplos: SOAP; HTTP; SMTP Semântica da invocação Request response; one-way; solicit response; notification Protocolo de transporte Valor do Soap action Formatação da mensagem Um porttype pode ter um mais bindings associados, mas cada documento WSDL normalmente só tem um. binding <binding name= PriceCheckSOAPBinding type= pc:pricecheckporttype > <soap:binding style= rpc transport=http://schemas.xmlsoap.org/soap/http/> <operation name= checkprice > <soap:operation soapaction= /> <input> <soap:body use= encoded namespace= http://www.skatestown.com/services/pricecheck encodingstyle= http://schemas.xmlsoap.org./soap/encoding/ /> </input> <output> <soap:body use= encoded namespace= http://www.skatestown.com/services/pricecheck encodingstyle= http://schemas.xmlsoap.org/soap/encoding//> </output> </operation> </binding>

Exemplo de binding para SMTP <!- - Binding definitions - -> <binding name= PriceCheckSMTPBinding type= pc:pricecheckporttype > <soap:binding style= document Transport= http://schemas.xmlsoap.org/soap/smtp /> <operation name= checkprice > <input> <soap:body use= literal /> </ input> <output> <soap:body use= literal /> </ output> </ operation> </ binding> port <! - - Service definition - -> <service name= PriceCheckService > <port name= PriceCheck binding= pc:pricechecksoapbinding > <soap:address location= http://localhost:8080/axis/services/pricecheck/> </port> </service> <! - - Service definition - - > <service name= PriceCheckSMTPService > <port name= PriceCheckSMTP binding= PriceCheckSMTPBinding > <soap:address location= mailto:pricecheck@skstestown.com /> </ port> </ service> Define o endereço da rede da rede onde o Web service é disponibilizado. Se existissem vários bindings podiam ser definidos vários ports por exemplo para http ou o endereço de email para SMTP

WSDL information model part type abstract interface porttype (abstract) message (abstract) operation (concrete) message (concrete) message concrete implementation binding Made concrete by service concrete endpoint port Contains zero or more WSDL exemplo (I) <?xml version= 1.0?> <definitions name= PriceCheck targetnamespace=http://www.skatestown.com/services/pricecheck xmlns:pc=http://www.skatestown.com/services/pricecheck xmlns:avail=http://www.skatestown.com/ns/availability xmlns:xsd=http://www.w3.org/2001/xmlschema xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ xmlns= http://schemas.xmlsoap.org/wsdl/ > <! - - Type definitions - -> <types> <xsd:schema targetnamespace=http://www.skatestown.com/ns/availability xmlns:xsd=http://www.w3.org/2001/xmlschema> <xsd:complextype name= availabilitytype > <wsd:sequence> <xsd:element name= sku type= xsd:string /> <xsd:element name= price type= xsd:double /> </xsd:sequence> </xsd:complextype> </xsd:schema> </types>

WSDL exemplo (II) <! - - Message definitions - -> <! - - A PriceCheckRequest is simply an item code (sku) - -> <message name= PriceCheckRequest > <part name= sku type= xsd:string /> </message> <! - - A PriceCheckResponse consists of an availability structure, - - > <! - - defined above. <message name= PriceCheckResponse > <part name= result type= avail:availabilitytype /> </message> <!- - Port type definitions - -> <porttype name= PriceCheckPortType > <operation name= checkprice > <input message= pc:pricecheckrequest /> <output message= pc:pricecheckresponse /> </operation> <porttype> WSDL exemplo (III) <binding name= PriceCheckSOAPBinding type= pc:pricecheckporttype > <soap:binding style= rpc transport=http://schemas.xmlsoap.org/soap/http/> <operation name= checkprice > <soap:operation soapaction= /> <input> <soap:body use= encoded namespace= http://www.skatestown.com/services/pricecheck encodingstyle= http://schemas.xmlsoap.org./soap/encoding/ /> </input> <output> <soap:body use= encoded namespace= http://www.skatestown.com/services/pricecheck encodingstyle= http://schemas.xmlsoap.org/soap/encoding//> </output> </operation> </binding> <! - - Service definition - -> <service name= PriceCheckService > <port name= PriceCheck binding= pc:pricechecksoapbinding > <soap:address location= http://localhost:8080/axis/services/pricecheck/> </port> </service> </definitions>

UDDI- Discovery stack UDDI Directory ADS/DISCO Inspection Modelo dos Web Services Service Registry Find Publish Service Requestor Bind Service Provider

Discovery Stack Protocolo de ligação ou binding entre o cliente e o servidor. Os fornecedores dos serviços publicam a respectiva interface O protocolo de inspecção permite verificar se uma dado serviço existe baseado na sua identificação O UDDI responde às questões Onde é que o Web service está localizado? Qual o processo de negócio que o serviço disponibiliza O UDDI permite encontrar o serviço baseado na sua definição capability lookup JAX - RPC Integração dos Web Services com o ambiente Java

Stack Tipico de Interacção View Requestor Provider Developer Java API Java API Web service SOAP message SOAP message Wire-level HTTP packet HTTP packet JAX-RPC Java API for XML-based Remote Procedure Call Em JAX-RPC, uma chamada remota de procedimento é efectuada utilizando o protocolo SOAP (que define a estrutura e regras de representação da informação). A API do JAX-RPC esconde a complexidade da utilização de SOAP do programador. No servidor, o programador especifica os procedimentos remotos definindo uma interface em Java e criando uma classe que implemente esta interface. No cliente, o programador cria uma proxy (objecto local que representa o serviço) que é invocado para executar os métodos. Um cliente JAX-RPC pode aceder a Web services definidos noutras plataformas (devido à utilização de HTTP, SOAP e WSDL).

JAX-RPC Passos de Execução JAX-RPC Arquitectura Web Container - Tomcat Service Client Stub WSDL description Service Endpoint Tie JAX-RPC API Client Side JAX-RPC Runtime System WSDL <-> Java Mapping Message Protocol - SOAP Transport Protocol - HTTP Dispatch JAX- RPC API Server Side JAX-RPC Runtime System

Service Endpoint A service endpoint interface declara os métodos que um cliente remoto pode invocar no serviço package soma; import java.rmi.remote; import java.rmi.remoteexception; public interface SomaIF extends Remote { public int soma(int arg1, int arg2) throws RemoteException; } Algumas das regras A interface estende a interface Remote O método tem de lançar a RemoteException ou uma subclasse Os parâmetros de entrada e de retorno tem de ser suportados pelo JAX-RPC Exemplo Exemplo de classe de implementação: package soma; public class SomaImpl implements SomaIF { public int soma(int arg1, int arg2) { return arg1 + arg2; } } A ferramenta wscompile gera classes stub (cliente) e tie (servidor), que interagem com as bibliotecas de run-time. O wscompile gera também o documento da WSDL que descreve o serviço Tem de ser fornecido um ficheiro de configuração

JAX-RPC Descrição Duas componentes Server-side Gerar o WSDL, ties Instalar (deploy) num Web Container Client-side Gerar os stubs, compilar e executar a aplicação A aplicação cliente pode ser: Aplicação linha de comando Aplicação web Adaptação do modelo RPC JAX-RPC Modelo da Arquitectura Stubs Classes java reconstruídas no cliente que medeiam o acesso aos serviços remotos Ties Classes instaladas no servidor que encaminham os pedidos para a implementação do serviço correspondente Message Protocol - SOAP Transport Protocol - HTTP

JAX-RPC Modelo de Programação Cliente JAX-RPC Servidor JAX-RPC public class FlightsClient { public static void main(string[] args) { try { // obter um proxy local para o WS remoto Stub stub = createproxy(); FlightServiceIF teste = (FlightServiceIF) stub; // definir o Endpoint Address (endereço do WS) stub._setproperty( Stub.ENDPOINT_ADDRESS_PROPERTY, "http://localhost:8080/flightservice/flights"); public interface FlightServiceIF extends Remote { public String saygreetings (String clientname) throws RemoteException; } FlightServiceIF.java } // invocar método remoto String resultado = teste.saygreeting("quinas"); System.out.println(resultado); } catch (Exception ex) { // tratamento da excepção } } private static Stub createproxy() { return (Stub) ( new FlightServiceEndpoint_Impl(). getflightserviceifport()) ; } FlightsClient.java public class FlightServiceImpl implements FlightServiceIF { public String saygreeting (String clientname) throws RemoteException { return "TAP greets " + clientname +. ; } } FlightServiceImpl.java Cliente O cliente pode ter um static proxy criado antes da execução (static stub) que é compilado a partir do WSDL pelo wscompile O cliente pode também usar um dynamic proxy uma classe que é criada durante a execução a partir do WSDL

Cliente com um static proxy package soma; import javax.xml.rpc.stub; public class SomaClient { public static void main(string[] args) { try { Stub stub = createproxy(); SomaIF soma = (SomaIF)stub; int res = soma.soma(1, 2); } System.out.println("O resultado e': " + res); } catch (Exception ex) { ex.printstacktrace(); } private static Stub createproxy() { // implementação estática de um proxy return (Stub)(new EndpointSoma_Impl().getSomaIFPort()); } } JAX-RPC Handlers (para funcionalidades avançadas) Os handlers podem ser usados por exemplo para efectuar logging ou cifrar/decifrar os envelopes SOAP que passam na rede Handler Estende a classe javax.xml.rpc.handler.handler Métodos relevantes handlerequest(messagecontext context) handleresponse(messagecontext context) handlefault(messagecontext context) Handler Chain Sequência de handlers executados sobre pedidos e respostas

Handlers Configuração Cliente: wscompile_config.xml <wsdl location=...... <handlerchains> <chain runat= client"> <handler classname= handlerclass"> <property name="prop" value="val"/>... </handler> </chain>... </handlerchains> </wsdl> Servidor: jaxrpc-ri.xml <endpoint name=...... <handlerchains> <chain runat="server"> <handler classname= handlerclass"> <property name="prop" value="val"/>... </handler> </chain>... </handlerchains> </endpoint> Os handlers podem ser usados por exemplo para cifrar/decifrar os envelopes SOAP que passam na rede Para autenticar as mensagens 1) Validação de cartão de crédito Permitir ao portal verificar se o número de cartão de crédito introduzido pelo utilizador deve ser aceite Integrar portal com SCC Web Service Comunicação síncrona resposta imediata

Serviço de Turismo Projecto em Sistemas Empresariais Integrados