ITA - Instituto Tecnológico de Aeronáutica

Apresentação em tema: "ITA - Instituto Tecnológico de Aeronáutica"— Transcrição da apresentação:

1 ITA - Instituto Tecnológico de Aeronáutica
Web Services Semânticos Disciplina: CE 262 – Ontologias e Web Semântica. Prof. Dr. José Maria Parente Grupo: Ferrucio, Rafael e Luiz Eduardo

2 Roteiro da apresentação
Introdução Histórico O que são Web Services? Por que Web Services? Tecnologias envolvidas SOA SOAP XML WSDL UDDI Vídeo-aula “Construção de WS com Eclipse” Aula prática usando Netbeans e .Net Web Semântica Anotações Semânticas em serviços SA-WSDL Vídeo-aula SA-WSDL com WSMO Exemplos WS Produtos disponíveis Links para padrões Considerações finais Referências

3 Histórico Aplicação de duas camadas. Aplicações cliente-servidor.
Busca de escalabilidade e tolerância maior a falhas, criou-se a arquitetura de 3 camadas. Camada de negócios, entre cliente e dados. Primeiros sistemas middleware foram os RPC (Remote Procedure Call), baseados na programação estruturada. Possibilitou execução de uma mesma aplicação em plataformas diferentes. Com POO, foram criados CORBA, DCOM e RMI, cada um com suas vantagens e desvantagens. Mas nenhuma delas se comunica com a outra. Aconselhados para Intranet. Até chegar em Web services.

4 Histórico CORBA Solução aberta de objetos distribuídos.
Desenvolvida pelo consórcio OMG (Object Management Group) para se tornar padrão de mercado. Primeira vantagem é que cliente e servidor podem ser feitos em qualquer linguagem, em função do alto nível de abstração conseguido com o IDL (Interface Definition Language), que possui o mapeamento dos métodos. Comunicação é feita através de ORBs (Object Request Broker), responsáveis pela tradução de solicitação e resposta. Aconselhável para aplicações que necessitam alta performance Principal desvantagem é o alto grau de complexidade na implementação de pequenas soluções.

5 Histórico RMI Remote Method Invocation
Habilita comunicação entre aplicações Java-Java, que usam JVM possivelmente em plataformas diferentes. Aplicação Java armazena apenas as referências dos objetos remotos. Uso do protocolo JRMP (Java Remote Method Protocol) para serializar os objetos. Não usa IDL no desenvolvimento das aplicações cliente Desenvolvimento de aplicações ficou mais simples. Suporte ao Garbage Collection Desvantagens Os dois lados devem ser aplicações Java. Serviços disponíveis em CORBA não são implementados em RMI.

6 Histórico DCOM Distributed Component Object Model
Desenvolvida pela Microsoft para distribuir objetos pela rede. Servidor DCOM publica métodos para clientes escritas em IDL, similar ao C++. Usa protocolo ORPC (Object Remote Procedure Call) que usa o PING para permanecer com os objetos ativos para o cliente. DCOM suporta o GC. Implantado nas empresas Apple, Unix e VMS. Desvantagem – proprietário.

7 O que são Web Services “ Um sistema de software identificado através de uma URI (Identificador Universal de Recursos ) cujas interfaces públicas e interconexões são descritas em XML. Sua definição é publicada de modo a poder ser “descoberta” por outros sistemas de software. Web Services podem interagir com outros sistemas ou Web Services do modo prescrito em sua definição, utilizando mensagens baseadas no padrão XML produzidas através de protocolos de Internet.” Ref: glossários do W3C Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web Services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.

8 O que são Web Services Resumindo, Um Web Service é:
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.

9 O que são Web Services Comunicação entre aplicações de WS usam 4 camadas que empacotam a requisição e a resposta entre o servidor e o cliente. XML – possibilita estabelecer objetos, métodos, parâmetros, dados e tipos de dados SOAP – protocolo que estabele a comunicação entre os ambientes WSDL – descreve o serviço (XML) UDDI – representa service broker. Contém as descrições dos WS.

10 O que são Web Services

11 O que são Web Services

12 O que são Web Services

13 Por que Web Services? Dois fatores chave: Interoperável:
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(impactante): Baseados em protocolos ubiqüos: HTTP/SMTP Complementam tecnologias já existentes

14 Por que Web Services? INTEGRAÇÃO Interna: Externa:
Dados como nome, endereço, telefone, matrícula, etc, todas as áreas da empresa utilizam. Assim, estes dados podem ser disponibilizados (em um formato comum) para que sistemas desenvolvidos por outras áreas possam utilizar em seus aplicativos específicos. Externa: Gestão da cadeia de suprimentos. Esta integração é baseada na interação que existe entre várias empresas durante os diversos processos de fabricação e a logística.

15 O que precisam? Web Services CORBA RMI Comunicação SOAP GIOP JRMP
Descrição WSDL CORBA IDL Java Registro UDDI Serviço de nomes RMI Registry

16 Exemplo de Web Services
envólucro BD Requisição XML sp_1 ... Resposta XML sp_n

17 Exemplo de Web Services

18 Exemplo de Web Services

19 Exemplo de Web Services

20 Tecnologias Envolvidas
XML SOA SOAP WSDL UDDI

21 XML XML (Extensible Markup Language) é uma recomendação da W3C para gerar linguagens de marcação para necessidades especiais.

22 SOA A arquitetura orientada a serviços (SOA) descreve uma categoria de aplicativos compostos formados pelos componentes provedor de serviço e consumidor de serviço. Uma SOA é um modelo de projeto com um conceito profundamente amarrado à questão do encapsulamento de aplicação. A arquitetura resultante estabelece essencialmente um paradigma de projeto, no qual web services são os blocos de construção chave. Serviços fracamente acoplados Vantagens: interoperabilidade, redução de custos e reuso [8] Comunicação entre Serviços [8] Arquitetura de integração orientada a serviço.

23 Consumidor de serviços
SOA? Service Oriented Architecture Novas palavras para um conceito antigo: Arquitetura para aplicações baseadas em serviços (que usam serviços como componentes básicos) Um serviço é a implementação de uma funcionalidade de negócio bem definida; aplicações com arquitetura SOA combinam serviços para oferecer outros serviços A principal forma de implementar SOAs hoje é através de Web Services O motivo? A interoperabilidade! Find-Bind-Execute (Ache, Mapeie, Use) – paradigma central de um SOA Provedor de serviços 4 mapeie Consumidor de serviços 5 use ache 3 1 Registro de serviços publique 2 procure

24 SOA A arquitetura é baseada em três componentes:
UDDI – Universal Description Discovery and Integration WSDL – Web Service Description Language SOAP – Simple Object Application Protocol

25 SOA Importância da arquitetura:
Um estudo de caso na CAIXA ECONÔMICA FEDERAL (CEF) “Nada será como antes na relacão da Caixa Econômica Federal com seus clientes. Agora ao entrar em uma agência para abrir uma conta corrente, apenas um processo colocará a disposição do usuário: número de conta, talão de cheques, acesso ao internet banking, informações de cadastro e uma linha de crédito aprovada. Estas facilidades fazem parte do novo processo de abertura de conta corrente de pessoa física, qe está sendo implantado nas agências do Banco, com base na arquitetura SOA considerada última etapa evolutiva do mercado mundial de software.” [9] O referido sistema está implantado em 2 agências e deverá ser implantado gradativamente nas 2400 agências até o final deste ano.

26 SOA Mercado SOA IBM E SAP ajustam estratégias para SOA [Por COMPUTERWORLD 30 de março de 2007 ] SAP anuncia entrega de sistema com arquitetura SOA. Estudo de Caso

27 Simple Object Access Protocol -SOAP
SOAP - Características Protocolo de comunicação baseado em XML; Iniciado em 1999 pela W3C; Permite que mensagens sejam trocadas entre computadores heterogêneos; Pode passar por firewalls;

28 SOAP SOAP - Objetivo O objetivo atrás do trabalho SOAP é ser um protocolo que é neutro para qualquer coisa: Transporte Linguagem de Programação Sistema Operacional Etc.

29 Dados da mensagem específica
SOAP ESTRTUTURA GERAL Envelope (Envelope): Define o conteúdo da mensagem OBRIGATÓRIO estar associada com o namespace do envelope SOAP: Cabeçalho (Header) (é opcional): contém informação de controle e processamento. Corpo (Body): contém informação da chamada e da resposta MENSAGEM SOAP ENVELOPE SOAP CABEÇALHO SOAP Cabeçalhos CORPO SOAP Dados da mensagem específica Estrutura de uma mensagem SOAP

30 SOAP- Funcionamento SOAP assumes messages have an originator, one or more ultimate receivers, and zero or more intermediaries. The reason is to support distributed message processing. That is, we can go beyond client-server messaging. Recipient Originator Intermediary Intermediary Intermediary Fonte:

31 SOAP O SOAP em ação

32 Exemplo 1- SOAP <?xml version="1.0"?>
<soap:Envelope xmlns:soap=" soap:encodingStyle=" <soap:Body> <m:GetPrice xmlns:m=" <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope> <?xml version="1.0"?> <soap:Envelope xmlns:soap=" soap:encodingStyle=" <soap:Body> <m:GetPriceResponse xmlns:m=" <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>

33 SOAP [1/3] - Travel Reservation
none; ultimateReciver; next.

34 SOAP [2/3] - Resposta da solicitação

35 SOAP [3/3] – Escolha do Aeroporto

36 WSDL O que é um Arquivo WSDL?
Um arquivo WSDL- Web Service Description Language, é descrição de serviço Web através de um documento XML. Criado por Microsoft, IBM, Ariba.

37 WSDL O que WSDL Descreve?
Tipos primitivos e complexos definidos pelo XML SCHEMA Elementos de dados de uma mensagem Nome da operação A interface de um serviço Os elementos de dados de uma operação Definem como a interface é implementada por um fornecedor

38 Informa onde está o serviço (endpoint)
Exemplo: WSDL <?xml version="1.0" encoding="UTF-8"?> <definitions name="BookstoreService" targetNamespace=" xmlns:tns=" xmlns=" xmlns:soap=" xmlns:xsd=" <types>...</types> <message name="BookstoreIF_getPrice"> <part name="String_1" type="xsd:string"/> </message> <message name="BookstoreIF_getPriceResponse"> <part name="result" type="xsd:decimal"/> <portType name="BookstoreIF"> <operation name="getPrice" parameterOrder="String_1"> <input message="tns:BookstoreIF_getPrice"/> <output message="tns:BookstoreIF_getPriceResponse"/> </operation> </portType> <binding ... > ...</binding> <service ... > ... </service> </definitions> Informa onde está o serviço (endpoint)

39 WSDL

40 WSDL Exemplo de Definição de Interface

41 WSDL Exemplo de Implementação de Serviço

42 WSDL Exemplo Completo Cenário : Um web service para reserva de hotel.
Funcionalidade CheckAvailability. To check availability, the client must specify a check-in date, a check-out date, and room type. The Web service will return a room rate (a floating point number in USD$) if such a room is available, or a zero room rate if not. If any input data is invalid, the service should return an error. Thus, the service will accept a checkAvailability message and return a checkAvailabilityResponse or invalidDataFault message

43 WSDL - Element Type

44 WSDL - Interface Element
<interface name = "reservationInterface" > Interfaces are declared directly inside the description element. In this example, we are declaring only one interface, but in general a WSDL 2.0 document may declare more than one interface. Thus, each interface must be given a name that is unique within the set of interfaces defined in this WSDL 2.0 target namespace. Interface names are tokens that must not contain a space or colon (":"). <fault name = "invalidDataFault" The name attribute defines a name for this fault. The name is required so that when an operation is defined, it can reference the desired fault by name. Fault names must be unique within an interface. element = "ghns:invalidDataError"/> The element attribute specifies the schema type of the fault message, as previously defined in the types section. <operation name="opCheckAvailability" The name attribute defines a name for this operation, so that it can be referenced later when bindings are defined. Operation names must also be unique within an interface. (WSDL 2.0 uses separate symbol spaces for operation and fault names, so operation name "foo" is distinct from fault name "foo".) pattern=" This line specifies that this operation will use the in-out pattern as described above. WSDL 2.0 uses URIs to identify message exchange patterns in order to ensure that the identifiers are globally unambiguous, while also permitting future new patterns to be defined by anyone. (However, just because someone defines a new pattern and creates a URI to identify it, that does not mean that other WSDL 2.0 processors will automatically recognize or understand that pattern. As with any other extension, it can only be used among processors that do recognize and understand it.) style=" This line indicates that the XML schema defining the input message of this operation follows a set of rules as specified in IRI Style that ensures the message can be serialized as an IRI. wsdlx:safe="true" > This line indicates that this operation will not obligate the client in any way, i.e., the client can safely invoke this operation without fear that it may be incurring an obligation (such as agreeing to buy something). This is further explained in Interface Operations. <input messageLabel="In" The input element specifies an input message. Even though we have already specified which message exchange pattern the operation will use, a message exchange pattern represents a template for a message sequence, and in theory could consist of multiple input and/or output messages. Thus we must also indicate which potential input message in the pattern this particular input message represents. This is the purpose of the messageLabel attribute. Since the in-out pattern that we've chosen to use only has one input message, it is trivial in this case: we simply fill in the message label "In" that was defined in WSDL 2.0 Predefined Extensions [WSDL 2.0 Adjuncts] section In-Out for the in-out pattern. However, if a new pattern is defined that involve multiple input messages, then the different input messages in the pattern could then be distinguished by using different labels. element="ghns:checkAvailability" /> This specifies the message type for this input message, as defined previously in the types section. <output messageLabel="Out" . . . This is similar to defining an input message. <outfault ref="tns:invalidDataFault" messageLabel="Out"/> This associates an output fault with this operation. Faults are declared a little differently than normal messages. The ref attribute refers to the name of a previously defined fault in this interface -- not a message schema type directly. Since message exchange patterns could in general involve a sequence of several messages, a fault could potentially occur at various points within the message sequence. Because one may wish to associate a different fault with each permitted point in the sequence, the messageLabel is used to indicate the desired point for this particular fault. It does so indirectly by specifying the message that will either trigger this fault or that this fault will replace, depending on the pattern. (Some patterns use a message-triggers-fault rule; others use a fault-replaces-message rule. See WSDL 2.0 Predefined Extensions [WSDL 2.0 Adjuncts] section Message Triggers Fault and section Fault Replaces Message.)

45 WSDL - Binding Element O elemento binding especifica um formato concreto de mensagem e protocolo da interface e deve suportar as mensagens e erros da interface. Como acessar o servico

46 WSDL - Service Element Onde acessar o servico

47 Arquitetura de Web Services: camadas
Camada de transporte (protocolo largamente utilizado) Principais: HTTP (POST), FTP, SMTP Camada de mensagens SOAP Camada dados ou serviços XML (formato de mensagens) XML-RPC Camada de descrição de serviços WSDL Camada de descoberta (registro) UDDI, ebXML Descoberta Descrição Dados Mensagens Transporte

48 UDDI Universal Description Discovery and Integration Especificações
Publicação e Descoberta de serviços Criado por Microsoft, IBM, Ariba Mantido pela OASIS ( “Consórcio que dirige o desenvolvimento, convergência e adoção de e-business patterns” OASIS UDDI Specification Commitee Especificações Esquema para descrição de provedores de serviços API SOAP para publicação e descoberta de serviços Baseado nos padrões da Web XML, HTTP, TCP/IP, SOAP Suporta serviços XML e outros modelos

49 UDDI Como o UDDI é usado? analistas de negócios: Desenvolvedores:
Para procurar por serviços similar a máquinas de busca 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

50 UDDI

51 UDDI Estrutura Páginas Brancas: contêm informações sobre nomes, endereços, números de telefone, além de outras informações sobre os fornecedores do serviço. Páginas Amarelas: contêm listagens comerciais baseadas nos tipos desses negócios, de maneira organizada por categoria específica (indústria, tipo de serviço) ou regiões demográficas. Páginas Verdes: são usadas para indicar os serviços oferecidos por cada negócio, incluindo todas as informações técnicas envolvidas na interação com o serviço. Resumindo, explica como fazer a comunicação com eles. 

52 UDDI Descrições de Serviço
Identificador único programável para um dado tipo qualquer de Serviço Web Usado por entidades padrão 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”

53 UDDI Registros Públicos
conteúdo inserido no UBR (Universal Business Registry) é 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 (nuvens) privadas caiu em desuso: Microsoft, IBM, Outras, cancelaram o registro público alegando (Microsoft) falta de maturidade da tecnologia, entre outros problemas.

54 UDDI

55 UDDI 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 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

56 UDDI Tipos de Registros Privados e-marketplace UDDI portal 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 disponível apenas para empresas membro publish e find restritos a usuários autorizados reside atrás de um firewall internal UDDI disponível apenas para uma única empresa

57 UDDI API de busca (Inquiry) API de Publicação (Publish) 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 (Publish) 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

58 UDDI 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.

59 UDDI Registros Registro da IBM: Registro da Microsoft:
(link quebrado) Registro da Microsoft: (remete para página do Win2003) Registro da SAP: (link quebrado) NTT communications: (link quebrado)

60 UDDI

61 Exemplo de Registro UDDI
Alguns Serviços Web já são acessíveis na Internet e.g., at serviços orientados a RPC, por exemplo: cálculos de taxa de câmbio, cotação de ações

62 Exemplo de Registro UDDI