Anatomia do Serviço (Taxonomia básica)
June 3, 2008 – 11:52 pm by Gustavo S. SinisSOA, na prática, exige uma taxonomia de serviços consistente. Serviços servem a propósitos diferentes e desempenham papéis muito distintos. A classificação dos serviços em uma corporação é essencial para o sucesso da abordagem.
Existem várias formas de categorização de serviços, considerando, por exemplo: granularidade [1]; consumidor; origem; segurança; com ou sem backend. Cabe a você encontrar a melhor forma de categorizar seus serviços de acordo com as políticas e retornos esperados em sua corporação. Temos vários autores com abordagens diferentes: Dirk Krafzig, Karl Banke, Dirk Slama; Thomas Erl; Jason Bloomberg, Ronald Schmelzer; James McGovern, Oliver Sims, Ashish Jain, Mark Little
Um ponto de partida interessante seria:
Serviço de Processo
Principal abstração de SOA, pois está relacionado intimamente com o processo de negócio, e possibilita que ele seja um vocabulário comum entre TI e as áreas de negócio, facilitando a comunicação. O negócio é a base para a identificação desse serviço (decomposição de processos), e, para a identificação ser efetiva, cada processo precisa ser modelado.
A existência desse serviço só faz sentido se o mesmo estiver associado a uma atividade no processo de negócio. Esse serviço, a fim de cumprir uma tarefa do processo de negócio, orquestra um ou mais serviços básicos (serviço básico é um conceito abstrato). Além disso, o Serviço de Processo é responsável por garantir a pré-condição dos serviços básicos.
Serviço de Negócio
Conhecido em CBD como Componente de Negócio, é utilizado para realizar o Serviço de Processo. Alguns autores não o classificam como serviço, mantendo o nome original “componente de negócio”.
Encapsula as regras de negócio e as expõe através de interfaces bem definidas. Os Serviços de Negócio são independentes, ajudam a gerenciar a complexidade e encorajam a reutilização.
O Serviço de Negócio pode ser identificado a partir da decomposição conceitual (domínio do processo), observando os objetos principais (conceitos mais fortes) e o tipo de associação (agregação, herança, etc.) entre os objetos relacionados, focando em coesão; têm-se na interface dos Serviços, todas as operações necessárias para “realizar” os passos dos UCs (Casos de uso). Serviços de Negócio são criados para atender as necessidades dos UC, mas sua interface deve ser projetada para ser reutilizável.
Além disso, visa proteger as regras de negócio, evitando, sobretudo, a duplicidade - ou seja, primando para que, quando da modificação de alguma regra, seja possível obter um único ponto de alteração.
Na prática, a implementação de tal ponto singular não é simples e, em muitos casos, inviável (problemas com redundância de dados e conceitos homônimos em diferentes sistemas legados).
Mesmo com esses possíveis problemas, a abordagem de componentes de negócio deveria ser uma meta ou um norte para criação dos Serviços de Negócios. Quando não for possível utilizar esse conceito, temos outras abstrações como, por exemplo, os Serviços Compostos com Serviços Wrapper, que ajudam a controlar redundância de dados.
A figura representa Serviços de Processo (representados como serviços corporativos) realizados por Serviços de Negócio
Serviços compostos
Operam em um nível mais alto que os serviços de negócios; são compostos de múltiplos serviços básicos; são responsáveis pela pré-condição e pela seqüência de execução dos Serviços Básicos. Um exemplo típico: serviços que controlam a redundância de conceitos em serviços Wrapper ou harmonizam conceitos homônimos na corporação, expondo uma interface mais limpa para o processo de negócio.
Ocasionalmente, temos códigos que orquestram serviços de negócio (códigos que não pertencem exclusivamente a um serviço de negócio) que precisam ser disponibilizados corporativamente. Essa lógica só ficará em Serviços de Processo se estiver associada/coesa a uma atividade do processo de negócio, caso contrário, é mais indicado para os Serviços Compostos.
Trabalhei em uma empresa que comprava ferrovias, herdando, assim, vários sistemas. Em um determinado sistema, o conceito “Trem” poderia ser uma composição de vagões, em outro, uma combinação de rota com hora de saída e hora de chegada. O Serviços Compostos podem harmonizar esses conceitos, fornecendo um interface limpa.
Serviços Wrapper ou de integração
São serviços de integração que “encapsulam e expõem” a lógica em um sistema legado.
————————————————
[1] Uma arquitetura não precisa estar exclusivamente ligada à granularidade baixa ou alta. Pelo contrário, a combinação das duas abordagens é recomendada. (Marcílio Oliveira, consultor da DigitalAssets)
11 Responses to “Anatomia do Serviço (Taxonomia básica)”
Gustavo, seu post ficou bem legal. Faltou apenas colocar imagens maiores, pois não ficou legível
[]’s
Emerson
By Emerson Macedo on Jun 4, 2008
Gostei muito do assunto tratado nos 3 últimos posts. Eles lembram bastante os últimos almoços que tivemos aqui pelo centro do Rio. Regados a lonnnngas conversas sobre arquitetura de software e afins.
Mas as figuras poderiam ficar melhores mesmo!
[]´s
Marcelo
By Marcelo Araújp on Jun 4, 2008
Grande Gustavo,
Primeiramente parabéns pela iniciativa de escrever suas idéias neste blog. Segundo que o assunto deste post é muito interesante e está exposto com clareza.
Sobre o assunto, o importante é salientar isso mesmo que você falou: que cada corporação deve definir a taxonomia que mais se adequa a sua realidade.
Senti falta de uma explicação mais detalhada dos Serviços Básicos. Que são básicos porém importantes, pois fazem parte da camada fundamental SOA, ou seja, suporta os serviços de negócio básicos.
Os Serviços Básicos normalmente possuem as propriedades ACID e implementam serviços como:
- Criar um novo cliente
- Alterar o endereço de um cliente
- Retornar os dados de um cliente
Também estão ligados diretamenta a um backend como: um banco de dados; um mainframe, um SAP, um rules engine e etc.
Um grande abraço,
Fábio
By Fábio Rosato on Jun 5, 2008
Olá Gustavo,
Eu já tinha visto na Internet alguma coisa falando sobre esses tipos de serviços, porem eu acho um pouco destorcida essa denominação, “Tipo de Serviços”. No meu ponto de vista, serviços são serviços e pronto e o que está sendo chamado de “tipo” seria a forma (implementação) de como ele foi feito por detrás do contrato.
Serviço é um mecanismo que permite acessar uma ou mais funcionalidades, esse acesso deve ser fornecido por um contrato. Na verdade o que deveria importar é esse tal de contrato e não a forma de como ele é feita. Se você utiliza um serviço para executar a atividade de um processo de negocio, não importa como é feito o serviço para o negocio e sim como vai se conectar.(Importa em nível de infra-estrutura corporativa, não em nível de serviço.)
Se partirmos pelo principio abordado, podemos concluir que hoje temos um numero X de tipo de serviços e esse X é igual ao numero de tecnologias no mercado que é capaz de construir uma funcionalidade que pode ser exposta como serviço.
- O que está sendo chamado de “Serviço de Processo” é uma orquestração de serviço utilizando processo, exposta como serviço, para ser acessada por uma atividade de um outro processo… Olha que complexidade desnecessária para falar que uma atividade acessa um serviço.
- O “Serviço de Negocio” como você escreveu no texto alguns autores usam o nome de componente de negocio, simplesmente porque ele é um componente de negocio. Então ele se torna em um Serviço de Negocio quando esse componente de negocio é exposto como serviço.
- Acessar vários serviços através de um serviço, não é “tipo” de serviço e sim orquestração e/ou coreografia, logo no contexto usado “Serviço Composto” é uma orquestração e/ou coreografia exposta como serviço.
Então se eu faço uma funcionalidade em Java e exponho ela como serviço seria um “Serviço Java”? Se essa é a abordagem dos autores concordo plenamente, mas se não for, qual é a definição de um “tipo de serviço”? Porque que falar como o serviço é feito é essencial para o sucesso da abordagem? Acredito que esse sucesso e maturidade da utilização de serviço dentro da empresa chegarão quando a empresa tiver um repositório de serviço com políticas bem definidas, e ai a classificação pode ser feito de qualquer forma, contando que o uso dos serviços sejam facilitados.
Abraço
Raoni Gomes
By Raoni on Jun 26, 2009
Raoni, compreendo o que você falou, mas concordo apenas em um ponto: contratos bem definidos são essências tanto no âmbito de negócio ou tecnológico.
A classificação dos serviços traz benefícios interessantes, principalmente quando você define o tipo de back-end que serviço encapsula. Auxilia principalmente no processo de modelagem, impondo restrições e dividindo responsabilidades, organizando seus serviços. Gosto dessa classificação: http://www.soamethodology.com/p5.asp
Considerações sobre seu comentário:
“Se partirmos pelo principio abordado, podemos concluir que hoje temos um numero X de tipo de serviços e esse X é igual ao numero de tecnologias no mercado que é capaz de construir uma funcionalidade que pode ser exposta como serviço.”
Não estou considerando tecnologia e sim princípios SOA. Você pode ter 3 tipos de serviços e usar diversas tecnologias diferentes.
“- O “Serviço de Negocio” como você escreveu no texto alguns autores usam o nome de componente de negocio, simplesmente porque ele é um componente de negocio. Então ele se torna em um Serviço de Negocio quando esse componente de negocio é exposto como serviço.”
Serviços são “pedaços de software” coesos e com interfaces bem definidas. Não vejo muita diferença entre um componente de negócio e um serviço. Na verdade, SOA tem muitos dos princípios de CBD. Componentes de negócio, coesos, pouco acoplados e com uma interface bem definida, são serviços. A classificação ajuda entender como foi modelado.
“- Acessar vários serviços através de um serviço, não é “tipo” de serviço e sim orquestração e/ou coreografia, logo no contexto usado “Serviço Composto” é uma orquestração e/ou coreografia exposta como serviço.”
Um serviço composto é exatamente isso: um serviço que acessa outros serviços. Ou seja, a classificação ajuda entender como foi modelado.
“Então se eu faço uma funcionalidade em Java e exponho ela como serviço seria um “Serviço Java”? Se essa é a abordagem dos autores concordo plenamente, mas se não for, qual é a definição de um “tipo de serviço”? Porque que falar como o serviço é feito é essencial para o sucesso da abordagem? Acredito que esse sucesso e maturidade da utilização de serviço dentro da empresa chegarão quando a empresa tiver um repositório de serviço com políticas bem definidas, e ai a classificação pode ser feito de qualquer forma, contando que o uso dos serviços sejam facilitados.”
Novamente, não estou considerando tecnologias, apenas princípios SOA. Não é relevante se você está usando WS ou EJB.
By admin on Jun 26, 2009
Gustavo, não discordo que um serviço composto é um serviço composto de vários outros, de que o de processo é um processo que executa vários serviços e assim vai, mas qual o critério para definirmos tipos de serviços?
Sem duvida classificação de serviço tem muitos benefícios, foi como eu disse na questão de um repositório de serviço. Mas a classificação deve ser feita através de algo que orienta a construção da solução e nem sempre esse tipo de classificação pode ser útil, para que se torne um padrão. Vamos analisar um caso mencionado por você.
“Auxilia principalmente no processo de modelagem, impondo restrições e dividindo responsabilidades, organizando seus serviços. “
Temos um fluxo de negocio, onde uma atividade de “cadastrar usuário”, necessita da execução de um serviço já existente, se tivermos 10 serviço com as classificações de Serviço Básico, Serviço Composto e Serviço de Processo. Qual seria a responsabilidade de cada um? Como eles estão restringindo algo? O que essas classificações ajudariam na minha modelagem? Qual classificação é equivalente a cadastrar usuário?
É bem mais sensato deixarmos que uma gerencia de configuração caracterize eles, do que definirmos essas nomenclaturas como padrão, por exemplo com a gerencia de configuração podemos saber onde buscar fisicamente o serviço requerido (servidor, repositório…), quem é responsável por manter ele funcionando ou adicionar regras (arquiteto, equipe de desenvolvimento…), quem tem permissão de usá-lo(setor x, setor y…), como posso acessar esse serviço (ws, ejb…) podemos definir tipos de acordo com negocio da empresa (Serviços Financeiro, Serviços Administrativo, Serviços de Calculo, Serviços de Solicitação, Serviços de Produção, Serviços de Estoque…) e assim vai.
Concordo com você que esses nomes dados são tipos de serviço, se partimos do ponto de vista de como eles são feitos, agora não entendo o porque de limitar esses tipos em de processo, composto, básico, de negocio e integração. Se essa classificação colaborar com o gerenciamento apoio o uso (sem restrições caso seja identificado outro tipo), senão, não vejo a obrigação de usá-los. Talvez isso fique mais claro pra mim se tiver um critério para definir tipos de serviços.
[]s
By Raoni on Jun 28, 2009
Raoni, repositórios são importantes, mas o assunto tem um âmbito bem maior.
Sobre modelagem você pode encontrar aqui, aqui e aqui. Recomendo inicialmente os livros de Thomas Erl.
Quando você define “tipos” de serviços, você está elaborando sua arquitetura. Com isso você pode organizar, por exemplo, como distribuir suas regras de negócio (divisão por domínio, isolar regras de conectividade, entre outras possibilidades), garantindo os princípios SOA.
[]´s Gustavo
By admin on Jun 29, 2009