FACULDADE DOM BOSCO DE PORTO ALEGRE WEB SERVICES GENÉRICOS APLICADOS

Tamanho: px
Começar a partir da página:

Download "FACULDADE DOM BOSCO DE PORTO ALEGRE WEB SERVICES GENÉRICOS APLICADOS"

Transcrição

1 FACULDADE DOM BOSCO DE PORTO ALEGRE CURSO DE SISTEMAS DE INFORMAÇÃO WEB SERVICES GENÉRICOS APLICADOS Ramon Martins da Silva Porto Alegre, julho de 2007.

2 FACULDADE DOM BOSCO DE PORTO ALEGRE CURSO DE SISTEMAS DE INFORMAÇÃO WEB SERVICES GENÉRICOS APLICADOS Ramon Martins da Silva Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso e apresentada ao Curso de Sistemas de Informação da Faculdade Dom Bosco de Porto Alegre, como pré-requisito para a obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Dr. Luis Fernando Fortes Garcia Porto Alegre, julho de 2007.

3 DEDICATÓRIA Dedico este trabalho especialmente a minha família por sua participação fundamental em todas as minhas conquistas.

4 AGRADECIMENTOS Em primeiro lugar agradeço a Deus por iluminar meu caminho e a minha namorada Gabriela por sempre estar ao meu lado. Estendo meus agradecimentos ao orientador Dr. Luis Fernando Fortes Garcia.

5 SUMÁRIO LISTA DE FIGURAS... 7 RESUMO INTRODUÇÃO OBJETIVOS MOTIVAÇÃO REFERENCIAL TEÓRICO EXTENSIBLE MARKUP LANGUAGE (XML) Documentos XML Declaração Comentários Instruções de Processamento Elementos SERVICE ORIENTED ARCHITECTURE (SOA) Sistemas Conectados Princípios da arquitetura baseada a serviços Serviço Componentes Modelagem de sistemas orientados a serviço Vantagens da utilização de SOA WEB SERVICES Arquitetura Simple Object Access Protocol (SOAP) Web Service Description Language (WSDL) Universal Description Discovery and Integration (UDDI) REFLECTION Aspectos Matemáticos da Reflexão Reflexão em Linguagens Orientadas a Objeto Cenário de utilização Meta-Objetos e o processo de Reflexão NET Reflection REMOTING Arquiteturas distribuídas Tecnologias distribuídas Objetos Distribuídos Binding de Objetos Early Binding... 38

6 Late Binding COM Callable Wrapper (CCW) Serialização de Objetos NET Remoting Arquitetura Ativação de Objetos Benefícios das aplicações distribuídas CENÁRIOS MODELO TRADICIONAL DE UTILIZAÇÃO DE WEB SERVICES WEB SERVICE GENÉRICO FUNCIONAMENTO ESTUDO DE CASO VALIDAÇÃO CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 62

7 LISTA DE FIGURAS Figura 1 - Documento XML bem formado Figura 2 - Declaração de um documento XML Figura 3 - Pilares dos sistemas conectados Figura 4 - Modelo da arquitetura orientada a serviços Figura 5 - Modelo de orientação a serviços em três partes Figura 6 - Modelo básico de acesso a um Web Service Figura 7 - Constituição de uma mensagem SOAP Figura 8 - Exemplo de um envelope de requisição RPC Figura 9 - Tráfego de mensagens via XML Figura 10 - Descrição gerada automaticamente pelo WSDL Figura 11 - WSDL Preâmbulo Figura 12 - Biblioteca de Classes do.net Framework Figura 13 - Exemplo de utilização da classe System.Type Figura 14 - Modelo Cliente/Servidor Figura 15 - Modelo N-Tier Figura 16 - Modelo Peer-to-Peer Figura 17 - Seleção de objetos para Automação Figura 18 - Automação de objetos via early-binding Figura 19 - Automação de objeto via late-binding Figura 20 - Chamada um objeto gerenciado (.NET) Figura 21 - Classe que será serializada Figura 22 - Classe que invoca o processo de serialização Figura 23 - Classe que será serializada Figura 24 - Processo de serialização/desserialização Figura 25 - Arquitetura.NET Remoting Figura 26 - Funcionamento do marshal-by-value Figura 27 - Funcionamento do marshal-by-reference Figura 28 - Acesso a tipos de instância context-bound Figura 29 - Modelo Web Services Figura 30 - Modelo Web Services Genéricos... 53

8 Figura 31 - Web Service Genérico - WSDL Figura 32 - Integrando as funcionalidades da Aplicação Web... 57

9 RESUMO Esta monografia apresenta uma proposta de solução de sistemas distribuídos utilizando Web Services Genéricos. O projeto de sua arquitetura foi baseada na análise realizada das principais tecnologias.net (Reflection, Remoting) com objetivo de utilizar as melhores práticas e garantir a confiabilidade desta solução. Seu desenvolvimento foi originado a partir das práticas observadas pela arquitetura orientada a serviços (SOA) e propõe estender este conceito, tornando a utilização dos Web Services mais eficiente na construção de sistemas distribuídos. São apresentados os conceitos envolvidos, exemplos que justificam a utilização desta tecnologia além de vantagens para utilização deste tipo de solução. Palavras-chaves: Web Services; sistemas distribuídos; SOA.

10 10 1 INTRODUÇÃO A informação é, atualmente, o bem que mais demanda investimento em pesquisa devido ao seu alto valor agregado. Além disto, a quantidade de informação gerada por uma instituição é muito grande e, na maioria das vezes, maior do que sua infra-estrutura comporta. Por este motivo, mecanismos de manipulação, integridade e segurança de acesso são permanentemente revisados para atender as crescentes, e a cada dia mais complexas, necessidades das instituições. Entretanto, um problema eminente é a capacidade de troca de informações entre instituições e/ou sistemas. É aparente a inviabilidade de uma instituição centralizar toda a informação de que necessita em um mesmo sistema de informação. Por conta disto, os sistemas devem ser capazes de interagir e compartilhar informação de maneira eficiente e segura. Este trabalho descreve o funcionamento dos Web Services, um padrão de comunicação e compartilhamento de informações utilizado para realizar a comunicação de informação entre aplicativos. Este padrão utiliza a internet para realizar este intercâmbio, além de padrões universais que possibilitam a interoperabilidade entre sistemas de maneira mais transparente e produtiva. Este documento está organizado como descrito a seguir: O segundo capítulo tem o objetivo de realizar uma revisão teórica sobre os principais temas relacionados, tais como: XML, SOA, Web Services, Reflection, Remoting, Sistemas Conectados, entre outros conceitos-chave para a compreensão de seu conteúdo. O terceiro capítulo tem o objetivo de apresentar os cenários de ambientes distribuídos contextualizando a utilização de Web Services para a troca de informações e demonstrar os benefícios desta tecnologia.

11 11 O quarto capítulo apresenta o conceito de Web Service Genérico que estende o conceito dos Web Services convencionais em um cenário mais flexível. Além disto, analisa determinados aspectos que subsidiam a concepção e aplicabilidade deste conceito em ambientes distribuídos. O quinto capítulo apresenta um estudo de caso onde é possível a verificação do comportamento e da aplicabilidade dos Web Services Genéricos na integração de sistemas heterogêneos, ou seja, entre sistemas gerenciados (.NET) e não gerenciados (Win32). 1.1 Objetivos O principal objetivo deste trabalho é projetar uma solução baseada na generalização dos conceitos de orientação a serviços e tecnologias de sistemas em ambientes distribuídos capaz de responder a necessidades mutáveis. Entre outros objetivos, destacam-se: Realizar uma análise do funcionamento e na concepção de aplicações construídas sobre arquiteturas baseadas em serviços (SOA), bem como visualizar sua aplicabilidade na construção de sistemas; Estudo do protocolo SOAP buscando analisar seu funcionamento no processo de empacotamento dos dados para transmissão dos pacotes; Estudar o padrão XML, cujo formato já é definido como universal para o tráfego de informações. Além disto, buscar contextualizar este formato de texto de marcação em um cenário de compartilhamento de serviços através de Web Services; Estudar os conceitos envolvidos na construção de Web Services, bem como sua arquitetura e tecnologias envolvidas. Outrossim, validar a sua eficácia quanto a interoperação entre sistemas; Estudar tecnologias.net que subsidiem a construção dos Web Services no intuito de implementar uma solução baseada neste framework com base nos demais conceitos avaliados; Desenvolver um Web Service Genérico capaz de refletir e utilizar as funcionalidades de qualquer aplicação.net; Validar a utilização deste artefato em um estudo de caso.

12 Motivação Este cenário dos sistemas distribuídos absolutamente variável e cujas necessidades estão voltadas para a solução efetiva dos requisitos de negócio e não mais na aplicabilidade tecnológica motivou a construção deste trabalho. Igualmente, se relacionam como itens motivacionais desta proposta: necessidade de troca de informações entre os sistemas de informações é eminente e demanda uma solução mais eficaz; A tecnologia Web Service é, possivelmente, um padrão para a comunicação entre informações entre sistemas; A tecnologia proposta pelos Web Services subsidia-se em conceitos e padrões universais, o que aumenta sua aceitabilidade.

13 13 2 Referencial Teórico Este capítulo realiza uma revisão teórica dos conceitos e tecnologias envolvidas para viabilizar a proposta de construção de Web Services genéricos. O propósito é expor as informações técnicas sobre o assunto para que haja contextualização e posteriormente um melhor entendimento dos objetivos e motivações que justificam o desenvolvimento deste trabalho. 2.1 Extensible Markup Language (XML) Extensible Markup Language (XML) é um formato de texto flexível derivado do Standard Generalized Markup Language (SGML) definida pela ISO Originalmente, foi concebido para a publicação eletrônica de informação em larga escala. Desempenha, também, um importante papel como padrão de comunicação de informações na internet. (W3C, 2006) O projeto da construção da linguagem de marcação XML foi basicamente norteado pela necessidade de criação de uma linguagem que fosse integrada a qualquer tipo de software e/ou linguagem. O projeto subsidiou-se ainda, sobre os seguintes pilares: Separação do conteúdo da formatação; Simplicidade e Legibilidade, tanto para humanos quanto para computadores; Possibilidade de criação de tags sem limitação; Criação de arquivos para validação de estrutura; Interligação de bancos de dados distintos;

14 14 Concentração na estrutura da informação, não em na sua aparência; Além disto, existem algumas diretivas a serem observadas para utilização da tecnologia XML, são estas: (W3C, 2006) XML deve ser diretamente utilizado sobre a Internet; XML deve suportar uma grande variedade de aplicativos; XML deve ser compatível com SGML; Deve haver facilidade em escrever programas aos quais sejam processados documentos XML; A quantidade de caracteríscas ocionais no XML devem ser evitadas ao máximo, sendo recomendado não existirem; Documentos XML devem ser inteligíveis e razoavelmente limpos; O projeto do XML deve ser construído rapidamente; O projeto do XML deve ser formal e conciso; Os documentos XML devem ser fáceis de serem criados; Aparência na marcação XML é a coisa menos importante Documentos XML O objeto da construção de um texto de marcação com a utilização de XML é o documento. Cada documento XML possui uma estruturas definidas: Lógica: o documento é composto por declarações, elementos, comentários, caracteres-referência e instruções de processo indicadas explicitamentes no documento; Física: o documento é composto por unidades chamadas entidades. Uma entidade pode fazer referência a outra para incluí-la a um documento. Entretanto um bloco de texto só é reconhecido como um documento XML caso seja bem formado. Um objeto de dados é um documento XML se este for bem-formado. Além disto, o documento XML é válido se este observa determinadas restrições. (W3C, 2006) Neste sentido, um documento é considerado bem-formado se observar, em sua produção, conforme ilustra a figura 1, os seguintes aspectos: Possuir uma declaração inicial (que pode ser vazia); Deve possuir um elememento Root (que pode conter n elementos);

15 15 Opcionalmente pode possuir uma parte mista (comentários, instruções de processamento, etc.); Todos os elementos devem ter anotações de início e fim; Os elementos devem ser aninhados corretamente, ou seja, o fechamento de um elemento deve corresponder ao elemento imediatamente anterior de nome afim. <?xml version="1.0" standalone="yes" encoding="utf-8"?> <cadastro> <?html action= hr?> <pessoa codigo=1> <!-- comentário sobre o elemento <nome> - -> <nome>joão</nome> <endereco>rua do Progresso, 70</endereco> </pessoa> </cadastro> <?html action= br?> Figura 1 Documento XML bem formado Declaração De acordo com as diretivas vistas anteriormente, um documento XML para ser reconhecido deve conter uma declaração. Apesar de ser um componente opcional é um item altamente recomendável por uma questão de organização e controle quanto aos documento XML produzidos. Esta declaração inicial é importante para especificar determinadas características do XML, como: versão do documento e codificação utilizada para sua construção. Esta declaração é ilustrada através da figura 2. É importante ressaltar que este é o ponto inicial de um documento. Qualquer coisa colocada anterior a declaração resultaria em uma má-formação do documento e, por conseguinte, seu não reconhecimento como um documento XML. <?xml version="1.0" encoding="utf-8"?> Figura 2 Declaração de um documento XML

16 Comentários Um comentário pode ser colocado em qualquer parte do documento XML, desde que observe algumas restrições: Não podem aparecer antes da declaração; Não podem aparecer dentro de uma anotação; Não permite a utilização da seqüência de caracteres "--". Comentários podem aparecer em qualquer lugar documento. Além disto, eles podem aparecer dentro da declaração do tipo do documento nos lugares permitidos pela gramática; não fazem parte dos dados de caracteres do documento; um processador XML pode, mas não precisa, fazer com que uma aplicação extraia o texto do comentário; por uma questão de compatibilidade -- (dois hífens) não podem ser utilizados dentro dos comentários; referências de parâmetros de entidades não são reconhecidos dentro de comentários. (W3C, 2006) Instruções de Processamento A instrução de processamento de é uma indicação direta ao processador sobre algo que deve ser executado. Este componente não faz parte do conteúdo nem da estrutura de um documento. Instruções de processamento (IPs) permitem que os documentos XML contenham instruções para aplicativos. (W3C, 2006) Elementos Os elementos compõem os blocos lógicos de um documento XML. Um elemento é composto por uma anotação inicial (identificada por um < sinal de menor), conteúdo e anotação final (identificada por um > sinal de maior), sendo que o elemento inicial é iniciado por uma anotação composta por </ sinal de maior e barra. O processador XML quando realiza a análise do documento assume que a anotação de fim de um elemento deve ser igual à anotação inicial declarada imediatamente anterior a esta. Além disto, um elemento deve estar completamente contido em outro elemento, com exceção do elemento raiz (conhecido como root). Em

17 17 adição a isto, um elemento pode conter direta ou indiretamente instâncias de si próprio. Esta possibilidade de recursividade ou aninhamento pode causar problemas no momento da execução do documento. Para a definição de um elemento é preciso nomeá-lo, entretanto existem algumas regras de nomes que devem ser observadas: Primeiro caractere deve ser uma letra, : dois pontos ou um _ underscore; Os caracteres seguintes podem conter valores alfanuméricos, pontos, : dois pontos e _ underscore; Não é permitido o uso de espaços em branco. É importante, ainda, observar que um documento XML é case-sensitive, ou seja, as letras maiúsculas e minúsculas são distinguidas. 2.2 Service Oriented Architecture (SOA) SOA expressa uma perspectiva para o desenvolvimento de software que define serviços fracamente acoplados de um software para responder aos requisitos dos processos definidos pelo negócio e pelos usuários. (Wiki, 2006) Historicamente, a arquitetura de soluções foi baseada na obtenção de um conjunto de requisitos de negócio e a partir destes derivar um modelo de tecnologia que normalmente envolve a orientação a objetos e tecnologias de componentes. Entretanto, distanciar o processo de desenvolvimento de um sistema dos negócios, normalmente ocasiona uma grande lacuna entre a real necessidade e as soluções de TI oferecidas Sistemas Conectados Embora o sistema de mensagens permita a conexão entre sistemas distintos e forneça a estrutura base de conexão de sistemas distribuídos, existe uma série de outras problemas importantes que precisam ser tratados, como questões de identidade, interação, etc. O sistema de mensagens é importante para a orientação a serviços, mas não é o único aspecto necessário para modelar serviços, existindo também diversos outros aspectos a serem analisados. (SEHMI, Arvindra)

18 18 Figura 3 Pilares dos sistemas conectados Existem cinco pilares fundamentais aos quais os sistemas conectados devem estar apoiados: Identidade e acesso. Noção de identidade federada (em um ambiente Web isto significa um único login para ter acesso a n locais) e autorização baseada em papéis. Este pilar trata do gerenciamento do relacionamento de confiança e da forma como deve ser controlado o acesso aos sistemas conectados. Além disso, normas de conformidade e governança são outros fatores importantes a serem observados; Dados. Esta premissa está relacionada à agregação de entidades e está relacionada à construção de uma fonte única e coerente de uma entidade de negócios específica, como um cliente, embora os dados do cliente possam estar duplicados em diversos sistemas; Interação. Este pilar é dedicado ao consumo humano de serviços, por exemplo, por meio de fornecimento, através de recursos on-line (Web) e off-line. A utilização de mecanismos ponto a ponto e dispositivos móveis também são ressaltados por este pilar; Sistema de mensagens. Refere-se a estrutura de base dos sistemas conectados e precisa dar suporte a sistemas de mensagens seguras, confiáveis e ordenadas; Workflow (fluxo de trabalho). Este pilar trata do fluxo de trabalho ou da automação dos requisitos de negócio, externos ao serviço. Há, neste ponto, uma preocupação quanto a orquestração dos processos de negócios e também a outros aspectos, como gerenciamento da interação com o usuário, processos especialistas e gerenciamento de exceções.

19 Princípios da arquitetura baseada a serviços A orientação a serviços se tornou um importante requisito no desenvolvimento de soluções em ambientes conectados, pois busca um alinhamento efetivo entre os requisitos de negócio e os serviços de TI oferecidos. Sendo assim, uma arquitetura orientada a serviço (SOA) é criada para fornecer flexibilidade para tratar elementos de processos de negócios e a infra-estrutura fundamental de TI como componentes (ou serviços) que podem ser reutilizados e combinados para atender às prioridades de mudanças de negócios. Service Oriented Architecture (SOA) é um paradigma para organização e utilização de recursos distribuídos que podem ser controlados por diferentes requisitantes. (OASIS, 2006) Existem alguns conceitos chave que devem ser observados em arquiteturas orientadas a serviço. Visibilidade refere-se à capacidade de aqueles que procuram o serviço e aqueles que fornecem o mesmo possam se encontrar. Isto envolve o provimento de descrição para cada funcionalidade disponível contendo sua sintaxe e semântica, formas de interação com tal funcionalidade, políticas de segurança que devem ser respeitadas e mecanismos de acesso a estes recursos; Interação através da troca de mensagens, a interação procede através de uma série de informações trocadas e ações invocadas. Resumidamente, a capacidade de interação constitui um conjunto de técnicas e elementos de negócio que formam o caminho entre os que requerem e aqueles que provêm algo; Efeito é o núcleo, pois é a capacidade efetiva de resposta de um ou mais efeitos do mundo real. Este efeito pode ser o retorno de informações ou a troca de estado de uma determinada entidade envolvida na interação. Para tornar os clientes de seus serviços mais auto-suficientes, permita que tenham uma visibilidade ampla ao usa-los. (OELLERMANN, Willian) Serviço Um serviço é um mecanismo que permite o acesso a uma ou mais funcionalidade. O serviço é provido por uma entidade específica (Service Provider)

20 20 onde os consumidores não precisam ter conhecimento sobre o provedor do serviço nem o provedor de serviço quanto ao consumidor de seu recurso. Um serviço é acessado através de interfaceamento de sistemas (interfaces do serviço), onde a interface compreende especificações sobre como acessar as capacidades inerentes ao serviço. Não existem restrições formais quanto a constituição das funcionalidades/capacidades a serem disponibilizadas nem como estas serão implementadas pelo Service Provider. Sendo assim, o serviço pode realizar a descrição das funcionalidades através de processos automáticos e/ou manuais que permitam que ele próprio possa invocar outros serviços disponíveis por outros provedores. Outra característica importante quanto aos serviços é sua transparência, quanto implementação, para o consumidor, ou seja, o consumidor não precisa conhecer detalhes técnicos do serviço, bastando ter ciência de sua existência, local e como acessalo. Os detalhes de um serviço só serão expostos ao consumidor, quando isto foi determinando para que este tenha conhecimento que o serviço é realmente apropriado a suas necessidades. Quando um serviço é invocado são realizados um ou mais efeitos no mundo real. Estes efeitos podem ser: a. Informação retornada em resposta a requisição; b. Uma troca de estado de uma determinada entidade; c. Combinações dos itens a e b ; Componentes A arquitetura orientada a serviços é constituída de determinados componentes, conforme figura 4, que concentram as principais 3 principais funções e tarefas a serem executados no tratamento dos serviços em um ambiente distribuído: disponibilização, requisição e distribuição de serviços

21 21 Figura 4 Modelo da arquitetura orientada a serviços Service Provider - nodo da rede que disponibiliza interfaces para recursos de software que trabalham com um conjunto específico de atividades. Este nodo pode representar os serviços de uma entidade de negócios ou pode simplesmente representar as interfaces de serviço para reutilização de sub-sistemas; Service Requestor - nodo da rede que descobre e invoca outros serviços de software para fornecer uma solução do negócio. Frequentemente, este nodo representa um componente de uma aplicação de negócio que executa chamadas remotas de procedimentos ao objeto distribuído, o Service Provider. Em alguns casos, o nodo provedor pode residir localmente em uma intranet ou, em outros casos, este pode residir remotamente na Internet; Service Broker nodo da rede que atua como um repositório para interfaces de software que são publicas pelo Service Provider. Um Service Broker pode ser representado por uma entidade de negócio ou um operador independente Modelagem de sistemas orientados a serviço Para criar sistemas orientados a serviços bem-sucedidos é necessário modificar a maneira como se pensa sobre orientação a serviços. (SCHWEGLER, Beat) Idealmente, o modelo de negócios e o de tecnologia devem estar alinhados precisamente, entretanto este relacionamento geralmente não se realiza. Os departamentos de tecnologia centralizados, que não trabalham em proximidade suficiente com a empresa e de forma efetiva, constituem uma razão chave para isso. O alinhamento real entre os modelos de negócio e o de tecnologia dificilmente é alcançado porque a lacuna entre estas duas perspectivas é muito grande.

22 22 Entretanto, para que este cenário seja modificado e o sistema seja concebido em uma modelagem orientada a serviço, é importante que alguns pontos sejam ressaltados: Profissionais de TI devem estar voltados para além da tecnologia. Isto significa que os profissionais da área de tecnologia de uma empresa devem estabelecer um melhor relacionamento com os profissionais focados na área de negócio. Tais profissionais não precisam ser especialistas neste ramo, mas precisam de uma linguagem objetiva que lhes permita conversar com a área de negócio sobre negócios e não sobre tecnologia. A figura do arquiteto de software advém exatamente desta necessidade, pois constitui um canal de comunicação entre os profissionais de negócio e o departamento de TI, precisando assegurar a interdependência entre os requisitos de negócio e as soluções tecnológicas; É necessário entender e participar das decisões da empresa. Este conhecimento influência as decisões de implementação, no âmbito que torna as medidas tecnológicas influenciadas pelos objetivos de negócio. Esta influência durante o próprio processo de desenvolvimento torna o sistema mais adequado a real necessidade real e estabelece um canal de comunicação mais estreito entre a tecnologia e o negócio; Uma Infra-estrutura operacional comum é fundamental para dar suporte a aplicativos de negócios que fornecem práticas inter-empresariais e globais. Construir um modelo íntegro de como operar e gerenciar a infra-estrutura e implantar aplicativos nela é fundamental para uma arquitetura bem-sucedida. Padrões de tecnologia de Web Services permitem que aplicativos sejam conectados. Ao final, o valor de conectar os sistemas leva as práticas de negócio mais eficientes e efetivas. É no modelo de serviços que pode capturar a semântica necessária para expressar os serviços que tornam a sua solução mais flexível e mais voltada para fora ou para os negócios. (SEHMI, Arvindra) Figura 5 Modelo de orientação a serviços em três partes

23 Vantagens da utilização de SOA Uma nova maneira de pensar em projetos de sistemas é eminentemente necessária. Adotando uma nova ótica, pode-se forçar a consideração explícita de artefatos de modelo de serviços nos processos de design, o que ajuda a identificar os artefatos corretamente e, no nível de abstração certo, atender e alinhas as necessidades de negócio. Sob uma perspectiva de modelagem, a lacuna entre os modelos de negócios e de tecnologia convencionais é muito grande, o que caracteriza o principal fator de fracasso de muitas iniciativas de projetos de sistemas, principalmente em ambientes conectados onde os fatores possuem maior variabilidade e o controle torna-se mais complexo. Desta forma, um modelo que promova um alinhamento dos serviços com os requisitos de negócios é a premissa de uma arquitetura concisa, de maior flexibilidade e de capacidade superior quanto ao cumprimento das metas estipuladas pelos requisitos de negócio. Por conseguinte, um modelo orientado a serviços é mais detalhado quanto aos pontos de intersecção entre os negócios e a tecnologia. Com efeito, a grande valor da arquitetura SOA é a providência de um paradigma simples para organizar uma grande rede de sistemas que requerem interoperabilidade para realizar o valor inerente aos seus componentes individualmente. Através desta habilidade de escalabilidade e envolvimento, SOA possibilita que um sistema ou uma rede de sistemas se tornem mais adaptáveis a uma variedade maior de necessidades e problemas específicos. 2.3 Web Services Sob uma breve ótica cronológica, temos um grande número de tecnologias existentes que permitem a comunicação entre aplicativos por intermédio da internet: Remote Procedure Call (RPC), Distributed Object Model (DCOM), e os serviços da fila de mensagens Microsoft Message Queue (MSMQ). Cada técnica destas é quase completa, porém foram projetadas para trabalharem somente com sistemas similares, como, por exemplo, o MSMQ que se comunica somente com outro MSMQ, ou um cliente DCOM que somente compartilha informação com um servidor DCOM. Todavia, isto não significa a impossibilidade destas tecnologias coexistirem em um mesmo ambiente computacional. Entretanto o tempo necessário para o

24 24 desenvolvimento de ferramentas que permitam a interoperabilidade destas e a confiabilidade no sucesso deste tipo de operação acaba inviabilizando a construção deste tipo de solução. O Web Service é uma tecnologia que busca exatamente esta comunicação e integração entre sistemas distintos, sob uma ótica arquitetural. Esta tecnologia foi concebida visando à independência de plataformas operacionais, hardware e linguagens de programação Arquitetura Um Web service é um sistema identificado por uma URL, da qual são publicadas interfaces públicas e definidas e descritas usando XML. Esta definição pode ser descoberta por outros sistemas de software. Estes sistemas podem então interagir com estes Web Services em um formato definido por sua definição, utilizando XML baseado em mensagens convencionadas por protocolos de internet. (W3C, 2006) Os Web Services são aplicativos totalmente independentes, isolando o acesso a demais recursos de um ambiente distribuído, como banco de dados. Para que este isolamento seja possível e esta independência seja efetiva, os Web Services são aplicativos baseados em um conjunto de padrões universais. Estes padrões descrevem a sintaxe e semântica do envio e recebimento de informações, bem como tecnologias de transporte, codificação e protocolos de comunicação. Esta padronização dos Web Services é de responsabilidade da W3C (World Wide Web Consortium) e o Organization for the Advancement of Structured Information Standards (OASIS). A arquitetura básica de um Web Service define uma interação entre aplicativos através de troca de mensagens entre agentes consumidores e agentes forncedores. Esta arquitetura capacita os Web Services para as seguintes funções básicas: Trocar mensagens; Serem serviços auto-descritivos; Publicar e possibilitar a navegabilidade sobre seus serviços.

25 25 Figura 6 Modelo básico de acesso a um Web Service Simple Object Access Protocol (SOAP) SOAP é um pacote de protocolo padronizado para as mensagens compartilhadas entre aplicações. (SNELL, James) SOAP foi projetado para encapsular e transportar chamadas de RPC (Remote Procedure Call), e para isto utiliza-se dos recursos e flexibilidade do XML, sob HTTP. A especificação define um modelo baseado em um envelope XML para que as informações sejam transformadas e um conjunto de regras para tradução de peculiaridades específicas de uma aplicação ou plataforma ou tipos de dados contidos na representação XML. Figura 7 Constituição de uma mensagem SOAP Segundo a W3C (World Wide Web Consortium), para toda chamada RPC são necessárias as seguintes informações: A URI do objeto alvo; O nome do método;

26 26 Os parâmetros do método (requisição ou resposta); Uma assinatura do método opcional; Um cabeçalho (header) opcional; POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1"> 5 <t:transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice> xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figura 8 Exemplo de um envelope de requisição RPC O elemento Envelope especifica: A URI identifica o namespace utilizado por esta requisição SOAP. possui o namespace padrão para todas as mensagens SOAP; O encodingstyle (estilo de codificação) é definido pela URI e identifica o estilo de codificação a ser utilizado; O cabeçalho Header define: Um atributo chamado Transaction que define um namespace (URI) para o elemento. O atributo mustunderstand=1 especifica que o cabeçalho deve ser processado pelo receptor da mensagem; O valor 5, que deve ser um valor compreendido pelos serviços que processam esta mensagem; O elemento Body define: Uma chamada de método GetLastTradePrice e seu respectivo namespace;

27 27 O elemento DIS especifica um parâmetro contido na chamada de método GetLastTradePrice. Além disto, o protocolo SOAP fornece a semântica para o envio e recebimento dos dados (utilizando XML), codificando os parâmetros de entrada/saída invocados pelas operações publicadas pelo Web Service. Em outras palavras, SOAP é uma aplicação especificada por XML. Isto garante uma intensa observância aos padrões XML como schema e namespaces para suas definições e funções. Figura 9 Tráfego de mensagens via XML Web Service Description Language (WSDL) A WSDL é o padrão que fornece as especificações e mecanismos de descrição dos Web Services. Através desta padronização, um Web Service pode descrever tudo aquilo que ele faz, como faz e como pode ser consumido. Figura 10 Descrição gerada automaticamente pelo WSDL

28 28 Existem algumas vantagens quanto à utilização do padrão WSDL: WSDL torna fácil escrever e manter serviços fornecendo um melhor estruturado jeito de deifinir as interfaces do Web Service; WSDL facilita o consumo do Web Service através da redução do montante de código que uma aplicação cliente precisa programar; WSDL torna mais simples a implementação de modificações com baixo impacto. Devido ao dinamismo de sua descrição, o WSDL permite que modificações sejam realizadas sem maiores prejuízos ao código do cliente. Figura 11 WSDL Preâmbulo Universal Description Discovery and Integration (UDDI) UDDI é um projeto responsável pelo processo de publicação, pesquisa e navegação dos Web Services. Sendo assim, define um registro de serviços contendo suas descrições para que os consumidores possam automaticamente navegar e utilizar o serviço desejado. Este projeto possui duas partes: um registro de todo o metadado do Web Service (incluindo um ponteiro a descrição WSDL do serviço) e um conjunto de tipos de definições de porta WSDL para a manipulação e localização dos registros.

29 Reflection Primeiramente é importante que seja definido o paralelo matemático que subsidia todo o conceito envolvido em reflexão de classes. Quando se fala em reflexão computacional evidenciam-se as problemáticas envolvidas pelas equações reflexivas. Sendo que tais equações possuem como principal funcionalidade a descrição de equações através de análises matemáticas baseadas na descoberta de seus respectivos domínios e, através destas descrições, realizarem a descrição de qualquer equação, é evidenciado um ponto de intersecção entre estas áreas do conhecimento Aspectos Matemáticos da Reflexão Criar uma arquitetura reflexiva é o caminho para o efetivo relacionamento de entidades implícitas de um domínio computacional D n, chamado nível básico, dentro de um outro domínio computacional D n+1, chamado meta-nível. (FERBER, Jacques) Cada domínio pode servir ambos o domínio básico para um nível superior, ou um meta-domínio para um domínio inferior, com exceção do domínio D0, construído por referências, aos quais pode ser utilizado somente como um nível básico. Modelos de reflexão facilmente são definidos por meios de equações de reflexão, as quais expressam como entidades e expressões de nível básico são descritas no meta-nível. Sendo assim, equações de reflexão agem como equações semânticas, fornecendo a semântica dos níveis inferiores em termos de níveis superiores. O modelo tradicional de reflexão é baseado em interpretação. O domínio D n é composto de um conjunto de entidades e expressões, escritas em uma linguagem L n, e de um interpretador I n que interpreta estas expressões. O interpretador é escrito em uma linguagem L n+1 que por sua vez é interpretado por um interpretador I n+1. Quando o sistema não é reflexivo, a linguagem L n+1 é completamente diferente da linguagem L n. Por exemplo, se L 1 é uma linguagem LISP, L 2 pode ser uma linguagem como Pascal ou C, L 3 o conjunto de instruções da linguagem de maquina, etc. Sendo assim, em arquiteturas reflexivas, existe uma infinita cadeia virtual de linguagens idênticas L i, também conhecidas como torre reflexiva. Este cenário é possível devido a existência de um interpretados, escrito em uma linguagem L

30 30 diferente de L i, que é usada para isolar a regressão e substituir o interpretador I n no nível computacional mais básico necessário. Um novo modelo de reflexão baseada em representação de objetos foi introduzida por Pattie Maes. Cada objeto O tem um meta-objeto M-O que representa O. (MAES, Pattie) O modelo proposto por Maes é baseado em uma explícita semântica de referência em representações do conhecimento. Representação é um processo notacional onde conceitos são implementados através de objetos conceituais. (STEELS, Luc). Sendo assim, todo o objeto é uma representação de alguma coisa, uma entidade do mundo real (pessoas, arquivos, tabelas) um evento ou uma situação. Objetos computacionais podem ser também representados por outros objetos, também conhecidos como meta-objetos. Em suma, objetos são referências de um meta-objeto Reflexão em Linguagens Orientadas a Objeto Quando um objeto O recebe uma mensagem, este a delega ao seu objeto M-O. Este processo é executado novamente, recursivamente, até que o sistema encontre o meta-objeto chamado Meta-Objeto Default, que utiliza um interpretador básico de mensagens escritas diretamente em LISP. Entretanto, utilizar um meta-objeto para realizar a reflexão não é a única maneira de contruir a reflexão computacional. Existe, ainda, a possibilidade de ajustar o processo de comunicação. Este método condiciona a uma outra forma de visualizar a reflexão em linguagens orientadas a objeto, ao qual possibilita a utilização tanto para o processo de debug como para a implementação Cenário de utilização No modelo introduzido pela programação orientada a objetos utiliza-se o conceito de instanciamento de classes para o acesso a atributos e invocação de métodos das mesmas. Por conseguinte, neste modelo proposto, é necessário um conhecimento prévio sobre a classe que se deseja acessar.

31 31 Entretanto, imaginemos um cenário em que o acesso aos atributos e métodos de classes possa ser realizado de maneira genérica. Neste caso, não seria necessário um conhecimento prévio sobre uma determinada classe, pois esta seria identificada no momento de sua utilização. A técnica de pesquisar atributos e métodos de classes em tempo de execução é conhecida como Reflection. Para a viabilidade disto, o.net Framework introduziu um importante conceito no desenvolvimento de aplicações: assembly auto-descritivas. Antigamente, na programação de componentes COM (Component Object Model) eram observados a presença de um type-library vinculado, que descrevia este componente, possibilitando a reutilização por outros componentes. Em.NET, os assembly possuem um metadado agregado, que descreve ele próprio e os tipos definidos pela mesma. Esta mudança no formato de construção de componentes reutilizáveis serviu de premissa à técnica do Reflection. O Reflection é o ato de, programaticamente, inspecionar um assembly, seu metadado e os tipos de dados contidos dentro deste Meta-Objetos e o processo de Reflexão No modelo de reflexão baseado em meta-objetos, cada objeto possui seu próprio meta-objeto que descreve seu comportamento básico. Como um meta-objeto também é um objeto, estes também podem possuir meta-objetos, e assim sucessivamente. Este modelo condiciona a um cenário infinito de possibilidade regressivas a meta-objetos, em uma realidade programática orientada a objetos. De acordo com a técnica proposta pelos meta-objetos, a semântica do envio da mensagem pode ser definida pelo responsável do envio HANDLEMSG - desta ao meta-objeto. Linguagens que utilizam o paradigma da orientação a objetos, estabelecem um paralelo lógico de comportamento. Sendo um objeto uma representação de seu metaobjeto respectivo, meta-classes são consideradas meta-objetos de classes devido a sua capacidade de descrição da estrutura da classe. Por conseguinte, uma meta-função de um objeto é equivalente a uma meta-função da classe, pois esta última retorna a classe do objeto.

32 32 A equação reflexiva comprova esta equivalência e agrega a questão do ponto de vista comportamental: um objeto O receber a mensagem M, está para sua classe receber a mensagem HANDLEMSG. Em suma, é importante a distinção entre reflexão estrutural (embasadas em equações matemáticas) onde a utilização de meta-classes é importante e a reflexão computacional, onde uma classe específica META-OBJETO pode ser introduzida como a raiz de todos os demais meta-objetos NET Reflection A utilização da técnica proposta pelo Reflection é realizada através de um conjunto de classes contidas em uma biblioteca de classes do.net Framework. Estas classes estão agrupadas e compõe o namespace: System.Reflection. Figura 12 Biblioteca de Classes do.net Framework O namespace System.Reflection contém todas as classes e interfaces que permitem a realização das tarefas pertinentes a exploração de classes em momento de execução. Tais tarefas podem ser caracterizadas por: exploração de tipos, exploração de métodos e exploração de campos. Muitos dos tipos existentes no namespace são os atributos que adicionamos nos assemblies a fim de disponibilizar informações como: Título, TradeMark, Versão, entre outras. Quando é necessária a manipulação direta aos assemblies, a classe System.Reflection.Assembly deve ser utilizada. Esta fornece a infra-estrutura necessária para, em tempo de execução, possuirmos uma completa visão e entendimento da capacidade de uma aplicação, reforçando suas regras de versionamento e dependência. Por sua vez, a classe System.Type é a chave para a obtenção de informações referentes aos tipos contidos em um assembly. Ela implementa a classe System.Reflection.MemberInfo que permite, através da sua manipulação, realizar as tarefas de busca de informações dos elementos, membros internos das classes, interfaces, arrays, tipos por valor e enumerações. Propriedades como: IsClass, IsEnum

33 33 ou IsInterface, que permite determinar os tipos, ou métodos como: GetConstructors, GetFields, GetMethods, GetProperties, GetEvents, e GetNestedTypes que retornam os vários membros do tipo informado. Desta forma, para descobrir os tipos contidos em uma determinada classe, é necessário que seja realizada a instância da classe System.Type. Esta instância, por sua vez, será inicializada utilizando-se um tipo específico que se deseja inspecionar. Figura 13 Exemplo de utilização da classe System.Type Um último aspecto importante a ser observado é a enumeração System.Reflection.BindingFlags, que determina como será conduzida a busca dos membros e tipos pelo mecanismo do Reflection. 2.5 Remoting Tecnologias de sistemas distribuídos como DCOM (Distributed Component Object Model), RMI (Remote Method Invocation) e CORBA (Common Object Request Broket Architecture) têm evoluído nas últimas duas décadas para responder às mudanças do crescente número de requisitos. Hoje em dia, uma tecnologia de sistemas distribuídos precisa ser eficiente, extensível, suportar transações, interoperar com diferentes tecnologias, ser altamente configurável e trabalhar sobre em ambiente Web Arquiteturas distribuídas Existem muitas arquiteturas que propõe a distribuição do sistema em pontos isolados e separados. Esta metodologia fracamente acoplada quanto a utilização dos recursos proverão um sistema é a premissa básica para a concepção do.net Remoting e demais tecnologias de sistemas distribuídos. É importante que alguns conceitos arquiteturais estejam bem esclarecidos quanto a ambientes distribuídos, tais como:

34 34 Programação modular É essencial para a distribuição de um sistema que este seja projetado de maneira modular, ou seja, o dividir o sistema em unidades sólidas e integradas que interagem entre si. Cliente/Servidor Conceito fundamental para arquiteturas distribuídas. Em termos gerais, cliente/servidor é um cenário onde um processo cliente requisita serviços de um processo servidor. O processo cliente é responsável pela camada de apresentação da aplicação UI (User Interface). Com efeito, cabe a esta camada a validação dos dados de entrada do usuário, despachar chamadas ao servidor e possibilitar executar algumas regras de negócio. O processo servidor, por sua vez, atua como um motor processa as requisições do cliente através da execução da lógica de negócios e interoperar com demais recusros, como banco de dados. Frequentemente, muitos clientes realizam suas requisições a um único servidor. Figura 14 Modelo Cliente/Servidor Multi-Camadas ou N-Tier Cliente/servidor também são dispostos como no modelo de duas camadas devido a invocação do cliente diretamente ao servidor. Arquiteturas duas camadas são comumente mais fáceis de serem implementadas, mas tendem a ter uma escalabilidade limitada. Em um modelo constituído por multi-camadas a entidade cliente, lógica das regras de negócio e armazenamento de dados são desenvolvidos e mantidos como módulos interdependentes e muito frequentemente em plataformas separadas.

35 35 Figura 15 Modelo N-Tier Peer-to-Peer Esta arquitetura compreende muitos nodos individuais não centralizados a um único servidor. A expressão Peer-to-Peer foi usada pela primeira vez em 1984, com o desenvolvimento do projeto Advanced Peer-to- Peer Networking Architecture na IBM. A internet é um exemplo clássico de uma arquitetura constituída de um servidor Web monolítico servindo clientes magros (thin clients). Entretanto temos exemplos de sistemas como Emule, BitTorrent, entre outros que permitem o compartilhamento de dados entre estações. Estas estações (peers) usam um servidor centralizado para descobrir outras estações e estabelecer algum tipo de requisição/provimento. Figura 16 Modelo Peer-to-Peer

36 Tecnologias distribuídas As arquiteturas distribuídas discutidas foram implementadas utilizando tecnologias que subsidiam a construção de ambientes descentralizados. Contudo, o grande crescimento nas aplicações distribuídas é observado nas nestas tecnologias. Isto pode ser comprovado pelo tempo cada vez menor necessário para a modelagem de uma arquitetura distribuída, através de ferramentas e conceitos tecnológicos mais enxutos e eficazes. Sockets uma das fundamentais abstrações das aplicações de rede modernas. Os sockets abstraem detalhes de baixo nível de uma rede através de construção de comunicações baseadas em entradas e saídas de streams. Embora seja oferecido controle total sobre a comunicação, os sockets demandam um trabalho de construção complexo para ser utilizado pelas aplicações distribuídas. Utilizando streams para entrada e saída dos dados acarreta o desenvolvimento de mensagens mais complexas, pois devem conter detalhes do sistema e interpretadores dos streams de dados. Remote Procedure Call (RPC) O ambiente de computação distribuída da Open Software Foundation define, entre outras tecnologias, uma especificação para a realização de chamadas remotas a procedimentos (RPC). O trabalho com RPC pressupõe alguns conceitos: o Stubs Estes pedaços de código rodam no lado do cliente e do servidor que realiza a chamada remota ao procedimento como se fosse uma chamada local. o Marshaling Este é o processo de passagem de parâmetros de um contexto para outro. Em RPC, os parâmetros das funções são serializados em pacotes para serem transmitidos. o Interface Definition Language (IDL) Esta linguagem fornece significados padrões para descrever, sintaxes de chamada e tipos de dados dos procedimentos remotos chamados independente da linguagem que foram programados. Pode-se, então, considerar a utilização de RPC um grande avanço na construção de comunicação remota de maneira simplificada, ao estabelecer um comparativo com Sockets, por exemplo.

37 Objetos Distribuídos A tecnologia de objetos distribuídos permite que objetos rodem em uma determinada máquina cujo acesso é disponibilizado a aplicações ou a objetos rodando em outras máquinas. Assim como RPC, os objetos distribuídos realizam chamadas a objetos remotos como se fossem locais. Embora as tecnologias distribuídas sejam implementadas de forma diferente possuam filosofias e premissas peculiares entre si, existem similaridades em alguns aspectos: São baseadas em objetos remotos que possuem identidade e estado próprio. Isto possibilita que tais objetos sejam manipulados da mesma forma que objetos locais, simplificando a programação de sistemas distribuídos, provendo um simples e unificado modelo de programação; São associados com o modelo de programação baseada em componentes. A utilização de componentes aumente a flexibilidade do sistema para realizar a distribuição bem como melhora a manutenabilidade do mesmo, visto que é separado em unidades lógicas menores; São associados a serviços corporativos. Os serviços corporativos geralmente provêm o suporte a algumas tarefas como transação, pool de objetos, controle de concorrência e locação de objetos. Devido a complexidade de implementação, são fornecidas por aplicativos próprios ou pelo próprio sistema operacional; Binding de Objetos As questões relativas a interoperabilidade devem ser consideradas quando é necessária a coexistência de sistemas heterogêneos em um ambiente distribuído. Mais do que isto, quando tais sistemas necessitam estabelecer um canal de comunicação visando o compartilhamento de informações e aproveitamento de funcionalidades. Desta forma, ao interagir sistemas não-gerenciados - win32 - com assemblys compilados em.net (ambiente gerenciado), a utilização de binding (early/late) é uma importante prática a ser considerada. Esta técnica baseia-se na automação do controle/comunicação de um componente utilizando o modelo COM (Component Object Model).

38 38 Abstraindo o conceito de associação de valores a identificadores, o processo de binding está associado a associação de valores a identificadores. Tal abstração está estreitamente ligada ao conceito de escopo, ou seja, escopo de validade de uma determinada associação através de binding. De acordo com o momento em que o processo de binding é chamado, pode-se classificá-lo da seguinte como: Early Binding e Late Binding Early Binding Esta técnica refere-se a associação de tipos-valor em momento de compilação. Isto significa que o componente cliente e o objeto COM estabelecem uma ligação binária e todos os tipos e métodos deste ficam disponíveis em ambiente de desenvolvimento. Pode-se identificar como ponto positivo da utilização de early binding a garantia a compatibilidade binária entre o cliente e o objeto, aumentando a velocidade de comunicação. Entretanto, um grande problema encontrado é que qualquer alteração no objeto COM necessitará a modificação do cliente. Isto pode gerar problemas de controle de versionamento e maior complexidade de delpoy (distribuição). Exemplo da utilização de early binding: fazer a referência ao objeto COM que será automatizado. Figura 17 Seleção de objetos para Automação

39 39 declarar objetos de tipo definido pelo objeto COM e utilizar os métodos por ele implementados: Dim PPApp As PowerPoint.Application Dim PPPres As PowerPoint.Presentation Dim PPSlide As PowerPoint.Slide Set PPApp = CreateObject("Powerpoint.Application") Set PPPres = PPApp.Presentations.Add Set PPSlide = PPPres.Slides.Add(1, pplayouttitleonly) With PPPres.SaveAs "C:\My Documents\Sample.ppt".Close End With PPApp.Quit Set PPSlide = Nothing Set PPPres = Nothing Set PPApp = Nothing Figura 18 Automação de objetos via early-binding Late Binding Esta técnica presume uma característica adicional ao componente COM. Todo o objeto passível é passível de automação via late binding se implementar a interface IDispatch. Esta interface permite a um cliente invocar os métodos e propriedades de um componente em tempo de execução. Pode-se considerar como ponto positivo quanto a utilização de late-binding a independência entre o componente cliente e o objeto COM facilitando a distribuição, entretanto a performance pode se tornar um fator crítico na utilização de automatização de componentes via late binding, dependendo da quantidade de instâncias do objeto COM e da quantidade de operações invocadas. Um exemplo de utilização de late binding pode ser ilustrado conforme a figura 19, onde é declarado um objeto do tipo Object e Este receberá uma instância do objeto COM.

40 40 Dim PPApp As Object Dim PPPres As Object Dim PPSlide As Object Set PPApp = CreateObject("Powerpoint.Application") Set PPPres = PPApp.Presentations.Add Set PPSlide = PPPres.Slides.Add(1, 11) With PPPres.SaveAs "C:\My Documents\Sample.ppt".Close End With PPApp.Quit Set PPSlide = Nothing Set PPPres = Nothing Figura 19 Automação de objeto via late-binding COM Callable Wrapper (CCW) Quando um aplicativo-cliente não gerenciado realiza uma chamada a um com componente.net, o compilador do framework cria um objeto gerenciado e um COM Callable Wrapper para o respectivo objeto. Por não ser possível a referência direta a este objeto criado, o cliente utiliza o CCW como um proxy de acesso ao objeto.net. Sendo assim, cada objeto gerenciado possui um COM Callable Wrapper respectivo, independente da quantidade de chamadas a ele efetuadas. Isto significa que múltiplos clientes não gerenciados podem utilizar uma mesma referencia ao CCW que expõe a interface INew. Figura 20 Chamada um objeto gerenciado (.NET) É importante salientar que os COM Callable Wrappers criados são invisíveis as outras classes gerenciadas. Isto reafirma sua principal funcionalidade que é realizar marshalling as chamadas feitas entre componente gerenciados e não-gerenciados. Adicionalmente, o CCW também é responsável pela identidade do objeto criado e pelo seu ciclo de vida (processo de garbage collection).

41 Serialização de Objetos Em termos gerais, o processo de serialização consiste no armazenarmos do estado de um objeto para fazer uso deste posteriormente para uma necessidade qualquer. Em contrapartida, o processo de desserialização é constituído na manipulação do estado do objeto serializado através do instanciamento desse objeto a partir do formato serializado. O processo de serialização possui grandes vantagens de utilização, tais como: Armazena preferências particulares no objeto; Mantém seguras as informações através das páginas Web e aplicativos desktop; Permite a modificação dos documentos XML sem a utilização de DOM (Document Object Model); Passagem de objetos de uma aplicação para outra; Passagem de objetos de um domínio para outro; Passagem de objetos através de firewall como uma string XML; Quando falamos em serialização de objetos, estamos buscando uma solução para trafegar nossos objetos entre sistemas, aplicações WEB e até mesmo entre redes. (SANCHES, Andrey) Existem maneiras para realizar o processo de serialização/desserialização de objetos utilizando a plataforma.net, conforme descrito abaixo: Utilizando as classes contidas no namespace System.Runtime.Serialization. Este processo realiza a serialização em dois formatos: binário ou XML/SOAP. Os objetos são serializados utilizando atributos do tipo private da sua classe no formato em que for especificado, no caso XML/SOAP ou binário. Para que uma classe possa ser serializada, é necessário informar o atributo <Serializable()> em [VB.NET] ou [Serializable()] em [C#] antes da declaração da classe, isso faz com que o framework autorize a serialização desta classe e, dessa forma, mantenha o estado do objeto no formato especificado.

42 42 using System; namespace ConjuntoClasseSeri { [Serializable] public class ClasseParaSerializar { [NonSerialized] public string uname; [NonSerialized] public int uid; public string ename; public int esal; public int calchra(int a,int b) { return (a-b); } public int CalcPF(int a,int b) { return (b-a); } } } public int Deductions; public int NetSal; Figura 21 Classe que será serializada using System; using System.Runtime.Serialization.Formatters.Binary; using System.IO; namespace ConjuntoClasse { class Class1 { [STAThread] static void Main(string[] args) { ConjuntoClasseSeri.ClasseParaSerializar obj= new ConjuntoClasseSeri.ClasseParaSerializar(); obj.deductions=90; obj.netsal=1000; Stream a= File.OpenWrite("C:\\abc.bin"); BinaryFormatter bf=new BinaryFormatter(); bf.serialize(a,obj); a.close(); } } } Figura 22 Classe que invoca o processo de serialização Serialização em XML. Este mecanismo de serialização utiliza as classes contidas no namespace System.XML.Serialization. Neste processo de serialização os objetos são formatados como documentos XML. Existem

43 43 algumas regras que devem ser observadas para a utilização deste tipo de processo de serialização. o Serializa somente os campos públicos e valores das propriedades de um objeto em uma stream XML; o Não inclui informação de tipo; o Requer um construtor padrão a ser declarado na classe a ser serializada; o Requer que todas as propriedades que serão serializadas sejam de leitutora e escrita. Por conseguinte, propriedades somente leitura não são serializadas; using System; using System.Collections; using System.IO; using System.Xml; using System.Xml.Serialization; [XmlRoot("shoppingList")] public class ShoppingList { private ArrayList listshopping; public ShoppingList() { listshopping = new ArrayList(); } [XmlElement("item")] public Item[] Items { get { Item[] items = new Item[ listshopping.count ]; listshopping.copyto( items ); return items; } set { if( value == null ) return; Item[] items = (Item[])value; listshopping.clear(); foreach( Item item in items ) listshopping.add( item ); } } public int AddItem( Item item ) { return listshopping.add( item ); } } public class Item { [XmlAttribute("name")] public string name; [XmlAttribute("price")] public double price; public Item() { } public Item( string Name, string Price ) { name = Name; price = Price; } } Figura 23 Classe que será serializada

44 44 ShoppingList mylist = new ShoppingList(); mylist.additem( new Item( "eggs",1.49 ) ); mylist.additem( new Item( "ground beef",3.69 ) ); mylist.additem( new Item( "bread",0.89 ) ); // Serialization XmlSerializer s = new XmlSerializer( typeof( ShoppingList ) ); TextWriter w = new ); s.serialize( w, mylist ); w.close(); // Deserialization ShoppingList newlist; TextReader r = new StreamReader( "list.xml" ); newlist = (ShoppingList)s.Deserialize( r ); r.close(); Figura 24 Processo de serialização/desserialização NET Remoting O.NET Remoting proporciona que seus aplicativos tenham comunicação com sistemas remotos utilizando protocolos de comunicação. Dessa forma, podemos aproveitar todos os recursos de um projeto Windowsforms com a facilidade de acessar informações remotas, estando em sua intranet ou até mesmo na internet. (SANCHES, Andrey) O.NET Remoting proporciona um ambiente de comunicação entre aplicativos em um cenário distribuído. Neste sentido, podem ser aproveitados recursos diversos onde quer que estes sejam disponibilizados fisicamente. Para que processos troquem informações, criam-se métodos com parâmetros e retornos de funções, e para que esses objetos possam trafegar devem ser serializáveis. Uma vez serializado, o objeto é enviado em um formato definido para que seja transportado pela rede até seu destino.

45 Arquitetura Figura 25 Arquitetura.NET Remoting Dependendo de sua categoria, um tipo remoto pode passar dos limites do framework ou pode ser acessado dentro do mesmo. Existem três categorias de tipos remotos: marshal by value, marshal by reference, and context bound. Marshal-by-Value instâncias de tipos marshal-by-value podem cruzar os limites do framework através da serialização dos objetos. Uma vez serializado, a infra-estrutura do.net Remoting transfere a seqüência de bits através das fronteiras do framework em outros domínios de aplicativos (application domain) ou contextos, onde o framework então desserializa a sequência de bits em uma instância de tipo correspondente ao estado capturado no momento da serialização. Figura 26 Funcionamento do marshal-by-value

46 46 Marshal-by-Reference Instância do tipo marsha-by-reference realiza o instanciamento de um tipo em um application domain mantendo a ciência que todos os acessos ao objeto ocorrerão na instância do objeto contida no application domain desejado. Este tipo de instanciamento é utilizado quando se quer utilizar a instância de um objeto desde que esteja sendo executada em uma determinada máquina. Figura 27 Funcionamento do marshal-by-reference Context-Bound Derivando o tipo da System.ContextBoundObject irá restringir instâncias de alguns tipos contidos em um contexto específico. Objetos contidos em contextos externos não podem acessar diretamente os tipos ContextBoundObject, mesmo se outro objeto está contido no mesmo application domain. Figura 28 Acesso a tipos de instância context-bound

47 Ativação de Objetos Antes da instância de um objeto remoto poder ser acessada, este precisa ser criada e inicializada por um processo chamado ativação. Existem dois tipos de ativação, são eles: Ativação do Servidor O processo servidor hospedando o tipo remoto é responsável por configurar o tipo como um objeto bem definido, publicá-lo como um endereço bem definido e ativar as instancias do tipo sob demanda..net Remoting distingue a ativação do servidor em dois modelos distintos que oferecem semânticas diferentes de ativação: singleton e singlecall. o Singleton Não mais do que uma instância de um tipo configurado como singleton pode ser ativado ao mesmo tempo. Uma instância é ativada a partir do primeiro acesso do cliente, se uma instância não existir. Enquanto ativa, uma instância singleton irá manipular todas as requisições de acesso dos clientes. É importante ressaltar que uma instância singleton pode manter o estado entre as chamadas dos métodos. o Singlecall Neste modelo de ativação, uma nova instância do tipo á ativada em resposta a toda invocação de método realizada. Quando a instância é liberada esta é colocada para reciclagem no próximo ciclo de coleta de lixo. Ativação do Cliente alguns cenários requerem que cada instância de objeto seja identificada por seu cliente respectivo. Este tipo de instanciamento pode mater ativa entre as chamadas de método e participar do mesmo ciclo de vida exposto pelo esquema singleton. Entretanto, ao invés de uma única instância de tipo servir todos os clientes, cada cliente referencia instâncias dos tipos remotos separadamente Benefícios das aplicações distribuídas Um dos grandes benefícios do modelo de aplicações distribuídas é a tolerância a falhas. Isto sugere que o sistema possa manter sua integridade mesmo com após a ocorrência de um erro. Isto é possível pois a arquitetura de um sistema distribuído é composta por unidades lógicas bem definidas e que, ao falhar, podem ser substituídas por outras sem prejuízo ao funcionamento do sistema.

48 48 Outra grande importância observada é a escalabilidade das aplicações distribuídas. A medida que a demanda do sistema for aumentando basta realizar uma redistribuição dos recursos para a resposta a esta nova necessidade. Por fim, a administração de aplicativos distribuídos é mais efetiva. Todavia, a existência de módulos concisos e interdependentes que diminuem a duplicação de código e partem da premissa da reutilização de recurso, possibilita que os processos de manutenção sejam muito mais eficazes. Outrossim, a alteração de um determinado ponto do sistema terá impacto somente no escopo do módulo em questão, não comprometendo o funcionamento de todo o resto do sistema.

49 49 3 CENÁRIOS Atualmente, o cenário proposto pelos sistemas distribuídos é bastante eficiente, no âmbito do compartilhamento de recursos e o aumento da escalabilidade de aplicativos. Entretanto, é notório que as técnicas propostas para a distribuição de sistemas são objetivadas, somente, na evolução tecnológica de técnicas antecessoras, haja vista o DCOM (Distributed Component Object Model) que se apresenta como um conjunto de agregações de técnicas de distribuição ao modelo COM (Component Object Model). Com a formalização da arquitetura orientada a serviços foi possível à reflexão sobre todo o processo de concepção e desenvolvimento de sistemas em ambientes distribuídos. Sob esta nova ótica o foco primordial dos aplicativos deve estar voltado à solução dos requisitos de negócio através da aplicação racional, e não fundamental, da tecnologia. Neste sentido, a arquitetura dos sistemas deve ser capaz de torná-los mais flexíveis para contemplarem tais necessidades em um ambiente de rápidas mudanças. Contudo, o consumo e fornecimento de serviços, premissa que norteia todo o conceito de arquiteturas orientadas a serviço só foi possível à medida que os sistemas começaram a ser projetados focados em uma divisão modular de seus processos. Com esta divisão, foi possível o esclarecimento de sistemas enquanto composição de componentes (unidades lógicas concisas e agrupadas por funcionalidades afins) que interagem entre si. Todavia, o advento dos Web Services possibilitou que a utilização da arquitetura orientada a serviços tivesse um crescimento sistemático nas instituições. Uma solução proposta segundo a orientação a serviços prevê a construção de sistemas e a interação entre estes, no intuito do alcance dos objetivos determinados pelos requisitos de negócio

50 50 e, como demonstrado em capítulos anteriores, é sob esta ótica que os Web Services foram concebidos. 3.1 Modelo tradicional de utilização de Web Services No modelo tradicional de utilização de Web Services pode-se observar um cenário claro de consumo de serviços. Observa-se então, um conjunto de Web Services contendo funcionalidades, que são implementadas sob demanda e liberadas para consumo. Clientes HTTP/SOAP Internet Web Service X Rede TCP/IP Web Service Y Servidor de Aplicação Web Web Service Z1 Web Service Z2 Web Service Z3 Servidor de Banco de Dados Figura 29 Modelo Web Services Este modelo é constituído da seguinte forma: Clientes entidade que consome os recursos de um ambiente distribuído. Realizam consultas a servidores de aplicativos, recursos de rede e recursos da

51 51 Internet. Por conseguinte, podem, ainda, realizar consultas diretamente a serviços disponibilizados pelos Web Services. Os navegadores são as principais ferramentas utilizadas para a realização de tais consultas. Devido ao retorno do Web Service ser um documento XML, o cliente pode manipulá-lo da forma que melhor atender a sua necessidade; Servidor de Aplicação Web em um modelo tradicional o servidor de aplicação é responsável por servir requisições dos clientes a sistemas de gestão, controle operacional e demais automatizações processuais da instituição. É possível, inclusive, em determinados momentos estes servidores acessarem serviços disponibilizados pelos Web Services, encapsular o resultado e trabalhá-lo para responder a uma determinada solicitação; Servidor de Banco de Dados ilustra os demais recursos que um ambiente distribuído pode compartilhar. No caso, trata-se de um repositório de dados. Conjunto de Web Services Os Web Services são componentes sistêmicos constituídos por um conjunto de funcionalidades. Estas funcionalidades são, como visto, expostas para acesso através de protocolos de comunicação padrões da internet. Ve-se, contudo, que os Web Services apesar de serem conceitualmente flexíveis, o são a partir do momento de sua liberação para acesso externo, ou seja, a flexibilidade oferecida por eles está na possibilidade de acessarmos funcionalidades através de protocolos padrões. Entretanto, o modelo tradicional não trata da flexibilidade quanto à concepção e construção de Web Services. Imaginemos, pois, um cenário de necessidades variáveis em que, por conta disto, sejam necessárias a publicação de diferentes serviços através de Web Services. Neste caso, é necessário que, para cada nova necessidade, uma nova funcionalidade seja agregada a um determinado Web Service para então ser liberado para o consumo.

52 52 4 WEB SERVICE GENÉRICO O modelo de proposto pelos Web Services genéricos credita a outras tecnologias a possibilidade de generalização do conceito de disponibilização de serviços. Através da junção de conceitos propostos basicamente pelas tecnologias Reflection e Remoting, é possível um ganho significativo na flexibilidade da concepção e construção de Web Services. Em um modelo de sistemas distribuídos a utilização de Web Services Genéricos apresenta um cenário semelhante ao encontrado em modelos tradicionais quanto ao consumo de serviços. A grande mudança observada está em seu projeto e desenvolvimento, onde se observa a existência de um único Web Service responsável pelo provimento de n serviços. Contudo, a manipulação dos serviços é realizada de maneira indireta. O Web Service não implementa a lógica envolvida na concepção do serviço, mas sim o reflete de alguma aplicação que o implemente. Este conceito de reflexão permite uma grande possibilidade de serviços capazes de serem distribuídos, sem a necessidade de manutenção de um Web Service responsável por esta tarefa. Para que este isolamento seja viabilizado, o Web Service Genérico foi construído a partir de conceitos extraídos de técnicas reflexivas utilizando, por conseguinte, algoritmos reflexivos sobre os assembly da aplicação-alvo. Tal aplicação é tida como alvo, pois esta possui a funcionalidade que um determinado cliente está requisitando. Sendo assim, o Web Service Genérico terá um papel de intermediar esta requisição, sendo responsável por invocar o processamento da rotina requisitada, bem como encapsular o resultado emitido em uma mensagem-resposta ao cliente. Portanto, os passos executados, compreendidos entre a requisição e o recebimento da resposta pelo cliente/requerente, da seguinte forma: a partir do momento

53 53 em que o Web Service Genérico recebe uma requisição, este realiza processamentos reflexivos que determinam o assembly a ser processado em um sistema.net (este contido no servidor de aplicação). Através da leitura de seu respectivo metadado, são determinados detalhes (capítulo 4.1) sobre a maneira com que determinada funcionalidade deverá ser manipulada e invocada de modo a processar os dados de entrada informados. Entretanto, existe um detalhe importante a ser observado. Visto que a aplicação contida no servidor de aplicação será acessada de maneira implícita, faz-se necessário a utilização de uma entidade que represente o acesso e ative os objetos necessários durante o processo de invocação da funcionalidade requisitada pelo cliente. Para tal, é necessário trabalhar com as premissas expostas pela tecnologia Remoting. Através desta técnica, é possível que sejam feitas instâncias remotas do objeto requisitado e, com posse da referência desta instância, a funcionalidade deste objeto pode ser invocada. Após este processo, o resultado gerado por tal rotina é serializado, empacotados através do protocolo SOAP e enviados ao processo requerente. Este processamento é demonstraado através da figura abaixo. HTTP/SOAP Figura 30 Modelo Web Services Genéricos

54 Funcionamento A interação existente entre o cliente e o serviço em um cenário que utiliza Web Services Genéricos não é em sua totalidade diferente de um ambiente que contenha Web Services tradicionais. Basicamente, o processo consiste na chamada de um determinado WebMethod, cuja descrição está contida no WSDL respectivo. Por conseguinte, a requisição é processada e o resultado gerado é encapsulado em uma mensagem XML para ser enviada ao cliente. Entretanto, a primeira grande diferença observada na utilização de Web Services Genéricos é encontrada em seu próprio descritor (WSDL), conforme ilustra figura 31. Neste, é possível verificar a existência de um só método chamado: Get. A descrição deste método é acrescida da especificação dos quatro parâmetros por ele esperados: pnamespace: nome do Namespace desejado que contém a classe desejada; pclass: nome da classe que contém a funcionalidade desejada; pmethod:nome do método que implementa a funcionalidade desejada; pparameter: parâmetros de entrada do método que implementa a funcionalidade desejada. Figura 31 Web Service Genérico - WSDL Estes parâmetros esperados pelo Web Service Genérico são utilizados para a determinação do assembly que fornecerá uma determinada funcionalidade, bem como artefatos para que esta interação seja possível (como os parâmetros de entrada do método da aplicação-alvo). Quando, então, o cliente realiza a chamada do WebMethod Get a primeira coisa realizada é determinar o assembly detentor do Namespace informado. Isto é realizado através da leitura de todos os metadado dos assembly de uma determinada aplicação.net. Ainda sobre o metadado são verificadas as ocorrências do método cuja descrição

55 55 foi passada pelo cliente. É previsível que possam ser encontradas n ocorrências de métodos de mesmo nome, pois estes podem ter sido sobrecarregados (Orientação a Objetos). Desta maneira, para determinar o método correto a ser utilizado para atender a requisição do cliente, são considerados os parâmetros. Este critério é subdividido em duas partes: a quantidade de parâmetros informados e o seus respectivos tipos. Para exemplificar o processamento deste critério seja avaliado o seguinte exemplo: uma classe implementa dois métodos cujas assinaturas são: a. public decimal Soma(int x, int y); b. public decimal Soma(int[] x). De acordo com o processo reflexivo a partir do metadado são realizados testes de compatibilidade entre parâmetros esperados e os parâmetros informados. Ao final desta análise é possível determinar com exatidão se o cliente está invocando, considerando o exemplo exposto, o método a ou o método b. Após este período reflexivo é então realizado o instanciamento remoto do objeto através de Remoting. Visto que o processo de Reflection determinou o assembly, classe e o método a ser utilizado, tal classe é instanciada e um wrapper recebe a serialização do objeto de retorno. Com este retorno, o Web Service Genérico então prepara o processo de encapsulamento em uma mensagem XML com estrutura padronizada. Este padrão é definido no intuito de facilitar o processo de leitura e interpretação do resultado gerado, por parte do invocador do serviço (cliente). O XML de retorno possui determinados nodos possíveis que podem ser esperados pelo cliente, sendo: <Result> que contém o resultado gerado nos casos de sucesso do processamento e <Error> contendo a descrição dos problemas que podem ter sido decorrentes do processo de reflexão, instanciamento remoto ou ainda exceções geradas pela aplicação-alvo. Desta maneira, a aplicação-cliente poderá realizar a leitura dos nodos do XML da forma que julgar adequada. Reitera-se assim, que a utilização dos serviços disponibilizados pelo Web Service Genérico não depende, em nenhum aspecto da origem de sua chamada, visto que a única ligação existente entre os dois é o protocolo HTTP/SOAP.

56 56 5 ESTUDO DE CASO Para atender as novas tendências mercadológicas e o aumento da demanda de clínicas e consultórios médicos de grande porte, é necessária a construção e/ou adaptação dos sistemas especialistas para adequação a esta nova realidade. Tais adaptações devem ser objetivadas na construção de subsídios ao controle gerencial e operacional destes ambientes. Além disto, devem possibilitar através de sua utilização o ajuste dos processos clínicos, a melhoria da utilização dos recursos disponíveis, e, por conseguinte, a maximização dos resultados. Neste sentido, seja considerado um sistema desktop que possua funcionalidades específicas e cuja atuação esteja restrita ao controle do agendamento de pacientes, prontuário médico e respectivo atendimento em um consultório médico. Para que tal sistema seja adequado às novas necessidades demandadas pelo mercado, este deverá ser reformulado de forma a agregar as funcionalidades que não são por ele contempladas. Esta adaptação pode ocorrer de duas maneiras distintas: programação das funcionalidades faltantes, ou através da integração com outro sistema utilizando o conceito de Web Service Genérico. Tem-se, portanto, dois cenários possíveis onde a aplicação da primeira opção é tecnicamente simplificada, pois os profissionais envolvidos não perceberiam modificações quanto às tecnologias utilizadas, entretanto o tempo necessário para que estas alterações sejam concluídas pode onerar o processo de forma a inviabilizá-lo. Quanto à aplicação da segunda opção é observada uma necessidade de capacitação dos profissionais, pois modifica o cotidiano tecnológico existente e demanda tempo em pesquisa para a definição das melhores práticas a serem utilizadas na chamada dos serviços por parte da aplicação desktop. Todavia, fica nítido o aumento da robustez do sistema, por adotar esta alternativa, pois o isolamento proposto pela utilização dos Web

57 57 Services Genéricos facilitaria a agregação futura de novas funcionalidades e grande adaptabilidade do sistema desktop frente às demandas mercadológicas. Avaliando as possibilidades expostas e por questões estratégicas da empresa fabricante do sistema desktop foi firmada a adoção da segunda opção demonstrada, ou seja, o cenário operacional, conforme ilustra figura 32, seria composto pela coexistência da aplicação desktop e uma aplicação Web, cujo comunicação seria intermediada por um Web Service Genérico. Aplicação.NET (Web) Web ServiceGenérico Servidor de Banco de Dados Objeto Remoto Servidor de Banco de Dados Aplicação Delphi (Desktop) Figura 32 Integrando as funcionalidades da Aplicação Web Dando continuidade à especificação deste cenário, são observadas as características tecnológicas da aplicação Web a ser integrada: tecnologia ASP.Net; ambiente Web; três camadas (3-layer), ou seja, um sistema de gerenciamento de banco de dados, uma camada de negócio (responsável pela lógica do sistema) e uma camada de interação com o usuário (UI). Quanto às características da aplicação desktop: tecnologia Delphi; ambiente desktop; duas camadas (2-layer), ou seja, um sistema gerenciador de banco de dados (SGBD) e um ambiente de interação com o usuário que agrupa a lógica de

Introdução a Web Services

Introdução a Web Services Introdução a Web Services Mário Meireles Teixeira DEINF/UFMA O que é um Web Service? Web Service / Serviço Web É uma aplicação, identificada por um URI, cujas interfaces podem ser definidas, descritas

Leia mais

Web Services. Integração de aplicações na Web. Sistemas Distribuídos

Web Services. Integração de aplicações na Web. Sistemas Distribuídos Web Services Integração de aplicações na Web Integração de Aplicações na Web Interoperação entre ambientes heterogêneos desafios diversidade de componentes: EJB, CORBA, DCOM... diversidade de linguagens:

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br CORBA Common Object Request Broker Architecture Unicamp Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br Objetivos Apresentação Tecnologia CORBA Conceitos Básicos e Terminologia Considerações

Leia mais

Sistemas Distribuídos Arquiteturas Middlewares

Sistemas Distribuídos Arquiteturas Middlewares Sistemas Distribuídos Arquiteturas s Arquitetura Arquitetura de um sistema é sua estrutura em termos dos componentes e seus relacionamentos Objetivo: garantir que a estrutura satisfará as demandas presentes

Leia mais

INTEROPERABILIDADE ENTRE APLICAÇÕES.NET

INTEROPERABILIDADE ENTRE APLICAÇÕES.NET INTEROPERABILIDADE ENTRE APLICAÇÕES.NET Ricielli Pelissoli Martins Orientador: Luiz Gustavo Mählmann Universidade Luterana do Brasil (ULBRA) Sistemas de Informação Canoas RS Brasil ricielli@gmail.com,

Leia mais

MADALENA PEREIRA DA SILVA SLA Sociedade Lageana de Educação DCET Departamento de Ciências Exatas e Tecnológica

MADALENA PEREIRA DA SILVA SLA Sociedade Lageana de Educação DCET Departamento de Ciências Exatas e Tecnológica MADALENA PEREIRA DA SILVA SLA Sociedade Lageana de Educação DCET Departamento de Ciências Exatas e Tecnológica Desenvolvimento de Web Services com SOAP. 1. Introdução. Com a tecnologia de desenvolvimento

Leia mais

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com. Consumindo um Web Service através de uma Aplicação Comercial em Android Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.br 08/2014 Agenda Introdução Conceitos Web Service Por que utilizar

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

SOAP. Web Services & SOAP. Tecnologias de Middleware 2004/2005. Simple Object Access Protocol. Simple Object Access Protocol SOAP

SOAP. Web Services & SOAP. Tecnologias de Middleware 2004/2005. Simple Object Access Protocol. Simple Object Access Protocol SOAP Web Services & SOAP Tecnologias de Middleware 2004/2005 SOAP Simple Object Access Protocol Os web services necessitam de comunicar entre eles e trocar mensagens. O SOAP define a estrutura e o processamento

Leia mais

Serviços Web: Introdução

Serviços Web: Introdução Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Mecanismos de Comunicação Protocolos de Aplicação Mecanismos de comunicação

Leia mais

Introdução Serviços Web WSDL SOAP UDDI Ferramentas. Serviços Web. (Web Services) Emerson Ribeiro de Mello

Introdução Serviços Web WSDL SOAP UDDI Ferramentas. Serviços Web. (Web Services) Emerson Ribeiro de Mello 1/39 Serviços Web (Web Services) Emerson Ribeiro de Mello Departamento de Automação e Sistemas Universidade Federal de Santa Catarina 22 de Maio de 2007 2/39 Arquitetura Orientada a Serviços Arquitetura

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

Ambientes Visuais. Ambientes Visuais

Ambientes Visuais. Ambientes Visuais Ambientes Visuais Inicialmente, apenas especialistas utilizavam os computadores, sendo que os primeiros desenvolvidos ocupavam grandes áreas e tinham um poder de processamento reduzido. Porém, a contínua

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

Leia mais

Arquitetura de Software: Uma Central para Gestão da execução de serviços

Arquitetura de Software: Uma Central para Gestão da execução de serviços Arquitetura de Software: Uma Central para Gestão da execução de serviços ADILSON FERREIRA DA SILVA Centro Paula Souza São Paulo Brasil afs.software@gmail.com Prof.a. Dr.a. MARILIA MACORIN DE AZEVEDO Centro

Leia mais

REST Um Estilo de Arquitetura de Sistemas Distribuídos

REST Um Estilo de Arquitetura de Sistemas Distribuídos REST Um Estilo de Arquitetura de Sistemas Distribuídos Márcio Alves de Araújo¹, Mauro Antônio Correia Júnior¹ 1 Faculdade de Computação Universidade Federal de Uberlândia (UFU) Monte Carmelo MG Brasil

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

PROGRAMAÇÃO SERVIDOR WEBSERVICES EM SISTEMAS WEB. Prof. Dr. Daniel Caetano 2012-1

PROGRAMAÇÃO SERVIDOR WEBSERVICES EM SISTEMAS WEB. Prof. Dr. Daniel Caetano 2012-1 PROGRAMAÇÃO SERVIDOR EM SISTEMAS WEB WEBSERVICES Prof. Dr. Daniel Caetano 2012-1 Objetivos Compreender o que é um WebService e sua utilidade Compreender a lógica de funcionamento de um WebService Capacitar

Leia mais

Modelagem de Sistemas Web. Ferramentas e metodologias para projeto de sistemas web

Modelagem de Sistemas Web. Ferramentas e metodologias para projeto de sistemas web Modelagem de Sistemas Web Aula 4 Ferramentas e metodologias para projeto de sistemas web Ferramentas e metodologias para projeto de sistemas web Ferramentas CASE Fontes: Sarajane e Marques Peres Introdução

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

Web services. Um web service é qualquer software que está disponível através da Internet através de uma interface XML.

Web services. Um web service é qualquer software que está disponível através da Internet através de uma interface XML. Web services Um web service é qualquer software que está disponível através da Internet através de uma interface XML. XML é utilizado para codificar toda a comunicação de/para um web service. Web services

Leia mais

tecnologias web e gestão de identidade

tecnologias web e gestão de identidade tecnologias web e gestão de identidade histórico serviços da era inicial da Internet telnet ftp gopher - estruturas hierárquicas www - hipertexto estudos sobre hipertexto e hipermídia sistemas locais www

Leia mais

Serviços Web: Arquitetura

Serviços Web: Arquitetura Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

A utilização do JSWDP para construção de Web Services

A utilização do JSWDP para construção de Web Services A utilização do JSWDP para construção de Web Services Fabiana Ferreira Cardoso 1, Francisco A. S. Júnior 1, Madianita Bogo 1 1 Centro de Tecnologia da Informação Centro Universitário Luterano de Palmas

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

Microsoft.NET. Desenvolvimento Baseado em Componentes

Microsoft.NET. Desenvolvimento Baseado em Componentes Microsoft.NET Lirisnei Gomes de Sousa lirisnei@hotmail.com Jair C Leite jair@dimap.ufrn.br Desenvolvimento Baseado em Componentes Resolução de problemas específicos, mas que podem ser re-utilizados em

Leia mais

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações Universidade de São Paulo Escola Politécnica Programa de Educação Continuada em Engenharia PROGRAMA DE MBA em Gestão e Engenharia do Produto O Produto Internet e suas Aplicações Tecnologias de Informação

Leia mais

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc. Implementar servidores de Web/FTP e DFS Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Conteúdo programático Introdução ao protocolo HTTP Serviço web

Leia mais

CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB

CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB CONSTRUÇÃO DE APLICAÇÕES DISTRIBUÍDAS UTILIZANDO SERVIÇOS WEB Deusa Cesconeti e Jean Eduardo Glazar Departamento de Ciência da Computação Faculdade de Aracruz UNIARACRUZ {dcescone, jean}@fsjb.edu.br RESUMO

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

A Estrutura de um Web Service

A Estrutura de um Web Service A Estrutura de um Web Service Paulo Vitor Antonini Orlandin paulovitor_e@hotmail.com Resumo Atualmente, o Serviço Web é a solução mais utilizada para integração entre sistemas, pois apresenta vantagens

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES Sistema de Informação e Tecnologia FEQ 0411 Prof Luciel Henrique de Oliveira luciel@uol.com.br Capítulo 5 INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES PRADO, Edmir P.V.; SOUZA, Cesar A. de. (org). Fundamentos

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Porque adotar SOA. (Service Oriented Architecture) SOA. Por Ricardo de Castro Barbosa. Publicado Setembro/2008. 1 Portal BPM - www.portalbpm.com.

Porque adotar SOA. (Service Oriented Architecture) SOA. Por Ricardo de Castro Barbosa. Publicado Setembro/2008. 1 Portal BPM - www.portalbpm.com. SOA Porque adotar SOA (Service Oriented Architecture) Por Ricardo de Castro Barbosa Publicado Setembro/2008 Ricardo de Castro Barbosa é sócio da SOA- Savoir Faire (www.soa-savoirfaire.com.br) empresa dedicada

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Kassius Vargas Prestes

Kassius Vargas Prestes Kassius Vargas Prestes Agenda 1. Introdução Web Services 2. XML, SOAP 3. Apache Tomcat 4. Axis 5. Instalação Tomcat e Axis 6. Criação de um Web Service 7. Criação de um cliente Baixar http://www.inf.ufrgs.br/~kvprestes/webservices/

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Sistemas Distribuídos Comunicação entre Processos em Sistemas Distribuídos: Middleware de comunicação Aula II Prof. Rosemary Silveira F. Melo Comunicação em sistemas distribuídos é um ponto fundamental

Leia mais

XML. 1. XML: Conceitos Básicos. 2. Aplicação XML: XHTML 3. Folhas de Estilo em Cascata XML

XML. 1. XML: Conceitos Básicos. 2. Aplicação XML: XHTML 3. Folhas de Estilo em Cascata XML 1 1. : Conceitos Básicos 2. Aplicação : XHTML 3. Folhas de Estilo em Cascata 2 é um acrônimo para EXtensible Markup Language é uma linguagem de marcação muito parecida com HTML foi designada para descrever

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE. Kellen Kristine Perazzoli 1, Manassés Ribeiro 2 RESUMO

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE. Kellen Kristine Perazzoli 1, Manassés Ribeiro 2 RESUMO INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE Kellen Kristine Perazzoli, Manassés Ribeiro RESUMO O grande avanço tecnológico vivenciado nos últimos anos, os web services vem sendo utilizados trazendo

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

SOA - Service Oriented Architecture. Marcelo Canevello Ferreira

SOA - Service Oriented Architecture. Marcelo Canevello Ferreira SOA - Service Oriented Architecture Marcelo Canevello Ferreira Índice Arquitetura baseada em componentes Introdução a SOA Principais conceitos de SOA SOA Framework Abordagem de integração Conclusões Evolução

Leia mais

Usando Borland DELPHI para implementar aplicações CORBA

Usando Borland DELPHI para implementar aplicações CORBA Página 1 de 10 USANDO BORLAND DELPHI PARA IMPLEMENTAR APLICAÇÕES CORBA por Simone Vey Dutra e César Bridi Introdução A Arquitetura CORBA Criando uma Aplicação CORBA em Delphi Criando um Servidor CORBA

Leia mais

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Conceitos Gerais Graça Bressan Graça Bressan/LARC 2000 1 Forças de marketing que conduzem à arquitetura cliente/servidor "Cliente/Servidor é um movimento irresistível que está reformulando

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1. Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1. Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3 INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1 Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3 INTRODUÇÃO Atualmente empresas de diversos portes estão encontrando nos web services soluções para seus

Leia mais

Gerenciamento e Interoperabilidade de Redes

Gerenciamento e Interoperabilidade de Redes EN-3610 Gerenciamento e Interoperabilidade de Redes Gerenciamento baseado na Web Prof. João Henrique Kleinschmidt Gerenciamento baseado na Web Web browser Acesso ubíquo Interface Web vs Gerenciamento baseado

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

Leia mais

Desenvolvimento Cliente-Servidor 1

Desenvolvimento Cliente-Servidor 1 Desenvolvimento Cliente- 1 Ambiienttes de Desenvollviimentto Avançados Engenharia Informática Instituto Superior de Engenharia do Porto Alexandre Bragança 1998/99 Ambientes de Desenvolvimento Avançados

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

Web Services. Tópicos. Motivação. Tecnologias Web Service. Passo a passo Business Web Conclusão. Integração de aplicações SOAP, WSDL, UDDI, WSFL

Web Services. Tópicos. Motivação. Tecnologias Web Service. Passo a passo Business Web Conclusão. Integração de aplicações SOAP, WSDL, UDDI, WSFL Web Services Antonio Dirceu adrvf@cin.ufpe.br Tópicos Motivação Integração de aplicações Tecnologias Web Service SOAP, WSDL, UDDI, WSFL Passo a passo Business Web Conclusão Motivação Integração de Aplicações

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Universidade Federal de Juiz de Fora Ciência da Computação Sistemas Distribuídos Professor Ciro Barbosa

Universidade Federal de Juiz de Fora Ciência da Computação Sistemas Distribuídos Professor Ciro Barbosa Universidade Federal de Juiz de Fora Ciência da Computação Sistemas Distribuídos Professor Ciro Barbosa Web Service Plínio Antunes Garcia Sam Ould Mohamed el Hacen Sumário Introdução conceitual O Web Service

Leia mais

Padrões Arquiteturais. Sistemas Distribuídos: Broker

Padrões Arquiteturais. Sistemas Distribuídos: Broker Padrões Arquiteturais Sistemas Distribuídos: Broker Sistemas Distribuídos Tendências: Sistemas Comp. com múltiplas CPUs Redes locais com centenas de hospedeiros Benefícios Economia Desempenho e escalabilidade

Leia mais

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Professora: Sheila Cáceres Computador Dispositivo eletrônico usado para processar guardar e tornar acessível informação. Tópicos de Ambiente

Leia mais

Anexo VI Edital nº 03361/2008. Projeto de Integração das informações de Identificação Civil. 1. Definições de interoperabilidade adotadas pela SENASP

Anexo VI Edital nº 03361/2008. Projeto de Integração das informações de Identificação Civil. 1. Definições de interoperabilidade adotadas pela SENASP Anexo VI Edital nº 03361/2008 Projeto de Integração das informações de Identificação Civil 1. Definições de interoperabilidade adotadas pela SENASP A Senasp procura adotar os padrões de interoperabilidade

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Autoria Web Apresentação e Visão Geral sobre a Web

Autoria Web Apresentação e Visão Geral sobre a Web Apresentação e Visão Geral sobre a Web Apresentação Thiago Miranda Email: mirandathiago@gmail.com Site: www.thiagomiranda.net Objetivos da Disciplina Conhecer os limites de atuação profissional em Web

Leia mais

Computação Distribuída, Web Service - um estudo de caso

Computação Distribuída, Web Service - um estudo de caso CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO Diogo Francisco Sales da Silva Flávio Rodrigo Lovatti Computação Distribuída, Web Service - um estudo de caso VILA VELHA 2009 Diogo Francisco

Leia mais

Arquitetura Orientada a Serviço

Arquitetura Orientada a Serviço Arquitetura Orientada a Fabio Perez Marzullo IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society 1 SOA e Web Services SOA é um modelo

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Web Services. Autor: Rômulo Rosa Furtado

Web Services. Autor: Rômulo Rosa Furtado Web Services Autor: Rômulo Rosa Furtado Sumário O que é um Web Service. Qual a finalidade de um Web Service. Como funciona o serviço. Motivação para o uso. Como construir um. Referências. Seção: O que

Leia mais

Guia de Consulta Rápida HTTP. Décio Jr. Novatec Editora. www.novateceditora.com.br

Guia de Consulta Rápida HTTP. Décio Jr. Novatec Editora. www.novateceditora.com.br Guia de Consulta Rápida HTTP Décio Jr. Novatec Editora www.novateceditora.com.br Guia de Consulta Rápida HTTP de Décio Jr. Copyright 2001 da Novatec Editora Ltda. Todos os direitos reservados. É proibida

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Soquetes Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos

Leia mais

GERÊNCIA DE DADOS SEMI ESTRUTURADOS -XML. Prof. Angelo Augusto Frozza, M.Sc.

GERÊNCIA DE DADOS SEMI ESTRUTURADOS -XML. Prof. Angelo Augusto Frozza, M.Sc. GERÊNCIA DE DADOS SEMI ESTRUTURADOS -XML Prof. Angelo Augusto Frozza, M.Sc. O QUE É XML? Tecnologia desenvolvida pelo W3C http://www.w3c.org W3C: World Wide Web Consortium consórcio formado por acadêmicos

Leia mais

Adriano Reine Bueno Rafael Barros Silva

Adriano Reine Bueno Rafael Barros Silva Adriano Reine Bueno Rafael Barros Silva Introdução RMI Tecnologias Semelhantes Arquitetura RMI Funcionamento Serialização dos dados Criando Aplicações Distribuídas com RMI Segurança Exemplo prático Referências

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

GERÊNCIA DE DADOS SEMIESTRUTURADOS -XML. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

GERÊNCIA DE DADOS SEMIESTRUTURADOS -XML. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza GERÊNCIA DE DADOS SEMIESTRUTURADOS -XML Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza O QUE É XML? Tecnologia desenvolvida pelo W3C http://www.w3c.org W3C: World Wide Web Consortium consórcio

Leia mais

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

Boas Práticas de Desenvolvimento Seguro

Boas Práticas de Desenvolvimento Seguro Boas Práticas de Desenvolvimento Seguro Julho / 2.012 Histórico de Revisões Data Versão Descrição Autor 29/07/2012 1.0 Versão inicial Ricardo Kiyoshi Página 2 de 11 Conteúdo 1. SEGURANÇA DA INFORMAÇÃO

Leia mais

Programação Cliente em Sistemas Web

Programação Cliente em Sistemas Web Programação Cliente em Sistemas Web WEBSERVICES Cap 18. - Sistemas distribuídos e serviços web em Deitel, H.M, Sistemas Operacionais, 3 ª edição, Pearson Prentice Hall, 2005 Fonte: Rodrigo Rebouças de

Leia mais

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes.

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Componentes para Computação Distribuída

Componentes para Computação Distribuída Componentes para Computação Distribuída Conceitos Foi a partir do fenômeno da Internet (WWW), no início dos anos noventa, que a computação distribuída passou a ter relevância definitiva, a ponto de a Internet

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 14 SOA e ESB Service-Oriented

Leia mais

CORBA Common Object Request Broker Architecture. Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos

CORBA Common Object Request Broker Architecture. Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos CORBA Common Object Request Broker Architecture Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos Introdução OMG (Object Management Group): uma organização formada por empresas

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Comunicação Remota Gustavo Reis gustavo.reis@ifsudestemg.edu.br 1 Comunicação entre processos está no coração de todo sistema distribuído. Não tem sentido estudar sistemas distribuídos

Leia mais

PRnet/2013. Linguagem de Programação Web

PRnet/2013. Linguagem de Programação Web Linguagem de Programação Web Linguagem de Programação Web Prnet/2013 Linguagem de Programação Web» Programas navegadores» Tipos de URL» Protocolos: HTTP, TCP/IP» Hipertextos (páginas WEB)» HTML, XHTML»

Leia mais

UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA

UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA EDITAL DO PROGRAMA DE CERTIFICAÇÕES EM COMPUTAÇÃO MACK COMPUTING CERTIFICATION MCC 2º SEMESTRE DE 2014 O Diretor da Faculdade de Computação e Informática (FCI), no uso de suas atribuições estatutárias

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais