Muitas empresas sem uma abordagem SOA possuem iniciativas de reuso e integração, promovidas por talentos individuais. Funcionando em um delicado equilíbrio, em que os desenvolvedores reusam seus próprios serviços ou os de uma pessoa de sua confiança, ignorando todos os outros possíveis serviços existentes (internos ou externos).

Nesse cenário de reuso limitado, empresas complexas com integrações espaguete e redundância de regras de negócio conseguem sobreviver - pois existe um nível de controle até certo ponto gerenciável -, mas abrindo mão da agilidade (uma alteração do negócio pode demandar um esforço imprevisível).

Por outro lado,  promover o reuso indiscriminadamente usando ferramentais atuais sem observar alguns princípios SOA, esse equilíbrio pode ficar comprometido. O que inicialmente pode parecer um ganho, com o efeito acumulativo, deixará muito mais complexo o cenário.

Para exemplificar, vamos imaginar um serviço legado de lançamentos contábeis que não encapsula todas as regras de negócio necessárias para efetuar o lançamento (não segue princípios SOA). Desta forma, todos os clientes deste serviço serão obrigados a implementar algumas regras antes de usar. Neste exemplo o serviço vai, no mínimo, promover a redundância de regas de negócio e acoplamento exagerado para seus clientes.

Multiplique isso por 40 serviços e 200 sistemas, depois tente alterar um processo ou regra de negócio com agilidade… Se o negócio mudar, simplesmente será imprevisível o impacto em seus sistemas. Outro exemplo, se for comprado um pacote de mercado para o backoffice (por exemplo, contabilidade), todos os sistemas que automatizam o processo de negócio principal (que gera dinheiro) será alterado significativamente.

Em outras palavras, o reuso e a integração limitada (atualmente um cenário comum) também limita a propagação dos problemas gerados por serviços que não seguem certos princípios SOA – portanto não é interessante sair reutilizando. Mas como obter agilidade e lidar com o legado?

Não existem respostas fáceis, cada cenário é único. No entanto, para evitar esse problema e muitos outros, o serviço poderia ser encapsulado ou alterado para que atenda alguns princípios SOA, possibilitando que seja reutilizado por todos sem aumentar a complexidade e redundância das regras.

SOA deve simplificar a TI para obter agilidade, usando abstrações obtidas com a análise do negócio, o serviço. SOA não é necessariamente integração e reuso, mas lida diretamente com as limitações humanas, por exemplo, pouca memória e manter cenários complexos, usando abstrações. Abstração está intimamente relacionado com encapsulamento. Portanto, encapsular o legado com serviços bem projetados é essencial.

Atualização:

Encapsular legado significa: encontrar conceitos importantes no legado e criar serviços que encapsulem as regras destes conceitos. Não é apenas criar uma camada de serviços, também envolve, em alguns casos, alterações no legado (mudar regras de lugar, por exemplo: todas as regras de negócio coesas com o serviço - identificado analisando o negócio do legado - que estão em outras aplicações, devem ser retiradas e encapsuladas pelo serviço).

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

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)

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

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:

“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.”

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 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.

“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.