Assim como o ESB (Enterprise Service Bus) atua como um mediador, permitindo que web services conversem uns com os outros sem a necessidade de criar um relacionamento ponto-a-ponto específico para cada um deles, um modelo canônico permite que sejam definidos esquemas para as entidades de uma organização (ex. Cliente, Produto, Fatura, etc..), desta forma, todos serviços fazem uso desse mesmo modelo de dados canônico, reduzindo o número de transações, o custo de infraestrutura e o custo de implementação e garantindo uma maior padronização como consequência do aumento do reúso.

Definir as entidades separadamente para cada serviço implica em um contrato de serviço (WSDL) totalmente customizado para cada serviço. Isto pode significar muita redundância, também conhecido como desnormalização de esquema.

Qualquer serviço que necessite fazer troca de dados pode traduzir sua versão de dados local para versão canônica.

Considere que uma empresa adquiriu outra empresa. Ambas as empresas possuem a entidade Funcionário. No entanto, o esquema de ambas as entidades são diferentes. Utilizando o modelo de dados canônico, basta que os dois serviços mapeiem seus dados para o modelo canônico, eles não precisam mapear de um para o outro ou serem individualmente reescritos.

A transformação de dados local para o modelo canônico ocorre mais frequentemente de três formas:

• O Consumidor 1 chama o Serviço A. Ambos utilizam o modelo canônico, nenhuma transformação é necessária, sendo esta implementação a ideal;
• O Consumidor 2 chama o Serviço B. A transformação para o modelo canônico ocorre dentro do barramento;
• O Consumidor 3 chama o Serviço C. Um adaptador transforma a mensagem do modelo local do serviço para o modelo canônico.

O modelo canônico existe para definir conceitos e agem como mediadores ideais.

O modelo canônico deve ser mantido de forma flexível e geral, dado que eles irão potencialmente absorver uma variedade de definições de entidades.

A evolução do modelo canônico implica na evolução do contrato do serviço (WSDL), já que o esquema faz parte do contrato do serviço (WSDL), sendo assim, será necessário re-gerar código do serviço.

A evolução do modelo canônico deve ocorrer através da governança SOA. Os esquemas podem ser versionados. Indicando explicitamente a versão do esquema no namespace, têm-se a liberdade para mudar apenas os serviços necessários no momento, sem a necessidade de alterar todos os serviços de uma só vez. Os demais serviços podem ser alterados ao longo do tempo, mas o ideal é que essa atualização não demore a ser feita. Ter muitas versões de esquema canônico em uso, pode levar a não se ter mais o esquema canônico. As atividades de governança para este processo devem estar bem definidas.

Abraço,
Daniel Varanda

Representação do Modelo Canônico em uma abordagem SOA

Related posts:

1. O lado técnico da aquisição de um ESB

Vejam:

• Mundo Java - Gartner lança Quadrante Mágico em Governança SOA e destaca Sensedia como visionária
• Executivos Financeiros - Sensedia é posicionada como visionária no Quadrante Mágico de Governança SOA do Gartner
• Baguete - Sensedia, 1ª brasileira no Quadrante de SOA

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. Oportunidade para especialista SOA
3. Aplicação de Metodologia Ágil em Consultorias SOA

=====================

Há consenso no mercado e nas corporações que poucas ações podem trazer melhorias tão significativas no desenvolvimento de software quanto a possibilidade de reaproveitar e capitalizar o que já foi construído, testado e validado, permitindo que soluções existentes sejam implementadas rapidamente em novos contextos. Essa é a idéia do asset reuse, ou reúso de ativos. Com ele, migra-se do modelo do software artesanal para uma indústria de software mais madura, capaz de “montar peças” para compor novos sistemas.

Isso torna o processo de engenharia de software mais eficiente em termos de custo, produtividade e qualidade, e mais apto a responder com agilidade às mudanças nos processos de negócio.

Por essa razão, o desenvolvimento de software baseado em componentes vem se firmando cada vez mais como uma proposta concreta para a melhoria da produção de software, cujo processo passa a ter foco em:

• Criação de ativos — sejam eles componentes (blocos de software com funcionalidades) ou serviços (funções de um sistema que são disponibilizadas na rede através de uma interface), base do modelo SOA — Service Oriented Architecture;

• Reúso de ativos — sejam eles parte do próprio capital intelectual da corporação, provenientes de comunidades de software livre ou comprados de terceiros.

Os benefícios dessa abordagem são obtidos através da definição de uma estratégia corporativa de reúso, representada por mudanças em termos de negócio, processos, pessoas e ferramentas. Com isso, tem-se o necessário para a implementação, monitoração, governança e capitalização das ações. Pesquisas elaboradas por Ivar Jacobson e Jeffrey Poulin (referências mundiais em engenharia de software e reúso de ativos) apontam melhorias em produtividade da ordem de 100 a 400% e redução de defeitos e custos de manutenção de 80 a 90% para corporações que adotam reúso sistemático de ativos.

imagem-minipaper1

Na prática, a implementação dessa estratégia deve seguir uma trajetória caracterizada por um novo direcionamento executivo, no qual o investimento inicial é necessário e a governança passa a ser fator de sucesso ou fracasso. O retorno do investimento (ROI) tipicamente é obtido de médio a longo prazo, uma vez que os desafios da estratégia sejam superados. Porém, existem fatores comuns apresentados por corporações que tiveram êxito na implementação da estratégia de reúso.

O primeiro é a mudança no processo de engenharia de software, com a formalização de todos os pontos do ciclo de desenvolvimento nos quais a componentização pode ser considerada. É importante pensar em reúso desde o início, quebrando a solução em pacotes menores. O refinamento ocorrerá em etapas posteriores, contribuindo para a biblioteca de ativos. É necessária também uma arquitetura corporativa de referência, garantindo produtividade e uniformidade técnica ao portfolio de projetos da corporação.

Para um fornecedor de TI, outro fator é a criação de um modelo de licenciamento, no qual os ativos são precificados e vendidos como parte da solução, reforçando ao cliente o potencial de diminuição do preço final. O cliente, ao adquirir soluções compostas por ativos reutilizáveis, cria uma biblioteca que facilita a construção de novos sistemas.

Por fim, tem-se a necessidade de investimento (ou uso da receita com licenciamento) em uma unidade de negócios focada no gerenciamento dos ativos, ou seja, criação, manutenção, controle de versões, divulgação e mecanismos de incentivos. Essa unidade deve ter foco em governança e integração dos processos, apresentando métricas e visões gerenciais que possibilitem o acompanhamento dos seus benefícios, como ROI, economia de cada reutilização, ativos mais solicitados, entre outros.

Nesse mundo de reúso de ativos, SOA e engenharia de software madura, as corporações precisam assumir efetivamente o modelo de colaboração, compartilhando e reutilizando soluções, unificando esforços e boas práticas. Todos têm a ganhar ao não reinventar a roda.

Para saber mais

http://en.wikipedia.org/wiki/Code_reuse
http://www.redbooks.ibm.com/redbooks/pdfs/sg247529.pdf
http://books.google.com/books?id=wrFQAAAAMAAJ&pgis=1

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. Aplicação de Metodologia Ágil em Consultorias SOA
3. Avaliando a maturidade em SOA

Recentemente fiz uma viagem para a China para participar de um evento sobre Reutilização de Software (ICSR 2008), que aconteceu em Pequim (ou Beijing para os íntimos). Agora com todo o oba-oba das olímpadas, eu também gostaria de compartilhar algumas curiosidades dessa viagem com vocês:

• O aeroporto de Beijing é muuuuuito grande.
• Os espetinhos de comidas estranhas como escorpião, vermes e cobras são nojentos e fedorentos.
• Quase ninguém fala inglês. Para se movimentar de taxi você precisa pedir para alguém do hotel escrever em mandarim o destino.
• A cidade está muito bonita, cheia de flores, super limpa e com uma poluição a lá São Paulo.
• Mas o que mais me impressionou em Beijing foi a quantidade de gente.
• (vejam algumas fotos dessa cruzada pelo oriente mais abaixo)

Mas falando agora sobre tecnologia (e mais especificamente sobre o evento), apesar da conferência ter um foco mais acadêmico, acabei participando de algumas boas apresentações. A mais interessante foi um workshop bem bacana com 2 pesquisadores renomados: Bill Frakes (http://frakes.cs.vt.edu/) e John Favaro (http://www.johnfavaro.com/) sobre iniciativas de reutilização de software e uma perspectiva econômica sobre os benefícios da reutilização. John Favaro mostrou como aplicar técnicas simples de economia e finanças como “Valor Presente” e “Taxa interna de retorno” para se ter uma visão mais precisa sob o aspecto financeiro (que nós computeiros normalmente negligenciamos).

De fato, fui convencido de que um bom programa de reutilização de software ou então uma boa iniciativa SOA devem adicionar algumas fórmulas financeiras em seu Business Case.

Se alguém quiser mais informações sobre isso, me mandem um e-mail (kleber.bacili@digitalassets.com.br).

Um abraço,
Kleber

Related posts:

1. Avaliando a maturidade em SOA
2. O papel dos Repositórios SOA
3. O Modelo Canônico em uma abordagem SOA

A tarefa de se definir ou até mesmo refletir sobre Asset Management não é simples. Para começo de conversa, é necessário qualificar o ativo, ou seja, precisamos definir o que é asset. Esse termo é tipicamente utilizado nas áreas de economia, mídia e tecnologia. Economicamente, Asset Management remete a gestão da carteira de ativos financeiros, com foco em investimentos coletivos ou simplesmente ativos pessoais. Com relação à mídia, o conceito aborda a criação, publicação e gestão de imagens e outros arquivos de mídia.Em tecnologia, há duas formas usuais de Asset Management: controle de inventário de licenças de software; e a gestão de ativos de conhecimento como componentes de software, serviços e bibliotecas com o objetivo de organização e reutilização.

Nessa discussão, vamos nos concentrar no conceito de Asset Management, significando a gestão da criação e reutilização de componentes, serviços, bibliotecas, etc. de forma integrada ao ciclo de desenvolvimento de aplicações de software. A gestão de ativos tem obtido papel fundamental na implantação de estratégias de vanguarda no desenvolvimento de software, como Service-Oriented Architecture (SOA). Nestes casos, é vital ter controle do acervo de ativos. Asset Management possibilita uma visão do que já se tem pronto para ser monitorado, evoluído e reusado em diferentes contextos com o objetivo de encurtar o ciclo de desenvolvimento, reduzir custos e aumentar a qualidade na criação de aplicações de missão crítica.

Anote aí. Quando a questão é Asset Management, devemos pensar em governança, controle do acervo, economia e visibilidade das aplicações e reutilizações. Esta abordagem, juntamente com as ferramentas, métricas e processos adequados, pode fornecer diferenciais competitivos consideráveis para as áreas de TI das empresas.

– Marcílio

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. Avaliando a maturidade em SOA