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

A aquisição de um ESB (Enterprise Service Bus) para compor o barramento de serviços de uma empresa é sempre um processo complexo. Se bem estruturado, o processo pode prever uma RFI e/ou PoC, além de outras RF’s.

E se a sua preocupação dentro desse processo está do lado técnico, segue abaixo uma lista de categorias de itens técnicos que são importantes observarmos em um ESB:

• Conectividade
• Linguagens
• Containers
• Mapeamento e Transformação
• Invocação
• Roteamento de Mensagens
• Processo ou Composição de Aplicação
• Formato de dados
• Depuração
• Logging, Trilha de Auditoria e Transaction Tracking
• Armazenamento
• Deployment
• Performance e Escalabilidade
• Segurança e Transação
• Testes, Operação e Monitoramento
• Ferramenta de Desenvolvimento e Gerenciamento
• Suporte e Integração a Outras Tecnologias

[]‘s

Fábio Rosato

Related posts:

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

Vejam o artigo sobre Mapa de Integração que a ComputerWorld divulgou na quarta.

Mapa de Integração: agilidade para tomada de decições em TI

O ambiente de TI das médias e grandes empresas tem se tornado mais complexo. Pacotes adquiridos, normalmente com diversas customizações, sistemas desenvolvidos sob medida nas mais diversas linguagens de programação são o pano de fundo da inflexibilidade de TI. Somem-se a isso todas as integrações ponto-a-ponto desenvolvidas para que os sistemas e processos de negócio sejam minimamente integrados e chegamos ao cenário no qual qualquer mudança pode gerar impactos inesperados.

O artigo completo pode ser lido em: http://computerworld.uol.com.br/blog/opiniao/2010/11/17/mapa-de-integracao-agilidade-para-tomada-de-decisoes-de-ti/

Por Kleber Bacili, diretor de Tecnologia da Sensedia

Abraço,
Kleber

Related posts:

1. Avaliando a maturidade em SOA
2. O lado técnico da aquisição de um ESB
3. O Modelo Canônico em uma abordagem SOA

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

Um vídeo rápido (5′) com uma explicação didática sobre a relação entre Governança SOA e Cloud Computing:

http://www.sensedia.com/br/videos/governanca-soa-cloud-computing-kleber-bacili

OBS1: É necessário fazer um cadastro simples.
OBS2: O vídeo foi criado na Sensedia e narrado por mim

Abraço,
Kleber

Related posts:

1. Avaliando a maturidade em SOA
2. Oportunidade para especialista SOA
3. O papel dos Repositórios SOA

Escrevi um artigo recentemente sobre técnicas para descoberta de serviços em SOA e ontem esse artigo foi publicado no site da IT Web. Vocês podem conferir lá clicando em: http://www.itweb.com.br/noticias/index.asp?cod=71973

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

Pergunta: Se quero expor serviços na “nuvem” (seja para aplicações, seja para processos), existe uma forma de ter serviços que representem as necessidades de negócio, sejam desacoplados, prontos para B2B, com arquitetura madura e etc?
Resp: Ah, tem sim . E nós, escribas e leitores de SOA sabemos disso.

Segue matéria, leitura rápida!

Arquitetura SOA cria plataforma para cloud computing, diz IDC

De acordo com analista da consultoria, nuvem é uma das tecnologias responsáveis pelos investimentos na arquitetura orientada a serviços, que devem crescer até 25% em todo o mundo entre 2008 e 2013.
Por COMPUTERWORLD/REINO UNIDO

Os investimentos realizados na Arquitetura Orientada a Serviços (SOA, da sigla em inglês), vão crescer até 25% em todo o mundo entre 2008 e  2013, de acordo com a consultoria IDC. O vice-presidente de aplicações empresariais da IDC da Europa Central, Ruediger Spies, afirmou que o crescimento será liderado pelos países das Américas, seguido pela região chamada EMEA, que compreende Europa, Médio-Oriente e África.

A declaração contraria rumores de mercado que diz que os investimentos em SOA teriam chegado ao seu final. Segundo Spies, a crença não poderia estar mais errada. E uma das razões é que a arquitetura é uma das melhores maneiras de proporcionar uma plataforma para implantar computação em nuvem.

Segundo Spies, é verdade o fato de que SOA ajuda no alinhamento entre a tecnologia e as necessidades de negócios. No entanto, a única forma de ter sucesso é pensar no longo prazo. “Arquitetura não é uma coisa simples, é um projeto que deve estar na pauta por alguns anos. O ciclo de vida chega a ser maior que os projetos de ERP, que chegam a durar entre 12 e 13 anos”, diz.

A escolha do arquiteto SOA é um dos pontos cruciais no sucesso da empreitada. O profissional precisa ser experiente, bem aceito tanto pelas áreas de negócios quanto de tecnologia, além de ser capaz de enxergar o valor da arquitetura para os negócios, além de fazer com que a área de negócios entenda as contribuições que SOA pode proporcionar em todas as pontas.

Se bem implantado, a SOA ainda cria uma base para estratégias de gerenciamentos de processos de negócios (BPM, da sigla em inglês), que por sua vez influencia na implantação adequada de cloud computing. “Se a empresa estiver em dia com SOA, terá um caminho desenhado para a arquitetura de processo e a arquitetura de informação, elementos responsáveis pelo alicerce das tecnologias e pela integração das mesmas”.

fonte: computerworld

Related posts:

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

Li um artigo da ZapThink recentemente que contrasta os fornecedores de infraestrutura para SOA (ferramentas e middleware) num interessante embate entre empresas gigantes e as menores, focadas em SOA.

O artigo completo segue abaixo, mas me permito resumí-lo da seguinte forma:

• O mercado SOA sofreu forte consolidação em seus fornecedores e hoje apresenta 5 big-players e alguns fornecedores menores (de nicho, startups e open-source)
• Comentam sobre restrições que as empresas possuem quanto ao investimento em soluções de empresas menores e afirmam que o investimento nas big-players é tão arriscado quanto ou até mais;
• Por fim, colocam também que o caráter mais inovador das ofertas aliada a uma política de preço mais agressiva e facilidades para influenciar a direção dos produtos são destaques positivos em se investir em empresas menores

A conclusão do artigo é bem interessante:

(…) ZapThink is very concerned that the rapid consolidation and maturation of the enterprise IT landscape will have a negative outcome on innovation in the marketplace. We believe that the consolidation is resulting in mammoth conglomerates of vendors that will be harder, more confusing, and more expensive to work with. We believe that there is just as much uncertainty around the future of the large vendor’s offerings as there are with startup offerings. In this light, we don’t believe that there’s anything more inherently risky about a startup solution than an established, incumbent vendor solution.

Grande abraço,
Kleber

Segue o artigo completo:

Including Startups in your SOA Infrastructure: A Guide for Enterprise Architects

Document ID: | Document Type: ZapFlash
By: Ronald Schmelzer | Posted: March 25, 2010

In a previous ZapFlash, ZapThink opined that Open Source Software could play an important role in your Service-Oriented Architecture (SOA) Infrastructure. Certainly, there were no architectural reasons why it couldn’t. As we explained in that article, the primary biases against OSS (if there are any) are from the people in the organization who have fear, uncertainty, or doubt about the risks or benefits of OSS. But of course, that article spoke at a fairly general level. Individual implementations or products might be better than others, or more suited for specific problems than others. This is where Enterprise Architects should spend their time focused – on the specific solutions to specific problems, rather than engaging in religious battles about the merits of entire classes of solutions.

Unfortunately, in addition to the biases against OSS, many companies have developed aversions to solutions from startup companies. Yet, in an environment where we are left with just a handful of incumbent companies remaining in the SOA infrastructure landscape, and these vendors have confusing collections of often conflicting and competitive infrastructure products, it might be a good time to revisit utilizing solutions from niche, best-of-breed, and often startup, solutions in your SOA environment. However, how do you do so without incurring substantial real or perceived risk? After all, it is the nature of a startup company to change, be acquired, or die. In this environment, EAs need to become wholeheartedly selfish: meet the requirements of the business in an agile manner by reducing the penalty for failure. In such an environment, startup solutions are not only feasible, but very appropriate.

Best of Breed in an Increasingly Suite World

Through a combination of consolidation, maturation, and the pressures of a tough economic environment, the landscape of enterprise IT software players has dwindled to a handful of companies that control the infrastructure for a vast majority of companies. Just like the auto industry experienced a period of rapid growth and diversity in the early part of the 20^thcentury, only to consolidate down to the “Big three” in the United States and a similar number in countries around the world, we are now faced with the reality of a “Big Five” set of vendors in the enterprise IT marketplace, especially in the area of SOA infrastructure.

However, consolidation is not always a friend of innovation. Many have argued that the consolidation of the auto industry in the US by the late 1970s resulted in products that were unable to compete with offerings from overseas. Indeed, it’s in the period after the consolidation that the US manufacturers saw its most precipitous decline in worldwide share of automobiles. Why is this? Is it because large companies can’t innovate? Or is it that the large portfolio or products and services are confusing not only to customers but even to internal managers? When one company owns Pontiac, Buick, Oldsmobile, Chevrolet, and a myriad of other brands, how can anyone really tell when one product is best suited for a problem or another? These brands compete for dollars not only among customers, but among their own budgets. Much hay has been made of Microsoft’s internal competition and struggles that have hindered its own ability to compete. Why should it be any different for the enterprise IT software companies that have grown primarily through acquisition?

Innovation is incredibly important in an area of continued maturation such as SOA. More importantly, agility is a key benefit of SOA, which means that properly designed architectures should not only be implementation-neutral, they should be fairly immune to infrastructural change. In this light, vendor selection is less a matter of making sure your infrastructure works and more a matter of picking the right vendor for the job while balancing risk and economic factors. In this light, startup and niche companies offer just as much opportunity, if not more, to advance your architectural efforts than those of large vendors. The only things that differentiate the startups from the large vendors are three core issues: the scope of their offerings, the potential risk of company failure, and the ability to negotiate price to your benefit.

Mitigating the Startup Risk: Enterprise Software and Cloud / SaaS Concerns

The biggest risk that many cite in working with startup companies is the risk that they might simply no longer exist. This fear is especially pronounced for companies that must spend a considerable amount of time and money implementing the solutions. If an enterprise is involved in a multi-year effort to implement a large-scale, highly visible, and important solution for the company, then in many cases startup solutions are ruled out very early in the vendor evaluation process. This is even if the startup company offers a better, more appropriate, and more innovative solution. The real issue here is whether the risk of company failure, real or perceived, should outweigh the loss of solution appropriateness and innovation. Or in other words, does it make sense for companies to implement less-optimal solutions based on what they know today because they fear an unknown event in the future?

Rather than rule out startup solutions out of hand, companies should mitigate vendor failure by incorporating such contingencies in their enterprise architecture. We would argue such vendor mitigation plans should be made for well-established vendors as well, since internal political or budgetary battles might result in the disappearance of even decades-old products.

There are two major areas of mitigation for enterprise IT vendor products: products that companies install, manage, and own in their own infrastructure (traditional enterprise software products sold by the license), and those solutions that are run and managed on the vendor’s infrastructure (such as Cloud or Software-as-a-Service [SaaS] offerings). In the case of licensed enterprise software, it has long been a practice of end-user companies to require that the vendor’s software code be held in escrow such that if the vendor goes out of business, it is transferred to the ownership of the end-user customer. While this is a far from optimal solution (after all, the company has no knowledge or ability to do much with the code), it provides some level of comfort to the buyers that the code at the very least won’t disappear.

More complicated is a mitigation plan for Cloud / SaaS offerings. If a SaaS vendor disappears, what happens to the code? If a Cloud vendor goes under, what happens to the infrastructure? More importantly, what happens to your data? It’s not enough to simply require that the vendor hand over the code for their SaaS implementation; in the event of their failure, you have to also implement all the infrastructure that makes the Cloud work or keeps the SaaS solutions running. This is because the economic benefit of Cloud computing and SaaS solutions is that you’re not paying the full cost of owning and managing the solution. It is easy to mitigate the data component of the Cloud / SaaS default risk – simply make sure that you maintain a “local” copy of all relevant data.

However, in order to mitigate the loss of application functionality and infrastructure, a company needs to have a backup plan. Enterprise architects need to discover or implement comparable Services run internally or on another Cloud / SaaS service. Or, companies should require an escrow provision similar to what is provided by licensed enterprise software vendors – if the SaaS / Cloud vendor goes belly up, they have to hand over not only the code and data that makes the application work, but also configured infrastructure on which to run it. While the hope is that these escrow provisions will never have to be enacted, they provide the security blanket necessary to give one at least a psychological sense of security.

Negotiation Leverage: It’s on your Side with Startups

Mitigation and product functionality issues aside, there is another good reason to work with startup vendors: it’s much easier to get your way with smaller companies hungry for your business. Smaller vendors have less layers of corporate infrastructure, and many times you are in direct communication with the individuals responsible for the functionality of your implementation. In this way, it’s easier to get your voice heard on features or bug fixes. Don’t like the way something works or want a new feature? Pick up the phone and talk directly to the product or development managers, or even the CTO. Perhaps you’ll get a fix the same day or within a very short timeframe. Try that with one of the super-vendors.

It’s also easier to negotiate on price. While large vendors might be able to discount or cut the price on one of their offerings so they can make another one sweeter, the realities of large sales forces and commission structures requires them to keep their products at a certain (increasingly higher) price point. Smaller companies are more eager to negotiate, especially if you are a large enterprise that could be a marquee name for them.

Finally, it’s easier to get help with your specific implementation from startup companies. Many enterprise software startup companies know that their products are not plug-and-play and require some additional effort and expense to set them up. As a result, many startups have professional services arms whose goals are not to drive revenue for the company, but rather to support the products in customer installations. Unless the startup vendor charges for this additional service (and we regularly counsel them notto), you should consider this to be free consulting and professional services help. Use as much of this as possible, and even negotiate more into your contract. It is in yours and the startup’s best interests to make sure you get the value you require from your investment.

The ZapThink Take

As you can see from the past few ZapFlashes, ZapThink is very concerned that the rapid consolidation and maturation of the enterprise IT landscape will have a negative outcome on innovation in the marketplace. We believe that the consolidation is resulting in mammoth conglomerates of vendors that will be harder, more confusing, and more expensive to work with. We believe that there is just as much uncertainty around the future of the large vendor’s offerings as there are with startup offerings. In this light, we don’t believe that there’s anything more inherently risky about a startup solution than an established, incumbent vendor solution.

The only thing that has us concerned about the startup landscape is the shortage of new startups. We’ve seen a significant drop-off in new enterprise software venture creation. We are not entirely sure why this is. Is there simply less demand for new enterprise software solutions? Is there less opportunity for new enterprise software startups? Has the venture capital and finance community lost interest with enterprise software? Or has the area of innovation moved away from enterprise software? We hope none of these things are true. The enterprise still has leagues to go to get closer to the vision of loosely-coupled, agile, heterogeneous systems that can meet the ever-changing needs of business with high governance and low risk. There’s plenty of opportunity here. Startups: do your part innovating in this space. Enterprises: do your part and implement startup companies’ offerings so that innovation does not come screeching to a halt.

Related posts:

1. O lado técnico da aquisição de um ESB
2. O Modelo Canônico em uma abordagem SOA
3. Avaliando a maturidade em 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

Dando uma olhada rápida aqui no blog, encontrei diversos posts falando de crise, investimentos e SOA:

• Aprenda a calcular o ROI em SOA
• Governança SOA Light
• Quanto vale SOA
• SOA em tempos de crise

Porém, apesar da discussão, a preocupação ainda não é regra. Conforme o texto abaixo:

40% dos usuários de SOA não medem o tempo necessário para ROI

por Reseller Web
25/05/2009

Gartner aponta que 50% dos entrevistados que não utilizam SOA não adotaram a tecnologia por não conseguirem demonstrar o valor que ela tem

Segundo o Gartner, “as organizações devem ter expectativas realistas e identificar métricas de sucesso que estejam de acordo com a empresa para obter valor a partir da arquitetura orientada aos serviços (SOA)”. Uma pesquisa global, realizada com 200 companhias no quarto trimestre de 2008, descobriu que 40% dos usuários de SOA não medem o tempo necessário para o retorno dos investimentos (ROI).

Já 50% dos pesquisados que não utilizam SOA não adotaram esses sistemas porque não conseguem articular e demonstrar o valor que ele tem para os negócios.

Para ter certeza de que as expectativas sejam realistas e que a empresa tomou medidas precisas com relação às suas metas, o Gartner recomenda que as organizações se concentrem inicialmente em obter somente um benefício chave da lista de vantagens comerciais de SOA. À medida que os esforços com a tecnologia ficarem amadurecidos, e os benefícios começarem a surgir, elas poderão acrescentar mais benefícios e mudar ou acrescentar novas medidas de acordo com a situação.

A escolha dos benefícios depende de qual o valor comercial mais urgente ou mais importante que a estratégia possa oferecer e a rapidez com que possa ser obtido. Entre os benefícios citados pelo Gartner estão: maior eficiência na execução dos processos de negócio; maior rapidez para chegar ao mercado/ciclos de projeto menores; estabelecimento de novos modelos de negócio de crescimento mais rápido; mudança da cultura de TI, de novos desenvolvimentos para reutilização; redução do custo total de desenvolvimento e manutenção das aplicações.

Related posts:

1. O papel dos Repositórios SOA
2. Oportunidade para especialista SOA
3. O Modelo Canônico em uma abordagem SOA