Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : SOA

SOA Manifesto

wcamb — Sun, 08 Nov 2009 19:11:00 GMT

Olá pessoal, tudo certo?

O final de outubro marcou a publicação do SOA Manifesto, assinado por diversas empresas e representantes do mercado.

SOA Manifesto
Ref.: http://www.soa-manifesto.org/

Você pode até pergunta: mais um Manifesto? Sim, mais um Manifesto! :)

Entre os signatários você encontra nomes como Thomas Erl, Grady Booch, Brian Loesgen e John deVadoss da Microsoft, Aaron Skonnard da Pluralsight entre outros nomes de peso! Também sou signatário por lá :)

Alguns princípios do SOA Manifesto são bem interessantes e estão de acordo com muitos dos posts e discussões que tivemos aqui no blog com a comunidade, veja:

Identificar os serviços através da colaboração com stakeholders de tecnologia e de negócios;
Verificar que os serviços atendam necessidades de negócio e metas da empresa;
SOA pode ser realizada através de uma variedade de tecnologias e padrões;
Reconhecer que SOA de fato demanda mudanças em vários níveis;
entre outros...

Opinião: de fato, temos visto diversas empresas falharem na adoção de projetos de SOA. Em alguns casos, as falhas estão relacionadas à escolhas equivocadas dos projetos-alvo; em outros, faltou um suporte maior de diferentes níveis da corporação, com o envolvimento integrado das áreas de soluções, desenvolvimento e infraestrutura. Um projeto de SOA é amplo e exige um envolvimento corporativo para seu sucesso.

Devido a esses vários problemas, gosto muito da separação entre LITTLE SOA e BIG SOA. Sistemas orientados a serviços, com interfaces bem definidas e uma boa organização de processos, com foco no domínio da aplicação são os chamados LITTLE SOA.

O grande desafio está nos projetos BIG SOA, que envolvem diversos domínios de aplicação e departamentos da corporação, exigindo uma estratégia mais ampla e com um impacto direto no negócio.

Confira também seu anúncio, realizado durante o 2nd International SOA Symposium, em Rotterdan:

SOA Manifesto Announcement
Ref.: http://www.youtube.com/watch?v=TCg16oTZSV0

Sem dúvida, Leitura Obrigatória!!!

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

Waldemir.

Arquitetura de Referência SOA e créditos devidos

wcamb — Tue, 03 Nov 2009 10:38:00 GMT

Olá pessoal, tudo certo?

Esses dias, troquei alguns emails com o arquiteto Marcelo Sávio da IBM. Ele fez alguns comentários bem legais sobre o blog (obrigado Marcelo) e também ajudou para uma errata sobre o diagrama abaixo:

Vi essa Arquitetura de Referência pela primeira vez em 2007, durante um evento sobre SOA nos Estados Unidos. Porém, a primeria aparição do diagrama foi de fato em 2006, no seguinte documento da IBM:

Patterns: SOA Foundation Service Connectivity Scenario (Publicação: Agosto, 2006 - pag. 5)
Ref.: http://www.redbooks.ibm.com/abstracts/sg247228.html

Errata: algumas vezes, coloquei equivocadamente o diagrama acima como apresentado apenas em 2007 pela Micrososft, ops! Faltava posicionar a data de nascimento correta (Agosto, 2006), assim como sua paternidade original (IBM). Confusão desfeita :)

Mais recentemente, passei a utilizar aqui no blog os diagramas abaixo:

Esses foram apresentados originalmente pela Microsoft, com o mapeamento de produtos e capacidades de uma arquitetura SOA sobre a plataforma.

Como sempre, fique a vontade para novos comentários, sugestões e correções por aqui. Numa área tão ágil e rica como a nossa, o importante é não confundir o pessoal, mantendo o conteúdo o mais exato possível!

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

Waldemir.

Architecture in a Box: Recomendações para serviços com WCF

wcamb — Mon, 19 Oct 2009 14:55:00 GMT

Olá pessoal, tudo certo?

A sessão de WCF e SOA gerou uma série de comentários offline, que justificaram mais uma sessão, que publico aqui neste post.

Projetos de SOA, SOI e composição de serviços podem ser tão diversos quanto a própria complexidade existente na TI das empresas. Por isso, gosto da frase “SOA é como flocos de neve: não existem dois iguais” :)

A sessão de hoje coloca alguns pontos mais sobre serviços com WCF e recomendações gerias, confira!

View more documents from Waldemir Cambiucci.

Em breve, novos temas aqui na série Architecture in a Box, fique ligado!

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

Waldemir.

Architecture in a Box: SOA – Service Oriented Architecture

wcamb — Thu, 15 Oct 2009 12:31:00 GMT

Olá pessoal, tudo certo?

Depois das sessões sobre serviços com WCF e workflows com WF, vamos conferir uma visão sobre SOA – Service Oriented Architecture.

A sessão de hoje faz um panorama sobre alguns dos aspectos de desenvolvimento e soluções orientadas a serviços, destacando a anatomia de um serviço WCF, assim como uma arquitetura de referência para SOA.

Aspectos de SOI – Service Oriented Infrastructure ficaram de fora da apresentação, mas creio que o Markus em breve deve tratar desse tema.

View more documents from Waldemir Cambiucci.

Para saber mais sobre SOA, veja ainda os posts já publicados aqui no blog.

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.

Artigo: Uma introdução ao Software + Serviços, SaaS e SOA

wcamb — Tue, 02 Jun 2009 22:38:00 GMT

Olá pessoal, tudo certo?

Boas Novas: já está no ar meu novo artigo sobre SOA, SAAS e Software + Services no MSDN Brasil. Ele acabou de ser publicado e está disponível na URL abaixo:

Uma introdução ao Software + Serviços, SaaS e SOA
por Waldemir Cambiucci
Maio de 2009
Ref.: http://msdn.microsoft.com/pt-br/library/dd875466.aspx

Entre outros assuntos, o artigo trata os principais aspectos envolvidos na visão Software + Serviços, usando como base os pilares abaixo:

Não deixe de conferir e fazer seus comentários!

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

Waldemir.

Capacidades de serviços e produtos da plataforma Microsoft

wcamb — Tue, 19 May 2009 22:00:00 GMT

Olá pessoal, tudo certo?

Ao longo dessas semanas, tenho falado sobre orientação a serviços e alguns desafios reais que ocorrem nesse tipo de desenvolvimento e arquitetura. Quando pensamos em questões como autenticação, autorização, instrumentação, suporte a transação, tratamento de exceção, etc., vemos o quanto uma abordagem de serviços possui as mesmas necessidades de uma arquitetura de software baseada em componentes ou mesmo outros cenários de soluções. Ferramentas como a Enterprise Library 4.1 são tão importantes para SOA quanto para aplicações Web em ASP.NET tradicional, por exemplo.

Semana passada, aproveitei um post para citar algumas recomendações sobre o “chão-de-fábrica”. Hoje, gostaria de chamar a atenção para o mapa de produtos da plataforma Microsoft.

Pensando numa arquitetura de referência de serviços e algumas capacidades principais, temos o seguinte desenho:

Vemos acima os grupos de capacidades de Consumo de serviços, Composição e Interação, Composição e Transação e Exposição de Funcionalidades, onde destacamos as principais capacidades:

Serviços de Apresentação
Serviços de Colaboração
Serviços de Interação
Serviços de Processos
Serviços de Dados
Serviços de Conectividade

Veja ainda uma série de capacidades de administração (ao lado), como gerenciamento, segurança, governança, BI, análises de negócio, etc. A partir do modelo acima, podemos posicionar nossos componentes de serviços de acordo com as necessidades de nosso negócio. Existem ainda outras questões associadas, como granularidade de serviços, análise de domínios envolvidos, templates para cada tipo de implementação, etc.

Usando esse mesmo mapa de serviços, gostaria de propor um mapa de produtos atuais da plataforma Microsoft, para atender cada camada acima:

Assim, teríamos (a grosso modo):

Camada de Apresentação: SharePoint Server, Siverlight, Office System, ASP.NET, Windows Client, Composite Application Guidance for WPF and Silverlight.
Camada de Colaboração: Office Communication Server, SharePoint Server.
Camada de Interação: SharePoint Server, WF
Camada de Processos: BizTalk Server, WF
Camada de Dados: BizTalk Server, SQL Server
Camada de Conectividade: BizTalk Server, WCF

Ao mesmo tempo, pacotes como System Center, MOF, Active Directory, ESB Guidance e soluções de terceiros oferecem recursos e ferramentas para as atividades de administração do ambiente.

Vemos que cada produto MS pode atender mais de uma camada ou conjunto de capacidades presentes numa visão de serviços. Ao mesmo tempo, quando pensamos em frameworks como WCF e WF, a implementação é por nossa conta, isto é, construímos os componentes de serviços (WCF) e workflow (WF) a partir de templates disponíveis no Visual Studio, conforme nossa necessidade de customização e desenvolvimento.

Usando pacotes completos como BizTalk Server e SharePoint Server, aproveitamos os recursos integrados oferecidos pelo ambiente, o que economiza dezenas de horas de desenvolvimento. Por exemplo, podemos implementar cenários de serviços customizados com WCF, que disponibilizam informações de notícias para uma certa empresa. Porém, se nossa solução exige a exportação dessas mensagens para uma série de ambientes diferentes, exigindo transformações de mensagens diversas, um motor baseado em BizTalk com seus recursos de mapeamento e transformação passa a ser interessante.

Em resumo, é importante conhecer as capacidades de cada produto, tecnologias e frameworks disponíveis no momento de decisão de cada camada de uma arquitetura de serviços. Podemos dizer que não existe um único produto ou tecnologia que atenda todos os cenários possíveis, de BPM a workflows, de serviços a web services. Cada cenário apresenta necessidades específicas que precisam ser identificadas e corretamente atendidas.

Por último, vale notar que o desenho acima é baseado apenas nas principais capacidades de cada produto. Existem cenários que podem aproveitar os produtos de diversas maneiras, compondo seus recursos e funcionalidades conforme a realidade de cada empresa.

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

Waldemir.

Links e recomendações para o desenvolvimento de serviços

wcamb — Sat, 16 May 2009 20:37:00 GMT

Olá pessoal, tudo certo?

Essa semana tive algumas reuniões com empresas e arquitetos, falando sobre ferramentas importantes para projetos envolvendo serviços, web services e aplicações de composição. Vamos aproveitar o post para citar os principais pacotes disponíveis, que ajudam no processo de desenvolvimento de uma solução orientada a serviços.

1) Enterprise Library 4.1 - October 2008
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=1643758B-2986-47F7-B529-3E41584B6CE5&displaylang=en

A Enterprise Library 4.1 oferece um conjunto de blocos de aplicação e bibliotecas que atendem questões básicas da infra-estrutura de software, como:
•    Caching
•    Criptografia
•    Acesso a Dados
•    Tratamento de Exceção
•    Interceptação de chamadas
•    Logging, auditoria
•    Segurança
•    Validação, entre outros.

Sem dúvida, é um pacote muito importante para consulta e uso durante o projeto.

Veja mais aqui: http://blogs.msdn.com/wcamb/archive/2009/04/17/enterprise-library-configuration-com-a-entlib-4-1.aspx

2) Hands-On Labs for Enterprise Library 4.1 – March 2009
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=AB3F2168-FEA1-4FC2-B40C-7867D99D4B6A&displaylang=en

O Hands On Labs (HOL) da Enterprise Library 4.1 é um pacote obrigatório para quem está iniciando seus primeiros passos com a biblioteca. Os laboratórios são muito bons, permitindo um excelente estudo sobre cada pacote.

Veja mais aqui: http://blogs.msdn.com/wcamb/archive/2009/04/13/hands-on-labs-for-enterprise-library-4-1-march-2009.aspx

3) patterns & practices Application Architecture Guide 2.0
Ref.: http://www.codeplex.com/AppArchGuide/Release/ProjectReleases.aspx?ReleaseId=20586

Esse documento é o guia de arquitetura em plataforma .NET. Leitura obrigatória sobre aplicações Web e arquiteturas de referência Web.

Veja mais aqui: http://blogs.msdn.com/wcamb/archive/2008/12/19/patterns-practices-application-architecture-guide-2-0.aspx

4) patterns & practices : Improving Web Services Secutiry
Ref.: http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=15892

Esse documento fala sobre os principais aspectos de segurança para Web Services e serviços em WCF. Questões sobre autenticação, autorização, impersonation, etc. são bem tratadas nesse documento. Leitura importante!

Veja mais aqui: http://blogs.msdn.com/wcamb/archive/2008/11/05/patterns-practices-improving-web-services-security.aspx

4) Composite Application Guidance for WPF and Silverlight – Prism 2.0
Ref.: http://compositewpf.codeplex.com/

Esse velho conhecido oferece uma biblioteca para a construção de aplicações de composição em WPF e Silverlight 2.0. Para isso, o Prism oferece uma biblioteca que permite que módulos independentes sejam construídos e integrados na mesma interface de aplicação, dinâmica e composta. Cada módulo pode consumir funcionalidades e serviços de fontes diferentes. A implementação de referência STOCK TRADER que vem com o Prism 2.0 já oferece um bom começo e exemplo de aplicação. Confira!

E sobre pacotes de instalação para aplicações Web, o recente:

6) Microsoft Web Platform Installer
Ref. http://www.microsoft.com/web/downloads/platform.aspx

Esse pacote é muito interessante para aplicações Web, que farão parte da solução com serviços. Questões como deployment, configuração e empacotamento dos bits para exportação para a produção também estão presentes em projetos SOA. Por isso, o Web Platform Installer vale como dica.

Veja mais aqui: http://blogs.msdn.com/wcamb/archive/2009/04/30/microsoft-web-platform-installer-1-0-e-2-0-beta.aspx

7) Health Monitoring to Instrument a WCF Service for Security
Ref.: http://msdn.microsoft.com/en-us/library/cc949048.aspx

O objetivo desse pacote é suportar um serviço WCF com vários elementos de instrumentação, monitoração e segurança. Leitura complementar bem interessante.

Esses foram alguns pacotes que tenho usado na orientação de projetos com serviços. Fique a vontade para comentar suas experiências ou ainda adicionar novas dicas para a comunidade.

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

Waldemir.

Recomendações gerais para a construção de serviços

wcamb — Wed, 22 Apr 2009 03:13:00 GMT

Olá pessoal, tudo certo?

Conforme combinado, vamos falar hoje de algumas dicas e ferramentas para a construção de serviços. Preparei uma lista com algumas direções para as várias questões envolvidas com o chamado “chão-de-fábrica” na construção de serviços de SOA.

E quais são essas questões? Vejamos algumas:

Qual será o modelo/template de serviço?
Qual será a granularidade dos serviços?
Qual será o modelo/template de workflow?
Qual será o modelo/template de segurança?
Qual será o modelo de instrumentação e monitoração?
Qual será o modelo de tratamento de exceções?
Qual será o modelo de consumo de serviços?
Como será obtido o reuso de serviços?

Entre outras. Claro, estou dando o foco em desenvolvimento e a lista acima é apenas parcial. Existem outros aspectos que focam a infra-estrutura, nos moldes das discussões conduzidas pelo Markus Christen. Aqui entram os barramentos corporativos, os containers de serviços e workflows, virtualização, consolidação de infra-estrutura, etc.

Assim, vejamos as tabelas abaixos, com alguns aspectos e comentários importantes:

Links importantes:

WCF – Windows Communication Foundation templates
Ref.: http://msdn.microsoft.com/en-us/library/ms735119.aspx

WCF And WF Services In The .NET Framework 4.0 And “Dublin”
Ref.: http://msdn.microsoft.com/en-us/magazine/2009.01.net40.aspx

WCF Security Guidance
Ref.: http://www.codeplex.com/WCFSecurity

Links importantes:

How to: Use Health Monitoring to Instrument a WCF Service for Security
Ref.: http://msdn.microsoft.com/en-us/library/cc949048.aspx

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

Composite Application Guidance for WPF and Silverlight 2.0
Ref.: http://compositewpf.codeplex.com

Enterprise Library 4.1 – October 2008
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=1643758B-2986-47F7-B529-3E41584B6CE5&displaylang=en

Hands-On Labs for Enterprise Library 4.1 – March 2009
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=AB3F2168-FEA1-4FC2-B40C-7867D99D4B6A&displaylang=en

Esses são alguns dos guias que tenho usado em discussões e projetos de SOA sobre a plataforma Microsoft. Cada tópico merece uma atenção especial enquanto construímos nossos serviços, por isso, não deixem de conferir os links acima.

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

Waldemir.

Sequential Workflow Service Library : integrando serviços WCF com workflows WF no .NET 3.5

wcamb — Wed, 18 Mar 2009 01:15:00 GMT

Olá pessoal, tudo certo?

Em breve teremos a chegada do .NET 4.0, com uma série de inovações e melhorias em seus recursos. Entre os benefícios, a dupla WCF (Windows Communication Foundation) e WF (Windows Workflow Foundation) promete maior integração e aderência ao modelo híbrido de programação enterprise/cloud (local e nuvem).

Um desenho conhecido aparece abaixo, onde nosso workflow encapsula chamadas para outros serviços externos, enquanto ele mesmo é exportado como um serviço, para outros participantes da solução.

Esse tipo de cenário é bem interessante para arquiteturas de serviços, onde pequenas orquestrações podem coordenar chamadas diversas para serviços da infra-estrutura. Assim, desenhos como esse abaixo são comuns em muitas empresas:

Com o .NET 3.0 era possível o consumo de serviços a partir de workflows em WF somente através de interfaces Web Services. Esse tipo de interação era obtida com os shapes de invocação e tratamento de Web Services, como o InvokeWebService, WebServiceInput, WebServiceOutput e WebServiceFault.

Com o .NET 3.5, a integração WCF + WF aumentou, com templates interessantes como o Sequential Workflow Service Library, objeto deste post.

Nesses últimos dias, tenhos conversado com muitas empresas que têm perguntado sobre essa integração entre interfaces de serviços e workflows em soluções para diversos cenários.

Como criar um SERVIÇO como um WORKFLOW?

Para a criação de um serviços como workflow, o .NET 3.5 oferece o template Sequential Workflow Service Library, que oferece uma interface de publicação WCF para um workflow WF.

Através deste template, temos a disposição todos os shapes e recursos do WF para a coordenação de atividades e chamadas para outros serviços ou mesmo outros workflows da solução. Ao mesmo tempo, esse workflow implementa uma interface IWorkflow, que exporta um contrato de serviço, permitindo que aplicações clientes disparem mensagens para consumo. No template, a interface IWorkflow implementa um método GetData(..) exemplo, o mesmo implementado pelo template de WCF Service Library.

A figura ao lado ilustra o template Sequential Workflow Service Library como oferecido pelo Visual Studio e o .NET 3.5.

Podemos adicionar novas interfaces de serviços através da adição de novos contratos de operação ou mesmo contratos de dados na interface IWorkflow, conforme a necessidade.

Ao mesmo tempo, podemos adicionar novos shapes de WF ao workflow, para o tratamento dos valores de entrada e execução da lógica de negócio desejada, preparando o valor de retorno do serviço.

Um exemplo de serviço WCF implementado como um WF é dado a seguir, veja:

Arquivo: workflow1.cs

No serviço acima, temos uma primeira atividade codeActivity1 que recebe o valor de entrada do serviço na variável InputValue. Os argumentos de entrada (InputValue) e saída (ReturnValue) do serviço são de fato oferecidos pelo template, como vemos a seguir:

No exemplo acima, o valor InputValue é colocado na propriedade myCond, que é testada na condição do shape ifElseActivity1. Para teste, foi criada uma cláusula declarativa de condição myCond, que verifica se o valor de myCond é igual a 0. Se for, a atividade codeActivity2 é executada, caso contrário, a atividade codeActivity3 é executada. No final, codeActivity4 adiciona uma string na mensagem de retorno do serviço, que feito através da propriedade ReturnValue do serviço.

O código completo deste serviço é dado a seguir:

   1: using System;   2: using System.Workflow.Activities;   3:     4: namespace myWorkflowService   5: {   6:     public sealed partial class Workflow1 : SequentialWorkflowActivity   7:     {   8:         // Minha variável interna para teste de condição no workflow.   9:         public int myCond = 0;  10:    11:         public Workflow1()  12:         {  13:             InitializeComponent();  14:         }  15:    16:         // These variables are bound to the input and output parameters of the ReceiveActivity.  17:         private String returnValue;  18:         private Int32 inputValue;  19:    20:         public Int32 InputValue  21:         {  22:             get { return inputValue; }  23:             set { inputValue = value; }  24:         }  25:    26:         public string ReturnValue  27:         {  28:             get { return returnValue; }  29:             set { returnValue = value; }  30:         }  31:    32:         private void codeActivity1_ExecuteCode(object sender, EventArgs e)  33:         {  34:             this.myCond = InputValue;  35:         }  36:    37:         private void codeActivity2_ExecuteCode(object sender, EventArgs e)  38:         {  39:             ReturnValue = "passei pelo IF";  40:         }  41:    42:         private void codeActivity3_ExecuteCode(object sender, EventArgs e)  43:         {  44:             ReturnValue = "passei pelo ELSE";  45:         }  46:    47:         private void codeActivity4_ExecuteCode(object sender, EventArgs e)  48:         {  49:             ReturnValue = ReturnValue + " - Fim!";  50:         }  51:     }  52: }

Para testes, podemos usar o WCF Test Client do Visual Studio para exercitar chamadas ao serviço, alterando os valores de entrada do método GetData, como vemos abaixo:

Desse modo, vimos um bom exemplo de template que pode ser usado em nossas aplicações e soluções envolvendo os conceitos de interfaces de serviços e workflows, integrando os recursos do WCF e do WF no .NET 3.5.

Em posts futuros, vamos falar um pouco mais sobre a integração WCF+WF no .NET 4.0 e as novidades que estarão chegando, fiquem ligados!

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.

Interoperabilidade e Comunicação na plataforma Microsoft.

wcamb — Mon, 09 Feb 2009 15:55:00 GMT

Olá pessoal, tudo certo?

A semana passada foi bem corrida, com uma série de reuniões de projetos em diferentes empresas. Um dos tópicos interessantes que vi foi um mapa sobre os diferentes níveis de interoperabilidade na plataforma Microsoft.

Podemos pensar em 3 níveis básicos de complexidade:

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

A figura abaixo faz um resumo desse mapa de interoperabilidades:

O chamado "Interop in the Framework" envolve a integração customizada, através de sua principal ferramenta, o WCF - Windows Communication Foundation. Através do WCF podemos construir arquiteturas de serviços com interfaces específicas para cada necessidade de negócio envolvida. Veja que a customização possível do WCF envolve a escolha dos melhores bindings, protocolos de entrega, formatação de dados, etc. Assim, suportamos de forma especializada padrões como ASMX, WSE, .NET Remoting, MSMQ, formatos como POX, REST, JSON, ATOM, além de mecanismos de roteamento, transação, coordenação, entre outros padrões do WS-I. Veja sobre cenários de WCF aqui.

Porém, existem cenários onde podemos aproveitar recursos de EAI - Enterprise Application Intergation ou mensageria, que envolvem tipicamente a transformação de mensagens, roteamento e principalmente atividades de tradução entre diferentes ambientes e tecnologias. Nesse caso, o chamado "Interop in the Box" apresenta uma caixa pronta, através do BizTalk Server na plataforma Microsoft. Na verdade, o BizTalk Server oferece um conjunto de recursos que podem ser configurados ou extendidos, permitindo a integração direta entre diferentes sistemas através de adaptadores, para SAP, Siebel, JD Edwards, etc, além do atendimento de protocolos de troca de dados como XML, EDI, EDIFACT, AS2, SWIFT, etc. Finalmente, é muito comum a integração de cenários "in the Framework" com cenários "in the Box", pois nossa TI sempre possui características mistas de composição de negócios e serviços.

Por último e mais recentemente, podemos pensar na composição de cenários entre múltiplas empresas, que implementam internamente suas integrações nos níveis "in the Box" e "in the Framework" através da nuvem. Usando elementos de escalabilidade e processamento massivo de um datacenter externo, fazemos a integração de diferentes cenários de negócio e suas necessidades, usando um ambiente de hardware provisionável por demandad. Temos assim o chamado "Interop in the Cloud". Nesse tipo de ambiente, identidade, conectividade e workflow ou orquestração de negócios na nuvem são elementos básicos para o projeto. Seu maior representando no Windows Azure é o .NET Services, sendo o principal mecanismo para a construção de uma integração "in the cloud". Como exemplo, a Microsoft está desenvolvendo um projeto conhecido como MEBA - Multi-Enterprise Business Application, usando a nuvem como ponto de integração entre empresas. Veja um pouco mais sobre MEBA aqui.

MEBA - Multi-Enterprise Business Application

Interoperabilidade é um dos temas principais de arquitetura, assim como a Comunicação entre diferentes ambientes. Na plataforma Microsoft, quando pensamos em comunicação citamos 4 caixas específicas:

Microsoft® BizTalk® Server (BTS)
Microsoft Host Integration Server (HIS)
Microsoft Message Queuing (MSMQ)
Microsoft Enterprise Service Bus (ESB) Guidance

Vamos falar um pouco mais dessas soluções em posts futuros.

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

Waldemir.

MEBA - Multi-Enterprise Business Application.

wcamb — Fri, 28 Nov 2008 21:15:00 GMT

Olá pessoal, tudo certo?

Um assunto muito interessante que foi apresentado durante o PDC 2008 e o SAF 2008 é o MEBA - Multi-Enterprise Business Application. Ele é parte dos trabalhos do time de Jach Greenfield, nosso grande conhecido do mundo das Software Factories. Vamos falar um pouco sobre MEBA hoje.

Quando pensamos no mundo enterprise, com software on-premise e hardware local, uma discussão frequente tem sido como aplicar uma abordagem SOA de sucesso. Entende-se por sucesso a correta seleção de funcionalidades das aplicações de linhas de negócios (LOB) como serviços, obtenção de SLA's aderentes às necessidades de negócio, facilidades de administração, uso de protocolos abertos, reuso, boa governança de serviços, etc.

A partir do sucesso de cada empresa na implementação de SOA, surge o desafio da integração entre empresas, por exemplo, participantes de um mesmo processo de Supply Chain. Como coordenar os vários processos de SOA locais com uma visibilidade maior, num processo maior com diversos participantes?

Esse desafio é grandioso e muitas empresas de diferentes verticais e ramos de atividades o enfretam todos os dias. No papel de arquitetos de soluções, de infra-estrutura ou de enterprise, como podemos tratar esses problemas e aspectos de integração?

Uma das abordagens é o reconhecimento de patterns de integração e manipulação de dados. De fato, existem diversos tipos de patterns publicados, seja para cenários específicos de SOA - Service Oriented Architecture, BPM - Business Process Management ou EAI - Enterprise Application Integration. Note que relacionei as três tecnologias (SOA/BPM/EAI) por estarem geralmente associadas em diversos projetos hoje em dia. Tenho conversado com várias empresas que questionam sobre soluções ou abordagens para as três frentes, adicionando ainda um quarto participante que seria o ESB - Enterprise Service Bus.

Nesse ponto, o ESB serve como modelo de integração central para essas múltiplas empresas de um cenário SOA global. Surge então o conceito de Multi-Enterprise Business Application. O MEBA trata um conjunto de patterns e cenários de integração de SOA's distribuídos, geograficamente dispersos entre várias empresas. E o que poderia ser usado para integrar esses vários cenários? Uma plataforma de serviços na nuvem. :)

Os patterns do MEBA devem consolidar cenários de integração de diferentes ambientes de SOA através de serviços e aplicações persistidos na plataforma Azure, que funcionará como um ponto central de conectividade e integração entre diferentes aplicações e linhas de negócio. Note que para essa integração, serviços como Service Bus Services, Workflow Services e Access Control do .NET Services, assim como o próprio SQL Services serão blocos construtivos desse ambiente de conectividade. Surge assim uma nova utilidade para os blocos construtivos da plataforma de serviços do Azure.

Os trabalhos estão em desenvolvimento, mas já é possível imaginar o mundo de oportunidades e alternativas de integração para cenários corporativos complexos e hoje proibitivos, com a utilização de soluções baseadas na nuvem. Nas palavras de Jack Greenfield, podemos estar diante de um renascimento de soluções B2B e de integração global entre empresas de diversas indústrias e ramos de atuação.

Esse foi só um primeiro post sobre o assunto. Em conversas futuras, vamos continuar discutindo esse tema, fiquem ligados.

Para saber mais sobre o assunto, veja a sessão apresentada durante o último PDC 2008 pelo próprio Jack Greenfield.

Behind The Scenes: How We Built a Multi-Enterprise Supply Chain Application
http://channel9.msdn.com/pdc2008/BB59/

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

Waldemir.