soa00

Arquivos contendo agrupamentos de dados foram uma das primeiras formas de integração entre sistemas. Ainda em uso atualmente, esta alternativa costuma ser empregada muitas vezes na transferência de grandes lotes de informações.

Vale destacar que o uso de arquivos é um tipo de prática bastante comum no desenvolvimento para aplicações de mainframe, bem como na implementação de processos de carga para soluções de Business Intelligence (BI). Além de arquivos de texto, outros formatos como CSV e planilhas do Excel (.xls/.xlsx) também são utilizados com alguma frequência.

O advento dos Web Services no começo dos anos 2000 revolucionou a comunicação entre diferentes sistemas. Tal acontecimento viabilizou a realização de transações online, característica esta fundamental para o sucesso de segmentos como e-commerce e Internet Banking. A popularização deste tipo de tecnologia foi possível graças à adoção, em seus estágios iniciais, do protocolo HTTP/HTTPS (para a transmissão de dados) e do formato XML (usado na representação de informações).

Como não é difícil de se imaginar, especialistas da área de software propuseram diretrizes visando uma melhor estruturação no que diz respeito à implementação de Web Services. O resultado deste trabalho é conhecido hoje como SOA (sigla do inglês “Service Oriented Architecture”) ou, em português, “Arquitetura Orientada a Serviços”.

O objetivo deste artigo é apresentar uma visão geral de SOA. Para isto serão abordados princípios, vantagens e cuidados úteis a projetos que se orientem por esta arquitetura.

Definição

A Arquitetura Orientada a Serviços (SOA) engloba uma série de diretrizes, padrões e boas práticas para a implementação de serviços. Trata-se de um corpo de conhecimentos concebido para atender às mais diferentes plataformas de desenvolvimento, sem se prender a uma tecnologia específica.

Quanto aos serviços, estes representam a unidade básica de implementação dentro desta arquitetura. Em termos práticos, um serviço nada mais é do que um componente de software com capacidades, as quais são implementadas sob a forma de operações (métodos). Já as capacidades podem ser vistas como funcionalidades das quais um ou mais sistemas dependem.

Um dos principais especialistas dentro deste ramo da arquitetura de software é o canadense Thomas Erl. Este autor desenvolveu uma notação para a representação de serviços que pode ser visualizada na Imagem 1 (através do uso de círculos, com a indicação opcional de suas respectivas capacidades):

soa01
Imagem 1. Representação de um serviço segundo Thomas Erl

Benefícios

Dentre os benefícios conseguidos ao se adotar os princípios propostos por SOA é possível destacar:

  • A possibilidade de reuso de um serviço ao longo de várias aplicações;
  • A interoperabilidade entre sistemas construídos em diferentes plataformas (a comunicação entre sistemas construídos em .NET e Java corresponde a um bom exemplo disto);
  • Reduções no tempo e custo de implementação de novos projetos, graças ao reaproveitamento de funcionalidades pré-existentes;
  • Uma maior organização dos processos de negócio, graças à ênfase na análise e modelagem das diferentes características e nuances dos mesmos.

Cuidados

A implantação de projetos em conformidade com SOA também exige cuidados:

  • A equipe envolvida deve ser capacitada e estar familiarizada com conceitos desta arquitetura;
  • Mudanças drásticas em um serviço podem resultar em efeitos indesejáveis em outras aplicações;
  • Questões envolvendo a segurança na transmissão de informações também devem ser priorizadas;
  • Analisar a real necessidade de implementação de um serviço (potencial de reuso, questões de infraestrutura) é um aspecto de fundamental importância, sobretudo por evitar esforços que podem se revelar como infrutíferos.

Tipos de serviço em SOA

De acordo com Thomas Erl serviços podem ser classificados como:

  • Entity Services, empregados em operações de CRUD (inclusão, exclusão, alteração e / ou consulta a informações);
  • Utility Services, contemplando funcionalidades que não estejam diretamente relacionadas ao negócio (log, envio de e-mail, etc.);
  • Task Services, utilizados na automação de processos de negócio. Tais estruturas costumam implementar a composição de serviços, com o consumo de Entity e/ou Utility Services;
  • Orchestrated Task Services, os quais incorporam lógica de orquestração e controlam o fluxo em composições de serviços que envolvam Entity, Utility e Task Services.

Princípios de Design de Serviços

Conforme mencionado anteriormente, diversos conceitos e padrões fornecem a base para a implementações de soluções orientadas a serviço. A finalidade desta seção é apresentar em detalhes os seguintes princípios:

  • Contrato Padronizado;
  • Acoplamento;
  • Abstração;
  • Reusabilidade;
  • Autonomia;
  • Independência de Estado;
  • Visibilidade;
  • Capacidade de Composição;
  • Granularidade.

Contrato Padronizado

Serviços mais antigos costumam fazer uso do protocolo SOAP (Simple Object Access Protocol), um formato de comunicação baseado em XML. A interação com Web Services que seguem este modelo acontece a partir de objetos conhecidos como proxies. Um proxy, por sua vez, é uma estrutura gerada a partir de informações baseadas nos padrões WSDL (Web Services Description Language) e XSD (XML Schema Definition Language).

No caso específico de serviços REST, os formatos JSON e XML substituem SOAP. A comunicação com tais estruturas se dá por meio de requisições HTTP, além da utilização de classes POCO (Plain Old CLR Objects) em aplicações criadas com a tecnologia ASP.NET Web API.

Acoplamento

Um baixo nível acoplamento entre as diferentes partes de uma aplicação é uma característica mais do que desejável, já que representa uma medida de quão bem estruturado tal software se encontra. A implementação de uma solução orientada a serviços contribui para um menor acoplamento, com isto acontecendo graças à separação de funcionalidades de negócio em serviços específicos.

Abstração

O conceito de abstração refere-se à ideia de caixa preta, ou seja, à ocultação de detalhes técnicos (infraestrutura em uso, bancos de dados, mecanismos de controle de acesso etc.). Aplicações que venham a consumir um serviço não necessitam conhecer detalhes internos da implementação deste, mas sim que funcionalidades tal estrutura disponibiliza para uso.

Reusabilidade

A implementação de um novo serviço deve levar em conta a possibilidade de reuso do mesmo. Logo, chances consideráveis de utilização de um Web Service imediatamente ou, até mesmo, a médio prazo constituem boas justificativas para a adoção deste tipo de estratégia.

Autonomia

A ideia de autonomia está ligada à independência de um serviço em relação a influências externas. Logo, um nível alto de autonomia é uma característica extremamente desejável na implementação de serviços.

Independência de Estado

Serviços devem ser, sempre que possível, implementados de forma a evitar o armazenamento de informações de estado em memória (stateless). Essa característica está ligada a questões de performance, impactando diretamente na escalabilidade (capacidade de se adequar a demandas crescentes) de um sistema.

Visibilidade

A visibilidade de um serviço está relacionada à capacidade de outras aplicações descobrirem o mesmo, bem como interpretarem a estrutura que o mesmo expõe.

Em serviços SOAP esta característica encontra-se ligada ao uso dos padrões UDDI (Universal Description, Discovery and Integration) e WS-MetadataExchange (especificação que regula a geração de documentos XML com a estrutura de um serviço).

Já serviços REST costumam expor sua estrutura através de páginas descritivas. No caso específico do ASP.NET Web API, um site descrevendo as APIs REST e suas funcionalidades pode ser criado automaticamente (através da seleção de um template específico no Visual Studio). Outra alternativa seria a utilização da solução conhecida como Swagger (http://swagger.io/).

Capacidade de Composição

A noção de composição está diretamente ligada à questão do reuso, envolvendo a criação de novos serviços a partir da combinação de outros já existentes. Um serviço implementado desta forma tende a possuir uma menor autonomia, estando sujeito às interferências que ocorrerem nos componentes dos quais depende.

Composições podem ser primitivas ou complexas.

Uma composição primitiva envolve a troca simplificada de mensagens entre dois ou mais serviços (Imagem 2).

soa02
Imagem 2. Uma composição de serviços primitiva

Já composições complexas contam com uma lógica mais elaborada, representando em muitos casos um processo de negócio. Orchestrated Task Services constituem um exemplo deste tipo de composição (Imagem 3).

soa03
Imagem 3. Uma composição complexa

Granularidade

A granularidade diz respeito ao escopo abrangido pelas capacidades de um serviço. Do ponto de vista prático, esta característica é determinada com base na quantidade de funcionalidades encapsuladas por um serviço. Levando em conta tal fator, a granularidade pode ser classificada em fina (fine-grained) e grossa (coarse-grained).

Serviços com granularidade fina possuem um maior potencial de reuso, sendo que os Entity e Utility Services constituem bons exemplos deste tipo de implementação.

Já a granularidade grossa resulta numa menor possibilidade de reaproveitamento, uma vez que implica em alguma forma de acoplamento com outras construções. Contudo, isto não representa um mau design. Task e Orchestrated Task Services costumam ser exemplos típicos desta granularidade.

Conclusão

Este artigo procurou detalhar diversos princípios úteis para a implementação de soluções orientadas a serviço, bem como vantagens e pontos de atenção a serem considerados ao se adotar esta abordagem.

Por mais que abordagens como REST e Microserviços estejam em alta, muitos dos conceitos aqui abordados (como reusabilidade, autonomia, abstração, por exemplo) se encaixam perfeitamente dentro da construção de soluções que sigam estes paradigmas.

O conteúdo aqui apresentado também pode ser visualizado no YouTube, em uma apresentação sobre arquitetura de serviços realizada em 18/12/2015:

https://www.youtube.com/watch?v=tJYohYwOqqk

Espero que este post tenha sido útil.

Até uma próxima oportunidade!

Referências

Thomas Erl – Site Oficial
http://www.thomaserl.com/

Renato Groffe

Atua como consultor em atividades voltadas ao desenvolvimento de softwares há mais de 13 anos. Bacharel em Sistemas de Informação, com especialização em Engenharia de Software. Microsoft Certified Technology Specialist (Web, WCF, Distributed Applications, ADO.NET, Windows Forms), Microsoft Specialist (HTML5 with JavaScript and CSS3, Developing ASP.NET MVC 4 Web Applications), Oracle Certified Associate (PL/SQL), Sun Certified (SCJP, SCWCD), ITIL Foundation V2, Cobit 4.1 Foundation.

Facebook Google+ 

Comentários

comentarios