faculdade dom bosco de porto alegre web services genéricos

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.
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.
DEDICATÓRIA
Dedico este trabalho especialmente a minha
família por sua participação fundamental em todas as
minhas conquistas.
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.
SUMÁRIO
LISTA DE FIGURAS .......................................................................................................... 7
RESUMO ............................................................................................................................. 8
1 INTRODUÇÃO ............................................................................................................. 10
2.1 OBJETIVOS .............................................................................................................. 11
2.2 MOTIVAÇÃO ............................................................................................................ 12
2 REFERENCIAL TEÓRICO......................................................................................... 13
2.1 EXTENSIBLE MARKUP LANGUAGE (XML) ............................................................... 13
2.1.1 Documentos XML........................................................................................... 14
2.1.2 Declaração ...................................................................................................... 15
2.1.3 Comentários .................................................................................................... 16
2.1.4 Instruções de Processamento ........................................................................... 16
2.1.5 Elementos ....................................................................................................... 16
2.2 SERVICE ORIENTED ARCHITECTURE (SOA) ............................................................. 17
2.2.1 Sistemas Conectados ....................................................................................... 17
2.2.2 Princípios da arquitetura baseada a serviços..................................................... 19
2.2.3 Serviço ............................................................................................................ 19
2.2.4 Componentes................................................................................................... 20
2.2.5 Modelagem de sistemas orientados a serviço ................................................... 21
2.2.6 Vantagens da utilização de SOA...................................................................... 23
2.3 WEB SERVICES ....................................................................................................... 23
2.3.1 Arquitetura ...................................................................................................... 24
2.3.1.1 Simple Object Access Protocol (SOAP)...................................................... 25
2.3.1.2 Web Service Description Language (WSDL) .............................................. 27
2.3.1.3 Universal Description Discovery and Integration (UDDI) ........................... 28
2.4 REFLECTION ........................................................................................................... 29
2.4.1 Aspectos Matemáticos da Reflexão ................................................................. 29
2.4.2 Reflexão em Linguagens Orientadas a Objeto.................................................. 30
2.4.3 Cenário de utilização ....................................................................................... 30
2.4.4 Meta-Objetos e o processo de Reflexão ........................................................... 31
2.4.5 .NET Reflection .............................................................................................. 32
2.5 REMOTING .............................................................................................................. 33
2.5.1 Arquiteturas distribuídas.................................................................................. 33
2.5.2 Tecnologias distribuídas .................................................................................. 36
2.5.3 Objetos Distribuídos........................................................................................ 37
2.5.4 Binding de Objetos.......................................................................................... 37
2.5.4.1 Early Binding ............................................................................................. 38
2.5.4.2 Late Binding ............................................................................................... 39
2.5.5 COM Callable Wrapper (CCW) ...................................................................... 40
2.5.6 Serialização de Objetos ................................................................................... 41
2.5.7 .NET Remoting ............................................................................................... 44
2.5.7.1 Arquitetura ................................................................................................. 45
2.5.7.2 Ativação de Objetos.................................................................................... 47
2.5.7.3 Benefícios das aplicações distribuídas......................................................... 47
3 CENÁRIOS ................................................................................................................... 49
3.1 MODELO TRADICIONAL DE UTILIZAÇÃO DE WEB SERVICES ...................................... 50
4 WEB SERVICE GENÉRICO....................................................................................... 52
4.1 FUNCIONAMENTO.................................................................................................... 54
5 ESTUDO DE CASO...................................................................................................... 56
5.1 VALIDAÇÃO ............................................................................................................ 58
6 CONCLUSÕES ............................................................................................................. 60
7 REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 62
LISTA DE FIGURAS
Figura 1 - Documento XML bem formado ........................................................................... 15
Figura 2 - Declaração de um documento XML..................................................................... 15
Figura 3 - Pilares dos sistemas conectados ........................................................................... 18
Figura 4 - Modelo da arquitetura orientada a serviços ......................................................... 21
Figura 5 - Modelo de orientação a serviços em três partes .................................................... 22
Figura 6 - Modelo básico de acesso a um Web Service ........................................................ 25
Figura 7 - Constituição de uma mensagem SOAP ................................................................ 25
Figura 8 - Exemplo de um envelope de requisição RPC ....................................................... 26
Figura 9 - Tráfego de mensagens via XML .......................................................................... 27
Figura 10 - Descrição gerada automaticamente pelo WSDL................................................. 27
Figura 11 - WSDL Preâmbulo.............................................................................................. 28
Figura 12 - Biblioteca de Classes do .NET Framework ........................................................ 32
Figura 13 - Exemplo de utilização da classe System.Type.................................................... 33
Figura 14 - Modelo Cliente/Servidor.................................................................................... 34
Figura 15 - Modelo N-Tier................................................................................................... 35
Figura 16 - Modelo Peer-to-Peer .......................................................................................... 35
Figura 17 - Seleção de objetos para Automação ................................................................... 38
Figura 18 - Automação de objetos via early-binding ............................................................ 39
Figura 19 - Automação de objeto via late-binding ................................................................ 40
Figura 20 - Chamada um objeto gerenciado (.NET) ............................................................. 40
Figura 21 - Classe que será serializada ................................................................................. 42
Figura 22 - Classe que invoca o processo de serialização ..................................................... 42
Figura 23 - Classe que será serializada ................................................................................. 43
Figura 24 - Processo de serialização/desserialização ............................................................ 44
Figura 25 - Arquitetura .NET Remoting............................................................................... 45
Figura 26 - Funcionamento do marshal-by-value ................................................................. 45
Figura 27 - Funcionamento do marshal-by-reference............................................................ 46
Figura 28 - Acesso a tipos de instância context-bound.......................................................... 46
Figura 29 - Modelo Web Services ........................................................................................ 50
Figura 30 - Modelo Web Services Genéricos ....................................................................... 53
Figura 31 - Web Service Genérico - WSDL ......................................................................... 54
Figura 32 - Integrando as funcionalidades da Aplicação Web............................................... 57
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
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
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
1.2
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
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 8879.
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
•
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.
2.1.1 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
•
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
2.1.2 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
2.1.3 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)
2.1.4 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)
2.1.5 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
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.
2.2.1 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
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
2.2.2 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)
2.2.3 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
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”;
2.2.4 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
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.
2.2.5 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
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
2.2.6 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
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.
2.3.1 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
Figura 6 – Modelo básico de acesso a um Web Service
2.3.1.1 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
•
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: www.stockquoteserver.com
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.
http://schemas.xmlsoap.org/soap/envelope/ possui o namespace padrão para
todas as mensagens SOAP;
•
O
encodingStyle
(estilo
de
codificação)
é
definido
pela
URI
http://schemas.xmlsoap.org/soap/encoding/ 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
•
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
2.3.1.2 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
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
2.3.1.3 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
2.4 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.
2.4.1 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 Dn, chamado nível básico, dentro de
um outro domínio computacional Dn+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 Dn é
composto de um conjunto de entidades e expressões, escritas em uma linguagem Ln, e
de um interpretador In que interpreta estas expressões.
O interpretador é escrito em uma linguagem Ln+1 que por sua vez é interpretado
por um interpretador In+1. Quando o sistema não é reflexivo, a linguagem Ln+1 é
completamente diferente da linguagem Ln. Por exemplo, se L1 é uma linguagem LISP,
L2 pode ser uma linguagem como Pascal ou C, L3 o conjunto de instruções da
linguagem de maquina, etc.
Sendo assim, em arquiteturas reflexivas, existe uma infinita cadeia virtual de
linguagens idênticas Li, também conhecidas como torre reflexiva. Este cenário é
possível devido a existência de um interpretados, escrito em uma linguagem L’
30
diferente de Li, que é usada para isolar a regressão e substituir o interpretador In 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.
2.4.2 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.
2.4.3 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
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.
2.4.4 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
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.
2.4.5 .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
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.
2.5.1 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
•
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
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-toPeer 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
2.5.2 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
2.5.3 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;
2.5.4 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
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.
2.5.4.1 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
• 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
2.5.4.2 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
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
2.5.5 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
2.5.6 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
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
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
using
using
using
using
System;
System.Collections;
System.IO;
System.Xml;
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
ShoppingList myList
myList.AddItem( new
myList.AddItem( new
myList.AddItem( new
= new
Item(
Item(
Item(
ShoppingList();
"eggs",1.49 ) );
"ground beef",3.69 ) );
"bread",0.89 ) );
// Serialization
XmlSerializer s = new XmlSerializer( typeof( ShoppingList ) );
TextWriter w = new StreamWriter( @"c:\list.xml" );
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
2.5.7 .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
2.5.7.1 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
•
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
2.5.7.2 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.
2.5.7.3 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
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
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
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
O
/S
TP
T
H
AP
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
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
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
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.
OA
/S
TP
T
H
P
Figura 30 – Modelo Web Services Genéricos
54
4.1
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
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
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
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)
Servidor de
Banco de Dados
Servidor de
Banco de Dados
Web ServiceGenérico
Objeto
Remoto
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
58
negócio e interface com usuário (UI). É instalado em cada computador que
trabalhará com o sistema.
Através de componentes nativos dedo Delphi, foi possível realizar a construção
de uma biblioteca (DLL) responsável por enviar mensagem SOAP ao Web Service
Genérico. Esta mensagem era composta por informações que subsidiasse a manipulação
das funcionalidades da aplicação-alvo (Web) através do Web Service Genérico.
Além disto, foi utilizado o componente TXMLDocument para a leitura e
manipulação do XML retorno gerado pelo WebService Genérico. Por intermédio deste
componente, foram realizadas as leituras aos nodos que continham as informações
buscadas, integrando-as ao fluxo do sistema.
5.1
Validação
É importante salientar que o cenário exposto no estudo de caso demonstra
simultaneamente a manipulação de componentes gerenciados e não-gerenciados, ou
seja, componentes que rodam sobre a plataforma .NET e outros de responsabilidade
exclusiva do sistema operacional. Por conseguinte, para que a aplicação desktop fosse
capaz de realizar chamadas as rotinas da aplicação Web foi necessário que a biblioteca
de tipos (type-library) fosse extraída do assembly .NET, ou de alguma forma, esta
ficasse visível ao ambiente não gerenciado. Isto se deve ao fato dos assembly .NET
possuírem o type-library intrínseco em seu metadado, ao contrário dos componentes
COM não gerenciados.
É bem verdade que esta integração seria tecnicamente possível em cenários
distribuídos que utilizam tecnologias de distribuição COM como DCOM ou CORBA.
Entretanto, estas tecnologias inviabilizam o processo em um ambiente heterogêneo,
como este apresentado, pois são tecnologias fortemente dependentes de plataforma.
Haja vista, com a migração da tecnologia da aplicação-cliente de delphi para Java, por
exemplo, necessitar uma reformulação arquitetural do ambiente distribuído e, por
conseguinte, da definição de outroas tecnologias de distribuição.
Mais ainda, seria possível estender o conceito de binding agregando o COM
Callable Wrapper para viabilizar a interação entre a aplicação desktop e a aplicação
Web .NET. Neste cenário, através do proxy gerado pelo CCW seria possível que
qualquer outra aplicação que suportasse automação de objetos realizasse chamadas aos
59
objetos gerenciados (.NET). Todavia, novamente são encontrados limites quando a
plataforma operacional, não uma solução viável se a aplicação que interagisse com o
sistema .NET fosse baseada em UNIX, por exemplo.
Desta
forma,
o
reaproveitamento
de
recursos
através
de
serviços
disponibilizados pelos Web Services Genéricos se mostrou a solução mais eficaz, poisa
agregou características que eram imprescindíveis para contemplar tal integração, como:
•
compatibilidade: os Web Services utilizam protocolos de comunicação e
formatos de dados padrões, independente da plataforma ou linguagem de
programação;
•
manutenabilidade: a manutenção é um ponto alto na utilização dos Web
Services Genéricos. Enquanto que tecnologias baseadas em RPC (Remote
Procedure Call), como DCOM, CORBA, entre outros, onde a alteração de
um determinado item no prestador do serviço (aplicação-alvo) demandará
uma mudança “em cascata”, os Web Services propõem alterações
independentes que podem ser efetuadas sem a necessidade de alterações
mútuas;
•
custo: a utilização de tecnologias baseadas em RPC pode se tornar inviável,
pois necessita de uma infra-estrutura mais abrangente e homogênea para
viabilizar a utilização de determinadas tecnologias. Por sua vez, os Web
Services são compatíveis com a maioria das infra-estruturas já estabelecidas
nas empresas, visto que este realizará todas as operações referentes a
comunicação de informações sobre protocolo HTTP.
60
6
CONCLUSÕES
Com o presente trabalho é possível entender os conceitos envolvidos na
manipulação de serviços em sua totalidade: fornecimento, distribuição e consumo.
Neste sentido, constata-se a arquitetura orientada a serviços (SOA) como um importante
artefato na concepção de sistemas especialistas, pois abrange premissas que garantem
um melhor tratamento das informações e maior flexibilidade frente às necessidades em
freqüente mudança.
Além disto, foi possível verificar com os capítulos anteriores a permanente
evolução das tecnologias de distribuição visando atender a necessidade de maximizar a
utilização dos recursos disponíveis em um ambiente distribuído. Entretanto, tais
tecnologias devem ser avaliadas sob aspectos que transcendem a viabilidade técnica e
considerem, inclusive, questões estratégicas de ordem mercadológica.
Neste sentido, com a apresentação da tecnologia dos Web Services é possível
compreender ambientes cujos recursos são explorados em sua totalidade sem limitações
decorrentes da interdependência entre componentes. Isto significa que, devido à adoção
de padrões universais, é possível observar uma maior robustez do ambiente distribuído,
pois são superados limites como: homogeneidade de plataformas operacionais e
dependência de protocolos de transporte e comunicação.
Por fim, foi verificado que a concepção de uma nova abordagem dos Web
Services através da agregação de tecnologias baseadas em reflexão e instanciamento
remoto é viável e agrega uma grande flexibilidade e produtividade na manipulação de
serviços. Isto é ilustrado através do estudo de caso que apresentou um cenário clássico
encontrado em ambientes distribuídos: a existência de sistemas heterogêneos que devem
coexistir e compartilharem informações. Viu-se que o processo de integração
apresentado foi significativamente facilitado através da utilização do conceito dos Web
61
Services Genéricos, pois este garantiu maior eficácia no gerenciamento dos serviços
aliado a uma grande facilidade de distribuição.
62
7
REFERÊNCIAS BIBLIOGRÁFICAS
OELLERMANN, William. Prepare a Empresa Orientada a serviços. The Architecture
Journal, Seatle, v. 7, p. 27-32, 2006.
SEHMI, Arvindra; SCHWEGLER, Beat. Modelagem Orientada a Serviços para
Sistemas Conectados – Parte 1. The Architecture Journal, Washington, v. 7, p. 27-32,
2006.
FERBER, J. Computational reflection in class based object-oriented languages. ed. New
York: ACM Press, 1989.
LEITE, José Carlos. XML e XSL da Teoria à Prática. ed. Lisboa: FCA, 2001.
OASIS. Reference Model for Service Oriented Architecture 1.0. <http://www.oasisopen.org/committees/download.php/19679/soa-rm-cs.pdf>. Acesso em: 15 novembro
2006
W3C. eXtensible Markup Language (XML). <http://www.w3.org/XML/>. Acesso em:
20 novembro 2006.
CORPORATION, Microsoft. ASP.NET Web The Official Microsoft ASP.NET Site
Home Page <http://www.asp.net/>. Acesso em: 2 novembro 2006.
W3C. Web Services. <http://www.w3.org/2002/ws/>. Acesso em: 22 novembro 2006.
63
WIKIPEDIA. Web Services. <http://pt.wikipedia.org/wiki/Web_service>. Acesso em:
22 novembro 2006.
MSDN. WebServices.
<http://www.microsoft.com/brasil/msdn/tecnologias/webservices/web_services_4.aspx>
Acesso em: 21 novembro 2006.
LINHA DE CÓDIGO. Consultando e invocando métodos dinamicamente usando
Reflection. <http://www.linhadecodigo.com.br/artigos.asp?id_ac=264>. Acesso em: 15
outubro 2006.
WIKIPEDIA. Reflection (Computer Science).
<http://en.wikipedia.org/wiki/Reflection_(computer_science)>.
Acesso
em:
18
novembro 2006.
WIKIPEDIA.
Service-oriented architecture.
<http://en.wikipedia.org/wiki/Service-
oriented_architecture>. Acesso em 18 novembro 2006.
W3C. SOAP – Specifications. <http:// www.w3.org/TR/soap/>. Acesso em: 20
novembro 2006.
ERL, Thomas. Service-Oriented Architecture : A Field Guide to Integrating XML and
Web Services (Paperback). ed. Indianápolis: Prentice Hall PTR, 2004
W3C. Web Service Definition Language (WSDL). <http://www.w3.org/TR/wsdl>.
Acesso em: 25 novembro 2006
MCLEAN, Scott; NAFTEL, James; WILLIAMS, Kim. Microsoft .NET Remoting. ed.
Washington: MS Press, 2003.
MSDN. COM Callable Wrapper.
< http://msdn2.microsoft.com/en-us/library/f07c8z1c.aspx> Acesso em: 03 junho 2006.