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

Olá Pessoal, li recentemente este Report do Forrester sobre o ritmo de adoção SOA e achei muito interessante, pois mata de vez aquele boato “Is SOA dead?” – segundo as pesquisas do Forrester, não!

Na verdade está longe de morrer, segundo o relatório: mesmo com a crise do ano passado abalando os departamentos de TI, dentre outros, SOA neste período continuou com um ritmo de adoção bastante forte, tanto por empresas de grande porte quanto por empresas de médio e pequeno porte.

A pesquisa também mostra que mais de 80% das empresas estão usando SOA agora (o agora é o Q42009) ou estarão até o final de 2010. E que o nível de satisfação continua alto: mais de 70% das empresas que estão adotando SOA se manifestaram satisfeitas com os resultados que estão conseguindo com a abordagem. No entanto, enfatizam que não foi fácil chegar aos resultados satisfatórios e que governança SOA é um fator crítico para o sucesso.

Related posts:

1. Aplicação de Metodologia Ágil em Consultorias SOA
2. O Modelo Canônico em uma abordagem SOA
3. O papel dos Repositórios SOA

Vai acontecer no dia 29 de OUTUBRO* um Webinar sobre Maturidade e Roadmap SOA, e recomendo fortemente a participação de todos! A apresentação será em português. A participação é aberta, com duração de uma hora. Você assiste aí, no seu computador, e ainda pode dar seus pitacos e enviar perguntas.

Acredito ser uma ótima oportunidade para assistir (e participar) de uma apresentação adequada ao cenário nacional, considerando a realidade das empresas de TI brasileiras e os níveis de maturidade SOA utilizados em diversas consultorias. Um dos apresentadores é este blogueiro que vos escreve, juntamente com Kleber Bacili (Diretor de tecnologia da Sensedia). Faça sua inscrição.

Para maiores detalhes e conteúdo da palestra, veja divulgação abaixo (ou aqui).

Detalhes do Webinar:

Data: 29/10/2009
Horário: 14hs

Em cenários de implantação estratégica de SOA, diferentes perspectivas devem ser consideradas: Mecanismos arquiteturais e padrões de desenvolvimento de serviços, Governança, Metodologia, Infraestrutura e também as Aplicações e Informações já existentes na empresa.

Muitas vezes, as empresas focam esforços na implementação dos serviços em si e acabam negligenciando as outras perspectivas. Entender como balancear as ações nas perspectivas mencionadas acima e como realizar os investimentos nos momentos certos é fundamental para a empresa otimizar os custos envolvidos e antecipar os resultados almejados com a iniciativa SOA

Neste webinar apresentaremos:

• Níveis de maturidade SOA com as suas diferentes perspectivas;
• Como avaliar sua própria maturidade conforme o modelo e os benefícios gerados em cada fase;
• Abordagem Lightweight SOA de priorização e geração de valor;
• Quais competências devem ser desenvolvidas;
• Principais padrões técnicos, mecanismos e boas práticas que devem ser consideradas em seu planejamento;
• Como planejas as ações nas diferentes perspectivas de forma a otimizar custos e antecipar resultados.

abraços,
Marcílio

Related posts:

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

E através da experiência com projetos de implantação, percebemos que a existência destes grupos é vital para a absorção e disseminação para as equipes de desenvolvimento internas da empresa (uma vez que a implantação inicial não envolve toda a fábrica).

Embora seja responsável por garantir a governança SOA sob uma visão corporativa, o Núcleo SOA deve existir já na fase de implantação, pois ele será o responsável por dar a “cara” da empresa na arquitetura definida.

Recentemente o Forrester publicou um relatório listando os benefícios da crianção do Núcleo SOA. Segue trechos de uma matéria a respeito:

Equipe focada em Arquitetura Orientada a Serviços tem como principais funções a garantia da governança e o alinhamento dos projetos.
24 de setembro de 2009

(…) No relatório da Forrester, quando questionados sobre as funções mais valiosas do centro de excelência de SOA, os entrevistados apontaram os cinco principais benefícios:

• Criar e manter a visão e os planos (do projeto SOA)
• Agir para a aprovação de regras que façam parte das políticas de governança de SOA
• Gerenciar os padrões para a implementação da arquitetura
• Gerenciar o portfólio e os documentos relativos aos serviços – baseados na nova arquitetura
• Planejar o futuro das tecnologias que suportam a arquitetura

Entre as conclusões de Heffner em relação ao levantamento, o especialista aponta também que os benefícios citados pelos executivos já são suficientes para mostrar que a criação de um centro de serviços durante a implementação de um projeto de SOA é muito mais eficiente do que simplesmente investir em capacitação das equipes de TI para adequar-se aos padrões exigidos por essa arquitetura.

Li em computerword.

Para mim, o recado é: A criação do núcleo é vital para uma implantação alinhada às necessidades da empresa e para a garantia que passaremos do projeto piloto para a visão corporativa de maneira menos traumática.

abraços,
Marcílio

Related posts:

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

A zapthink acabou de publicar um artigo muito legal a respeito de implantação light de SOA. Um modelo de implantação incremental, focado em ROI de curto prazo, em resposta principalmente para o cenário econômico atual.

Artigo escrito por Jason Bloomberg, um dos principais analistas do mercado. (Download aqui!)

O artigo traz uma série de informações relevantes de mercado e ferramentas, e apresenta também uma visão macro de abordagem para implantação de SOA em um modelo leve, com menores riscos e resultados em curto prazo.

LEITURA OBRIGATÓRIA!!

Lightweight SOA

Download do artigo: aqui!

Alguns trechos do paper:

- “SOA is not particularly risky.”

- “It’s finally time to dispel the myth that SOA success requires a large initial investment and a long-term effort to achieve significant business results.”

- “When times are tough, it is imperative that businesses rethink the way they are doing business.”

- “In lightweight SOA projects, architecture, business processes, and governance drive SOA infrastructure and tooling choices.”

Abraços,
Marcílio

Related posts:

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

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

Recentemente foi publicado um case SOA (Success with SOA: A Cisco case study) com muita relevância, principalmente pelo trabalho envolver um roadmap bastante maduro e preocupações com as questões que, na minha opinião, são cruciais.
Li a notícia na infoQ (Estudo de caso: Sucesso com SOA na CISCO), e de lá retirei um texto para discutirmos aqui.

Segue abaixo alguns trechos do texto e algumas considerações pessoais:

“Harvinder Kalsi é arquiteto líder do domínio SOA/BPM na Cisco, apresentou um estudo de caso em dezembro no SOA Consortium meeting em Santa Clara.

Na sua opinião, nós estamos em um momento crucial para SOA. Ele argumenta que a partir de 2008, o padrão e as tecnologias estarão bastante maduras enquanto o interesse dos negócios está crescendo. Neste estudo de caso o negócio foi o principal driver por trás do desenvolvimento SOA.

Eles estabeleceram suas estretégias SOA utilizando quatro passos para o processo de maturidade:

1. Serviço permite sistemas legados criar uma camada de serviço de negócios
2. Atingir a excelência dos processos de negócio
3. Dar visibilidade ao negócio
4. Eles vêem vários benefícios gerados pela abordagem SOA:

• Reusabilidade
• Agilidade
• Impacto mínimo para mudança

Finalmente, na sua opinião SOA permite pegar a funcionalidade que a Cisco tem internamente e a oferecer ao seu ecosistema de parceiros, ampliando os benefícios para toda a cadeia de estoque.”

Ou seja, conhecemos os benefícios e muitas empresas investiram em maturidade. Agora é o momento das empresas (e não os fornecedores) obterem seus benefícios! Pensei que só eu acreditava nisso, mas vejo que não estamos sozinhos!

Em seguida, são descritas algumas capacidades desenvolvidas na Cisco, durante o projeto. Vou repetir apenas as três que considero totalmente indispensáveis (Padrões de desenvolvimento, Repositório ou Registro de serviços e Governança):

“Mais adiante, Harvinder descreve nos mínimos detalhes as capacidades que a Cisco desenvolveu como parte de sua iniciativa SOA. Muitos destes elementos tem sido desenvolvidos em 2007 e em 2008:

Framework de Desenvolvimento de Serviço

• Este é ambiente de desenvolvimento de serviço padronizado
• Eles tiveram uma redução de 20-30% no desenvolvimento de serviço
• Este foi o elemento chave do seu framework de Operações & Gerenciamento
• Suporta Web 2.0 (JSon, REST)

Registro SOA

• Um stop shop para publicação, descoberta e contratação dos serviços
• Repositório master para todos os serviços dentro da Cisco
• Chave para permitir governança SOA
• UDDI v2
• Integrado com outros componentes da Plataforma SOA
• SOA Gateway

SOA Governança

• Políticas & padrões técnicos
• Templates para definição de serviço
• Processos”

Fico particularmente satisfeito ao encontrar casos de sucesso SOA, principalmente quando percebemos que (quem sabe por coincidência ) eles só acontecem  com planejamento, governança e padrões! Implementar projetos com um monte de serviços não garante que a artquitetura e o negócio sejam “orientados a serviço”… certamente, neste caso, SOA não apenas morre, como mata o projeto.

Como o próprio Harvinder concluiu: “São Pessoas, processos e tecnologias que fazem SOA ser bem sucedido”

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB
3. O papel dos Repositórios SOA

Fui convidado para fazer uma apresentação no primeiro dia. O tema será: “Governança de serviços e qualidade arquitetural em SOA”. Discutiremos sobre controle de qualidade de mecanismos arquiteturais e gestão de serviços. A idéia é ressaltar os cuidados essenciais com qualidade em uma Arquitetura Orientada a Serviço, e traçar um paralelo entre Qualidade x Reúso x Governança SOA, com conceitos, alguns exemplos práticos de cases e ferramentas.

Mais detalhes, alguns links abaixo:

• Programação (lista de palestras e empresas)
• Site da ASR Consultoria
• Blog do Robson

[]s
Marcílio

Related posts:

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

Bom, para pensar em situações aplicadas, vamos falar rapidamente sobre integração. A necessidade de usar SOA para facilitar a integração de sistemas tem se destacado e usa bastante estes conceitos (based e enabled), facilitando a vida de fornecedores e evoluindo a forma das aplicações conversarem.

Sempre que visitamos uma empresa que trabalha com linha de produtos, vejo que um dos nortes das preocupações é evoluir a maturidade de integração com outros produtos e pacotes! A necessidade de integração existe não é de hoje, a diferença é que não estamos mais querendo disponibilizar “aquela view no oracle” para que um sistema converse com o outro. Alguns clientes apresentam, inclusive, restrições técnicas para estas conversas através de Banco de Dados.

Fornecedores vêm se movendo, criando camadas e mais camadas nos seus produtos, para que a integração seja através de serviços. Não é viável reimplementar o produto, não agora! Então, o que eu estou fazendo? Gambiarra ou SOA? Para que especialistas possam responder esta questão sem se comprometer , surgiu até o conceito de SOA Enabled e SOA Based!

• SOA Enabled: O núcleo da aplicação é o mesmo, mas inserimos uma ou duas camadas de abstração, para publicar algumas funcionalidades como serviços. Muitas vezes, os problemas arquiteturais persistem! Mas, agora a integração é mais bonita e posso falar que disponibilizo serviços. Ok, tudo bem que os serviços surgem por demanda (feio né?!), mas tenho visto esta abordagem ser positivamente aplicada em diferentes empresas. É importante usar um processo de reengenharia e identificação de serviços legados, sendo possivel descobrir e criar serviços totalmente alinhados às necessidades de negócio, mesmo tendo que abrir mão de algumas características técnicas que vão continuar rodando por baixo dos panos.
• SOA Based: A aplicação é feita tendo a Arquitetura “Orientada a Serviços” (bingo!). Ou seja, os serviços não vão surgir depois, eles são identificados no início do projeto, através de um processo de identificação de serviços que orienta o design arquitetural. Show de bola! Mas, é necessário que seja uma nova aplicação ou um refactoring arquitetural (talvez até traumático) para conseguirmos aplicar SOA Based efetivamente. Uma grande vantagem é que, descobrindo os serviços logo no início do projeto, potencializamos o poder de reúso sem precisar criar serviços genéricos e a arquitetura é voltada para estes serviços identificados.

Três considerações antes da conclusão:

1. Primeiro: Bom mesmo seria se só existisse SOA Based.
2. Segundo: SOA enabled não é, obrigatoriamente, uma má prática! Mas a Arquitetura não foi Orientada a Serviços.
3. Terceiro: O que as duas abordagens têm em comum? Para ambas, é necessário estabelecer um processo de identificação de serviços! Que esteja alinhado às demandas de negócio. E o processo vai rodar para criar uma nova aplicação, ou para descobrir serviços em produtos existentes. A abordagem deve ser top-down! Não estarei apenas “disponibilizando alguns web services”, o que é bastante comum.

Enfim, para SOA based e SOA enabled, o mais importante é que surjam serviços de negócio disponibilizados no produto, que possam ser evoluídos, integrados, reutilizados, rastreados e, inclusive, governandos e monitorados em runtime.

Ou seja, não esqueçamos da governança dos serviços. Para garantir diversas diretrizes SOA, como desacoplamento, seria necessário sujar as mãos. Mas cá entre nós, mesmo sem isso, os benefícios de utilização de serviços de negócio para tornar meu produto SOA Enabled são reais.

[]s
Marcilio

Related posts:

1. O lado técnico da aquisição de um ESB
2. O Modelo Canônico em uma abordagem SOA
3. Aplicação de Metodologia Ágil em Consultorias SOA

Ser referência em um esporte é ser perseguido por todos que querem no mínimo superá-lo. É a tal da referência. Um padrão a ser seguido que “pode” levá-lo ao sucesso. Óbvio que o talento faz toda a diferença e eu acredito muito nas pessoas.

Mas falando em referência, você possui referências para o seu projeto SOA? Ou sendo mais específico, você tem uma arquitetura de referência na sua empresa para estes projetos?

Aplicações SOA possuem um grau maior de complexidade em relação as aplicações tradicionais, visto que alguns níveis de abstração são adicionados. Uma maneira comprovadamente eficaz de vencer este desafio é elaborar e manter uma Arquitetura de Referência forte e versátil.

Meu amigo Airton Lastori no seu trabalho de pós-graduação diz que: “Uma Arquitetura de Referência consiste no conjunto de informações acessíveis a toda equipe de desenvolvimento e que provêem um conjunto consistente de boas práticas. Seu corpo pode conter informações vindas de diversas fontes: artefatos de projetos anteriores, princípios, metodologias, modelos conceituais, tecnologias, padrões de mercado, além dos próprios padrões corporativos. Portanto, a sua missão é prover um repositório de boas práticas arquiteturais que podem ser reusadas horizontalmente pela empresa, ao longo de todo ciclo de vida dos seus projetos de software, minimizando riscos e retrabalho.”

Eu concordo, e resumiria a arquitetura de referência como sendo:

• Apenas um conjunto de decisões técnicas!
• Decisões que afetam a qualidade do sistema inteiro: camadas, componentes e tecnologias, padrões, guias, nomeclaturas e patterns.

 

Mas também, uma Arquitetura de Referência:

• Aumenta a produtividade das equipes de projeto.
• Poupa tempo, pois fornece um ponto de partida.
• Norteia as preocupações do arquiteto.
• Provê um marco zero a partir do qual pode-se fazer medidas.
• Conhecendo uma arquitetura, é fácil familiarizar-se com outro projeto na mesma arquitetura.
• Quanto mais pessoas conhecem uma tecnologia, mais fácil é obter ajuda.

 

A figura abaixo é a representação dos itens que compõem uma arquitetura de referência, seja como produto gerado ou como inspiração para a sua elaboração.

arq_ref1

Arquitetura de Referência

Cada corporação deve ter a sua arquitetura de referência. Não acredito em Arquiteturas de Referência vendidas como um pacote. Será que existe uma Isinbayeva sendo vendida como pacote para ser campeã olímpica? É claro que podem haver exceções, mas no geral cada corporação já possui os seus padrões, a sua cultura e as suas necessidades no desenvolvimento das suas aplicações. A arquitetura de referência carrega o DNA da corporação.

A idéia central disso tudo é a criação de aplicações SOA com serviços interoperáveis, facilitando as integrações, reutilizações e a manutenção das aplicações, bem como o domínio sobre os problemas conhecidos atrelado com aumento de produtividade (agilidade).

Para finalizar e reforçar, eu considero fundamental a criação de uma arquitetura de referência em qualquer estratégia de implantação SOA. Alguém concorda ou discorda?

olimpiadas_soa3

Arquitetura de Referência SOA Olímpica

- Fábio Rosato

Related posts:

1. O Modelo Canônico em uma abordagem SOA
2. O lado técnico da aquisição de um ESB
3. O papel dos Repositórios SOA