A palavra correta para hierarquia, no contexto do texto, é “Taxonomia”. A idéia foi apresentada em um artigo da revista SOA World Magazine, edição de Outubro/08. O autor é Mark Richards, ex-IBM, ex-lider de vários Java User Groups nos E.U.A e atualmente na empresa Collaborative Consulting, LCC.
A idéia é simples. Taxonomia nada mais é do que uma forma de classificar as coisas de uma forma hierárquica. Assim o fazemos para os animais (famílias, classes, ordens…), para as plantas etc. E quanto as serviços?
Bom, uma Taxonomia de Serviços é a proposta do autor original do artigo que propõe uma forma simples de organizar, de forma hierárquica os serviços dentro da arquitetura SOA.
SOA: Taxonomia
(fontes de todas as images: “Creating an Effective SOA Service Taxonomy”, M.Richards, SOA World Magazine, October/2008)
Inicialmente os serviços foram classificado em 4 tipos básicos:
- Business Service (serviço de negócio): serviço abstrato utilizado para representar um processo de negócio ou função independente
- Enterprise Service (serviço corporativos): serviço “concreto” utilizado para implementar um serviços de negócio utilizando um relacionamento “one-to-one” ou “many-to-one”
- Application Service (serviço de aplicação): serviço “concreto” utilizado em funções específicas de aplicação tais como coleta e manipulação de dados, validação etc
- Infrastrucuture Service (serviço de infraestrutura): serviço “concreto” utilizado para suportar funções não relacionadas ao “negócio”, para solucionar questões específicas de uma plataforma, subsistemas etc.
1. Business Service
Business Service
São os “core services” de SOA. Eles podem vir de use cases, user stories, user scenarios ou através de processos de ivestigação, identificação e especificação inerente aos passos iniciais de várias metodologias de implatação de uma Arquitetura Orientada a Serviços. Veja uma sugestão neste link (pdf, 32 pags/OASIS-Open.org) e neste link (IBM DeveloperWorks).
Business Services são definições abstratas contendo um nome do serviço, especificação dos dados de entrada e dos dados de saída, independente da tecnologia a ser utilizada para o desenvolvimento.
Exemplo: gerar uma cotação de um seguro para um carro qualquer. Grosso modo, o serviço irá coletar dados do cliente, do automóvel, irá armazenar estes dados e devolver o valor do seguro. Mais ou menos o que o corretor nos pede no telefone quando queremos fazer uma cotação de seguro. Perceba que, na definição, não devemos nos preocupar com a liguagem que será implementado, se utilizaremos Web Services, qual a plataforma… …precisamos definir os dados de entrada e os dados de saída do serviço “CreateQuote“.
2. Enterprise Services
Enterprise Service
São também considerados “core”, porém são “concrete services“, ou seja, implementam Business Services.
Uma vez que estes são serviços corporativos, que geralmente “atravessam” vários sistemas da empresa, devem ser definidos pelo Enterprise IT Architect ou pelo time de arquitetura da organização.
Lembrando que tais serviços tem um relacionamento “um-para-um” ou, mais comumente, “muito-para-um”, com os Business Services. Assim , voltando ao mesmo exemplo, vários Enterprise Services seriam necessários para implementar o Business Service “CreateQuote” do exemplo acima.
Exemplo: “createCustomer“, “checkMotorVehicleReport”, “calculateQuote”, “saveQuote” etc.
Importante: não necessariamente este serviços precisam ser compartilhados em todos os sistemas da organização. Não existe uma fórmula para definirmos a “granularidade” adequada para um serviço; tudo é uma questão de “trade-offs” e um bom arquiteto e muita prática é que definem a correta amplitude do serviço.
3. Application Services
Application Services
São serviços “básicos” (not core), são serviços de suporte. Geralmente são de baixa granularidade e associados a uma aplicação específica. Um exemplo típico são os serviços que interagem com os “silos” existentes em qualquer empresa.
Assim sendo, devem ser construídos considerando esta especificidade, baixa ou nenhuma reutilização e portanto, o desenvolvedor pode ter mais liberdade de otimizar para extrair a máxima performance possível de tais serviços.
Exemplo: voltando ao “CreateQuote”, serviços como “addDriver”, “addAddress”, “addVehicle” etc são necessários para persisitir os dados necessários (input) para gerarmos o valor da cotação.
Pensar nos inputs e outputs dos Business Services é uma boa dia para definir os Application Services.
4. Infrastructure Services
Infrastructure Services
Tipicamente serviços que eu chamo de “satélites”. São necessários para acessar os dados e, entre outras coisas, garantir a segurança, rastreabilidade, atendimento de normas e políticas da empresa (compliance).
Exemplos: logging, auditoria, acesso a dados, segurança (AAA) etc.
O que distingue Infrastructure Services dos Enterprise Services é que os Infrastructure Services implementam funcionalidades não relacionadas ao negócio.
A Taxonomia dos serviços pode, em um primeiro momento, parecer muito abstrata, distante do mundo.real.com.br mas, acredite, esta simples classificação ajuda na divisão de tarefas, prioridades e organização da biblioteca de serviços, além de ser um excelente ponto de partida para a definição dos serviços na sua arquitetura orientada a serviços.
Werner Vogels trabalhou por 10 anos em pesquisas de sistemas distribuidos em larga escala. Ele entrou na Amazon em 2004 para ajudar a gigante on-line na tarefa de lidar com as grandes demandas (“picos”) de acesso, para ajudar a planejar quão escalável iriam ser as suas soluções de software, a arquitetura e como disponibilizar a sua infraestrutura de TI da Amazon como um produto.
