Arquitetura Distribuída
Na arquitetura distribuída, os componentes são apresentados em diferentes plataformas e vários componentes podem cooperar uns com os outros em uma rede de comunicação para atingir um objetivo ou meta específica.
Nessa arquitetura, o processamento da informação não está confinado a uma única máquina, mas sim distribuído por vários computadores independentes.
Um sistema distribuído pode ser demonstrado pela arquitetura cliente-servidor que forma a base para arquiteturas multicamadas; as alternativas são a arquitetura do broker, como CORBA, e a Arquitetura Orientada a Serviços (SOA).
Existem várias estruturas de tecnologia para oferecer suporte a arquiteturas distribuídas, incluindo .NET, J2EE, CORBA, serviços da Web .NET, serviços da Web AXIS Java e serviços Globus Grid.
Middleware é uma infraestrutura que oferece suporte adequado ao desenvolvimento e execução de aplicativos distribuídos. Ele fornece um buffer entre os aplicativos e a rede.
Ele fica no meio do sistema e gerencia ou oferece suporte aos diferentes componentes de um sistema distribuído. Exemplos são monitores de processamento de transações, conversores de dados e controladores de comunicação, etc.
Middleware como infraestrutura para sistema distribuído
A base de uma arquitetura distribuída é sua transparência, confiabilidade e disponibilidade.
A tabela a seguir lista as diferentes formas de transparência em um sistema distribuído -
| Sr. Não. | Transparência e descrição |
|---|---|
| 1 | Access Oculta a forma como os recursos são acessados e as diferenças na plataforma de dados. |
| 2 | Location Oculta onde os recursos estão localizados. |
| 3 | Technology Oculta do usuário diferentes tecnologias, como linguagem de programação e sistema operacional. |
| 4 | Migration / Relocation Oculte recursos que podem ser movidos para outro local que estão em uso. |
| 5 | Replication Oculte recursos que podem ser copiados em vários locais. |
| 6 | Concurrency Oculte recursos que podem ser compartilhados com outros usuários. |
| 7 | Failure Oculta falha e recuperação de recursos do usuário. |
| 8 | Persistence Oculta se um recurso (software) está na memória ou no disco. |
Vantagens
Resource sharing - Compartilhamento de recursos de hardware e software.
Openness - Flexibilidade de uso de hardware e software de diferentes fornecedores.
Concurrency - Processamento simultâneo para melhorar o desempenho.
Scalability - Maior rendimento ao adicionar novos recursos.
Fault tolerance - A capacidade de continuar em operação após a ocorrência de uma falha.
Desvantagens
Complexity - Eles são mais complexos do que sistemas centralizados.
Security - Mais suscetível a ataques externos.
Manageability - Mais esforço necessário para o gerenciamento do sistema.
Unpredictability - Respostas imprevisíveis dependendo da organização do sistema e da carga da rede.
Sistema Centralizado vs. Sistema Distribuído
| Critério | Sistema centralizado | Sistema distribuído |
|---|---|---|
| Economia | Baixo | Alto |
| Disponibilidade | Baixo | Alto |
| Complexidade | Baixo | Alto |
| Consistência | Simples | Alto |
| Escalabilidade | Pobre | Boa |
| Tecnologia | Homogêneo | Heterogêneo |
| Segurança | Alto | Baixo |
Arquitetura Cliente-Servidor
A arquitetura cliente-servidor é a arquitetura de sistema distribuído mais comum, que decompõe o sistema em dois subsistemas principais ou processos lógicos -
Client - Este é o primeiro processo que emite uma solicitação para o segundo processo, ou seja, o servidor.
Server - Este é o segundo processo que recebe a solicitação, realiza e envia uma resposta ao cliente.
Nessa arquitetura, o aplicativo é modelado como um conjunto de serviços que são fornecidos por servidores e um conjunto de clientes que usam esses serviços. Os servidores não precisam saber sobre os clientes, mas os clientes devem saber a identidade dos servidores, e o mapeamento de processadores para processos não é necessariamente 1: 1
A arquitetura cliente-servidor pode ser classificada em dois modelos com base na funcionalidade do cliente -
Modelo Thin-Client
No modelo thin client, todo o processamento do aplicativo e gerenciamento de dados é realizado pelo servidor. O cliente é simplesmente responsável por executar o software de apresentação.
Usado quando os sistemas legados são migrados para arquiteturas cliente-servidor nas quais o sistema legado atua como um servidor por conta própria com uma interface gráfica implementada em um cliente
A principal desvantagem é que ele coloca uma grande carga de processamento no servidor e na rede.
Modelo de cliente grosso / gordo
No modelo de cliente gordo, o servidor é responsável apenas pelo gerenciamento de dados. O software no cliente implementa a lógica do aplicativo e as interações com o usuário do sistema.
Mais apropriado para novos sistemas C / S onde as capacidades do sistema do cliente são conhecidas com antecedência
Mais complexo do que um modelo thin client, especialmente para gerenciamento. Novas versões do aplicativo devem ser instaladas em todos os clientes.
Vantagens
Separação de responsabilidades, como apresentação da interface do usuário e processamento da lógica de negócios.
Reutilização de componentes de servidor e potencial para simultaneidade
Simplifica o design e o desenvolvimento de aplicativos distribuídos
Facilita a migração ou integração de aplicativos existentes em um ambiente distribuído.
Também faz uso eficaz dos recursos quando um grande número de clientes acessa um servidor de alto desempenho.
Desvantagens
Falta de infraestrutura heterogênea para lidar com as mudanças de requisitos.
Complicações de segurança.
Disponibilidade e confiabilidade limitadas do servidor.
Testabilidade e escalabilidade limitadas.
Clientes gordos com apresentação e lógica de negócios juntas.
Arquitetura multicamadas (arquitetura n-camadas)
A arquitetura multicamadas é uma arquitetura cliente-servidor na qual as funções como apresentação, processamento de aplicativos e gerenciamento de dados são fisicamente separadas. Ao separar um aplicativo em camadas, os desenvolvedores obtêm a opção de alterar ou adicionar uma camada específica, em vez de retrabalhar todo o aplicativo. Ele fornece um modelo pelo qual os desenvolvedores podem criar aplicativos flexíveis e reutilizáveis.
O uso mais geral da arquitetura multicamadas é a arquitetura de três camadas. Uma arquitetura de três camadas é normalmente composta de uma camada de apresentação, uma camada de aplicativo e uma camada de armazenamento de dados e pode ser executada em um processador separado.
Camada de Apresentação
A camada de apresentação é o nível superior do aplicativo pelo qual os usuários podem acessar diretamente, como uma página da web ou GUI do sistema operacional (interface gráfica do usuário). A principal função dessa camada é traduzir as tarefas e resultados em algo que o usuário possa entender. Ele se comunica com outras camadas para que coloque os resultados na camada do navegador / cliente e em todas as outras camadas da rede.
Camada de aplicativo (lógica de negócios, camada lógica ou camada intermediária)
A camada de aplicativo coordena o aplicativo, processa os comandos, toma decisões lógicas, avalia e executa cálculos. Ele controla a funcionalidade de um aplicativo executando processamento detalhado. Ele também move e processa dados entre as duas camadas adjacentes.
Camada de Dados
Nesta camada, as informações são armazenadas e recuperadas do banco de dados ou sistema de arquivos. As informações são então devolvidas para processamento e, em seguida, de volta para o usuário. Inclui os mecanismos de persistência de dados (servidores de banco de dados, compartilhamentos de arquivos, etc.) e fornece API (Interface de Programação de Aplicativo) para a camada de aplicativo que fornece métodos de gerenciamento dos dados armazenados.
Advantages
Melhor desempenho do que uma abordagem thin client e é mais simples de gerenciar do que uma abordagem thick client.
Aumenta a capacidade de reutilização e escalabilidade - conforme as demandas aumentam, servidores extras podem ser adicionados.
Fornece suporte multi-threading e também reduz o tráfego de rede.
Oferece facilidade de manutenção e flexibilidade
Disadvantages
Testabilidade insatisfatória devido à falta de ferramentas de teste.
Disponibilidade e confiabilidade de servidor mais críticas.
Estilo de arquitetura do corretor
Broker Architectural Style é uma arquitetura de middleware usada em computação distribuída para coordenar e permitir a comunicação entre servidores e clientes registrados. Aqui, a comunicação de objetos ocorre por meio de um sistema de middleware denominado object request broker (barramento de software).
O cliente e o servidor não interagem diretamente entre si. O cliente e o servidor têm uma conexão direta com seu proxy, que se comunica com o mediador-corretor.
Um servidor fornece serviços registrando e publicando suas interfaces com o broker e os clientes podem solicitar os serviços do broker estaticamente ou dinamicamente por consulta.
CORBA (Common Object Request Broker Architecture) é um bom exemplo de implementação da arquitetura do broker.
Componentes do estilo arquitetônico do corretor
Os componentes do estilo de arquitetura do corretor são discutidos através dos seguintes cabeçalhos -
Broker
O Broker é responsável por coordenar a comunicação, como encaminhar e despachar os resultados e exceções. Pode ser um serviço orientado a invocação, um documento ou um corretor orientado a mensagem para o qual os clientes enviam uma mensagem.
É responsável por intermediar as solicitações de serviço, localizar um servidor adequado, transmitir solicitações e enviar respostas aos clientes.
Ele retém as informações de registro dos servidores, incluindo sua funcionalidade e serviços, bem como informações de localização.
Ele fornece APIs para clientes solicitarem, servidores para responder, registrar ou cancelar o registro de componentes do servidor, transferir mensagens e localizar servidores.
Stub
Os stubs são gerados no momento da compilação estática e, em seguida, implantados no lado do cliente, que é usado como proxy para o cliente. O proxy do lado do cliente atua como um mediador entre o cliente e o corretor e fornece transparência adicional entre eles e o cliente; um objeto remoto parece um local.
O proxy oculta o IPC (comunicação entre processos) no nível do protocolo e realiza o empacotamento dos valores dos parâmetros e o desempacotamento dos resultados do servidor.
Skeleton
O esqueleto é gerado pela compilação da interface de serviço e, em seguida, implantado no lado do servidor, que é usado como proxy para o servidor. O proxy do lado do servidor encapsula funções de rede específicas do sistema de baixo nível e fornece APIs de alto nível para mediar entre o servidor e o broker.
Ele recebe as solicitações, descompacta as solicitações, desempacota os argumentos do método, chama o serviço adequado e também empacota o resultado antes de enviá-lo de volta ao cliente.
Bridge
Uma ponte pode conectar duas redes diferentes com base em protocolos de comunicação diferentes. Ele medeia diferentes corretores, incluindo DCOM, .NET remoto e corretores Java CORBA.
Bridges são componentes opcionais, que ocultam os detalhes de implementação quando dois brokers interoperam e pegam solicitações e parâmetros em um formato e os traduzem para outro formato.
Broker implementation in CORBA
CORBA é um padrão internacional para Object Request Broker - um middleware para gerenciar comunicações entre objetos distribuídos definidos por OMG (grupo de gerenciamento de objetos).
Arquitetura Orientada a Serviços (SOA)
Um serviço é um componente da funcionalidade de negócios bem definido, autocontido, independente, publicado e disponível para ser usado por meio de uma interface de programação padrão. As conexões entre os serviços são conduzidas por protocolos orientados a mensagens comuns e universais, como o protocolo de serviço da Web SOAP, que pode entregar solicitações e respostas entre serviços de forma flexível.
A arquitetura orientada a serviços é um projeto cliente / servidor que oferece suporte à abordagem de TI orientada a negócios, na qual um aplicativo consiste em serviços de software e consumidores de serviços de software (também conhecidos como clientes ou solicitantes de serviços).
Recursos de SOA
Uma arquitetura orientada a serviços fornece os seguintes recursos -
Distributed Deployment - Exponha os dados corporativos e a lógica de negócios como unidades de funcionalidade chamadas de serviços frouxamente, acopladas, detectáveis, estruturadas, baseadas em padrões, de granulação grossa e sem estado.
Composability - Monte novos processos de serviços existentes que são expostos em uma granularidade desejada por meio de interfaces de reclamação bem definidas, publicadas e padrão.
Interoperability - Compartilhe recursos e reutilize serviços compartilhados em uma rede, independentemente dos protocolos subjacentes ou da tecnologia de implementação.
Reusability - Escolha um provedor de serviços e acesse os recursos existentes expostos como serviços.
Operação SOA
A figura a seguir ilustra como SOA opera -
Advantages
O acoplamento fraco de orientação a serviços oferece grande flexibilidade para que as empresas façam uso de todos os recursos de serviço disponíveis, independentemente das restrições de plataforma e tecnologia.
Cada componente de serviço é independente de outros serviços devido ao recurso de serviço sem estado.
A implementação de um serviço não afetará a aplicação do serviço, desde que a interface exposta não seja alterada.
Um cliente ou qualquer serviço pode acessar outros serviços, independentemente de sua plataforma, tecnologia, fornecedores ou implementações de linguagem.
Reutilização de bens e serviços uma vez que os clientes de um serviço apenas precisam de conhecer as suas interfaces públicas, composição do serviço.
O desenvolvimento de aplicativos de negócios baseados em SOA é muito mais eficiente em termos de tempo e custo.
Aumenta a escalabilidade e fornece conexão padrão entre sistemas.
Uso eficiente e eficaz de 'Business Services'.
A integração se torna muito mais fácil e a interoperabilidade intrínseca aprimorada.
Complexidade abstrata para desenvolvedores e energizar processos de negócios mais próximos dos usuários finais.