Paulo F. Pires Unirio & UFRJ [email protected] http://www.uniriotec.br/~pires Agenda O que são Serviços Web? Serviços Web X Tecnologias de Componentes Tecnologias de Serviços Web: SOAP WSDL UDDI Exemplos Java Projetando Serviços Web Serviços Web & Web Semântica Aplicando Tecnologia de Serviços Web O que são Serviços Web? A Web de hoje Web planejada para aplicações voltadas para interação com o homem Serviu muito bem a seu propósito: Compartilhamento de informação: uma biblioteca de conteúdo distribuído. Possibilitou e-commerce B2C. Interações B2B não automatizadas. Interações Automatizadas? Se você quisesse fazer uma aplicação para processar uma página, você poderia, mas teria de fazer uma varredura (scraping) do HTML. O que é um Serviço Web? “…A Web pode crescer significativamente em poder e escopo se ela for estendida para apoiar a comunicação entre aplicações, de um programa para outro." -- Fonte: W3C XML Protocol Working Group Charter O que é um Serviço Web? Qualquer serviço que é disponibilizado através da web. Qualquer serviço que possibilita duas aplicações de computador trocarem dados. Principalmente, mas não exclusivamente baseado em: XML para codificação de dados HTTP para transporte de dados Um documento XML transmitido remotamente e mapeado para um programa executável. Definição(ões) W3C Serviços web Arch WG: “Um “Um serviço serviço Web Web éé uma uma aplicação aplicação de de software software identificada por uma URI, cujas interfaces identificada por uma URI, cujas interfaces ee ligações ligações são são capazes capazes de de serem serem definidas, definidas, descritas descritas ee descobertas descobertas por por artefatos artefatos XML XML ee que que suporta suporta interações diretas com outras aplicações interações diretas com outras aplicações de de software usando mensagens baseadas em XML software usando mensagens baseadas em XML via via protocolos baseados na internet” protocolos baseados na internet” Modelo de Serviços Web Serviços Web DBMS .NET Mensagens XML J2EE Mensagens XML Internet/Intranet CORBA ERP Bu s Adapter ca P Registro lica ub Sistemas de Backend Agente (Broker) de Integração Principais tipos de Serviços Web Orientados a Documento Envia dados formatados como um documento de negócio Semelhante a Intercâmbio de Dados Eletrônico (EDI) Tipicamente inicia um fluxo de processo Assíncrono exemplo: Ordem de Compra Orientados a chamadas de procedimento remotas Remote procedure call (RPC) Envia dados formatados como argumentos para uma procedure ou invocação de objeto Semelhante a CORBA, COM, ou EJB Retorna um resultado diretamente Síncrono Serviços Web orientados a Documento Ordem de Compra de Produto Interface do Serviço Web Recebe Confirmação por Email DB Verifica Prepara Recibo Envia Fluxo de processo de negócio Serviços Web orientados a RPC Interface do Serviço Web Requisição online de pedido Programas aplicativos ou stored procedures Resposta online ao pedido Banco de Dados Perspectiva da Arquitetura Um Serviço Web é essencialmente um padrão (pattern) do tipo facade, ou wrapper para acessar componentes de middleware não padronizados. Resposta XML Web Serviço middleware Requisição XML Listener Servidor Web Serviço de Negócio Exemplo: Validação de Cartão de Crédito Browser Empresa example.com “Valide o Cartão de Crédito : 33333333” XML Web serviço Cartão de Crédito “Cartão de Crédito: OK” Esta funcionalidade já existe. Todavia, o objetivo dos Serviços Web É padronizar o processo, possibilitando funcionalidade “plug and play” Integração P2P - Problemas Projetando Serviços Web Objetivos Possibilitar interoperabilidade universal. Larga adoção, ubiqüa: rápida! Possibilitar (a nível de Internet) ligação dinâmica. Compare com a adoção boa, mas ainda limitada do padrão OMA da OMG. Apoio de uma arquitetura orientada a serviços (SOA). Apoia eficientemente ambientes abertos (Web) e outros mais restritos. Diminui a “dor” da incompatibilidade (linguagens, sistemas operacionais, & protocolos de rede) Serviços Web são um esforço para construir uma plataforma de computação distribuída para a Web Projetando Serviços Web Requisitos Baseado em padrões. Suporte pervasivo é crítico. Assume-se uma quantidade mínima de infraestrutura necessária. Espera-se um nível muito baixo de integração de aplicações. Só um conjunto mínimo de padrões tem de ser implementado. Mas pode ser aumentado de forma flexível. Foco em mensagens e documentos, não em APIs. Por que Serviços Web? Dois fatores chave ubiqüidade facilidade de uso Interoperável Neutro em relação a SO e linguagem integração Java & .NET : simples e barata Todo mundo dá suporte ou irá dar a Serviços Web Necessário dar suporte a Serviços Web para facilitar integração Não-invasivos Baseados em protocols ubiqüos : HTTP/SMTP Complementam tecnologias já existentes Estatísticas (Cristal Ball) - USA Gartner estima que o mercado de software de Serviços Web seja $1.7 bilhões em 2003 Evans Data estima que 63% de todos os desenvolvedores estarão trabalhando em projetos de serviços Web pelo final de 2003 37% já estão trabalhando em projetos de serviços Web Butler Group diz que mais de 76% de CIOs acreditam que Serviços Web são altamente significantes para o modo como eles elaboram serviços de TI. Jupiter Media Matrix recentemente descobriu que 60% dos CEOs planejavam usar Serviços Web em 2002 Uma pesquisa recente da InfoWorld mostrou que 28% das empresas estão agora usando Serviços Web outros 23% estão planejando introduzi-los este ano. Tecnologia de Integração & SW CORBA, EJB, e COM resolvem muitos problemas de integração Porém… Cada tecnologia erroneamente assume que ela é ubiqüa O suporte da Indústria para cada padrão de componente é fragmentado Desenvolvimento Complexo Resultado: “Ilhas de interoperabilidade” EDI - Electronic Data Interchange? Proprietárias Solução complexas e caras Problema de integração É difícil integrar Diferenças no Modelo de Objetos Diferenças nos protocolos de Comunicação Diferenças nos sistemas de Tipo (type system) Diferenças no tratamento de exceções: especialmente exceções de runtime vs. aplicação Exemplo: chamando de CORBA para EJB requer mapeamento reverso EJB em IDL CORBA IDL resultante não é limpa O Problema de Mapeamento Sempre que uma nova tecnologia (tal como Serviços Web) aparece, alguns tentam mapeála diretamente para as suas tecnologias já existentes Isto na verdade nunca funciona integração parcial: Mapeamento COM-CORBA e mapeamento reverso Javapara-IDL Mas diferenças de impedância entre os sistemas causam dor e não permitem uma completa interação de trabalho. Granularidade, Acoplamento & Abstração Alta Abstração Alto acoplamento Baixa Abstração POO Granularidade fina EJB IDL WS Baixo acoplamento Granularidade grossa Serviços Web em Todo Lugar? Algumas vezes o entusiasmo é um pouco demais… Serviços Web são complementares a tecnologias tais como J2EE, CORBA, etc. Eles não as substituem! Else nos dão um “mínimo denominador comum” Web-amigável para integração de sistemas definitivamente a maneira mais simples de integrar .NET, CORBA, J2EE, etc. Oferta de Serviços Web Uma nova (& necessária) camada de abstração Serviços Web J2EE / CORBA / .NET Framework Java CLI UNIX Existentes/Novas aplicações Windows XP/Novas aplicações Serviços Web: Evolução da Tecnologia Processo 1 Monolítico Programa Principal Ligação Estática MP Ligação Dinâmica MP Chamada de Procedimento Remota (RPC) MP Serviço Web Processo 2 MP Func1Func n Func 1 Func n Proxy Mensagem Binária Proxy SOAP / XML Func n Func n Framework de Serviços Web Serviços web Stack Descrição Rede de Protocolo para Estrutura Publicação e Descoberta Dados de Serviços. Serviços. . Descoberta Formato para Descrever serviços Protocolo XML (SOAP) Descrição de Serviçospara Protocolo (WSDL) Diretório (UDDI) Sintaxe (XML) Structure (XML Schema) HTTP Sintaxe (XML) Sintaxe (XML) Troca de Dados Serviços Web - Tecnologias Básicas Serviços Web WSDL DBMS SOAP .NET Mensagens XML J2EE Mensagens XML Internet/Intranet CORBA ERP Bu s Adapter ca Pu UDDI ã aç blic Agente (Broker) de Integração o Sistemas Back end Arquitetura Orientada a Serviços Agente de Registro do Serviço a Lig Pu bli c a Provedor do Serviço Busca Usuário do Serviço Protocolos de Serviços Web Encontre um serviço http://www.uddi.org HTML com ponteiro para WSDL Consumidor do Web serviço UDDI Como nós conversamos? conversamos? (WSDL) http://servico.com/?WSDL Descrições de serviço (XML) DeixeDeixe-me falar com você (SOAP) http://servico.com/svc1 Resposta do serviço (XML) serviço Web Soap Comunicação Motivação Muitas aplicações distribuídas se comunicam usando chamadas de procedimento remotas (RPC) entre objetos distribuídos como DCOM e CORBA. HTTP não é projetado para aqueles objetos, então as chamadas RPC não são facilmente adaptadas para a Internet. Problemas de segurança existem para métodos do RPC, então a maioria dos firewalls e servidores proxy são configurados para bloquear este tráfego. HTTP é suportado por todos os browsers e servidores da Internet, então SOAP se apresenta como um ótimo protocolo para fazer RPC. SOAP - Objetivo The objetivo atrás do trabalho SOAP/ XMLP é criar um protocolo que é neutro para qualquer coisa exceto a representação de dados XML: Transporte Linguagem de Programação Modelo de Objetos Sistema Operacional Etc. SOAP - Características Protocolo de comunicação leve Suporta diferentes modelos: Projetado para comunicação via HTTP one-way, request/response, multicast, etc.. Não restrito a Não é amarrado a nenhuma tecnologia de componentes Não é amarrado a nenhuma linguagem de programação Baseado em XML Simples e extensível SOAP - Modelo de Troca de Mensagens Fundamentalmente one-way Pode ser combinado para contemplar padrões tais como request/response Mensagens podem ser direcionadas ao longo de um caminho de mensagem. Mensagem SOAP – Estrutura Geral Envelope (Envelope): Define o conteúdo da mensagem OBRIGATÓRIO estar associada com o namespace do envelope SOAP : http://www.w3.org/2001/06/soap-envelope Cabeçalho (Header) (é opcional): contém informação de cabeçalho informação específica da aplicação sobre a mensagem SOAP. Corpo (Body): contém informação da chamada e da resposta Isto é o básico…exemplo Um Umdocumento documentosimples simplesSOAP SOAPXML XMLrequisitando requisitandoaacotação cotação de uma ação. de uma ação. <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=“example.com/StockQuotes"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP 3 2 proxy Soap 1 6 XML/HTTP 5 listener Soap Serviço Web Aplicação Cliente 4 Componente Vendedor A 1. A Aplicação Cliente faz uma chamada Vendedor B 2. O Proxy intercepta a chamada, constrói e transmite a mensagem de requisição XML 3. O listener Soap recebe, analisa gramaticalmente e valida a requisição 4. O Listener chama a mensagem do componente 5. O Listener pega o resultado da chamada, constrói e transmite a msg. XML de resposta 6. O Proxy recebe, analisa gramaticalmente a resposta, e retorna o resultado ao cliente Este processo é transparente para o cliente e o componente Convenções SOAP RPC informação necessária para a chamada de um método: A URI do objeto destino (namespace) exemplo: <SOAP-ENV:Body> <p:getLastTradePrice xmlns:p=“http://example.com/StockQuotes”> <Symbol>AMZN</Symbol> </p:getLastTradePrice > </SOAP-ENV:Body> Convenções SOAP RPC informação necessária para a chamada de um método : A URI do objeto destino Um nome de método exemplo: <SOAP-ENV:Body> <p:getLastTradePrice xmlns:p=“http://example.com/StockQuotes”> <Symbol>AMZN</Symbol> </p:getLastTradePrice> </SOAP-ENV:Body> Convenções SOAP RPC informação necessária para a chamada de um método : A URI do objeto destino Um nome de método Os parâmetros do método exemplo: <SOAP-ENV:Body> <p:getLastTradePrice xmlns:p=“http://example.com/StockQuotes”> <Symbol>AMZN</Symbol> </p:getLastTradePrice> </SOAP-ENV:Body> Convenções SOAP RPC informação necessária para a chamada de um método : A URI do objeto destino Um nome de método Os parâmetros do método Dados de cabeçalho opcionais exemplo: <SOAP-ENV:Body> <p:getLastTradePrice xmlns:p=“http://example.com/StockQuotes”> <Symbol>AMZN</Symbol> </p:getLastTradePrice> </SOAP-ENV:Body> SOAP HTTP Request - exemplo POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com content-Type: text/xml; charset=“utf-8” content-Length: nnnn SOAPAction: "Some-URI" HTTP Header SOAP Extensions (extensões SOAP) <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>AMZN</symbol> </m:getLastTradePrice> </SOAP-ENV:Body> XML payload </SOAP-ENV:Envelope> SOAP HTTP Response exemplo 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> Serialização public publicinterface interfacegetQuote getQuote {{ public publicint int getLastTradePrice getLastTradePrice (string (stringSymbol) Symbol) }} Serializador <m:getLastTradePrice <m:getLastTradePrice xmlns:m=“example.com/StockQuotes xmlns:m=“example.com/StockQuotes "> "> <symbol>DIS</symbol> <symbol>DIS</symbol> </m:getLastTradePrice> </m:getLastTradePrice> SOAP + Attachments (anexos) Mecanismo para codificar mensagens SOAP em uma estrutura MIME multipart e associá-la com quaisquer partes naquela estrutura Mensagem SOAP Raiz da estrutura Refere-se a attachments usando uri cid:prefix (content ID) SOAP + Attachments - exemplo Comece com uma mensagem SOAP... <SOAP-ENV:Envelope xmlns:SOAP-ENV=“..."> <SOAP-ENV:Body> .. <Person> </Person> .. </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP + Attachments exemplo Adicione um link para uma imagem externa… <SOAP-ENV:Envelope xmlns:SOAP-ENV=“..."> <SOAP-ENV:Body> .. <Person> <Picture href=“http://example.com/myPict.jpg” /> </Person> .. </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP + Attachments - exemplo Adicione dados de empacotamento (packaging) MIME … MIME-Version: 1.0 content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<[email protected]>“ --MIME_boundary content-Type: text/xml; charset=UTF-8 content-Transfer-Encoding: 8bit content-ID: [email protected] <SOAP-ENV:Envelope xmlns:SOAP-ENV=“..."> <SOAP-ENV:Body> .. <Person> <Picture href=“http://example.com/myPict.jpg” /> </Person> .. </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary-- SOAP + Attachments exemplo Adicione uma MIME part e faça o link para ela… MIME-Version: 1.0 content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml; start="<[email protected]>“ --MIME_boundary content-Type: text/xml; charset=UTF-8 content-Transfer-Encoding: 8bit content-ID: [email protected] <SOAP-ENV:Envelope xmlns:SOAP-ENV=“..."> <SOAP-ENV:Body> <Person> <Picture href=“cid:[email protected]” /> </Person> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary content-Type: image/jpg content-Transfer-Encoding: binary content-ID: <[email protected]> ...binary image... --MIME_boundary-- SOAP – Estilo de Documento Empacota xml em um envelope Empacota um documento XML dentro de um envelope soap. exemplo: Ordem de compra. Uma resposta não é mandatória. EDI – Electronic Document Interchange SOAP Java APIs API Java para Serviços Web Baseada em mecanismo remote procedure call (RPC) Chamada método remoto de cliente é convertida para uma msg SOAP e enviada para o Serviço como uma requisição HTTP Serviço recebe a requisição, traduz a msg SOAP para uma chamada de método e o invoca e vice versa com o resultado da chamada do método Detalhes de implementação são invisíveis para o cliente e o Serviço Mensagens SOAP como objetos Java SAAJ (API SOAP com Attachments para Java) Modelo de programação Um cliente JAX-RPC pode acessar um Serviço Web que não esteja rodando em plataforma Java Um serviço JAX-RPC pode ser accessado por um cliente não Java Classes SAAJ SOAPPart SOAPMessage AttachmentPart Node SOAPFault SOAPElement SOAPFaultElement SOAPBody SOAPHeader * SOAPBodyElement SOAPHeaderElement * SOAPEnvelope * JAX-RPC Modelos de invocação JAX-RPC cliente interface de invocação dinâmica (DII) Considerando WSDL modelo stub estaticamente definido modelo de invocação proxy dinâmico Aplic. Cliente Serviço stubs ties JAX_RPC JAX_RPC msg SOAP HTTP Arquitetura física JAX-RPC Terminação do Serviço Serviço Cliente Stub Container Dispatch JAX-RPC API Lado Cliente JAX-RPC Runtime System JAX-RPC API Lado Servidor JAX-RPC Runtime System Protocolo (SOAP) Transporte Um Exemplo Simples Escrevendo o Programa Cliente Serviço de Calculadora Usando Interface de Invocação Dinâmica (DII) Calculadora Cliente – usando JAX-RPC import import org.apache.axis.client.Call; org.apache.axis.client.Call; import import org.apache.axis.client.Service; org.apache.axis.client.Service; import javax.xml.namespace.QName; import javax.xml.namespace.QName; public public class class CalcClient CalcClient {{ public static public static void void main(String main(String [] [] args) args) {{ try try {{ String String endpoint endpoint == "http://localhost:8080/axis/Calculator.jws"; "http://localhost:8080/axis/Calculator.jws"; Service Service Service Service == new new Service(); Service(); Call call == (Call) Call call (Call) Service.createCall(); Service.createCall(); call.setTargetEndpointAddress( call.setTargetEndpointAddress( new new java.net.URL(endpoint) java.net.URL(endpoint) ); ); call.setOperationName(new call.setOperationName(new QName("http://localhost:8080/axis/ QName("http://localhost:8080/axis/ Calculator.jws/axis/Calculator.jws", Calculator.jws/axis/Calculator.jws", "add") "add") ); ); Integer ret = (Integer) call.invoke( Integer ret = (Integer) call.invoke( new new Object[] Object[] {{ new new Integer(5), Integer(5), new new Integer(6)} Integer(6)} ); ); }} }} System.out.println("Result System.out.println("Result == "" ++ ret); ret); }} catch catch (Exception (Exception e) e) {{ System.err.println("ERROR! System.err.println("ERROR! :: "" ++ e.toString()); e.toString()); }} Demo SOAP tcpmon org.apache.axis.utils package java org.apache.axis.utils.tcpmon atenção com o classpath… listen port - é a porta para a qual o cliente faz o pedido (tcpmon port) target hostname - servidor rodando o servidor web target port – porta na qual está rodando o servidor web Visualizando msgs SOAP utilitário tcpmon http://localhost:8100/… Cliente tcpmon (porta 8100) http://localhost:8080/… Servidor Web (porta 8080) Analisando Aplic. CalClient Os detalhes do verdadeiro protocolo SOAP foram manipulados pelos objetos Call e Service. O desenvolvedor preocupou-se em: Achar o dado correto para invocar o Serviço, Processar a resposta Analisando Aplic. CalClient Cliente SOAP codificado manualmente: URL,Service ID, nome do método, parâmetros, etc. Automatizar Tarefas? E se nós pudéssemos descobrir essas coisas a tempo de execução? WSDL UDDI WSDL Descrevendo Serviços Web O que é WSDL? Um formato XML para descrever Serviços Web Para o Consumidor: Como usar o Serviço (e.g., “para usar meu carrinho de compras, envie estas mensagens SOAP com HTTP para http://myService.net/cart”) Para o Servidor: Como configurar o Serviço (e.g., “faça meu carrinho de compras disponível usando SOAP com HTTP em http://myService.net/cart”) Para o Registro: Como encontrar o Serviço (e.g., “Ache todos os carrinhos de compras com os quais eu possa me comunicar.”) O que é um Arquivo WSDL? Um arquivo WSDL é um documento XML. A raiz é o elemento <definitions> : define os namespaces que iremos usar. <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/> O que é um Arquivo WSDL? O elemento <definitions> tem até seis diferentes elementos filhos : Types Messages Port types Bindings Ports Services Elementos WSDL por Exemplo Termos WSDL Port Type ShoppingCart Add Remove List Operation Elementos WSDL por Exemplo Termos WSDL ShoppingCartService ShoppingCart http://myService.net/soap/cart HTTP SOAP http://myService.net/cart HTTP POST Add Port Type Operation Port Remove Binding Service List Elementos WSDL por Exemplo Termos WSDL ShoppingCartService AddItemInput ShoppingCart HTTP SOAP AddItemOutput <soap:envelope …> <soap:envelope <soap:envelope…> …> <soap:body> <soap:body> <soap:body> <soap:fault> <soap:fault> <soap:fault> <faultcode>… <faultcode>… <faultcode>… <faultstring> … <faultstring> <faultstring>…… </soap:fault> </soap:fault> </soap:fault> <soap:body> <soap:body> <soap:body> <soap:envelope> <soap:envelope> <soap:envelope> HTTP POST Add Remove Port Type Operation Port Binding Service List Message Fault Fault Faults O que WSDL Descreve? Conceitos Abstratos Port Types (e.g., ShoppingCart) Operations (e.g., add, remove, list) Messages (i.e., inputs, outputs e faults) Data types (i.e., schemas) Ligações Concretas Estilos de codificação de Dados (e.g., SOAP encoding) Protocolos de Transporte (e.g., HTTP, SMTP) Endereços de Rede (e.g., http://myService.net/cart) Como WSDL Descreve Serviços? <definitions name=“ShoppingCartDefinitions” xmlns=“http://schemas/xmlsoap.org/wsdl” targetNamespace= … > <types> … </types> <message name=“AddItemInput”> … </message> <message name=“AddItemOutput”> … </message> <portType name=“ShoppingCart”> … </portType> <binding name=“CartHTTPXMLBinding” type=“tns:ShoppingCart”>… <binding name=“CartSOAPBinding” type=“tns:ShoppingCart”>… <service name=“ShoppingCartService”> <port name=“HTTPXMLCart” binding=“tns:CartHTTPXMLBinding”> … <port name=“SOAPCart” binding=“tns:CartSOAPBinding”> … </service> <import namespace=“…” location=“…”> </definitions> Tipos de Dados (Data Types) Você pode definir datatypes, que são tipicamente baseados em XML Schema: porém, outros type systems são permitidos <types> <schema targetNamespace=“http://myService.net/cart/types” xmlns=“http://www.w3.org/2000/10/XMLSchema”> <complexType name=“item”><all> <element name=“description” type=“xsd:string”/> <element name=“quantity” type=“xsd:integer”/> <element name=“price” type=“xsd:float”/> </all></complexType> </schema> </types> Mensagens Descrevem o fluxo de informação Uma coleção nomeada de message parts Cada part tem um name e um type <message name=“AddItemInput”> <part name=“cart-id” type=“xsd:string”/> <part name=“item” type=“carttypes:item”/> <part name=“image” type=“xsd:base64Binary”/> </message> Port Types Uma coleção nomeada de operações relacionadas Operations: Têm uma assinatura (messages - input, output e fault) podem ser one-way, request-response, notifications ou solicit-response PortType Contém uma ou mais operações abstratas Cada operação referencia uma ou mais mensagens Operations Têm uma assinatura (input, output e fault messages) tipos: One-way Request-response Envia mensagem para o Serviço o qual retorna uma mensagem correlata Solicit-response Envia mensagem para o Serviço e não há resposta O Serviço envia uma mensagem e o requisitante retorna uma mensagem correlata Notification Serviço envia uma mensagem para o requisitante Port Types <portType name=“ShoppingCart”> <operation name=“AddItem”> <input message=“tns:AddItemInput”/> <output message=“tns:ACK”/> <fault name=“BadCartID” message=“tns:BadCartID”/> <fault name=“ServiçoDown” message=“tns:ServiçoDown”/> </operation> <operation name=“RemoveItem”> … </operation> <operation name=“ListItems”> … </operation> </portType> Bindings Bindings descrevem o protocolo usado para acessar um Serviço, bem como os formatos de dado para as mensagens (messages) definidas por um portType específico Um binding é uma associação nomeada de detalhes de protocolo com um port type, suas operações (operations) e suas mensagens (messages) Bindings (ligações): SOAP Binding <binding name=“CartHTTPSOAPBinding” type=“tns:ShoppingCart”> <soap:binding style=“RPC” transport=“http://schemas.xmlsoap.org/soap/http”/> <operation name=“AddItem”> <soap:operation soapAction=“http://myService.net/cart/AddItem”/> <input> <soap:body use=“encoded” namespace=“http://myService.net/cart” encodingStyle=“http://schemas.xmlsoap.org/soap/encoding”/> </input> <output> <soap:body use=“encoded” namespace=“http://myService.net/cart” encodingStyle=“http://schemas.xmlsoap.org/soap/encoding”/> </output> <fault name=“BadCartID”> <soap:body use=“encoded” namespace= … /> </fault> <fault name=“ServiçoDown”> <soap:body use= … /> </fault> </operation> … Elementos Elementos </binding> deExtensão Extensão de Bindings <binding name=“CartHTTPPostBinding” type=“tns:ShoppingCart”> <http:binding verb=“POST”/> <operation name=“AddItem”> <http:operation location=“/AddItem”/> <input> <mime:content type="application/x-www-form-urlencoded”/> </input> <output> <mime:content type="application/x-www-form-urlencoded”/> </output> <fault name=“BadCartID”> <mime:mimeXML/> </fault> <fault name=“ServiceDown”> <mime … /> </fault> </operation> … </binding> Como WSDL Descreve: Bindings <binding name=“CartHTTPPostBinding” type=“tns:ShoppingCart”> <http:binding verb=“POST”/> <operation name=“AddItem”> <http:operation location=“/AddItem”/> <input> <mime:content … /> </input> <output> <mime:content …. /> </output> <fault name=“BadCartID”> <mime …/> </fault> <fault name=“ServiçoDown”> <mime … /> </fault> </operation> … </binding> Elementos Elementos de Extensão de Extensão MIME Binding Mensagens de Input ou output podem ser definidas usando MIME binding MIME binding podem ser combinadas com SOAP binding para definir um Serviço que usa SOAP attachments Use binding do tipo multipart/related O envelope SOAP tem de estar no part raiz Defina outros part usando MIME binding MIME Binding – exemplo <definitions name="AttachmentService-interface" ...> <types> <schema ...> <complexType name="ArrayOfString"> <complexcontent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType“ arrayType="xsd:string[]"/> </restriction> </complexcontent> </complexType> <complexType name="ArrayOfBinary"> <complexcontent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" arrayType="xsd:binary[]"/> </restriction> </complexcontent> </complexType> </schema> </types> ... Interface p/ Serviço c/ Attachment [2] <message name="AttachmentRequest"> <part name="fileList" type="types:ArrayOfString"/> <part name="classFile" type="types:ArrayOfBinary"/> <part name="imageFile" type=”types:ArrayOfBinary"/> </message> <message name= ="AttachmentResponse"> <part name="list" type="xsd:string"/> </message> <portType name="AttachmentService"> <operation name="listAttachments"> <input message="tns:AttachmentRequest"/> <output message="tns:AttachmentResponse"/> </operation> </portType> <binding name="AttachmentBinding" type="tns:AttachmentServiço"> <soap:binding style="rpc" transport="http://.../soap/http"/> <operation name="listAttachments"> <soap:operation soapAction=""/> ... Interface p/ Serviço c/ Attachment [2] <input> <mime:multipartRelated> <mime:part> <soap:body parts="fileList" use="encoded" namespace="http://tempuri.org/attachment-Service" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </mime:part> <mime:part> <mime:content part="classFile" type="application/octet-stream"/> </mime:part> <mime:part> <mime:content part="imageFile" type="image/jpeg"/> </mime:part> </mime:multipartRelated> </input> <output> <soap:body use="encoded“ namespace=“http://tempuri.org/attachment-Service" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> Portas (port) Uma associação nomeada de uma ligação de protocolo (binding) com um endereço de rede <port name=“SOAPCart” binding=“tns:SOAPCartBinding”> <soap:address location=“http://myService.net/soap/cart”/> </port> <port name=“HTTPPostCart” binding=“tns:HTTPPostCartBinding”> <http:address location=“http://myService.net/cart”/> </port> http://myService.net/soap/cart HTTP SOAP http://myService.net/cart HTTP POST Serviços (service) Uma coleção relacionada de portas <service name=“ShoppingCartServiço”> <documentation>A Shopping Cart for the Web</documentation> <port name=“HTTPPostCart” binding=“tns:HTTPPostCartBinding”> <http:address location=“http://myService.net/cart”/> </port> <port name=“SOAPCart” binding=“tns:SOAPCartBinding”> <soap:address location=“http://myService.net/soap/cart”/> </port> </service> WSDL – Camadas de Abstração Types & Messages Operations, Port Types, Ports Bindings Transporte Reutilizando Elementos WSDL <import namespace=“http://webservices.org/cart/cart-type” location=“http://services.org/cart/cart-type.wsdl”/> <binding xmlns:ws=“http://webservices.org/cart/cart-type” name=“CartHTTPXMLBinding” type=“ws:ShoppingCart”> … Shopping Cart Shopping Cart Service Add Remove List http://myServiço.net/soap/cart HTTP SOAP http://myServiço.net/cart HTTP XML AddItemInput http://xml.org/shopping/items.xsd <soap:envelope Cart …> Shopping Add <soap:body> <soap:fault> <faultcode>… <faultstring> … </soap:fault> <soap:body> <soap:envelope> Remove List AddItemOutput http://webservices.org/cart/cart-type.wsdl http://myService.net/cart/cart.wsdl SOAP & WSDL Analisando o Código de CalcClient SOAP e WSDL O código SOAP precisa da URL do roteador (router) SOAP: String endpoint= call.setTargetEndpointAddress (endpoint); WSDL: <service … <port … <soap: address location= /> “http://localhost:8080/axis/Calculator.jws” SOAP e WSDL O código SOAP precisa do (namespace) Serviço: call.setOperationName(new QName(http://localhost:8080/axis..., args[1])) WSDL: <binding … <soap: binding style=“ rpc” … <operation name= “add”> <input> ... <soap: body namespace= “http://localhost:8080/...” SOAP e WSDL O código SOAP precisa do nome do método: call.setOperationName(new QName(http://localhost:8080/axis..., args[1])) WSDL: <binding … <soap: binding style=“ rpc” … <operation name= “add” SOAP e WSDL O código SOAP precisa preencher os argumentos. WSDL <portType <operation name=“add”> name=“ Calculator”> <input message= “intf:addRequest ” /> Isto indica que precisamos usar a mensagem addRequest como input para o método. SOAP e WSDL Agora podemos observar a mensagem addRequest : <message name=" addRequest "> <part name=“val1" type=“xsd:int"/> <part name=“val2" type=“xsd:int"/> </ message> Por isso, precisamos de dois argumentos (val1, val2) do tipo Integer para chamar o Serviço SOAP e WSDL Na prática, o código cliente SOAP é escrito usando uma interface de programação bem conhecida. A URL do roteador SOAP e o ID do Serviço podem mudar, O nome do método e os argumentos para ele serão conhecidos de antemão. O nome do método e os parâmetros provavelmente não. O arquivo WSDL fornece toda a informação necessária para invocar um Serviço Web Automatiza a tarefa de chamada de Serviços web Ferramentas para esconder os detalhes da tecnologia de serviços Web Plataformas de Serviços Web O que é uma Plataforma de Serviços Web? Serializam/de-serializam Tipos de Dados Serializam objetos nativos da linguagem em XML De-serializam XML em objetos nativos da linguagem Publicam uma Terminação de Serviço (Endpoint) Invocam um Handler do Serviço ou Cadeia de Handlers Geram descrições WSDL Geram stubs cliente e servidor a partir do WSDL Implementando SW Java – Apache Axis Apache Axis Uma máquina de processamento SOAP Sistema Cliente JAX-RPC Sistema Servidor JAX-RPC (baseado em Servlet ) Implementação SAAJ Arquitetura flexível e extensível Ferramentas, exemplos, documentação, … Uma ótima ferramenta para aprender (e produzir) sobre Serviços web !! Open-source hospedado pela Apache Software Foundation Conjunto de Funcionalidades do Axis Distribuição (deployment) “Drop-in" de serviços SOAP Suporte para todos os tipos básicos de dados, e um sistema de mapeamento para definir serializadores/deserializadores Provedores para serviços baseados em SOAP RPC e em documentos Generação automática de WSDL a partir dos serviços implementados (deployed) Utilitário WSDL2Java para construir proxies Java e skeletons a partir de documentos WSDL Utilitário Java2WSDL para construir WSDL a partir de classes Java. Transporte HTTP baseado em servlets Axis - arquitetura Instalando o Apache Axis Pré-requisitos J2SE SDK 1.3 or 1.4 Um Servlet Container: i.e. Tomcat4.0.1 Estrutura de Diretórios : Download: xml-axis-rc1-bin.zip http://xml.apache.org/axis axis-1_0 Unzip Distribua o Axis (deploy). Axis roda como uma Servlet. Copie a árvore webapps\axis para o directório webapps do Tomcat. Ou modifique server.xml doTomcat. Rode o Tomcat: bin\startup a partir de Tomcat home. webapps lib docs samples axis WEB-INF lib classes web.xml …… Teste a Distribuição (Deployment) http://localhost:8080/axis Escolha Validate .. Calculadora - exemplo Calculator: A extensão do nome do arquivo tem de ser “.jws” (abreviatura de Java Web Service). Distribuição: Uma classe Java simples com dois métodos para somar e subtrair dois inteiros. Copie o arquivo Calculator.jws para o diretório webapps/axis Examine sua descrição WSDL. http://localhost:8080/axis/Calculator.jws?wsdl public class Calculator { public int add(int val1, int val2){ return val1 + val2; } public int subtract(int val1, int val2) { return val1 - val2; } } Escrevendo o Programa Cliente Modos de escrever um programa Cliente Usando Interface de Invocação Dinâmica ( DII) Usando Stubs gerados a partir da descrição WSDL do Serviço Usando Proxy Dynâmico Configuração do CLASSPATH : xml-axis-beta2/lib/axis.jar xml-axis-beta2/lib/jaxrpc.jar xml-axis-beta2/lib/saaj.jar xml-axis-beta2/lib/commons-logging.jar xml-axis-beta2/lib/tt-bytecode.jar xml-axis-beta2/lib/wsdl4j.jar Um parser JAXP-1.1 compatível com XML como xerces + recursos app CalcClient – Stubs Gerados Gere os stubs: java org.apache.axis.wsdl.WSDL2Java \ http://localhost:8080/axis/Calculator.jws?wsdl cláusula WSDL Para cada entrada na type section Classe(s) Java geradas Nome Uma classe java Um holder se este type é usado como um parâmetro de input/out Para cada portType Uma interface java Calculator.java Para cada binding Uma classe stub CalculatorSOAPBindingStub.java Uma interface do serviço CalculatorService.java Uma implementação do Serviço (o locator) CalculatorServiceLocator.java Para cada service Programa CalcClient–Stubs Gerados import localhost.*; public class CalcClient{ public static void main(String [] args) { try { CalculatorService srv = new CalculatorServiceLocator(); Calculator calc = srv.getCalculator(); System.out.println("addInt(5, 3) = " + calc.addInt(5, 3)); } catch (Exception e) { System.err.println("Execution failed. Exception: " + e); } } } Demo CalcClient – Stubs Gerados Distribuição Customizada Distribuição Instantânea (.jws) é simples, mas tem limitações: Você tem de ter o código fonte Não pode especificar mapeamentos de tipo customizados, handlers etc. Java2WSDL: Construindo WSDL a partir do Java Etapa 1: Forneça uma interface ou classe Java Etapa 2: Crie o WSDL usando Java2WSDL Etapa 3: Crie Bindings Cliente/Servidor usando WSDL2Java Etapa 4: Use adminClient & Deployment Descriptor para distribuir (deploy) o Serviço Etapa 1: Forneça uma interface ou classe Java package calculator; public interface Calculator extends java.rmi.Remote { public int add(int in0, int in1) throws java.rmi.RemoteException; public int subtract(int in0, int in1) throws java.rmi.RemoteException; } Etapa 2 - Java2WSDL – Gerando o arquivo WSDL java org.apache.axis.wsdl.Java2WSDL \ -o calculator.wsdl \ -l “http://localhost:8080/axis/serviços/Calculator” \ -n "urn:Calculator" -p “custom.deploy=urn:Calculator” \ custom.deploy.Calculator Arquivo WSDL “calculator.wsdl” Etapa 3: Crie Bindings Cliente/Servidor usando WSDL2Java Gere as classes: java org.apache.axis.wsdl.WSDL2Java \ --server-side --skeletonDeploy true calculator.wsdl Todas as classes geradas sem a opção “--server-side -skeletonDeploy true” : Cláusula WSDL Classe(s) Java geradas Uma classe skeleton Para cada binding Para todo service Nome CalculatorSoapBindingSkeleton.java Uma classe template de implementação CalculatorSoapBindingImpl.java Um descritor de deployment deploy.wsdd Um descritor para Undeployment Undeploy.wsdd Etapa 4: Forneça a Implementação do Serviço Inclua o código do Serviço na Classe template de Implementação Compile o código fonte O Serviço está pronto para distribuição (deployment) Step 5: Use adminClient & Descritor de Deployment para distribuir o Serviço java org.apache.axis.client.AdminClient deploy.wsdd Não esqueça de iniciar o servidor Web! Copie os arquivos class servidores para TOMCAT_HOME\webapps\axis\ WEB-INF\classes Lista de serviços distribuídos: java org.apache.axis.client.AdminClient list Descritores de Deployment WSDD (Web Services Deployment Descriptors) permitem Handlers distribuições mais flexíveis no caminho do pedido ou resposta Mapeamento customizado de tipos Diferentes transportes – HTTP/S, TCP/IP, DIME Diferentes Dispatchers – Classes Java, EJB, Servlets O Descritor de Deployment <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <!-- serviços do CalculatorServiço WSDL --> <service name="Calculator" provider="java:RPC"> <parameter name="wsdlTargetNamespace" value="urn:custom.deploy"/> <parameter name="wsdlServiceElement" value="CalculatorService"/> <parameter name="wsdlServicePort" value="Calculator"/> <parameter name="className" value="deploy.custom.CalculatorSoapBindingSkeleton"/> <parameter name="wsdlPortType" value="Calculator"/> <parameter name="allowedmethods" value="*"/> </service> </deployment> Funcionalidades Adicionais SOAP com Attachments Mapeamento customizado de tipos (Pluggable Serializers) Chamadas One-way Trocas de Documentos Dispatch para EJBs Transporte HTTPS e autenticação mútua Autenticação baseada em Username e password Demo Calculadora Demo Consumindo um Serviço Web usando Delphi Bindings WSDL HTTP Post & Get HTTP GET & POST Binding WSDL inclui uma binding para os verbos GET e POST do HTTP 1.1 : isto permite que outras aplicações que não Web Browsers interajam com o site. As seguintes informações relativas a protocolo podem ser especificadas: Uma indicação dizendo se a binding usa HTTP GET ou POST Um endereço para a porta Um endereço relativo para cada operação (relativo ao endereço base definido pela porta) HTTP GET/POST - exemplos Considere 2 portas que são ligadas diferentemente para um dado port type. Se os valores sendo passados são part1=1, part2=2, part3=3, o formato da requisição seria o seguinte para cada porta: port1: port2: GET, URL="http://example.com/o1?p1=1&p2=2&p3=3 POST, URL="http://example.com/o1", PAYLOAD="p1=1&p2=2&p3=3" Para cada porta: a resposta é uma imagem GIF ou JPEG. <definitions .... > <message name="m1"> <part name="part1" type="xsd:string"/> <part name="part2" type="xsd:int"/> <part name="part3" type="xsd:string"/> </message> <message name="m2"> <part name="image" type="xsd:binary"/> </message> <portType name="pt1"> <operation name="o1"> <input message="tns:m1"/> <output message="tns:m2"/> </operation> </portType> <service name=“service1"> <port name="port1" binding="tns:b1"> <http:address location="http://example.com/"/> </port> <port name="port2" binding="tns:b2"> <http:address location="http://example.com/"/> </port> </service> ... <binding name="b1" type="pt1"> <http:binding verb="GET"/> <operation name="o1"> <http:operation location="o1"/> <input> <http:urlEncoded/> </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output> </operation> </binding> <binding name="b2" type="pt1"> <http:binding verb="POST"/> <operation name="o1"> <http:operation location="o1"/> <input> <mime:content type="application/x-www-form-urlencoded"/> </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output> </operation> </binding> </definitions> UDDI Descoberta de Serviços web UDDI UDDI = (Universal Description, Discovery and Integration) - de Serviços web Projeto UDDI (www.uddi.org) é um esforço da indústria para definir um registro que permita buscas de serviços iniciado pela IBM, MS e Ariba em Set 2000 Membros do UDDI > 200 Atualmente UDDI V3.0 Planejado tornar-se especificação do W3C na V3.0 UDDI não é restrito a serviços SOAP pode ser usado para: desde páginas web simples e endereços de email, até aps distribuídas completas UDDI White Pages Yellow Pages Green Pages Dados dentro do UDDI são categorizados em 3 tipos white pages (páginas brancas) yellow pages (páginas amarelas) info básicas de contato sobre empresas permite associação de Ids únicos aos empresários info geral de classificação sobre a empresa ou Serviço que ela oferece (e.g. NAICS: códigos de indústria, UNSPC: produtos & Serviços clasf, ISO: geog) green pages (páginas verdes) info técnica sobre um Serviço Web referência a uma especificação externa (e.g. WSDL) endereço para chamada do Serviço Descrições de Serviço Identificador único programável para um dado tipo qualquer de Serviço Web Usado por entidades padrão, ISVs, e desenvolvedores para “publicar” como estes serviços trabalham Usado como uma assinatura por web sites que implementam aquelas interfaces Armazenados no UDDI como “tModels” Registro no UDDI documento XML Criados pela empresa do usuário final (ou em seu nome) Pode ter múltiplas listas de serviço Pode ter múltiplas listas de taxonomia BusinessEntity BusinessKey name URL Description contacts businesSservices identifierBag categoryBag keyedReference keyedReference tModelKey tModelKey keyName keyName keyValue keyValue Contact Contact Phone Phone Address Address Email Email businessServiço negócioServiço ServiçoKey Name Description BindingTemplates keyedReference keyedReference tModelKey tModelKey keyName keyName keyValue keyValue Exemplo de um Registro Peter Smythe 872-6891 4281 King’s Blvd, Sydney, NSW [email protected] businessEntity XY1032Ze54T2384wZ2f23100293 Harbour Flowers www.harbourflowersltd.co.au “Serving Inner Sydney Harbour for … businessService negócioServiço 23T701e54683nf… Key Online catalog Name “Website where you can … Descrição BindingTemplates BindingTemplates contacts businessService identifierBag categoryBag keyedReference keyedReference EE123… NAICS 02417 DFE-2B… DUNS 45231 BindingTemplate 5E2D412E5-44EE-… http://www.sydneynet/harbour… tModelInstanceDetails tModelInstanceInfo 4453D6FC-223C-3ED0… http://www.sydneynet.com.catalog.asp Referências tModel, cada uma com um identificador único Como o UDDI é usado? analistas de negócio : Para procurar por serviços similar a máquinas de busca são necessários portais Desenvolvedores: Para publicar serviços Para escrever software que usa os serviços descobertos incorporados em toolkits: para automatizar a publicação de serviços UDDI Duas partes especificações técnicas para construir um diretório distribuído de negócios & Serviços Web, incluindo XML schema para descrever as estruturas de dados usadas detalhes de API para buscar (find) & publicar (publish) UDDI – Registro de negócios (“cloud services”) implementação operacional completa lançado em Maio 2001 por MS & IBM Operação de Registro businessEntity UDDI SOAP Request Peer nodes (websites) UDDI SOAP Response Empresas se registram em qualquer dos nós IBM Registros das empresas são replicados diariamente Conjunto completo de registros replicação “cadastrados” disponível em todos os nós Conjunto comum de other UDDI.org APIs SOAP suportados replicação por todos os nós SAP Nó do Operator Microsoft outro UBR conteúdo inserido no UBR é feito em um único nó que se torna proprietário mestre do conteúdo conteúdo pode ser acessado de qualquer nó qualquer negócio pode configurar um nó operador empresas podem configurar: nós privados clouds privadas Registros Privados Descoberta Direta Incluem funcionalidades adicionais de segurança Serviços acessíveis apenas de dentro da organização ou de grupos de parceiros confiáveis Geralmente envolvem custo Podem ser usados para operações internas ou B2B Permite que as empresas forneçam serviços personalizados para clientes Empresas estão adotando registros privados mais rápido que os públicos Tipos de Registros Privados e-marketplace UDDI hospedado por uma indústria, lista negócios e serviços de membros do consórcio portal UDDI publica Serviços Web de empresas só busca (find) é disponível externamente partner catalog UDDI reside atrás de um firewall disponível apenas para empresas membro publish e find restritos a usuários autorizados internal UDDI reside atrás de um firewall disponível apenas para uma única empresa Por que usar o UDDI? exemplo: indústria de semi-condutores >400 empresas membros do consórcio RosettaNet que criou Partner Interface Processes (PIPs) PIPs = interfaces baseadas em XML para permitir troca de dados e.g. PIPs PIP2A2 – consulta informação de produto PIP3A2 – consulta preço e disponibilidade de produtos específicos PIP3A3 – submete ordem de compra eletrônica (e-purchase) PIP3B4 – consulta status de envio de mercadoria >80 PIPs individuais registrados no UBR Vantagens do UBR provedor do serviço método efetivo de propaganda visibilidade global Æ expansão de mercado consumidor do serviço simplifica o uso de Serviços Web por tornar disponíveis especificações técnicas geral não é preciso pagar para anunciar ou para descobrir Software do UDDI servidores de aplicação incorporando servidor UDDI BEA WebLogic, IBM WebSphere projeto UDDI é Open source jUDDI (www.juddi.org) implementações UDDI compatíveis com J2EE : Systinet, Cape Clear, HP, Oracle, SAP… Limitações do UDDI Ainda evoluindo Registros Públicos – confiabilidade de dados? não há data da “última-atualização” não há verificações de validade Qualidade-do-Serviço de um Serviço Web? com que freqüência ele pode ser acessado? escalabilidade? suporte técnico? Etc. UDDI e SOAP Entidade de Negócio UDDI Requisição SOAP UDDI Resposta SOAP registros de Create, View, Update, e Delete Nó UDDI HTTP Server SOAP Processor UDDI Serviço de Diretório Diretório B2B independente de implementação Registro WSI (Mensagens SOAP) API de busca (Inquiry) Busca coisas find_business find_service find_binding find_tModel Obtém detalhes sobre coisas get_businessDetail get_serviceDetail get_bindingDetail get_tModelDetail API de Publicação Salva coisas Deleta coisas save_business save_service save_binding save_tModel delete_business delete_service delete_binding delete_tModel Segurança… get_authToken discard_authToken Mapeamento de WSDL para UDDI Mapeamento de WSDL para UDDI (exemplo) Trabalhando com UDDI Encontrando serviços in UDDI serviços são encontrados no UDDI usando-se a API do UDDI serviços são encontrados por nome ou por descrição Binding Uma vez que o requisitante do serviço localizou o serviço, ele invoca o serviço naquela localização Publicando um Serviço Use programa de publicação batch baseado em script UDDI4J API Ou use ferramenta GUI para uso via browser Encontrando Serviços no Registro UDDI Escreva um programa para achar serviços Pode-se usar UDDI4J Ou use uma interface voltada para browsers Obtenha os detalhes do serviço Extraia a overviewURL: a localização do arquivo WSDL Registros Registro da IBM : www. Registro da Microsoft : uddi. ibm. com/ services/ uddi/ microsoft. com/ Registro da SAP: http://uddi.sap.com/ NTT communications: http://www.ntt.com/uddi UDDI4J IBM anunciou o lançamento do UDDI4J: uma implementação open source do lado cliente do UDDI. AXIS, HP, WebSphere Simplifica a tarefa de interagir com um registro UDDI. página web do UDDI4J : www- 124. ibm. com/ developerworks/ projects/uddi4j. Projetando SW Uso de Serviços Web Hoje Abordagem: Exposição direta de componentes como Serviços Web Está Correto? Granularidade, Granularidade, acoplamento, acoplamento, quantidade quantidade de de detalhes detalhes de de implementação, implementação, ee níveis níveis de de abstração abstração aa nível nível de de componente componente são são inapropriados inapropriados para para os os Serviços Serviços Web Web Exportação Direta - Problemas Exportar assume que o componente exportado possa se manter sozinho Só funciona para modelos simples O que acontece se operações retornarem: seqüências de referências, ou estruturas de dados complexas com referências embutidas? Quem faz o mapeamento? Exportação direta um-para-um de componentes para Serviços Web normalmente só funciona para serviços simples Serviços Web - Exemplos Alguns Serviços Web já são acessíveis na Internet e.g., at http://www.xmethods.net/ serviços triviais orientados a RPC, por exemplo: cálculos de taxa de câmbio, cotação de ações Muito baixo-nível e.g., cotador de ações requer polling: não são fornecidos callbacks questões fundamentais ignoradas: e.g latência Coreografia da Aplicação Define as “conversações” entre aplicações cooperativas as quais permitem a elas trabalharem juntas corretamente Coreografias de Serviços Web têm de levar em conta processos de negócio Serviços Web triviais resolvem apenas coisas triviais Serviços web não-triviais devem desempenhar um papel nos processos de negócio Integração business-to-business (B2Bi) requer coreografias padronizadas Coreografias de Serviços Web Coreografias CORBA, EJB, etc. não são diretamente apropriadas para Serviços Web muitos detalhes de implementação ficam transparentes, e.g. exceções, interdependências de componentes Em vez disso, Serviços Web podem integrar multiplas tecnologias de componentes back-end usando máquinas de processo para evitar a necessidade de mais codificação manual Coreografias devem esconder completamente detalhes de implementação a nível de componente Coreografias de Serviços Web (2) Serviços não possuem modelo de objeto Coreografias CORBA, EJB, etc. não podem ser expostas diretamente a clientes de Serviços Web Serviços Web devem encapsular e abstrair a lógica de componentes de negócio existentes Coreografias de Serviços Web exportadas externamente requerem padrões baseados em B2B necessários para assegurar interações corretas e acordadas legalmente Source: Serviços web and Component Tecnologias - Steve Vinoski (IONA) Serviços Web em Múltiplos Níveis Alto Nível Médio Nível Baixo Nível Source: Serviços web and Component Tecnologias - Steve Vinoski (IONA) Serviços Web - Arquitetura de Sistemas Evolução de Serviços Web - BPM Serviços Web e a Web Semântica Serviços Web e a Web Semântica Objetivos Complementares Web É sobre tornar links entre informações mais inteligentes. Web Semântica Transacional (Serviços Web) É sobre melhorar o modo pelo qual a informação é trocada Serviços Web e a Web Semântica Diferentes Pontos de Vista Web Deriva as “peças do quebra-cabeças” a partir da grande figura Web Semântica Transacional Deriva a grande figura a partir das “peças do quebra-cabeças” Serviços Web e a Web Semântica Encontrando-se no meio Web Fornece um modelo de dados formal para os Serviços Web Web Semântica Transacional Fornece a foundação tecnológica para a Web Semântica Comentários Finais Os Serviços Web agregam que valor ao negócio? Valor de negócio dos Serviços Web Menores Riscos de Desenvolvimento Novas fontes de renda Reusabilidade de Sistemas Tempo de Desenv. Reduzido Menores Riscos de Desenvolvimento Serviços Web representam padrões da indústria : protocolos padronizados (HTTP e SMTP) formatos de mensagem padronizados (SOAP and XML-RPC) descrições de serviços padronizadas (WSDL) registros de serviços padronizados (UDDI) O uso de padrões comuns no desenvolvimento reduz os custos e riscos envolvidos porque há menos fatores variáveis Novas Fontes de Renda E-serviços Componentizados Serviços Web representam a próxima etapa na evolução do modelo de negócio Application Service Provider (ASP) Máquinas de cotação de Ações, placar de esportes, taxas de câmbio, taxas/quantias de empréstimos, e aplicações tradicionais de escritório serão todas oferecidas sob forma de subscrição ou pagamento por uso. Serviços Inteligentes Dinâmicos Leilões virtuais em tempo real para tudo: de empréstimos para casa, livros usados, até gasolina Habilidade para procurar pela melhor oferta em tempo real Novas Fontes de Renda Utilização de Dispositivos Móveis Serviços Web abrem a porta para o mundo Wireless por se apoiarem em formatos e protocolos padrões da indústria Devido à pequena utilização de memória, é crucial o uso de formatos e protocolos padrões exemplos: Compre uma coca com seu celular Permita que médicos façam uma pesquisa em tempo real comparando os sintomas de um paciente com diagnósticos conhecidos Acesse seu computador pessoal doméstico, sua conta corrente, e suas reservas de viagem através de um dispositivo handheld Reusabilidade de Sistemas Eficiência Aumentada Mantenha uma biblioteca de componentes intercambiáveis, extensíveis que se comunicam através de formatos padronizados sobre protocolos padronizados “Desenvolva uma vez, Venda em Todo Lugar” Desenvolva uma aplicação ou conjunto de aplicações e faça que eles exponham suas interfaces como Serviços Web, então revenda este pacote para múltiplos clientes Crie uma aplicação que processe reivindicações de seguro para um hospital. Então turn around e revenda esta solução para 10, 20, ou 100 outros hospitais. Uma vez que o sistema é acessado através de interfaces padronizadas, a integração é rápida e fácil Tempo de Mercado Reduzido Se você está desenvolvendo componentes e sistemas com: menores riscos de desenvolvimento bibliotecas de código reutilizáveis sistemas reutilizáveis que podem ser facilmente configurados e acessados por outros sistemas Então o resultado será um ciclo de desenvolvimento mais rápido e uma escala de distribuição (deployment) mais rápida Se você cobrar dos clientes exatamente o mesmo, mas você é capaz de satisfazer as necessidades de 10 vezes mais clientes do que antes então …$$$ Valor de Negócio dos Serviços Web Menores Riscos de Desenvolvimento Novas Fontes de Renda Reusabilidade de Sistemas Tempo de Mercado Reduzido = $$$ Source: Serviços web and Component Tecnologias - Steve Vinoski (IONA) Tecnologias de Serviços web Fases de Utilização dos Serviços Web Projetos Internos : Alcance Externo : integração entre divisões, etc. seleção de parceiros Mercado Externo : consumo sob demanda Sumário O framework de Serviços Web está sendo definido, padronizado e suportado pela indústria em um ritmo recorde. Aceitação ampla da indústria e conformidade com padrões irão fazê-lo ubiqüo. Irá trazer um nível sem precedentes de interoperabilidade para as aplicações Web. Os benefícios dos Serviços Web, todavia, não são limitados à Web! A tecnologia de Serviços Web agrega valor real ao negócio A Pilha de Serviços Web já está crescendo … Alguns produtos dos vendedores Microsoft .NET J2EE: BEA -- WebLogic Studio Cape Clear – CapeConnect, CapeStudio IBM – Alpha works toolkits, DB2 XML Extender, WORF, WebSphere Studio, WebSphere UDDI IONA -- XMLBus, WSIP, ASP Oracle – Oracle9iAS Serviços Web & UDDI Sun – Sun ONE (iPlanet, etc) Systinet – WASP Developer, Server, UDDI, Security Open Source: ASP.NET, .NET Framework, Visual Studio.NET Axis (Apache) Muitos outros vendedores: EAI, ERP, CRM, IDE Recursos Atividade em relação a Serviços web http://www.w3.org/2002/ws/ SOAP W3C Working Drafts - 17 December 2001 http://www.w3.org/2002/ws/#drafts SOAP 1.2 Primer Messaging Framework Adjuncts XML Protocol Drafts WSDL W3C Note Released March 2001 http://www.w3.org/TR/wsdl WSDL Schema - Especificações Base Definition: http://schemas.xmlsoap.org/wsdl/ SOAP Extension: http://schemas.xmlsoap.org/wsdl/soap/ Serviços Web - Grupo de Trabalho sobre Descrição http://www.w3.org/2002/ws/desc/ Recursos UDDI http://www.uddi.org Diretórios de Serviços Web http://www.xmethods.net http://www.salcentral.com Ferramentas Online para Serviços Web http://www.soapclient.com
Download
