Fala, meus consagrados! Tudo beleza com vocês?
No artigo O que é SOA?, estudamos sobre a Computação orientada a serviços, os Serviços e, principalmente, a SOA (Arquitetura Orientada a Serviços). Em outro artigo, tivemos a oportunidade de responder 15 questões de concursos a fim de treinarmos o que aprenderemos. Agora, o foco é entendermos quais são os Princípios Básicos da SOA.
Então, simbora comigo!
Visão geral
Padronização do contrato de serviço
Um contrato de serviço representa descrições de um serviço e de outros documentos que descrevem como um serviço pode ser acessado.
O contrato tem por objetivo principal definir as capacidades e o modelo de dados/expressão funcional de determinado serviço. Por meio da leitura de um contrato funcional de serviço, o consumidor deve ter clareza daquilo que o serviço se propõe:
- A fazer; e
- Como fazer.
O contrato de serviço funciona como uma interface funcional do serviço, expondo somente informações necessárias para consumo do mesmo e desprezando qualquer tipo de informação específica de tecnologia.
O consumidor não precisa se preocupar em:
- Como a lógica da solução funciona;
- Qual linguagem de programação foi escrita;
- Se consome dados de um determinado SGBD;
- Entre outras informações específicas.
O consumidor apenas precisa se preocupar somente em como consumi-la.
Com a padronização do contrato de serviço, é possível determinar a estrutura de entrada e saída de dados para cada capacidade no contexto funcional do serviço. Essa capacidade é um método ou atividade de serviço para se executar determinado processo da lógica de serviço.
A padronização contribui para evitar a transformação de dados nas mensagens enviadas/recebidas, o que é outra premissa importante na SOA.
Abstração do serviço
Além do que é descrito no contrato de serviço, serviços escondem a lógica do mundo exterior e ocultam detalhes funcionais, tecnológicos e de qualidade.
Abstrair um serviço é uma questão muitas vezes complicada e exige algumas decisões delicadas, pois o serviço:
- Deve ser genérico o bastante para se adaptar ao máximo de composições possíveis;
- Favorecendo:
- O cenário de redundância de recursos;
- O desperdício financeiro; e
- O atraso da TI frente ao negócio; e
- Favorecendo:
- Não pode ser abstrato demais;
- Ao ponto de o consumidor não saber do que se trata o serviço.
Dentro desse princípio, nos deparamos com o termo agnóstico. Ele representa a capacidade de adaptação e serventia a diversos propósitos. Serviços com esta habilidade deixam de ser vistos como meros serviços e ganham uma posição importante na corporação:
- Sendo reconhecidos como recursos empresariais;
- Tendo valores estratégicos para o negócio como um todo.
O poder de adaptação e a capacidade de utilização em diversos cenários é um grande passo para:
- Obter-se um bom retorno de investimento (ROI);
- Aumentar a agilidade operacional da TI; e
- Diminuir a redundância de serviços e aplicações descartáveis para a empresa.
Baixo ou fraco acoplamento
O acoplamento representa o nível de dependência entre recursos e serviços. Está relacionado com a capacidade de um serviço de ser independente de outros para realizar a sua tarefa.
Existem duas formas de acoplamento entre o consumidor e o provedor do serviço:
- Consumidor para implementação; e
- Consumidor para o contrato.
O consumidor para implementação acontece quando o consumidor do serviço ignora os termos do contrato e acessa diretamente a funcionalidade de um serviço de forma indiscriminada e despadronizada.
Já o consumidor para o contrato é o acoplamento ideal para consumo de serviço, pois garante-se que a lógica de solução será acessada se somente se o contrato de serviço for respeitado.
Autonomia do serviço
Sobre a autonomia de serviço, temos que os serviços têm controle sobre a lógica que a encapsulam.
Esse princípio é fortemente influenciado pelo princípio de baixo acoplamento do serviço, pois quanto mais recursos compartilhados o serviço utilizar, menor será sua autonomia para o negócio.
A autonomia prega que cada serviço deve ser responsável pelo seu ambiente em tempo de execução e projeto. No entanto, em composições complexas, à medida com que o serviço aproxima-se do topo da cadeia de composição, o nível de autonomia é automaticamente comprometido. Em contrapartida, é possível afirmar que quanto menor for a posição do serviço na composição, maior será sua autonomia.
Visibilidade do serviço
Esse princípio também é chamado de descoberta de serviço.
Os serviços são projetados para ser exteriormente descritos, para que possam ser encontrados e avaliados através de mecanismos de descobertas disponíveis.
Eles devem ser de fácil interpretação e descoberta e também devem ser genéricos o bastante para servirem a diversas causas.
Neste princípio, há dois tipos de capacidades:
- Capacidade de descoberta:
- Um serviço possui a capacidade de descoberta quando tem metadados e contrato coesos e padronizados, os quais permitem a descoberta deste serviço em dado ambiente; e
- Capacidade de interpretação:
- Um serviço possui a capacidade de interpretação se, após descoberto, o candidato a consumidor conseguir identificar o objetivo, as capacidades e o modelo funcional necessário para se cumprir com o contrato de serviço.
Relacionamento com outros princípios:
- Abstração de serviços:
- O serviço deve ser sim o mais abstrato possível, mas não ao ponto de perder sua identidade
- Padronização do contrato de serviço:
- Para auxiliar na modelagem do contrato, a capacidade de descoberta do serviço influencia na criação de convenções para:
- Nomenclaturas de capacidades;
- Normalização de modelos;
- Entre outros.
- Para auxiliar na modelagem do contrato, a capacidade de descoberta do serviço influencia na criação de convenções para:
Sem estado (Stateless)
Por padrão SOA, serviços não devem guardar estado.
O objetivo desse princípio é garantir o melhor desempenho do serviço por meio do isolamento da responsabilidade de se guardar estado. O serviço deve:
- Receber a mensagem;
- Fazer o devido tratamento na mesma; e
- Responder de forma esperada a cada requisição.
Serviços minimizam a retenção da informação em determinada atividade.
Serviços reutilizáveis e composições complexas por si só já aumentam consideravelmente a carga de processamento de infraestrutura e complexidade do projeto. Se adicionado o armazenamento de estado poderia ser o divisor de águas entre o sucesso e o fracasso a longo prazo.
O excesso de dados em memória influenciaria diretamente na escalabilidade e disponibilidade do serviço, ferindo o princípio de autonomia do serviço.
Alguns tipos de estado específicos para serviços:
- Ativo:
- Indica que o serviço está em atividade;
- Sendo usado ou invocado por um consumidor; e
- Indica que o serviço está em atividade;
- Passivo:
- Standby;
- Indica que o serviço está disponível;
- Mas não está em uso.
Reusabilidade
A lógica é dividida no serviço com a intenção de reuso.
Esse princípio está associado à necessidade de adaptação do serviço a diferentes tipos de requisições e ambientes, dando corpo ao conceito de composição de serviços.
A reusabilidade permite ao serviço contribuir com todos os objetivos estratégicos da arquitetura orientada a serviços de forma que a construção de recursos duplicados seja mitigada:
- Facilitando o gerenciamento dos recursos de TI; e
- Consequentemente aumentando a agilidade da TI em responder a novas necessidades do negócio
- Aumentando consideravelmente o retorno de investimento da corporação;
- Uma vez que o alinhamento estratégico da TI com o negócio se perpetua por meio da adaptação dos serviços.
- Aumentando consideravelmente o retorno de investimento da corporação;
Composição de serviços
Vários serviços pequenos podem criar um serviço maior.
Heterogeneidade
Para promover a interoperabilidade, SOA promove na implementação de serviços a independência de:
- Plataforma de desenvolvimento;
- Tecnologias de implementação; e
- Linguagens de programação.
Referências
- Abordagem de Serviços da Web para uma Arquitetura Orientada a Serviços. Disponível em: https://www.ibm.com/docs/pt-br/was/8.5.5?topic=architecture-web-services-approach-service-oriented
- A Fresh Graduate’s Guide to Software Development Tools and Technologies. Disponível em: https://www.comp.nus.edu.sg/~seer/book/2e/
- Defining SOA as an architectural style. Disponível em: http://www.ibm.com/developerworks/library/ar-soastyle/
- FERNANDES, Aguinaldo Aragon. Implantando a Governança de TI – da Estratégia à Gestão de Processos e Serviços. Editora Brasport, 2012.
- JOSUTTIS, Nicolai M. SOA na prática – A Arte da Modelagem de Sistemas Distribuídos. Editora Alta Books, 2008.
- MARZULLO, Fábio Perez. SOA na prática – Inovando seu negócio por meio de soluções orientadas a serviços. Editora Novatec, 2009.
- Service-oriented architecture. Disponível em: http://en.wikipedia.org/wiki/Service-oriented_architecture
- Service-Oriented Architecture. Disponível em: http://www.inf.ufg.br/~fabrizzio/web/ejb/aula14.pdf
- SOA: princípios de projetos orientados a serviço. Disponível em: https://www.profissionaisti.com.br/2017/05/soa-principios-de-projetos-orientados-a-servico/
- What Is Real-Time SOA?. Disponível em: http://community.rti.com/sites/default/files/archive/RTI_WP_RealTimeSOA.pdf
Então é isso!
[]’s e até a próxima!
_________________________
Professor Rogerão Araújo