Paulo F. Pires Unirio & UFRJ Paulo.pires@uniriotec.br 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& WebSemâ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 serviço Web é uma aplicação de software identificada por uma URI, cujas interfaces e ligações são capazes de serem definidas, descritas e descobertas por artefatos XML e que suporta interações diretas com outras aplicações de software usando mensagens baseadas em XML via protocolos baseados na internet Modelo de Serviços Web Serviços Web DBMS.NET Mensagens XML Mensagens XML J2EE Internet/Intranet CORBA ERP Busca Adapter Registro Publica 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 exemplo: Ordem de Compra Semelhante a Intercâmbio de Dados Eletrônico (EDI) Tipicamente inicia um fluxo de processo Assíncrono 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 Confirmação por Email Recebe Verifica DB 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 Resposta online ao pedido Programas aplicativos ou stored procedures 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. Servidor Web Requisição XML Resposta XML Listener Web Serviço middleware 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 Web serviço XML 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! Compare com a adoção boa, mas ainda limitada do padrão OMA da OMG. Possibilitar (a nível de Internet) ligação dinâmica. 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. Só um conjunto mínimo de padrões tem de ser implementado. Espera-se um nível muito baixo de integração de aplicações. 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 EJB IDL WS Baixo acoplamento Granularidade fina 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 UNIX Existentes/Novas aplicações CLI Windows XP/Novas aplicações
Serviços Web: Evolução da Tecnologia Processo 1 Processo 2 Monolítico Programa Principal Ligação Estática MP Func1Func n Ligação Dinâmica MP Func 1 Func n Chamada de Procedimento Remota (RPC) MP Proxy Mensagem Binária Proxy Func n Serviço Web MP SOAP / XML Func n Framework de Serviços Web
Serviços web Stack Rede Descrição Estrutura de Protocolo para Dados Publicação e Descoberta de Serviços.. Protocolo XML (SOAP) Sintaxe (XML) Descrição de Protocolo Serviçospara (WSDL) Troca de Dados Structure (XML Schema) Descoberta Formato para Descrever serviços Diretório (UDDI) HTTP Sintaxe (XML) Sintaxe (XML) Serviços Web - Tecnologias Básicas Serviços Web WSDL SOAP DBMS.NET Mensagens XML Mensagens XML J2EE Internet/Intranet CORBA ERP Busca Adapter UDDI Publicação Sistemas Back end Agente (Broker) de Integração
Arquitetura Orientada a Serviços Provedor do Serviço Publica Liga Agente de Registro 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 UDDI Consumidor do Web serviço Como nós conversamos?? (WSDL) http://servico.com/?wsdl Descrições de serviço (XML) Deixe-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: one-way, request/response, multicast, etc.. Projetado para comunicação via HTTP Nãorestritoa 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 Um documento simples SOAP XML XML requisitando a cotação de de uma umaaçã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 1 proxy Soap 2 6 XML/HTTP 3 5 listener Soap Serviço Web 4 Aplicação Cliente Componente Vendedor A Vendedor B 1. A Aplicação Cliente faz uma chamada 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 interface getquote { public int intgetlasttradeprice (string Symbol) } Serializador <m:getlasttradeprice xmlns:m= example.com/stockquotes "> "> <symbol>dis</symbol> </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="<soapmsg.xml@example.com> --MIME_boundary content-type: text/xml; charset=utf-8 content-transfer-encoding: 8bit content-id: soapmsg.xml@example.com <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="<soapmsg.xml@example.com> --MIME_boundary content-type: text/xml; charset=utf-8 content-transfer-encoding: 8bit content-id: soapmsg.xml@example.com <SOAP-ENV:Envelope xmlns:soap-env=..."> <SOAP-ENV:Body> <Person> <Picture href= cid:mypict.jpg@example.com /> </Person> </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary content-type: image/jpg content-transfer-encoding: binary content-id: <mypict.jpg@example.com>...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 SOAPElement SOAPFault SOAPBody SOAPHeader SOAPFaultElement * * 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 stubs JAX_RPC msg SOAP HTTP Serviço ties JAX_RPC Arquitetura física JAX-RPC Serviço Cliente Stub Container Terminação do Serviço 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 import javax.xml.namespace.qname; javax.xml.namespace.qname; public public class class CalcClient CalcClient { { public public static 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 Integer ret ret = = (Integer) (Integer) call.invoke( 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/ tcpmon (porta 8100) http://localhost:8080/ Cliente 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 Operation Add Remove List
Elementos WSDL por Exemplo ShoppingCartService Termos WSDL Port Type http://myservice.net/soap/cart http://myservice.net/cart HTTP SOAP HTTP POST ShoppingCart Add Remove List Port Operation Binding Service Elementos WSDL por Exemplo AddItemInput AddItemOutput <soap:envelope <soap:envelope > <soap:body> <soap:envelope > > <soap:body> <soap:fault> <soap:body> <soap:fault> <faultcode> <soap:fault> <faultcode> <faultstring> <faultcode> <faultstring> </soap:fault> <faultstring> </soap:fault> <soap:body> </soap:fault> <soap:body> <soap:envelope> <soap:body> <soap:envelope> <soap:envelope> ShoppingCartService HTTP SOAP HTTP POST ShoppingCart Add Remove List Termos WSDL Port Type Operation Port Binding Service Message 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 Envia mensagem para o Serviço e não há resposta Request-response Envia mensagem para o Serviço o qual retorna uma mensagem correlata Solicit-response 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> </binding> Elementos de de Extensão 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 de 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 HTTP http://myserviço.net/soap/cart SOAP HTTP http://myserviço.net/cart XML Remove List Shopping <soap:envelope Add Cart > <soap:body> <soap:fault> Remove <faultcode> List <faultstring> </soap:fault> <soap:body> <soap:envelope> AddItemInput AddItemOutput http://xml.org/shopping/items.xsd 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 name= Calculator > <operation name= add > <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. O nome do método e os argumentos para ele serão conhecidos de antemão. A URL do roteador SOAP e o ID do Serviço podem mudar, 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 Download: xml-axis-rc1-bin.zip http://xml.apache.org/axis Unzip Axis roda como uma Servlet. Distribua o Axis (deploy). 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 axis WEB-INF lib Estrutura de Diretórios : axis-1_0 lib classes web.xml docs samples Teste a Distribuição (Deployment) http://localhost:8080/axis Escolha Validate..
Calculadora - exemplo Calculator: Uma classe Java simples com dois métodos para somar e subtrair dois inteiros. A extensão do nome do arquivo tem de ser.jws (abreviatura de Java Web Service). Distribuição: 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 Para cada porttype Para cada binding Para cada service Classe(s) Java geradas Uma classe java Um holder se este type é usado como um parâmetro de input/out Uma interface java Uma classe stub Uma interface do serviço Uma implementação do Serviço (o locator) Nome Calculator.java CalculatorSOAPBindingStub.java CalculatorService.java CalculatorServiceLocator.java 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 Para cada binding Para todo service Classe(s) Java geradas Uma classe skeleton Uma classe template de implementação Um descritor de deployment Um descritor para Undeployment Nome CalculatorSoapBindingSkeleton.java CalculatorSoapBindingImpl.java deploy.wsdd 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 distribuições mais flexíveis Handlers 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: GET, URL="http://example.com/o1?p1=1&p2=2&p3=3 port2: 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) info básicas de contato sobre empresas permite associação de Ids únicos aos empresários yellow pages (páginas amarelas) 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 negócioserviço businessserviço ServiçoKey Name Description BindingTemplates keyedreference keyedreference tmodelkey keyname tmodelkey keyvalue keyname keyvalue
Exemplo de um Registro businessentity XY1032Ze54T2384wZ2f23100293 Harbour Flowers www.harbourflowersltd.co.au Serving Inner Sydney Harbour for contacts businessservice identifierbag categorybag keyedreference EE123 NAICS 02417 keyedreference DFE-2B DUNS 45231 Referências tmodel, cada uma com um identificador único Peter Smythe 872-6891 4281 King s Blvd, Sydney, NSW PeterSmythe22@hotmail.com negócioserviço businessservice Key 23T701e54683nf Name Online catalog Descrição Website where you can BindingTemplates BindingTemplate 5E2D412E5-44EE- http://www.sydneynet/harbour tmodelinstancedetails tmodelinstanceinfo 4453D6FC-223C-3ED0 http://www.sydneynet.com.catalog.asp 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 Peer nodes (websites) 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 APIs SOAP suportados other UDDI.org por todos os nós businessentity UDDI SOAP Request UDDI SOAP Response replicação outro SAP Microsoft Nó do Operator
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 Nó UDDI HTTP Server SOAP Processor UDDI Serviço de Diretório registros de Create, View, Update, e Delete 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 save_business save_service save_binding save_tmodel Deleta coisas 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. ibm. com/ services/ uddi/ Registro da Microsoft : 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, acoplamento, quantidade de de detalhes de de implementação, e níveis de de abstração a nível de de componente são inapropriados para os osserviços 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 Semântica É sobre tornar links entre informações mais inteligentes. Web 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 Semântica Deriva as peças do quebra-cabeças a partir da grande figura Web 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 Semântica Fornece um modelo de dados formal para os Serviços Web Web Transacional Fornece a foundação tecnológica para a Web Semântica