Limitações Arquiteturais

Para a correção das limitações apresentadas pela arquitetura cliente-servidor, propõe-se a utilização de outros padrões arquiteturais para a reconstrução do Sig2m, como n-Tier e a Orientada a Serviço [KEE2004], [TID2001].

3.4.1.1 Arquitetura n-Tier

É uma variante da arquitetura cliente-servidor, na qual os elementos do sistema distribuído estão organizados em camadas verticais (tiers). A arquitetura n-Tier comumente utilizada é a arquitetura 3-Tier, que é composta por 3 camadas, sendo cada uma responsável por um tipo de tarefa:

• Apresentação: contém os elementos responsáveis pela interação direta com o usuário;

• Lógica da Aplicação (ou lógica de negócio): contém os elementos responsáveis pela lógica da aplicação, faz o processamento da informação;

• Dados (Back-End): contém os elementos responsáveis pela persistência e consistência dos dados.

Os elementos de uma camada interagem apenas com elementos de camadas adjacentes. Os pontos de interação entre camadas devem explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços disponíveis em cada camada. Por exemplo, o ponto de interação entre as camadas de Apresentação e Lógica da Aplicação utiliza protocolos RMI ou HTTP para a troca de informações, conforme mostra a Figura 15.

Geralmente, a camada de Lógica da Aplicação fica armazenada em um Servidor de Aplicação. Um Servidor de Aplicação (também conhecido como software de middleware), trata-se de um software que é responsável por realizar a administração dos componentes da aplicação. A administração dos componentes envolve o fornecimento dos componentes em tempo de execução, gerência de sessão de acesso, monitoramento, segurança e balanceamento de carga, possibilitando ao desenvolvedor concentrar-se apenas na implementação da camada lógica da aplicação.

O Modelo MVC - Modelo, Visão e Controlador

Um dos modelos mais conhecidos da arquitetura 3-tier é o modelo MVC - Modelo, Visão e Controlador (tradução de Model, View e Controller), apresentado pela Figura 16. Esta arquitetura consiste em separar a aplicação em três camadas interoperáveis chamadas Modelo, Visão e Controlador [BUS1996].

A camada “modelo” contém o núcleo funcional da aplicação. Ele encapsula dados apropriados e exporta procedimentos que realizam o processamento específico da aplicação (regras de negócio). Os componentes controladores, por sua vez, invocam estes procedimentos, de acordo com as ações do usuário. O modelo também provê funções de acesso a dados que são utilizados pelo componente visão para apresentação do mesmo. Um modelo pode ter várias visões associadas a ele.

A camada “visão”, transforma o modelo em uma forma apropriada para interação (normalmente uma interface de usuário), que apresenta ao usuário, dados provenientes de um processamento realizado pelo modelo. Diferentes visões apresentam informações do modelo em diferentes formas. Cada visão possui um único controlador que, por sua vez, é associado ao modelo.

O componente “controlador” define o comportamento da aplicação, responde às ações do usuário (eventos) e provoca mudanças nos componentes modelo e visão. Ele interpreta os eventos do usuário, tais como entrada de teclado e cliques de mouse, e as mapeia para as chamadas do modelo. Os eventos são traduzidos em requisições de serviços ao modelo, o qual, realiza ativação das regras de negócio efetuando algum processamento. Com base nas ações do usuário (gerada na visão) e nos resultados do processamento no modelo, o

controlador seleciona uma visão a ser exibida. Em geral, existe um controlador para cada conjunto de funcionalidades relacionadas do sistema.

Figura 16 - Arquitetura MVC – Model, View e Controller.

3.4.1.2 Implementação do Sig2m sob a Arquitetura 3 - Tier

O Sig2m poderia ser reestruturado em três camadas, conforme a arquitetura 3-tier. O fato de uma estação Sig2m estar dividida em camadas facilitaria o acesso de uma estação aos recursos disponíveis de outra, como por exemplo, um componente da camada de Lógica de Aplicação da estação A acessar a camada de dados da estação B (vide Figura 17). Todo o gerenciamento de acesso entre o uso dos componentes seria regido pelo Servidor de Aplicação. Assim, problemas de acesso às informações de nível cliente-cliente e de congestionamento no servidor seriam sanados.

Figura 17 - Implementação do Sig2m sob arquitetura 3 -Tier.

3.4.1.3 Arquitetura Orientada a Serviço

A Arquitetura Orientada a Serviço (Service Oriented Architecture - SOA) é um tipo de arquitetura de processamento distribuído inter-organizacional, que tem como propósito manter a interoperabilidade e a segurança da informação utilizando uma arquitetura baseado no conceito de serviços. Serviços são aplicativos ou rotinas que são disponibilizadas em uma rede de computadores que encapsulam uma lógica de negócio, dotadas de uma interface de acesso independente de outros serviços. No SOA, os serviços podem ser acessados sem a necessidade de conhecer ou entender a sua plataforma de implementação.

Atualmente o SOA vem sendo implementado, utilizando a tecnologia baseada em serviços web (Web Services). Pode-se dizer que SOA baseado em Web Services é o corrente estado da arte na integração entre sistemas, pois esta tecnologia atende aos requisitos de interoperabilidade, através do uso de protocolos como HTTP, XML e SMTP, que são padrões de tráfego de informação para a web baseados no formato de texto [TID2001] [KEE2004].

A arquitetura de “Web Service” funciona como interface posicionada entre código da aplicação e o usuário provendo uma camada de abstração entre este e o código da aplicação, conforme ilustrado na Figura 18.

Figura 18 - Funcionamento da arquitetura de web services (Extraído de [TID2001]).

A estrutura de Web Services permite dividir uma aplicação em três camadas: • Camada de Aplicação: plataforma de suporte a serviços;

• Camada de Negócio: detém as regras de negócio definidas e suas políticas de uso; • Camada de Serviço: representa as interfaces e conexões entre os serviços, que são

elementos de ligação entre a camada de aplicação e a de negócio.

Na arquitetura de Web Services, o Provedor do Serviço descreve e publica o(s) serviço(s), sob forma de interface de invocação em um Registro de Serviços. As interfaces de invocação dos serviços são escritas em um arquivo descritor que possui formato

eXtensible Markup Language (XML), conhecido como Web Services Description Language

(WSDL). Quando o Consumidor do Serviço quer fazer uso de um serviço, este deve pesquisar e recuperar o serviço que necessita no Registro de Serviços, utilizando um protocolo chamado Universal Description, Discovery and Integration (UDDI). O Registro de Serviços retorna um documento conhecido como Web Services Description Language (WSDL) que contém especificações de localização do serviço, possibilitando o seu uso pelo consumidor. Este processo pode ser visualizado pela Figura 19. O tráfego da informação entre o serviço e seu requisitante é realizado por um protocolo chamado Simple Object

Access Protocol (SOAP). O protocolo SOAP é um conjunto de regras para representar a

informação em formato XML.

Figura 19 - Arquitetura de SOA - Web Services, adaptado de [TID2001].

As principais características da Arquitetura Orientada a Serviços são [BOO2007] [BIE2007]:

• Baixo acoplamento entre aplicações;

• Alta interoperabilidade entre plataformas tecnológicas; • Alta reutilização dos serviços (regras de negócio);

• Resposta rápida a mudanças nos processos de negócio; • Serviços são interoperáveis;

• Transparência sobre a implementação dos serviços;

• Serviços disponibilizados em plataforma Web;

• Interfaces especificadas em XML na sintaxe WSDL;

• Mensagens trocadas através de requisições HTTP no protocolo SOAP (via padrão XML);

• Podem ser implementados em diferentes tecnologias como Java, .Net, PL/SQL, C++, entre outros.

3.4.1.4 Implementação do Sig2m sob a Arquitetura de Web Services

Em uma proposta de arquitetura de Web Services para o Sig2m, os módulos estariam dispostos sob forma de serviços, em que cada estação do Sig2m acessaria os seus próprios serviços e o de outras estações, através de permissões específicas de acesso. Por exemplo, a estação A do Sig2m pode acessar o módulo de relatórios pertinentes à estação B, conforme ilustrado na Figura 20.

Figura 20 - Implementação do Sig2m sob arquitetura de Web Services.

3.4.2 Soluções propostas para as Limitações de Gestão de Materiais e