Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : ESB

Leitura Recomendada: REST com WCF e Capacidades do ESB

wcamb — Fri, 19 Jun 2009 00:51:00 GMT

Olá pessoal, tudo certo?

Novo artigo no ar: o Rafael Godinho, especialista em desenvolvimento aqui da Microsoft acabou de publicar um artigo muito interessante sobre serviços REST com WCF, confiram!

Criando serviços REST com WCF
por Rafael Godinho
Junho 2009
Ref.: http://msdn.microsoft.com/pt-br/library/dd941696.aspx

Já havia recebido aqui algumas perguntas sobre o tema, por isso a indicação. Aproveitem também o blog do Godinho, que tem falado bastante sobre WCF, aqui.

Outro artigo do time que merece destaque é sobre ESB – Enterprise Service Bus, do arquiteto de infra-estrutura Markus Christen.

Conhecendo melhor as Capacidades do Enterprise Service Bus
por Markus Christen
Junho 2009
Ref.: http://msdn.microsoft.com/pt-br/library/dd920288.aspx

Confira também o blog do Markus, que tem falado bastante sobre ESB e os vários patterns de infra-estrutura para SOI/SOA, aqui.

Por enquanto é só! Até o próximo post :)

Waldemir.

Microsoft BizTalk ESB Toolkit 2.0

wcamb — Tue, 09 Jun 2009 20:43:00 GMT

Olá pessoal, tudo certo?

Para quem tem acompanhado as discussões sobre serviços, SOA, SOI e ESB que eu e o Markus temos feito, temos uma boa novidade essa semana: acaba de ser anunciado o novo pacote Microsoft BizTalk ESB Toolkit 2.0.

Anteriormente, esse pacote era conhecido como ESB Guidance 2.0, sendo apresentado por aqui no blog em alguns posts, veja aqui!

Entre as novidades do novo pacote temos a aderência aos patterns da Enterprise Library 4.1, assim como a consolidação dos principais patterns de integração, mensageria e roteamento de mensagens, como esperado para o atendimento de um barramento corporativo com composição de serviços.

A figura a seguir ilustra os principais componentes do núcleo do ESB Toolkit 2.0, veja:

Não deixe de acompanhar o blog do Markus Christen, que tem preparado bons posts e guias com exemplos sobre a infra-estrutura ESB 2.0.

Para saber mais sobre ESB e o novo lançamento, veja o link abaixo:

Microsoft BizTalk ESB Toolkit 2.0
Ref.: http://msdn.microsoft.com/en-us/dd876606.aspx

O pacote está disponível no link a seguir:

Download BizTalk ESB Toolkit 2.0
Ref.: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bc86cf1e-ef29-4b19-95f7-388f64555090

Por enquanto é só! Até o próximo post :)

Waldemir.

Enterprise Service Bus (ESB) : barramento de serviços e seus desafios.

wcamb — Wed, 18 Feb 2009 01:31:00 GMT

Olá pessoal, tudo certo?

Recentemente, acompanhei uma discussão de arquitetura onde me foi apresentado um desenho de infra-estrutura simplificado, como esse:

Até aqui, nada de novo, tenho certeza que muitos de vocês já viram cenários como esse. O que chamou minha atenção foi o "barramento" no meio do desenho, o chamado Enterprise Service Bus (ESB). Após notá-lo entre as várias caixas de servidores, perguntei sobre a real necessidade do ESB na arquitetura e quais seriam as funcionalidades do barramento que seriam aproveitadas na solução.

Ouvi como resposta um sonoro : "é óbvio!!! precisamos publicar os serviços num barramento de serviços!!" :) Certo! Um barramento de serviços é importante, mas quais funcionalidades você vai utilizar a partir do barramento de serviços? : "ora!!! um barramento de serviços é um barramento de serviços!!!" :(

Enfim, acabei descobrindo que o chamado barramento de serviços poderia até ser trocado por uma barra de Ethernet no desenho acima, pois de fato, a solução não mapeava qualquer funcionalidade envolvida numa camada ESB tradicional, nada além da ideia do varal universal de serviços....

Esse é um erro comum em muitos cenários hoje em dia. Diversas empresas já colocaram um barramento de serviços sem um detalhamento prévio ou conhecimento dos reais desafios que um barramento pretende endereçar.

Por exemplo, veja um artigo de Dezembro de 2007, que inicia o assunto de um modo bem interessante, posicionando a dificuldade em termos de integração e hub de aplicações, algo como :

Services Fabric: Fine Fabrics for New-Era Systems
Ref.: http://msdn.microsoft.com/en-us/architecture/cc168621.aspx

Muito bem, já deu para perceber que existe muito mais que apenas um "barramento" nesse assunto. Como o autor bem coloca, precisamos responder quais issues iremos atender com nosso ESB em nossa solução.

A Microsoft disponibiliza um pacote de Enteprise Service Bus chamado ESB Guidance. É interessante ver que a Microsoft define um ESB como um "conjunto de patterns de mensageria, EAI, integração e barramento de serviços", relacionando assim uma série de recursos. Entre os recursos mais importantes temos:

Monitoração de Atividades de Negócio
Motor de Regras de Negócio
Integração de Aplicações
Serviços de Transformação
Serviços de Resolução (UDDI)
Serviços de Itinerário
Serviços de Exceções
Repositório e Registro de Serviços
Portal de Gerenciamento

O desenho a seguir apresenta o mapa de funcionalidades do ESB Guidance 2.0 da Microsoft, disponível de forma gratuíta através do CodePlex, veja:

Enterprise Service Bus Guidance
Ref.: http://www.codeplex.com/esb/

Vale destacar que o ESB Guidance aproveita a infra-estrutura de mensageria e integração de aplicações (EAI) disponibilizada pelo produto BizTalk Server. Assim, o pacote estende as funcionalidades do produto para a criação de uma infra-estrutura de barramento de serviços, como vemos acima. Enquanto o ESB Guidance 1.0 trabalha com o BizTalk Server 2006 R2 (atual), o ESB Guidance 2.0 trabalhará sobre o BizTalk Server 2009, previsto ainda para esse semestre.

Para finalizar, o ESB Guidance 2.0 CTP2 - Janeiro 2009 foi recentemente disponibilizado no CodePlex para download. Confira:

ESB Guidance 2.0 CTP2 - January 2009
Ref.: http://www.codeplex.com/esb/Release/ProjectReleases.aspx?ReleaseId=21605

Sem dúvida, ESB é um componente crítico para soluções de serviços e integração de aplicações de forma padronizada no ambiente corporativo. Não deixem de acompanhar esse assunto em suas discussões.

Por enquanto é só! Até o próximo post :)

Waldemir.

Arquitetura de serviços e capacidades de SOA na plataforma Microsoft.

wcamb — Fri, 13 Feb 2009 18:54:00 GMT

Olá pessoal, tudo certo?

Esses dias estive em algumas discussões sobre os vários serviços de uma arquitetura de referência SOA e como podemos mapear os produtos e recursos da plataforma Microsoft. A importância dessa discussão é enorme: seja qual for o fornecedor de sua plataforma, é importante o mapeamento correto de recursos e funcionalidades disponíveis, que irão atender as necessidades de sua solução, respeitando o SLA esperado pelo negócio.

Como o assunto é orientação a serviços, vamos fazer uma rápida revisão. Uma definição simples sobre SOA pode ser:

"um estilo de arquitetura onde funcionalidades de aplicações de negócio existentes (LoB - Line of Business) são disponibilizadas e publicadas na forma de serviços".

Muito bem! E o que seria serviço? Podemos citar uma rápida definição para ele também:

"são componentes de software que expõem funcionalidades de aplicações numa arquitetura SOA, respeitando algumas características importantes:

serviços são autônomos;
serviços são orientados a mensagens;
serviços podem suportar diferentes protocolos e mecanismos de transporte;
serviços podem ser publicados ou hosteados em diferentes tipos de hosts;
serviços suportam contratos de operação, interfaces e tipos de mensagens;"

Respeitando as características acima, nossa solução caminha para um modelo de arquitetura desacoplada entre cliente e serviço, criando um ambiente propício para o reuso de funcionalidades, assim como a composição de funcionalidades em uma dada aplicação. Esses são elementos essenciais de uma arquitetura de serviços ou SOA.

Veja que não falei nada sobre granularidade de serviços, governança de serviços, versionamento de interface e mensagens, administração e deployment, controle de exceções, roteamento de mensagens, rastreabilidade, monitoração, controle de níveis de serviços, etc. Portanto, a discussão sobre SOA é muito maior e pode ter abordagens diversas, algumas mais técnicas, outras mais de negócio. Estou focando a visão técnica.

A partir dos pontos acima, vejamos um mapa de serviços geral de uma arquitetura SOA:

A figura acima destaca serviços comuns de uma arquitetura SOA, como serviços de apresentação, colaboração, integração entre sistemas, persistência de dados, serviços de orquestração de processos, entre outros. Podemos tratar esses vários serviços como capacidades de SOA. Na verdade, avaliando capacidades de serviços, podemos identificar quais são os aspectos que realmente precisamos para o sucesso de nossa solução. Existem cenários onde segurança e monitoração de serviços é crítico, assim como a orquestração de processo. Para outros cenários, a capacidade mais importante é integrar diferentes plataformas e ambientes de linhas de negócio, que estarão envolvidos na arquitetura SOA. Avaliar quais são as principais capacidades que precisamos é fundamental para a condução de um projeto de SOA.

Com base nesse desenho, vejamos quais produtos de uma infra-estrutura Microsoft atendem quais capacidades de serviços:

Vemos então que alguns produtos podem atender capacidades específicas, assim como várias capacidades ao mesmo tempo. É o caso do WF - Windows Workflow Foundation, que pode ser usado tanto para a construção de serviços de interação entre sistemas como para orquestração de processo. Da mesma forma o BizTalk Server oferece capacidades de integração, assim como de processos e orquestração de serviços.

A conclusão é que não teremos um único produto ou infra-estrutura de software que irá implementar toda a visão de SOA.

Uma orientação a serviços é formada por diferentes capacidades. Identificar quais capacidades são importantes para nosso cenário de negócio é tão crítico para o projeto quanto a própria escolha do fornecedor ou infra-estrutura de software que será adotada.

Por enquannto é só! Até o próximo post :)

Waldemir.

Interoperabilidade e Comunicação na plataforma Microsoft : o que e quando usar?

wcamb — Wed, 11 Feb 2009 20:59:00 GMT

Olá pessoal, tudo certo?

No post anterior vimos que a interoperabilidade na plataforma Microsoft pode ser organizada em 3 níveis básicos de complexidade:

Interop in the Framework
Interop in the Box
Interop in the Cloud

Os recursos assim agrupados permitem um melhor entendimento das necessidades de cada solução, seja através da customização com WCF, WF, seja via um motor de mensageria e transformação com o BizTalk Server ou um barramento de mensanges com o ESB Guidance, ou até mesmo um modelo de integração entre empresas através da nuvem, no chamado ISB - Internet Service Bus, como .NET Services do Azure.

Falamos também de 4 componentes importantes para a interoperabilidade no ambiente enterprise (local). Vejamos:

O que usar?

Microsoft® BizTalk® Server (BTS) : BizTalk oferece uma pilha ampla de adaptadores, orquestração, mensageria e protocolos para a construção de soluções preparadas para EAI - Enterprise Application Integration. Através de ferramentas de mapeamento de mensagens, manipulação de schemas, transformação, monitoração e regras de negócio, o ambiente BTS permite a construção de soluções de mensageria em cenários de elevado volume de mensagens e vazão;
Microsoft Host Integration Server (HIS) : HIS oferece uma plataforma para a conectar aplicações com sistemas da plataforma IBM zSeries e iSeries. Ainda, HIS suporta a conexão de dados entre Microsoft Message Queuing (MSMQ) e o IBM WebSphere MQ;
Microsoft Message Queuing (MSMQ) : o MSMQ permite a conexão de entre aplicações usando um modelo de fila de mensagens. MSMQ oferece a garantia de entrega de mensagens, mensagens baseadas em prioridades e segurança. Ele suporta a integração com sistemas parcialmente conectados ou temporariamente offline. MSQM também suporta cenários de mensageria síncrona e assíncrona;
Microsoft Enterprise Service Bus (ESB) Guidance : o ESB Guidance é uma unidade lógica que oferece uma arquitetura desacoplada baseada em mensagens, usando para isso a infra-estrutura do BizTalk Server. O ESB Guidance é na verdade um conjunto de templates e patterns que extendem as funcionalidades do BTS, adicionando características como roteamento de mensagens, repositório de serviços, garantia de entrega, segurança de mensagens, registro de serviços e tratamento unificado de exceções;

Cada uma das tecnologias acima aplica patterns de arquitetura importantes para diversos cenários de integração em TI. Porém, cada cenário exige uma tecnologia mais adequada que a outra. Adotar um modelo síncrono de mensageria quando nossa solução permite cenários parcialmente conectado pode ser desastraso, por exemplo. Então, surge a pergunta:

Quando usar?

Considere o uso de BizTalk Server quando:

quando a solução interage com múltiplos web services via uma orquestração, como parte de uma arquitetura orientada a serviços (SOA), suportando as latências de I/O devido a transformação de mensagens, persistência de mensagens para tracing ou latência devido subscrição/distribuição de mensagens;
quando a solução deseja suportar processos business-to-business (B2B), incluindo padrões de indústria como EDIFACT, ANSCI X12, HL7, HIPAA, or SWIFT.
quando a solução exige a execução de serviços em paralelo, com mecanismos facilitadores para esse tipo de orquestração e sincronização entre processos;
quando a solução exige alta confiabilidade e infra-estrutura dedicada para escalabilidade, com garantia de entrega e recuperação de mensagens;
quando a solução necessita medir KPI's - Key Performance Indicators de negócio, através de um motor de análise como BAM - Business Analysis Manager, que deve fornecer uma visibilidade em tempo real sobre os dados processados pela solução;
quando a solução deseja abstrair a lógica de negócios e aplicações através de políticas, que podem ser alteradas de acordo com as necessidades de negócio da solução;

Considere o uso de Host Integration Server quando:

quando a solução precisa suportar interação com aplicações IBM zSeries ou iSeries;
quando a solução deve integrar BizTalk com DB2, WebSphere MQ, Aplicações Host (em plataforma alta) ou servidores de arquivos;
quando a solução deve integrar mensageria MSMQ com WebSphere MQ;

Considere o uso de Message Queuing quando:

quando a solução deve suportar interação entre aplicações baseada em mensagens;
quando a solução precisa integrar plataformas Microsoft e Não-Microsoft, suportando a conversação assíncrona;
quando a solução precisa suportar conversação SRMP - SOAP Reliable Messaging Protocol entre as aplicações envolvidas;

Considere o uso de Enterprise Service Bus Guidance quando:

quando a solução necessita suportar a abordagem de mensageria com itinerário de mensagens ou roteamento entre sistemas envolvidos;
quando a solução deve suportar a resolução dinâmica de roteamento de mensagens;
quando a solução deve usar transformação de mensagens dinâmicamente;
quando a solução deve suportar um gerenciamento de exceções de forma unificada e robusta, para a integração de sistemas EAI;
quando a solução necessita de uma abordagem de repositóio de serviços, para publicação de funcionalidades envolvidas;

O mapa acima é uma relação parcial de benefícios ou aspectos de arquitetura que justificam cada tecnologia para uma dada solução. Claro, para alguns cenários, podemos abrir mão dos pacotes acima e simplesmente implementar nossos próprios componentes de integração, interoperabilidade ou orquestração usando frameworks como o WCF - Windows Communication Foundation e o WF - Windows Workflow Foundation, sempre considerando o esforço de nosso próprio desenvolvimento.

No final, podemos construir uma matriz de decisão, que pode nos ajudar no momento de análilse de uma solução e as tecnologias mais indicadas. Fica a dica para ampliar esse estudo e detalhamento destacando os aspectos mais importantes para sua própria solução.

Por enquanto é só! Até o próximo post :)

Waldemir.

Microsoft BizTalk Server 2006 R2 e o modelo ESB - Enterprise Service Bus.

wcamb — Sat, 04 Oct 2008 22:31:00 GMT

Olá pessoal, tudo certo?

Essa semana tive uma bela discussão sobre SOA - Service Oriented Architecture - e o posicionamento do Microsoft BizTalk Server 2006 R2 (ou "BTS" para simplificar) nesse tipo de cenário. Se você tem acompanhado nossos papos sobre SOA aqui no blog, sabe que existem diversas questões que precisam ser tratadas para a construção de uma boa arquitetura de serviços. Latência, interfaces, proxies, protocolos, segurança, composição de aplicações, workflows, etc., são algumas das questões conhecidas.

Para entender como o BTS está relacionado ao assunto, vejamos um desenho básico sobre seu funcionamento:

A figura acima representa o fluxo de mensagens do BTS, onde pipes de entrada recebem mensagens do meio externo, permitindo operações como validação, transformação de campos, descriptografia, etc. As mensagens recebidas são então persistidas numa base de dados chamada MessageBox. Esse passo é importante para todo o processo de auditoria e rastreamento de mensagens dentro do ambiente BTS. Outro fator importante da persistência de mensagens é a possibilidade de recuperação de mensagens históricas, subscrição e publicação para destinatários diversos, além do disparo de orquestrações associadas. Mensagens podem ser interceptadas, disparando processos ou orquestrações de processo (workflows), que operam diversas atividades dentro do ambiente BTS, até a geração final das mensagens de saída para o meio externo.

De modo simplificado, uma das grandes funcionalidades do BTS é seu poder de mensageria, permitindo o tratamento de mensagens entre fonte/destino, com recursos de manipulação de dados, transformação, validação, assinatura, subscrição e roteamento.

Porém, esse mesmo núcleo de mensageria pode ser usado como um HUB de serviços. Nesse contexto, é possível construir cenários onde serviços implementados no ambiente do BTS são publicados através de interfaces WCF - Windows Communication Foundation. Mensagens endereçadas para esses serviços podem ser tratadas, permitindo atividades como inspeção de propriedades, análises de negócio (com a consolidação de grupos de mensagens relacionadas), aplicação de regras de decisão sobre as mensagens recebidas, etc., através das próprias ferramentas do ambiente BTS. No modo mais simples de publicação de serviços, o ambiente BTS funcionará como um ponto central de disponibilidade de serviços com rastreamento de mensagens.

Nesse ponto, surge a discussão sobre ESB - Enterprise Service Bus, ou barramento de serviços. Mas o que é um barramento de serviços?

O termo ESB tem sido usado largamente em diversas discussões sobre SOA. Podemos interpretar o tema de acordo com o foco da discussão, passando de um simples repositório de serviços até o núcleo de orquestração ou motor de BPM - Business Process Management. Mais recentemente, ESB tem sido colocado apenas como um dos muitos componentes presentes numa infra-estrutura de suporte a SOA, ou SOI - Service Oriented Infrastructure.

Na minha opinião, uma boa definição de ESB é "um conjunto de patterns de arquitetura baseados em modelos tradicionais de EAI - Enterprise Application Integration, middlewares orientados a mensagens, Web Services e interfaces de serviços, integração com sistemas da plataforma alta ou aplicações de negócio (LOB - Line of Business), interoperabilidade com serviços registrados e repositório de serviços. Todos esses elementos podem ou não aparecer na arquitetura envolvendo ESB, dependendo das necessidades da solução."

Considerando nossa introdução sobre BizTalk Server e o modelo ESB, agora podemos falar sobre o Microsoft ESB Guidance for BizTalk Server 2006 R2.

O desenho abaixo apresenta os principais componentes do ESB Guidance com BizTalk.

Note que para cada funcionalidade prevista no modelo ESB, temos um recurso BTS associado. Assim, é possível identificar os motores de orquestração, de transformação de mensagens, de regras de negócio e persistência associados às funcionalidades do ESB. Ao mesmo tempo, a interoperabilidade entre sistemas heterogêneos torna-se possível com o BTS+ESB, através de seus adaptadores de conexão como WCF, JMS, Pipes, etc. Existem mais de 300 adaptadores disponíveis hoje no mercado para o ambiente BTS, o que amplia seu poder de interoperabilidade.

Atualmente, diversas empresa do mercado brasileiro têm discutido sobre infra-estrutura SOA e plataformas ESB. Um dos principais motivadores dessa discussão é a evolução da atual plataforma de negócios da empresa para um modelo mais ágil, que permita composição de aplicações e serviços, enquanto garante uma melhor administração e governança sobre os componentes da arquitetura. É sempre bom lembrar que uma outra ferramenta importante para essa evolução são os modelos de maturidade ou otimização de infra-estrutura. Reconhecer o grau de maturidade de nossas capacidades de infra-estrutura é fator crítico para a estratégia de evolução a longo prazo.

Esse post foi apenas uma introdução sobre o assunto. Para saber mais sobre os recursos do ESB Guidance sobre o BizTalk Server, visite os links abaixo:

Microsoft ESB Guidance for BizTalk Server 2006 R2
Ref.: http://msdn.microsoft.com/en-us/library/cc487894.aspx

Microsoft ESB Guidance
Ref.: http://www.codeplex.com/esb

Por enquanto é só! Até o próximo post :)

Waldemir.

Encontro de Arquitetos em São Paulo - Edição Novembro de 2007.

wcamb — Thu, 29 Nov 2007 23:40:00 GMT

Olá pessoal, tudo certo?

Tivemos hoje mais um Encontro de Arquitetos aqui na Microsoft, em São Paulo.

O evento teve 2 sessões de discussões: uma apresentando a visão da Microsoft sobre Orientação a Serviços (comigo) e uma sessão sobre Integração de Plataformas, com o Fernando Gebara. O Gebara aproveitou o tema para posicionar o produto BizTalk Server 2006 R2, assim como o WCF - Windows Communication Foundation do .NET Framework 3.0, em cenários de integração de sistemas e plataformas heterogêneas, assunto muito atual.

Está no meu plano de posts futuros tratar especificamente do tema Modelo de Maturidade de uma Arquitetura Orientada a Serviços. Muita gente tem perguntado sobre como classificar uma infra-estrutura de TI, assim como reconhecer os pontos de atenção e quais aspectos devem ser trabalhados para seguir de um nível para o próximo na escala de maturidade, o que envolve questões como segurança, versionamento, monitoração, publicação, auditoria, autorização, etc.

Porém, uma discussão que foi iniciada pelo arquiteto Otávio Coelho durante o encontro é referente aos desafios do dia-a-dia para a implementação de serviços. Fala-se muito sobre visão de maturidade, arquiteturas de referência e evolução de capacidades, mas alguns sobre cenários de implementação e codificação sofrem de alguma carência.

Assim, questões como tratamento de erros, identificação de falhas numa camada de serviços, quando utilizar um mecanismo síncrono ou assíncrono, comportamento e interfaces de serviço, performance, latência, entre outras, ainda necessitam esclarecimentos ou mesmo mapas de decisão.

Por isso, acho que ganhamos mais alguns temas para discutir aqui no blog. E vamos ter muito material para discutir. Fiquem ligados!

Por enquanto é só. Até o próximo post! :)

Waldemir.

The Architecture Journal #13 - Leitura obrigatória.

wcamb — Thu, 22 Nov 2007 21:03:00 GMT

Olá pessoal, tudo certo?

Já está circulando na Web e na mesa de alguns arquitetos a edição de número 13 do "The Architecture Journal".

Para quem ainda não conhece, é o jornal sobre arquitetura de sistemas e soluções publicado pela Microsoft, com muitos temas importantes, discussões quentes e artigos obrigatórios. Alguns arquitetos de peso da Microsoft são responsáveis pelos artigos, por isso era importante comentar a revista aqui no Blog.

No site do jornal você tem acesso a todas as edições anteriores de forma online (em inglês).

Confira em http://www.ArchitectureJournal.net.

E na edição #13, temas importantes como a estratégia Software + Services da Microsoft, uma visão sobre Internet Service Bus, o Projeto Astoria e outros temas que já foram comentados em posts anteriores. Mais uma dica imperdível para o arquiteto conectado!

Por enquanto é só. Até o próximo post! :)

Waldemir.

Microsoft ESB Guidance for BizTalk Server 2006 R2 - Versão final publicada!!!

wcamb — Fri, 09 Nov 2007 23:33:00 GMT

Olá pessoal, tudo certo?

Conforme anunciado semana passada no SOA & BP Conference, a Microsoft acaba de publicar o ESB Guidance for BizTalk Server 2006 R2 em sua última versão.

Veja o artigo do anúncio aqui: http://msdn2.microsoft.com/en-us/library/bb931189.aspx

O Microsot ESB Guidance fornece guias de arquitetura, patterns, melhores práticas, frameworks, componentes de reuso e exemplos para o BizTalk Server R2, simplificando o desenvolvimento de uma infra-estrutura de Enterprise Service Bus (ESB). Desse modo, fica fácil extender os mecanismos de mensageria e integração de soluções sobre a plataforma Microsoft.

Entre as principais capacidades presentes temos:
- Mediação e auditoria orientada a políticas;
- Suporte para conexão de sistemas múltiplos;
- Monitoração e gerenciamento de serviços;
- Recursos para governança de SOA;

Para a conclusão desta versão, foram envolvidos internamente times do Patterns and Practices e o BizTalk Server, muita gente mesmo.

Fiz alguns testes com o ambiente com sucesso. O anúncio comenta que não existem planos para uma segunda versão do pacote, mas que tudo depende do feedback da comunidade. Vale lembrar que os comentários para o time devem ser direcionados através do site http://www.codeplex.com/esb.

O importante é que esta versão já fornece um ambiente bem interessante para a implementação de aspectos críticos de uma infra-estrutura ESB e SOA.

Recomendo o estudo deste pacote. Por enquanto é só. Até o próximo post! :)

Waldemir.

Internet Service Bus no ARCast.TV.

wcamb — Tue, 06 Nov 2007 04:19:00 GMT

Olá pessoal, tudo certo?

Falando sobre ISB ou Internet Service Bus, semana passada foi publicado o segundo vídeo da série ARCast.TV comm Ron Jacobs. Para quem ainda não conhece a série, ARCast.TV apresenta discussões interessantes sobre vários temas da arquitetura de sistemas, em formatos MP3 e WMA, a partir do site CHANNEL9.MSDN.COM.

Semana passada, Ron Jacobs falou sobre as aplicações do futuro e como o Internet Service Bus terá impacto sobre nossas decisões de arquitetura.

Assim, recomendo os links:

ARCAST.TV - Parte 1 de 2 - App Of The Future - The Internet Service Bus.
http://channel9.msdn.com/ShowPost.aspx?PostID=350983

ARCAST.TV - Parte 2 de 2 - App Of The Future - The Internet Service Bus.
http://channel9.msdn.com/ShowPost.aspx?PostID=352005

Por enquanto é só. Até o próximo post! :)

Waldemir.

SOA & Business Process Conference - Um resumo.

wcamb — Sat, 03 Nov 2007 20:43:00 GMT

Olá pessoal, tudo certo?

O SOA & BP Conference terminou nesta sexta-feira de tarde, com uma grande palestra sobre soluções com o Microsoft ESB Guidance, dada por Marty Wasznicky.
Antes dele, John Callaway apresentou uma série de dicas e anti-patterns para uma visão SOA.

Ao todo, foram mais de 70 sessões sobre vários temas como:

Plataforma SOA
Service Lifecicle Management
SOA capabilities
Composite Applications
Composite Activities
WorkFlow Foundation
BizTalk Services 1
Internet Service Bus
Enterprise Service Bus
Office Business Application
BizTalk RFID Platform
SOAMM - Maturity Model
E roadmap "OSLO", com a visão da Microsoft sobre arquitetura orientada a serviços e seus produtos.

Termina assim uma grande conferência que envolveu diversas indústrias e empresas de TI numa discussão ampla sobre os problemas e soluções para uma estratégia de implantação de uma arquitetura SOA, que tem como um de seus maiores motivadores o chamado BUSINESS AGILE, ou negócio ágil. Mesmo esse tema será motivo de novos posts neste blog.

A partir de agora, nossa missão será "digerir" e aprofundar cada tema discutido, afim de tornar realidade toda essa visão.

Aproveito aqui para agradecer o time da Microsoft que muito enriqueceu esse evento, como José Ribon, Fernando Egas, José Zorzi, Fábio Miranda, Georgette van Swaay, entre outros. Show de bola pessoal! Obrigado pelas discussões entre uma palestra e outra, além do extremo cuidado e atenção com as empresas participantes.

Vamos ficando por aqui. Até o próximo post! :)

Waldemir.

Exporando o ESB Guidance da Microsoft.

wcamb — Sat, 03 Nov 2007 03:08:00 GMT

Olá pessoal, tudo certo?

Essa semana, aproveitei o blog para falar sobre as novidades apresentadas pela Microsoft durante o SOA & Business Process Conference, em Redmond.

Nesta quinta-feira, Marty Wasznicky, Principal Program Manager da Divisão de Sistema Conectados da Microsoft, explorou a arquitetura do ESB Guidance da Microsoft. Marty apresentou exemplos de monitoração e auditoria, a partir do pacote disponível no link http://www.codeplex.com/esb/.

Outro exemplo interessante que foi discutido durante a sessão foi a solução da AmberPoint. Essa empresa implementou uma arquitetura ESB sobre plataforma Microsoft, com recursos adicionais de monitoração, auditoria, trace de mensagens e análise de negócios, recuperação, entre outros recursos relacionados com a governança de serviços. Recomendo visitar o link http://www.amberpoint.com/ para explorar os exemplos. Através do site, é possível criar uma conta e utilizar o pacote Trial AmberPoint Express.

O pacote ESB Guidance está na versão CTP - Community Technology Preview e por isso ainda temos muitos passos manuais e muita configuração que precisa ser feita com cuidado. Mas passando por todo procedimento, é possível monitorar mensagens e navegar auditoria e regras sobre o BizTalk Server 6 R2.

Assim, para quem ainda não viu, fica a recomendação para explorar o pacote do CodePlex e os exemplos da AmberPoint.

Por enquanto é só. Até o próximo post! :)

Waldemir.

Internet Service Bus : um pouco mais sobre o tema...

wcamb — Thu, 01 Nov 2007 17:45:00 GMT

Olá pessoal, tudo certo?

No post anterior, falamos rapidamente sobre o ISB - Internet Service Bus, que a Microsoft recentemente anunciou para o mercado.
Algumas pessoas pediram mais detalhes sobre o assunto. Lá vai:

O ISB está disponível no status de CTP - Community Technology Preview, o que significa que a Microsoft aguarda o feedback e comentários da comunidade.
Atualmente, estão disponíveis 3 building-blocks de serviços:
- Identity
- Connectivity
- Worklow

Para maiores detalhes, confira a página do ISB no BizTalk labs: http://labs.biztalk.net/OverviewDetails.aspx

Por enquanto é só. Até o próximo post! :)

Waldemir.

BizTalk Services "1.0" : Implementando o Internet Service Bus.

wcamb — Thu, 01 Nov 2007 07:44:00 GMT

Olá pessoal, tudo certo?

Já falamos aqui um pouco sobre os conceitos de Enterprise Service Bus ou ESB. Para relembrar, nossos serviços podem ser organizados e disponibilizados através de um barramento de conectividade, através do qual podemos acessar recursos de mensageria, roteamento, monitoração, etc.

Mas podemos pensar o ESB no contexto da organização. Quando pensamos no contexto de internet, precisamos envolver recursos de federação, segurança, discovery, etc, e um nome apropriado que surge é o ISB - Internet Service Bus.

Esta semana, a Microsoft apresentou sua visão para o conceito de ISB, através do Roadmap "Oslo". E a realização do ISB é o BizTalk Services.

BizTalk Services não tem relação direta com o BizTalk Server, não é uma versão ou implementação do produto de orquestração da Microsoft. Na verdade, é mesmo um pacote que é atualmente disponibilizado através de um SDK, para a implementação de serviços públicos de forma transparente e flexível. Enfim, permite a codificação de serviços publicáveis na Web através de WCF 3.0 e com grande facilidade.

Podemos baixar a versão 1.0 do BizTalk Services a partir do link: http://labs.biztalk.net/

Entre no site, crie uma conta, faça o download do SDK e veja os exemplos disponíveis.

Por enquanto é só. Até o próximo post! :)

Waldemir.

SOA Service Lifecycle Management e seus desafios.

wcamb — Wed, 31 Oct 2007 22:38:00 GMT

Olá pessoal, tudo certo?

Um dos grandes desafios de SOA é o gerenciamento do ciclo de vida de serviços (Service Lifecycle Management ). William Oellerman, diretor de tecnologia para o time de soluções SOA da Microsoft, acabou de apresentar alguns aspectos sobre esse tema.

Segundo William, os principais passos previstos no Service Lifecycle são:

Identificação do serviço
Desenvolvimento do serviço
Provisionamento do serviço
Consumo do serviço
Gerenciamento do serviço

Através desta visão, procuramos garantir maior aderência dos serviços às necessidades do negócio.

Porém, note que cada passo deve envolver papéis e responsabilidades diversos, como arquitetos de solução, arquitetos de infra-estrutura, desenvolvedores de serviços, arquitetos de enterprise, responsáveis pelo negócio, etc. Ainda, podemos relacionar uma série de desafios presentes na organização, que exigem cuidados na implementação deste ciclo, como:
- A remoção de barreiras técnicas pode expor barreiras políticas;
- Muitas decisões de negócio não são orientadas para o reuso ou o design consistentes;
- Sistemas complexos poodem obscurecer as responsabilidades de TI;
- Pessoas e processos são parte do contexo, assim como a cultura organizacional, etc.

A partir disso tudo, minha proposição: a área de NEGÓCIOS precisa focar o "O QUE", enquanto que a área de TI deve focar o "COMO". Esse alinhamento passa obrigatoriamente pelo envolvimento de times das duas áreas, de arquitetos e especialistas de negócio.

E finalmente, duas ferramentas devem ser consideradas nessa visão: um modelo de análise e reconhecimento de serviços e um modelo de maturidade para a implementação de serviços. Na Microsoft, esse modelo de análise é dado pelo MSBA - Microsoft Services Business Architecture, que é bem uma metodologia para a análise de requisitos e mapeamento de negócios para uma arquitura SOA. Da mesma forma, a Microsoft anunciou o SOAMM - Modelo de Maturidade SOA, que visa posicionar as necessidades da empresa numa estratégia de evolução de sua arquitetura de serviços. Esse modelo de maturidade conta com 36 capacidades de negócio, que são mapeados para um roadmap de implementação sobre serviços.

A Microsoft espera a versão final de seu modelo de maturidade para início de 2008, assim como um pacote de oferta de Assessment de arquitetura com foco em SOA. Esse pacote contará com extensa documentação, casos de uso e exemplos. Até lá, vamos ficar ligados nos novos anúncios.

Por enquanto é só. Até o próximo post! :)

Waldemir.