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=" SOAP-ENV:encodingStyle=" <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