Projetando serviços, referências

November 21, 2008 – 2:42 am by Gustavo S. Sinis

Projeto de serviços é uma questão freqüente, por isso montei uma relação de referências interessantes. Também vou escrever algumas experiências nos próximos posts.

As referências clássicas são IBM Rational e Thomas Erl , no entanto, existem alguns autores que não são focados no tema que possuem um material importante, por exemplo:

Robert C. Martin
Founder, CEO, and president of Object Mentor Incorporated.

Jim Webber
Global Architecture Lead, ThoughtWorks

Scott W. Ambler
Leader Agile Development with IBM Rational

Martin Fowler
Author, speaker, consultant and general loud-mouth on software development

Existem muitas referências para projetar serviços no mercado, para navegar e obter resultados com essas abordagens é importante compreender a essência. Uma boa base geral ajuda muito, criei uma relação de livros para uma formação básica, mas não relacionados diretamente com SOA. Claro que não é uma lista definitiva, mas um começo interessante.

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)

Fundamentals of Object-Oriented Design in UML (Addison-Wesley Object Technology Series)

Business Component Factory : A Comprehensive Overview of Component-Based Development for the Enterprise (Hardcover)

UML Components: A Simple Process for Specifying Component-Based Software (Component Software Series)

Domain-Driven Design

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)

Refactoring to Patterns (Addison-Wesley Signature Series)

Anatomia do serviço. O que é, afinal?

November 10, 2008 – 12:24 pm by Gustavo S. Sinis

Aquele blog de SOA publicou mais um post meu. No post procurei fazer uma reflexão do papel dos Serviços, contando com referências de autores como: Jim Webber e Thomas Erl.

Grupo de Interesse em BPM - RJ, painel sobre SOA

October 30, 2008 – 3:28 pm by Gustavo S. Sinis

No dia 23 de outubro de 2008, a convite de Leonardo Borges (Diretor de Tecnologia da Atimus) e de Fernando Botafogo (Coordenador do Grupo de Interesse de BPM da Sucesu-RJ), participei de um painel muito interessante sobre SOA, realizado na Firjan, do Grupo de Interesse em BPM - SucesuRJ.

O interesse e as contribuições relevantes do público presente foi um dos destaques do evento, e possibilitou um rico diálogo. O formato de talk show, com o uso de questões previamente elaboradas pelo grupo de interesse em BPM, incentivou a interação entre todos.

O painel foi formado por profissionais com forte atuação no mercado: Marcilio Oliveira, da Digital Assets, André Boaventura, da Oracle, e por mim, da CPM Braxis.

Gostaria de agradecer o convite e a troca de experiência.

Para ter acesso ao material de apoio e às atividades do grupo: GI_BPM_SucesuRJ

Realidade do ESB sem SOA

October 22, 2008 – 6:57 pm by Gustavo S. Sinis e Leonardo Nicolás

ESB são importantes em quase todos os cenários, fornecendo uma infra-estrutura para SOA como, por exemplo, lógica de compensação, transformação de dados, segurança, garantia de entrega, logging. Ainda todos os WS-*…

Vendedores de ferramentas ESB freqüentemente usam em suas apresentações uma figura clássica, que representa a complexidade de TI causando grande impacto visual. Em seguida, usando uma figura mais impressionante, mostram como ferramentas ESB podem organizar a casa, resolvendo todos os problemas.

No entanto, a verdadeira flexibilidade de SOA é obtida com serviços bem projetados, não com a adoção de ferramentas (muitos vendedores deixam essa impressão). Os serviços devem ser representativos para o negócio, seguindo certos princípios, como: low coupling, stable interface, entre outros.

Sem serviços bem projetados o cenário não muda muito: toda bagunça produzida no mundo corporativo, criando integrações espaguete, não some com a implantação de ESBs. Apenas fica escondida debaixo do tapete, ou seja, dentro do barramento, exigindo uma “lógica de conectividade” muito complexa.

Realidade de TI, nossa versão:

Aparente milagre de ferramentas ESB (onde está a bagunça?):

Olhando mais de perto, de acordo com Jim Webber, o que realmente acontece com ESB:

Aplicações sem serviços bem projetados misturam a lógica do fluxo do negócio (processo de negócio), lógica de conectividade e a lógica de domínio em abstrações pouco coesas; desta forma aumenta drasticamente o acoplamento e complexidade da integração, sendo comum a ocorrência de dependência circular.

Em outras palavras, mesmo com uma ferramenta ESB eliminando a integração ponto a ponto, na ausência de serviços projetados para apoiar processos de negócio (ou seja, sem SOA), ainda teríamos “integração espaguete”, só que agora escondida dentro de uma ferramenta, inviabilizando a flexibilidade prometida pela abordagem SOA.

Já trabalhei em empresas que utilizam o Broker e o que acontece é que a complexidade das integrações passa para dentro dessa ferramenta. Por um lado isso é bom porque o ESB / Broker passa a ser um ponto comum de comunicação, gera uma padronização e outros ganhos.

Mas se o que está dentro do ESB / Broker não estiver muito bem projetado, ficará quase impossível dar manutenção e suporte. Usar ESB assim é equivalente a pegar a integração espaguete e dar um nó no meio, este nó é o ESB. Para desatar o nó apenas serviços bem projetados.

Vídeo interessante relacionado com SOA sem ESB: Does My Bus Look Big in This?, Martin Fowler & Jim Webber, QCon London 2008. Um post também interessante relacionado: SOA, cuts the Gordian Knot — Not, Uncle Bob.

Apenas por curiosidade, desenhamos as figuras que ilustram o post utilizando Java e a API para desenho 3D Java Monkey Engine.

Espaguete.java

EspagueteComNo.java

Front de batalha, continuação

October 10, 2008 – 3:42 pm by Gustavo S. Sinis

Segunda parte do artigo foi publicada. Conta com uma analogia para conceituar SOA sobre a ótica do Serviço:  serviço de organização de grandes eventos. 

Front de batalha:

“Aquele blog de SOA publicou um post meu. Este blog reúne consultores SOA com experiências distintas, atuando fortemente no mercado.

No post procurei conceituar SOA sobre a ótica do Serviço, contando com citações de autores como: Jim Webber, Uncle Bob e Thomas Erl.”

Front de batalha

September 24, 2008 – 3:43 pm by Gustavo S. Sinis

Aquele blog de SOA publicou um post meu. Este blog reúne consultores SOA com experiências distintas, atuando fortemente no mercado.

No post procurei conceituar SOA sobre a ótica do Serviço, contando com citações de autores como: Jim Webber, Uncle Bob e Thomas Erl.

Grandes Civilizações e Jazz ( EPF WIKI )

August 24, 2008 – 11:13 pm by Gustavo S. Sinis

A tecnologia torna grandes civilizações possíveis. Desde a antigüidade, grandes populações tornaram ferramentas e técnicas indispensáveis. Desde 1.000 a.C, as civilizações já contavam com o arado, construções em arco, aqueduto, e com o carrinho de mão. Civilizações são organizadas, por exemplo, em cidades e acrópoles, possibilitando lidar com a complexidade que envolve administrar e suportar grandes populações.

Grandes corporações também precisam de ferramentas, e algumas são importantes para apoiar a governança. Encontramos desafios em coordenar e gerenciar várias equipes simultâneas, que estão freqüentemente desenvolvendo sistemas para automatizar partes distintas do mesmo sistema e processo de negócio, algumas trabalhando remotamente.

Isto resulta na necessidade de uma abordagem fácil de planejar, divulgar e reaproveitar processos de governança como, por exemplo, no caso de SOA, políticas de propriedades de serviço (“com quem eu reclamo?”) e de incentivos ao reuso. Esses processos de governança podem ser publicados, reutilizados e compostos com ajuda do EPF (Eclipse Process Framework).

A publicação pode ser feita em HTML, WAR (recursos mais avançados) e PDF. Além disso, pode ser transformada em um WIKI, montando um ambiente mais colaborativo.

“EPF Wiki is Wiki technology designed to be used together with Eclipse Process Framework (EPF). This offers the best of two distinct worlds: the worlds of powerful process frameworks and Wikis. It offers an process engineering infrastructure that combines a modular method construction approach and the flexibility and ease of use that is the defining characteristic of a Wiki. ” Site do EPF Wiki.

Grandes corporações possuem uma vasta quantidade de processos de negócio - muitos são complexos e em constante mudança. SOA ajuda a lidar com a complexidade, uma vez que organiza, indexa e encapsula o código, tornando as mudanças aceitáveis. Alguns vendors sustentam que ferramentas ESB são essenciais para SOA, mas acredito que práticas para representar e apoiar processos de negócio são mais importantes. O EPF pode ajudar a consolidar e divulgar corporativamente essas práticas. Does My Bus Look Big in This?, Martin Fowler & Jim Webber, QCon London 2008

A maior parte das pessoas não lê livros, especialmente descrições longas de processo, por isso, práticas ágeis e processos de governança simples e flexíveis - governança ágil – são essenciais. Ivar Jacobson defende esse novo paradigma em Enough of Processes: Let’s Do Practices. Ivar é um dos “pais” da arquitetura de componentes, caso de uso, UML e do RUP.

Jacobson sustenta que um processo é apenas uma composição de Práticas. Uma prática é um elemento reutilizável/essencial destacado do método/processo que pode ser usado separadamente de outras práticas. EPF fornece suporte para manter, compor e divulgar práticas de diferentes origens (EPF Practices, XP, SCRUM, OpenUP, OpenUP/MDD , FDD, EssUP…).

Alguns anos atrás, em uma grande corporação, nós utilizamos o EPF para facilitar o acesso de equipes a uma vasta gama de informações. Precisavam adquirir informações sobre desenvolvimento em tecnologias específicas (JEE e . NET), práticas e processos de desenvolvimento, bem como guia para ferramentas em diferentes ambientes e também políticas internas.

Até então, o conhecimento estava distribuído em vários PDFs, dificultando o acesso e o processo de atualização de diversas publicações inter-relacionadas (muito trabalho braçal para manter os links). O processo de desenvolvimento não poderia ser alterado (isto é, ele é rigorosamente controlado para finalidade de auditoria), então restava apenas trabalhar com a “arquitetura de informação”. O EPF forneceu um meta-modelo e um meio de publicação para manter e criar uma grande variedade de processos de TI, como processos de governança SOA e processos de desenvolvimento de Software.

Alguns, já acostumados com os endereços dos PDFs, alegaram dificuldades com a publicação gerada, pois esta exigia algum treinamento básico (mesmo existindo ferramentas de buscas eficientes); para outros, o acesso a novas informações ficou mais intuitivo. O ponto crítico foi a reengenharia da informação, um processo que deve ser contínuo. Com o conhecimento organizado/indexado, foi possível evidenciar vários problemas no processo de desenvolvimento. O EPF contribui com evolução do conhecimento, facilitando a inclusão de novas práticas e a supressão das antigas.

Além disso, o EPF permite que sua experiência em uma determinada abordagem seja armazenada e mantida de forma coesa e independente. Você pode criar um núcleo SOA, por exemplo, com processos, papéis e práticas para apoiar o desenvolvimento de aplicações em uma estratégia SOA e incrementar o processo de um cliente (se publicado com EPF) de forma não invasiva, ou seja, sem alterar fisicamente os processos, apenas usando os mecanismos de extensão (Herança, Descritores e outros) ou, ainda, publicar uma versão nova adaptada para a realidade do cliente (se ainda não utiliza o EPF).

Como o EPF pode ajudar?

O EPF é uma ferramenta de código aberto (Tecnologia Eclipse), baseado no SPEM/OMG (Software & Systems Process Engineering Metamodel specification), que fornece uma terminologia comum para documentar processos (governança) e práticas; mecanismos para adaptar e estender o conhecimento para projetos diferentes; e um ambiente central de publicação para facilitar a disseminação da base de conhecimento (navegação gráfica em todo o processo publicado).

Os conceitos do SPEM norteiam todas as funcionalidades do EPF. Todo método e prática/processo pode ser representado usando a seguinte estrutura básica:

Elementos principais

Produto de Trabalho - Um Produto de Trabalho é algo significativo, resultante da execução de uma tarefa. Não precisa ser formal, pode ser uma idéia em um quadro branco, ou algo mais formal como, por exemplo, código ou um documento de arquitetura.

Função (Papel) - Uma Função define um conjunto de habilidades, competências e responsabilidades relacionadas;

Tarefa - Uma Tarefa descreve uma unidade de trabalho. Cada Tarefa é desempenhada por Funções específicas. A granularidade de uma Tarefa geralmente é algumas horas em poucos dias.

Processo - pode agrupar tarefas em atividades, e as relaciona em seqüências ordenadas.

Orientação - é um conceito abstrato que generaliza o conteúdo, cuja finalidade principal é fornecer explicações e ilustrações adicionais aos elementos anteriores. Exemplos de orientações especializadas: Mentor de Ferramentas, Conceito, White Paper, Exemplo, Diretriz.

Existem diversos processos disponíveis nesse modelo, organizados em plugins (mecanismo que organiza os processos e métodos fisicamente no EPF), por exemplo, XP e SCRUM. Temos, ainda, uma coleção de práticas para serem acrescentadas em seu processo de desenvolvimento de software ( EPF Practices ), quais sejam: Continuous Integration; Iterative Development; Two Level Project Planning; Concurrent Testing; Evolutionary Design; Use Case Driven Development; Test Driven Developmen; Evolutionary Architecture. Uma metodologia para criar governança SOA da IBM também está disponível neste formato.

O EPF fornece mecanismos de “herança e polimorfismos” para o Conteúdo do Método (Tarefa, função, Produto) e para os Processos, ajudando a compor ou a combinar práticas e processos distintos.

O EPF também separa o Conteúdo do Método (Tarefa, Tarefa, Produto) - o núcleo - dos Processos. Isso assegura a reutilização do núcleo em processos diferentes. Um dos mecanismos utilizados para a separação é o Descritor.

Um Descritor representa uma ocorrência de um Elemento de Conteúdo concreto (como, por exemplo, Tarefa, Função, Produto de Trabalho) em um Processo. Os Descritores fornecem uma representação tipo proxy para esses Elementos de Conteúdo. Além de apenas fazer referência, permitem substituir os relacionamentos estruturais de Elementos de Conteúdo, definindo seus próprios conjuntos de associações, acrescentado mais orientações ou trocando papeis em uma tarefa.

O EPF permite que diferentes metodologias relacionadas como, por exemplo, desenvolvimento unificado e práticas para apoiar SOA (identificação, especificação de serviços) sejam mantidos independentemente (separação física com plugins) e ainda relacionadas, ou seja, usadas de forma combinada e não intrusiva, apenas usando os recursos de extensão do EPF.

Abordagem com WIKI

A ferramenta EPF WIK , é uma estratégia interessante para disseminação de novas práticas.

Segundo Per Kroll (EPF Project Lead), o EPF WIK pode ajudar:

” 1.Rapidly gather useful feedback by writing comments associated around content (lock content from editing)

2.Build communities around key content areas (lock editing to be centered around dedicated topics);

3.Rapidly gather useful feedback by directly editing process content

4.Improve process content without learning the metamodel or Composer

5.Capture process related experiences through harvesting “

Outras considerações

A plataforma JAZZ tem como promessa fornecer ferramentas para apoiar um desenvolvimento mais colaborativo e ágil.

“ Developing software in a team is much like playing an instrument in a band. Both require a balance of collaboration and virtuosity. Jazz defines a vision for the way products can integrate to support this kind of collaborative work, and a technology platform to deliver on this vision. ”

Em julho participei do IBM Development Conference, onde foi promovido o Team concert, criado com base na plataforma Jazz, que incorpora tecnologias de colaboração e um motor de processos, em que podemos “executar” um processo de governança definido com o EPF, por exemplo.

Revista ESM

Foi publicado recentemente um artigo meu com uma introdução da ferramenta.

DDD, SOA

August 13, 2008 – 12:08 am by Gustavo S. Sinis e Leonardo Nicolás

SOA promove flexibilidade ao negócio - foco corporativo, processos - , no entanto, utilizar uma filosofia em que os conceitos do negócio ficam explícitos - DDD, programar para o domínio -, aumenta dramaticamente o nível de flexibilidade possível.

“Fundamentally, DDD is the principle that we should be focusing on the deep issues of the domain our users are engaged in, that the best part of our minds should be devoted to understanding that domain, and collaborating with experts in that domain to wrestle it into a conceptual form that we can use to build powerful, flexible software.” - Eric Evans, infoq.

“…SOA, when it is used well, provides us a very useful way of isolating the domain.”
- Eric Evans, infoq.

Artigo interessante: Domain-Driven Design

[ Temos neste blog uma taxonomia de referencia, facilitando a exploração de conceitos, pois existem muitas abordagens conflitantes no mercado. ]

Os serviços básicos de negócio (parecidos com “serviços corporativos” para Erl), por exemplo, encapsulam um domínio, expondo funcionalidades básicas e mais atômicas do negócio (regras de negócio), são coesos e pouco acoplados, normalmente representam um conceito principal do negócio. (Em corporações complexas, dificilmente teremos total controle de duplicação de regras, mas podemos usar algumas abordagens, por exemplo, serviços compostos, para encapsular essas redundâncias.)

Algumas abordagens do livro de Eric Evans podem ajudar na organização desses serviços básicos negócio, por exemplo, distillation na parte de Strategic Design (apenas os serviços importantes para o negócio serão publicados, os serviços essenciais). “Distillation is the process of separating the substances composing a mixture. The purpose of distillation is to extract a particular substance from the mixture. During the distillation process, some byproducts may be obtained, and they can also be of interest. ”, Eric Evans. Strategic Distillation.

Essas abordagens se destinam, na maioria das vezes, a superar limitações humanas, como gerenciar complexidade. Não são incomuns empresas com várias equipes (ou consultorias) desenvolvendo sistemas para automatizar partes diferentes do mesmo subprocesso de negócio.

….

Serviços, em muitos casos, são construídos utilizando objetos. O domínio é “instanciado” também usando objetos (por exemplo, POJOS), objetos devem garantir seu estado consistente (Page Jones) e muitos devem ser persistidos. Neste ponto, começam as dificuldades técnicas, por isso usamos AOP (por exemplo, Spring Framework), EJB 3.0, hibernate; possibilitando focar esforços no domínio (camada de negócio). Algumas abordagens e experiências com uma aplicação JPA e Spring estarão em um próximo post.

Elegibilidade de SOA

July 15, 2008 – 2:32 pm by Gustavo S. Sinis

O negócio determina se a abordagem SOA é apropriada, ou seja, se flexibilidade e resposta rápida a mudanças são importantes para um determinado processo de negócio. Quando utilizamos SOA, criamos uma abstração que indexa, isola e organiza o código (que representa as regras de negócio). A indexação leva tempo e exige um projeto mais elaborado, mas proporciona controle da complexidade e respostas rápidas a mudanças. SOA só faz sentido se pensarmos corporativamente e no efeito acumulativo da abordagem.

A criação de níveis de orquestração, por exemplo, exige um projeto mais elaborado. Serviços compostos proporcionam baixo acoplamento, funcionam como uma camada de indireção para outros serviços, substituindo trocas de mensagens diretas (projeto mais simples) por orquestrações (projeto mais elaborado).

Soluções com SOA se destinam, na maioria das vezes, a superar limitações humanas, como lidar com grande quantidade de sistemas com regras compartilhadas e processos complexos freqüentemente alterados. Para lidar com tal complexidade, no caso de SOA, a principal abstração é o serviço de processo de negócio. Serviços orientam a arquitetura e fornecem um vocabulário comum entre TI e as áreas de negócio.

Além da relevância para o negócio, é necessário considerar o equilíbrio entre processos, ferramentas e pessoas. Na prática, não é fácil conciliar interesses de projetos de desenvolvimento de software - que possuem pressão de prazos, custos e objetivos imediatos - com os interesses mais corporativos e estratégicos. Corrida de cem metros ou maratona? Por isso, só e viável a abordagem SOA se for possível o mínimo de governança, com políticas de propriedade de serviços e de incentivos.

Grandes corporações encontram desafios em coordenar e gerenciar várias equipes simultâneas, e algumas vezes desenvolvendo partes diferentes do mesmo sistema. Isto resulta na necessidade de uma forma fácil de planejar, divulgar e reaproveitar processos de governança e práticas mais ágeis, algumas ferramentas podem ajudar como, por exemplo, o Team Concert.

Já no caso de ferramentas, ESBs são interessantes, mas não obrigatórias para SOA, sendo os processos e os métodos mais importantes. Contudo, ferramentas que podem apoiar a governança SOA como, por exemplo, EPF, DAM e JAZZ, devem ser seriamente consideradas.

Finalmente, uma equipe madura, treinamentos e consultoria são essenciais.

Separar a lógica do processo de negócio

July 15, 2008 – 2:17 pm by Gustavo S. Sinis

Promover uma cultura de processo é um dos fundamentos da adoção de SOA.

Em geral, os processos de negócio concentram-se nas tarefas repetitivas executadas em uma seqüência lógica (fluxos), fornecendo resultados definidos para apoiar os objetivos da organização. As tarefas buscam atingir alguma meta atômica, freqüentemente utilizando como entrada ou saída produtos de trabalho. Os processos podem ser classificados como: a) principal, para os processos de negócio que fornecem valor para atores externos da empresa como, por exemplo, clientes; b) administrativo, para os processos de negócio que fornecem a valor para atores internos da empresa; c) apoio, para os processos de negócio que apóiam os processos principais.

Freqüentemente, os processos são utilizados sem considerar explicitamente os fluxos de trabalho do negócio (seqüência lógica das tarefas do processo), utilizando apenas os conceitos principais extraídos do negócio. A isto dá-se o nome de modelagem de domínio de negócio, que são conceitos obtidos a partir da análise dos produtos de trabalho e do vocabulário utilizado no processo relevante ao software que está sendo desenvolvido. Tais conceitos são utilizados como um vocabulário comum para OOAD.

Para ilustrar uma abordagem tradicional, focando em práticas, podemos relacionar de forma sintética algumas atividades.

Na iteração temos:

  • processo de negócio é modelado ou entendido e, em muitos casos, já está modelado previamente (BPMN);
  • em função das necessidades de automação ou alteração do processo (ou seja, os requisitos), soluções funcionais são detalhadas (UC essencial [1], historias, TDD);
  • na realização dos UCs, os POJOS, representando o modelo de domínio da aplicação (MDD), recebem responsabilidades e trocam mensagens para atender as necessidades dos UCs (Cartões CRC [1], diagrama de robustez [1], GRASP, DDD);

Nesta abordagem, como mais de um UC pode ser realizado em paralelo, equipes colaborativas são indispensáveis. É comum existir uma pessoa responsável pelo merge dos objetos/conceitos que estão sendo trabalhados em paralelo, pois UCs podem compartilhar esses conceitos (Domínio). Em corporações mais complexas, existem sistemas que também compartilham conceitos; com isso, em muitos casos, as regras de negócio são duplicadas ou integrações spaghetti são usadas. Para controlar a complexidade, uma estratégia de decomposição de domínio pode ajudar, pois a abordagem facilita o reaproveitamento do domínio criando módulos coesos e pouco acoplados.

O processo é considerado, mas o fluxo do processo fica dentro da aplicação misturado com: lógica do domínio, pré-condições dos componentes de negócio ou, ainda, fica por conta da disciplina dos usuários ou de gerentes de áreas. O problema reside em considerar apenas o domínio, sem separar o fluxo do negócio, pois o processo de negócio é uma forma natural de entender como uma corporação funciona. Práticas de BPM como, por exemplo, monitoração de instâncias de processos, análise de tendência e simulação, podem provocar mudanças em processos de negócio. Separar a lógica do processo proporciona flexibilidade, que é um diferencial estratégico.

Serviços de processo - uma abstração que representa uma atividade do processo - auxiliam na separação da lógica do processo de negócio da lógica do domínio, fornecendo uma interface bem definida e independente, que organiza a aplicação para apoiar processos. Serviços são orquestrados (lógica de processo de negócio) para executar o processo, e o padrão de mercado atual utilizado é o BPEL.

Existem também abordagens em que serviços representam partes de um processo ou subprocessos, não apenas uma tarefa. Neste caso, o serviço possui o estado do processo, representa um conjunto de tarefas e a seqüência de execução. Atualmente, implementações BPMS e BEPL substituem com vantagens essa abordagem.

Mesmo que a aplicação não tenha uma abordagem BPM (BPMS +BPEL), serviços de processo são úteis, pois orientam a arquitetura, fornecem um vocabulário comum entre o processo de negócio e a aplicação, facilitando também a comunicação da TI com as áreas de negócio. Técnicas de decomposição de processos ajudam a identificar os serviços candidatos, uma vez que a existência desse serviço de processo só faz sentido se o mesmo estiver associado a uma atividade no processo de negócio.

Para auxiliar na separação da lógica do processo, algumas atividades devem ser incluídas no desenvolvimento como, por exemplo, a identificação de serviços. Na identificação de serviços candidatos, podemos relacionar as seguintes técnicas: a decomposição de processos, ou seja, a identificação de serviços de processo de negócio; e a decomposição de domínio, isto é, a identificação de serviços básicos.

Taxonomia instanciada

Serviços de processos são executados em uma seqüência lógica, e essa seqüência pode ser criada em BPEL ou em uma camada específica para a lógica de processo. Esses serviços, a fim de cumprir uma tarefa do processo de negócio, orquestram um ou mais serviços básicos.

Serviços básicos de negócio encapsulam a lógica de domínio e a expõem através de interfaces bem definidas. No mesmo sistema, podemos ter mais de um serviço básico; neste caso, eles são identificados a partir da aplicação de técnicas de decomposição de domínio. Um serviço básico pode, ainda, representar um sistema legado inteiro. Serviços básicos são criados para atender as necessidades dos UC, mas sua interface deve ser projetada para ser reutilizável corporativamente.

Eventualmente, para atender um UC, temos códigos que não pertencem exclusivamente a um serviço básico (seqüência de execução), e também não estão coesos/associados diretamente a um serviço de processo. Neste caso, se o código for reutilizável, podemos usar o conceito de serviço composto, que é um serviço básico que orquestra outros serviços básicos, funcionando como um camada de indireção, ou seja, evitando que serviços básicos troquem mensagens diretamente (baixo acoplamento).

Clientes dos serviços de processo são responsáveis pela lógica de processo (BPMS ou aplicações); clientes dos serviços básicos são responsáveis por garantir a pré-condição e a seqüencia de execução (Serviços compostos ou aplicações); serviços básicos encapsulam regras de negócio.

———————————————————————-
[1] Scott W. Ambler