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

2009-05-28

Waldemir Cambiucci
Maio de 2009

Sumário

Nesses últimos anos, diversas empresas de diferentes áreas de atuação têm implementado projetos em torno do tema SOA – Service Oriented Architecture. Os projetos de SOA buscam um conjunto de benefícios que juntos prometem a organização de uma TI mais ágil, de fácil administração e que atenda de forma mais rápida as necessidades de negócio da empresa, em torno do chamado negócio ágil (ou Agile Business). Nesse mesmo período, vimos o nascimento do modelo de entrega de software como serviço, o SaaS – Software as a Service, com novas exigências para uma solução de software mais flexível e reutilizável, suportando diversos usuários sobre uma mesma infra-estrutura configurável, oferecendo funcionalidades sob demanda. Finalmente, conceitos de Web 2.0, aplicações de composição, barramento de serviços corporativo, entregas de software como serviço e o uso de infra-estrutura provisionável e de alta escalabilidade conhecida como computação na nuvem (ou cloud computing) são tendências que juntas criaram um novo contexto de infra-estrutura e soluções que temos hoje a disposição das empresas. Sem dúvida, existe uma convergência de todas essas tecnologias e recursos em torno do conceito de serviços. Assim, o objetivo desse artigo é apresentar uma abordagem sobre o tema software+serviços na plataforma Microsoft, uma estratégia da empresa que envolve as principais tendências presentes hoje no setor de TI em torno de serviços. Vamos apresentar algumas das tecnologias e conceitos envolvidos, que facilitam a construção de uma nova TI, também conhecida como TI dinâmica.

Conteúdo

Introdução
A combinação do Software + Serviço
Entregando software como serviço – SaaS
       A cauda longa
       O modelo de maturidade SaaS
       Uma plataforma como serviço
       A computação na nuvem
Construindo arquiteturas orientadas a serviços – SOA
       Arquitetura de Referência SOA
       Capacidades de uma infra-estrutura de SOA
       Camada de serviços com WCF
       Camada de processos com WF
       Construindo aplicações compostas – Web 2.0
       Composite Application Guidance for WPF and Silverlight
Considerações finais
Referências
Agradecimentos
Sobre o Autor

1. Introdução

De forma simplificada, podemos definir SOA – Service Oriented Architecture – como um estilo de arquitetura onde funcionalidades específicas de sistemas existentes são oferecidas na forma de serviços. Aqui, temos alguns conceitos normalmente associados ao tema como barramento de serviços, níveis de operação de serviços, granularidade de serviços, etc. Da mesma forma, consumo de serviços, governança, reuso e todas as capacidades associadas à administração de um ambiente de serviços ganham importância nesse tipo de arquitetura. Antes de tratarmos todos esses conceitos, vamos apresentar um breve histórico sobre como o ambiente corporativo evoluiu nos últimos anos, posicionando essa discussão nos dias de hoje.

A figura abaixo apresenta uma visão em décadas, onde vemos diferentes abordagens para o ambiente de TI – Tecnologia da Informação:

Figura 1 – Evolução do ambiente de TI em décadas.

Iniciando com a década de 70, nessa época as empresas dispunham de grandes centros de processamento com custos elevados de operação e manutenção. Prevaleciam os sistemas monolíticos, que exigiam pessoal especializado, com grande conhecimento sobre detalhes técnicos de operação e muito pouco era transparente para o desenvolvedor ou para o usuário que operava sobre esses centros.

Já na década de 80, observamos o nascimento da computação pessoal, oferecendo poder de processamento a baixo custo para o usuário final. O usuário doméstico tinha mais poder para operar e manipular sua própria máquina, com menor necessidade de especialização. Quem não se lembra de linguagens de programação como o Basic, que alimentavam computadores de 8 bits em atividades domésticas como sistemas de locadoras de filmes ou agendas pessoais J. No final dos anos 80 iniciava o modelo de computação cliente/servidor, com o uso intenso de redes interoperáveis que integravam ambientes corporativos. Redes FDDI - Fiber Distributed Data Interface, Token Ring, Ethernet (IEEE 802.3) e uma série de equipamentos de integração como bridges, roteadores, switches e hubs iniciavam suas aparições, permitindo que empresas integrassem ambientes de computação e sistemas, ainda que com grande acoplamento de interfaces, protocolos e formatos de dados via rede.

Nos anos 90, vimos a consolidação da arquitetura cliente/servidor. Vimos também o surgimento da Web como uma rede pública de baixo custo disponível para universidades, empresas e usuários domésticos. Enquanto que diferentes topologias de redes proliferavam, vimos mais e mais equipamentos de interconexão invadindo nossas empresas, ampliando as capacidades de comunicação e integração entre sistemas. Sobre esses equipamentos, funcionalidades de aplicações eram publicadas através de serviços, que atendiam as diversas requisições através de protocolos TCP/IP ou diálogos proprietários, customizados para cada cenário de indústria. Serviços eram implementados expondo funcionalidades de aplicações ou sistemas fora das empresas.

A virada do século veio com mudanças ainda mais importantes: padrões como SOAP (Simple Object Access Protocol), HTTP (Hypertext Transfer Protocol), HTML (HyperText Markup Language) e XML (eXtensible Markup Language) permitiram que sistemas fossem integrados mais rapidamente, suportando um número crescente de usuários e aplicações através da internet. Sobre esses padrões, novas aplicações ganharam visibilidade como wikis, blogs, redes sociais, buscadores, etc., e conceitos como Web Services e serviços ganharam importância. Através da combinação HTTP+SOAP, serviços foram definitivamente expostos pela internet, cruzando as barreiras de firewalls pelas portas 80 (HTTP) e 443 (HTTPS) do TCP, ampliando as possibilidades de integração.

Hoje, estamos acompanhando o nascimento de uma nova onda no setor de TI, a chamada computação na nuvem (ou cloud computing). Gigantes como Microsoft, Amazon e Google ampliam suas ofertas de datacenters pelo mundo, oferecendo recursos de infra-estrutura provisionável além das fronteiras de nossas empresas. Vivemos assim o surgimento de uma TI mais dinâmica, flexível e híbrida, combinando serviços locais, hospedados em máquinas e servidores locais, com serviços remotos, hospedados em datacenters diversos. Da mesma forma, o custo de operação dessa nova TI será mais flexível, entre custos próprios, de serviços auto-hospedados e custos dinâmicos, a partir de serviços oferecidos pela internet e pagos por demanda, pelo volume de uso.

Com esse breve histórico, voltamos ao tema central da introdução: os serviços. Seja sobre uma infra-estrutura local ou através de datacenters espalhados pelo mundo, funcionalidades de aplicações serão cada vez mais oferecidas como serviços, permitindo a combinação e o consumo de uma forma flexível e dinâmica. Ao longo deste artigo, vamos conhecer as diferentes tecnologias que tornam esse cenário possível hoje sobre a plataforma Microsoft.

2. A combinação do Software + Serviço

Nesses últimos anos, a Microsoft tem utilizado a expressão software+serviço (S+S) para expressar sua estratégia sobre o uso de recursos locais e remotos, sobre uma mesma infra-estrutura de TI. Essa visão também envolve os principais conceitos presentes hoje em dia no setor, como o SAAS – Software as a Service, a Web 2.0 e uma arquitetura SOA.

A figura 2 ilustra esses principais conceitos e servirá de guia para nosso artigo, veja:

Figura 2 – Principais elementos do Software+Serviço: Web 2.0, SaaS e SOA.

No centro, vemos as questões de entrega de nossa infra-estrutura: funcionalidades de software podem ser entregues na forma de serviço, hospedados localmente em nossa empresa, em provedores parceiros ou mesmo em datacenters remotos com provisionamento dinâmico, na direção da computação na nuvem. De fato, o modelo de entrega SaaS envolve uma mais TI flexível, que pode compor diferentes níveis de operação (ou SLA’s – Service Level Agreement). Serviços hospedados localmente em servidores de nossa própria infra-estrutura tendem a responder de forma mais rápida do que serviços remotos, parcialmente conectados pela internet, seja por questões de acesso e latência de rede ou por condições de contrato ou interfaces customizadas para um cenário específico. Uma infra-estrutura local normalmente envolve maior especialização e customização para o cenário de negócio da empresa. Ao mesmo tempo, serviços hospedados na nuvem podem aproveitar o alcance global, com provisionamento dinâmico e o poder de computação elástico, que aumenta ou diminui conforme a necessidade da aplicação. Essa combinação entre local e remoto (on-premise e off-premise) ou maior controle e maior alcance será avaliada de acordo com as necessidades de negócio de cada empresa não havendo certo ou errado, mas sim combinações vantajosas ou mais aderentes às metas de custos de operação de cada indústria.

Ainda na figura 2, a Web 2.0 (do lado esquerdo) agrupa questões focadas no usuário (consumidor), envolvendo a experiência de acesso e sua usabilidade, assim como as medidas de acesso e monetização sobre o software. Hoje, as aplicações são consumidas através de diferentes interfaces como desktops, notebooks, netbooks, smartphones, pda’s, entre outros dispositivos. Essa variação de interfaces exige também um maior suporte a uma série de protocolos e formatos de dados, além de uma maior riqueza de recursos gráficos e melhor usabilidade e navegação. Ainda como recurso da Web 2.0, o software como serviço é tarifado de diferentes maneiras, seja via licença, subscrição ou por transação efetuada, além de aproveitar o volume de acesso para gerar renda através de propaganda e campanhas publicitárias sobre sua base de usuários. Todas essas formas de monetização são clássicas do modelo SaaS e estão presentes em diferentes tipos de aplicação hoje em dia, principalmente em sistemas na Web, portais colaborativos, marketplaces na Web, entre outros.

Finalmente, vemos as questões de SOA, contemplando a combinação de serviços e a federação de infra-estruturas. No ambiente corporativo, a visão de SOA busca o reuso de serviços e workflows, permitindo a coordenação de processos de negócio, assim como o reuso de recursos e funcionalidades da infra-estrutura disponível. Essa combinação também deve estar disponível para os usuários, através de interfaces dinâmicas e aplicações de composição. Diferentes empresas com arquiteturas SOA localmente implementadas também podem participar de federações de empresas e serviços, através do compartilhamento e integração de barramentos corporativos, identidades unificadas e recursos de computação compartilhados pela nuvem.

Enfim, os conceitos acima envolvem diferentes produtos e plataformas para sua realização. A seguir, vamos percorrer algumas dessas tecnologias, a fim de realizar o modelo software + serviços em nossas empresas.

3. Entregando software como serviço – SaaS

Alguns especialistas afirmam que o mercado ao redor de SaaS envolve cifras em torno de US$ 5 bilhões. Ainda, de acordo com o Gartner Group, SaaS representou cerca de 5% do mercado total de software em 2005 e até 2011, deverá representar 25% das vendas totais para o segmento corporativo. O uso de SaaS para a automação dos processos de negócio fim-a-fim, como ordens de pagamento para grandes empresas por exemplo, deve crescer ainda mais nos próximos anos. Porém, o que inicialmente era uma visão de negócio para a exposição de funcionalidades na forma de serviços está se tornando uma opção real de publicação de funcionalidades também no ambiente corporativo, entre departamentos, através de infra-estrutura local, remota ou na nuvem.

Em poucas palavras, SaaS é um software distribuído como um serviço, implementado em plataforma web de forma nativa e acessado usando tecnologias e protocolos de internet. Do ponto de vista do usuário, é um software que não é instalado localmente na infra-estrutura do cliente (on-premise), mas é utilizado através da web e pago pelo tempo de uso ou volume, por demanda. Desse modo, um software SaaS envolve mecanismos de tarifação e métricas de uso ou billing. Ainda, é um software que fornece uma API para acesso pela web, através de Web Services, interfaces REST, SOAP, entre outros protocolos.

Um aspectos importante da arquitetura SaaS é o envolvimento de uma infra-estrutura compartilhada entre diversos clientes, o que caracteriza um de seus grandes desafios de construção. Quando pensamos em SaaS, o conceito de multi-inquilino está presente. Ele é referente ao uso do mesmo software e instância por vários clientes e empresas de forma simultânea. Em apresentações sobre SaaS, o termo tenant é utilizado para designar o inquilino, ou cliente que acessa o software pela web. O objetivo dessa abordagem é disponibilizar os mesmos recursos de software para um número muito maior de clientes. E essa visão tem suas bases no conceito da "Cauda Longa".

3.1 Cauda longa

Se você ainda não leu o livro "The Long Tail : Why the Future of Business is Selling Less of More" (do autor Chris Anderson [1]), é o primeiro passo para um entendimento do tema SaaS. Veja o desenho abaixo sobre a visão da Cauda Longa:

Figura 3 – Gráfico da Cauda Longa / The Long Tail.

O gráfico ilustra que conforme baixamos o custo de adoção, um número maior de clientes pode adotar nossa solução. E esse número tende a crescer, aproveitando o alcance global do ambiente Web. No modelo SaaS de fornecimento de software, precisamos pensar em soluções e infra-estruturas de baixo custo, com alto aproveitamento de recursos por um número muito grande de clientes, para atingirmos um público não suportado hoje em dia, devido os custos proibitivos de entrada.

Outro conceito importante do modelo é o "micro-pagamento". Na cauda longa, um número muito grande de usuários poderá adotar nossa solução pagando pelo uso, por demanda, o que deve gerar um valor muito baixo de pagamento ou ticket. Nesse cenário, estamos realmente buscando o chamado "milhões de mercados de poucos" ao invés dos atuais "poucos mercados de milhões", sendo a essencial do modelo baseada na Cauda Longa.

3.2 O modelo de maturidade SaaS

A partir dos conceitos do SaaS, fica claro o impacto na construção de uma arquitetura baseada nesse modelo. Existem diversas necessidades de tecnologia e infra-estrutura que precisam ser atendidas para que essa visão seja suportada. Um modelo de maturidade SaaS é apresentado a seguir, conforme discussão que encontramos no artigo "Architecture Strategies for Catching the Long Tail" de Frederick Chong e Gianpaolo Carraro [2]:

Figura 4 – Modelo de maturidade SaaS, sobre a evolução do suporte multi-inquilino.

Note que no primeiro quadrante, a solução possui uma instância dedicada para cada inquilino (tenant) ou usuário do sistema. Isso garante um completo atendimento das demandas do cliente, mas com elevado custo de operação e manutenção devido a ausência de compartilhamento de recursos e customização elevada. Também no quadrante 1, cada cliente é atendido por uma instância dedicada da solução, o que exige um bom planejamento de capacidade enquanto mais clientes são suportados pela infra-estrutura.

No quadrante 2, a solução ainda apresenta uma instância dedicada para cada inquilino, porém, já é possível observar que a solução é a mesma, com nenhuma customização presente. Isso garante um custo menor de manutenção, já que a mesma solução atende a diversos clientes.

No quadrante 3, a solução é multi-inquilino (multi-tenant) e apresenta total compatilhamento de recursos, havendo uma única instância para todos os clientes. Note que questões importantes para o tratamento de metadados, assim como manutenção e modelagem do banco de dados estão presentes aqui. Um dos grandes desafios desse estágio é a modelagem de um banco de dados SaaS, multi-inquilino e com bom desempenho, porém, nesse cenário apresentamos uma solução que suporta de uma forma automática a custormização de diferentes inquilinos, com baixo custo de operação, permitindo a prática de micro-pagamento e baixo custo de subscrição de funcionalidades.

Finalmente, o quadrante 4 permite um atendimento diferenciado para inquilinos que exigem elevada demanda de recursos, havendo uma carga balanceada na infra-estrutura do provedor da solução SaaS (o chamado tenant load balancer).

Falamos rapidamente de um modelo de maturidade SaaS, onde notamos alguns pontos importantes como um serviço de metadados e questões para se garantir uma base de dados com facilidades para o tratamento multi-inquilino.

Dentro da plataforma Microsoft, a implementação de serviços passa pelo uso do WFC – Windows Communication Foundation, componente do .NET framework que oferece um modelo de programação para a construção de interfaces de serviços, respeitando um modelo de comunicação baseado em mensagens.

Considerando o modelo SaaS de funcionalidades como serviços, podemos imaginar serviços implementados localmente, assim como serviços consumidos a partir de provedores externos ou datacenters remotos, com provisionamento dinâmico. Como principal ambiente para suporte desse modelo, a Microsoft trabalha atualmente na plataforma Windows Azure, um plataforma como serviço.

3.3 Uma plataforma como serviço

De forma simplificada, podemos definir o cloud computing ou computação na nuvem como um ambiente de processamento e armazenamento de dados massivo, de alta escalabilidade e alta disponibilidade, acessível via interfaces web como HTTP, REST e SOAP, instalado em datacenters de última geração espalhados pelo mundo.

Uma grande característica desse modelo de computação é o provisionamento elástico de computação: imagine um cenário típico de uma aplicação ASP.NET. Podemos iniciar a operação do sistema com 10 máquinas previstas para o front-end e back-end. Com o crescente volume de requisições devido uma campanha de marketing sobre o sistema, podemos contratar novas máquinas, passando para um cenário de 20 máquinas para o front-end e back-end de forma dinâmica, através da configuração do ambiente via um portal de administração, por exemplo. Terminado o pico de utilização e retornado o volume original de acesso, podemos simplesmente voltar para a configuração original de 10 máquinas, apenas atualizando o arquivo de configuração do ambiente na nuvem.

Esse poder de configuração é conhecido por computação elástica (ou elastic computing), onde o provisionamento é feito de modo dinâmico através de um modelo de descrição de infra-estrutura que será provisionada, conforme a demanda da aplicação. Ao mesmo tempo, novos modelos de contração, subscrição de serviços e licenciamento estão associados, onde a empresa pode pagar apenas pela infra-estrutura que realmente utiliza. Fazendo algumas contas, você verá que o cenário de computação na nuvem pode oferecer uma grande redução nos custos de administração e operação da TI nas empresas, o que tem explicado o interesse crescente de clientes e fornecedores de software, como a Microsoft.

A computação na nuvem oferece o poder da alta escalabilidade e alcance global com os conceitos de software como serviços oferecidos pelo SaaS. Recentemente, alguns trabalhos acadêmicos já sugerem uma taxonomia para as aplicações e recursos de uma plataforma na nuvem, como vemos na figura a seguir:

Figura 5 – Proposta de taxonomia para a computação na nuvem, conforme proposto Lamia Youseff e outros [3].

Veja que a proposta acima classifica as aplicações na nuvem (cloud applications), assim como os recursos disponíveis pela infra-estrutura na nuvem, como a plataforma (PaaS - Platform as a Service), a comunicação (CaaS - Communication as a Service), o armazenamento (DaaS – Data as a Service), o processamento (IaaS – Infrastructure as a Service), etc.

Logo após a publicação da taxonomia proposta acima por Lamia Yousef [3], vimos alguns frameworks de camadas sugeridos para a computação na nuvem, procurando organizar os vários recursos disponíveis no ambiente. Ao longo deste artigo, veremos mais detalhes sobre a plataforma Windows Azure, assim como suas características sobre o modelo PaaS.

3.4 A computação na nuvem

Embora o termo “Cloud Computing” ou computação na nuvem seja baseado numa coleção de velhos e novos conceitos como SOA – Service Oriented Architecture, computação distribuída (Grid Computing), virtualização e modelos de entrega de software como serviço, nesses últimos anos temos visto um crescente interesse sobre o tema.

Esse foco tem sido resultado pelo grande potencial de reuso de recursos e tecnologias atualmente colocadas em datacenters sub-utilizados. Em linhas gerais, podemos considerar que a computação na nuvem entrega um novo paradigma de computação, onde usuários e empresas utilizam de forma temporária um maior ou menor poder de processamento e armazenamento de uma infra-estrutura disponível através da web, suprindo suas necessidades de infra-estrutura local, conforme a necessidade do negócio.

Essa combinação entre poder de processamento escalável e ilimitado com a potencial redução de custo da operação local explicam o grande interesse de empresas e usuários no modelo de computação na nuvem.

Esse é o contexto de lançamento do Windows Azure, um sistema operacional para a nuvem, anunciado pela Microsoft no último PDC 2008 – Professional Developers Conference, em Los Angeles. O Windows Azure é um sistema operacional que deve rodar sobre os vários datacenters da Microsoft em construção pelo mundo. A partir de suas funcionalidades e serviços, podemos mesmo classificar o Windows Azure como uma plataforma como serviços, ou PaaS – Platform as a Service.

Entre as características presentes no Windows Azure destacamos sua natureza para o “utility computing”, onde diversos serviços são oferecidos pelo sistema operacional para administrar e abstrair os recursos presentes no datacenter, como:

Facilidade para expandir para novas localidades (geo-distribuição);
Atualização viva de novas funcionalidades de software;
Aplicação de patches e correções de sistema operacional;
Diagnóstico e recuperação de falhas de hardware no próprio datacenter;
Grande capacidade de armazenamento com alta disponibilidade;
Lidar com o aumento de tráfego;
Diagnosticar e responder a falhas de serviços;

Alguns cenários de aplicações são especialmente aderentes ao modelo de computação na nuvem, como:

SaaS LOB Applications, ou aplicações linhas de negócio no modelo SaaS – Software as a Services, oferecendo funcionalidades como serviços. Alguns exemplos são CRM SaaS, HR SaaS, ERP SaaS, etc;
Aplicações Web Colaborativas, envolvendo diversos dispositivos e usuários com a manipulação de formatos de dados diversos;
Aplicações com Hub de dados compartilhados, envolvendo um volume crescente de dados compartilhados entre diversas empresas, como cenários de cadeias de suprimentos, integração entre empresas, etc;
Aplicações Web com Business Intelligence e Data Mining, com volumes crescentes de dados e armazenamento de informações;
Entre outras...

4. Construindo arquiteturas orientadas a serviços – SOA

Quando falamos em SOA, destacamos aqui duas palavras-chave: composição e federação.

A composição compreende a agregação de serviços e workflows participantes de uma arquitetura SOA, permitindo a combinação de chamadas chamadas para serviços diversos, assim como a coordenação de processos participantes de uma aplicação.
A federação compreende a integração de diferentes arquiteturas de serviços, através de recursos como federação de identidades, compartilhamento de recursos e áreas de armazenamento comuns ou por colaboração entre os participantes.

Para posicionar os vários elementos de uma visão de SOA que colaboram para o consumo, agregação e coordenação de serviços, vejamos uma arquitetura de referência proposta pela Microsoft.

4.1 Arquitetura de Referência SOA

Uma arquitetura de referência normalmente é apresentada como um diagrama ou desenho que orienta o arquiteto de soluções e desenvolvedores na construção das diversas camadas e componentes de uma solução.

Durante o evento SOA & Business Processes Conference 2007, realizado em Redmond, USA, a Microsoft apresentou para o mercado uma arquitetura de referência para projetos de SOA, como uma proposta para a organização de camadas e serviços, como vemos na figura abaixo:

Figura 6 – Arquitetura de Referência SOA proposta pela Microsoft.

Acompanhando o desenho de cima para baixo, vejamos uma descrição sobre as principais camadas da arquitetura de referência SOA:

Primeiro, notamos uma camada de aplicações compostas ou consumidores, que é destinada para as interfaces de composição de serviços da solução. Aqui, temos nossas interfaces e aplicações combinam serviços e chamadas de processos da infra-estrutura;
Logo abaixo, temos a camada de composição de negócios ou processos, onde orquestrações e workflows podem consumir serviços ou tratar regras de negócio, de acordo com as necessidades da solução;
Na seqüência, temos acamada de serviços atômicos ou de composição, que implementam as interfaces de serviços propriamente ditas. Baterias de Web Services ou serviços hospedados em servidores IIS são exemplos para essa camada;
Suportando os serviços acima, encontramos os componentes de serviços que podem ser componentes legados, exportando funcionalidades existentes de nossa infra-estrutura;
Por último, a camada de integração ou legado (LoB – Line of Business Application), onde encontramos nossos sistemas nativos, bancos de dados e soluções existentes que pretendemos exportar para outras áreas da empresa, por exemplo;
Atendendo todas as camadas encontramos as bibliotecas comuns, necessárias para a manutenção, administração e operação da solução. Assim, vemos as camadas verticais do desenho, que implementam monitoração, autorização, segurança, controle de acesso, auditoria, etc. São bibliotecas básicas, construídas ao longo do projeto ou fornecidas por alguma ferramenta de operação de serviços. Em muitos casos, barramentos de serviços oferecem essas funcionalidades de forma nativa, economizando algum tempo de desenvolvimento para o projeto.

Um fator de sucesso em muitos projetos de SOA tem sido a adoção de uma arquitetura de referência, que posiciona corretamente as camadas e componentes da solução. Em muitos casos, essa estruturação garante o respeito de interfaces de forma padronizada, assim como a coesão e responsabilidades previstas para cada camada, fornecendo o mínimo de organização e facilidade de manutenção futura.

A seguir, veremos alguns aspectos importantes de uma infra-estrutura orientada a serviços, a chamada SOI – Service Oriented Infrastructure.

4.2 Capacidades de uma infra-estrutura de SOA

Considerando uma solução baseada em serviços, uma questão importante que aparece é a hospedagem destes componentes, assim como sua administração, segurança, controle, versionamento, governança, entre outros aspectos de infra-estrutura da solução.

Surge então o conceito de SOI – Service Oriented Infrastructure, que envolve os principais aspectos de administração do ambiente de serviços disponíveis em nossa TI. Na plataforma Microsoft, existem diferentes tipos de hospedagem de serviços, oferecendo benefícios e limitações próprias. Da mesma forma, podemos organizar os diferentes recursos e camadas da arquitetura SOA, posicionando seus componentes físicos de acordo com a arquitetura de referência SOA apresentada anteriormente.

A figura a seguir ilustra as principais capacidades de uma infra-estrutura orientada a serviços, implementando a visão da arquitetura de referência SOA.

Figura 7 – Principais capacidades de uma infra-estrutura de serviços SOI – Service Oriented Infrastructure.

A figura ilustra algumas das principais capacidades presentes em uma infra-estrutura de serviços, que atendem as necessidades de uma arquitetura SOA. Vejamos uma breve descrição de cada uma dessas capacidades a seguir:

Gerenciamento de serviços: um dos aspectos importantes de uma infra-estrutura de serviços são os recursos para gerir o ciclo de vida de serviços, que prevê o gerenciamento de diferentes níveis de operação e a definição de atributos descritivos para cada serviços implementado. Outro aspecto importante é o registro de serviços, que permite o mapeamento dos serviços disponíveis, facilitando a monitoração da saúde de serviços presentes, assim como o gerenciamento centralizado de exceções;
Monitoração de infra-estrutura: além da monitoração específica sobre o comportamento dos serviços disponíveis, a monitoração da infra-estrutura e funcionalidades de hardware são igualmente importantes;
Consumidores de serviços: para o consumo e chamadas das funcionalidades implementadas como serviços, as soluções de hoje dispõem de dashboards, aplicações em dispositivos móveis, aplicações de composição, portais web, etc;
Processos de negócios e Business Intelligence: coordenando os serviços e funcionalidades implementadas, componentes de BI permitem a inspeção das mensagens e informações trafegadas no ambiente.Da mesma forma, o gerenciamento de regras de negócio, workflows de processos e automação de processos de negócio oferece importantes ferramentas de administração e análise de informações tratadas pela solução;
Barrramento corporativo de serviços: mediação de serviços, transformação de mensagens e validação de mensagens, assim como resolução dinâmica de serviços, tratamento de itinerários e mensageria são patterns de administração importantes de uma solução. Um dos principais aspectos do barramento de serviços é a padronização das interfaces de consumo através de um ponto único de acesso, o barramento, que é responsável pela resolução de itinerários e endpoints de serviços disponíveis;
Componentes de mensageria de serviços: entre os principais aspectos de mensageria e suporte de serviços citamos a virtualização de serviços, o suporte a padrões WS-*, adaptadores e sistemas legados, bindings, conectores e endpoins de serviços.
Federação de dados e Federação de identidades: um traço importante de uma infra-estrutura de serviços é a capacidade de federação com outros ambientes, permitindo o relacionamento integrado a partir de dados e identidades reconhecidas e comuns. Esse mecanismos de integração é importante para uma maior transparência entre funcionalidades de uma mesma solução.
Ferramentas de desenvolvimento: existem diversos recursos disponíveis para a construção de uma infra-estrutura de serviços, seja para a camada de interfaces, serviços, processos, workflows ou funcionalidades adjacentes. Pacotes como fábricas de software para construção de serviços, ferramentas para testes e modelagem de serviços, assim como templates e patterns aplicáveis são críticos para o sucesso de uma solução.
Governança e ferramentas de governança: finalmente, todo o ambiente de uma infra-estrutura de serviços exige cuidados especiais ao longo de sua operação e mesmo inspeção de funcionalidades. Ferramentas de governança são peças tão importantes quanto os próprios containers de serviços ou mesmo barramentos de serviços dinâmicos.

A partir dessa descrição, podemos rever o diagrama de SOI em mais detalhes, como ilustrado a seguir:

Figura 8 – Capacidades de uma infra-estrutura de serviços SOI – Service Oriented Infrastructure.

A partir desse mapa de infra-estrutura, executamos os componentes básicos de nossa solução SOA: serviços e processos.

4.3 Camada de serviços com WCF

Quando pensamos sobre os fundamentos de uma arquitetura SOA passamos obrigatoriamente pelo conceito de serviço. Porém, quando falamos em serviço, uma série de questões aparece, como:

O que é um serviço?
Quais são os patterns para criação e consumo de serviços?
Quais os mecanismos de conexão, transporte de mensagens e comunicação entre serviços?
Quais funcionalidades serão implementadas como serviços?
Como aproveitar os investimentos existentes em nossa infra-estrutura de TI?
Como publicar os serviços gerados para outros departamentos e sistemas?
Como consumir os serviços gerados de maneira padronizada?
Como administrar os serviços em produção?
O que é governança de serviços mesmo?

Esse conjunto de questões é determinante para o sucesso ou o fracasso de um projeto de SOA. Ao longo deste artigo, vamos passar pelas respostas para algumas dessas questões. Para começar, vamos definir o que é um serviço.

Podemos definir um serviço como um componente de software que permite o consumo e a combinação de funcionalidades, respeitando algumas características importantes como:

Um serviço é orientado a mensagem;
Um serviço pode ser autônomo ou composto por outros serviços encadeados;
Um serviço garante o desacoplamento entre cliente e funcionalidades. Em alguns cenários, esse desacoplamento envolve uma abordagem assíncrona na integração entre cliente e serviços, ou o uso de mensageria através de filas e mecanismos de entrega de mensagens;
Um serviço pode oferecer flexibilidade na escolha do protocolo de entrega e mecanismo de transporte;
Um serviço pode oferecer flexibilidade na escolha do ambiente de execução do serviço (hosting);
Um serviço envolve a definição de contratos de operação e contratos de mensagens;

Das habilidades acima, talvez as mais importantes sejam a orientação a mensagens, assim como a padronização de uma interface de exportação descrevendo claramente os contratos de operação e funcionalidades expostas. Com esses requisitos respeitados, começamos a visualizar um dos grandes benefícios prometidos pela arquitetura de SOA, que é o reuso.

Por reuso entende-se a capacidade de aproveitar código ou recursos de infra-estrutura já implementados no ambiente de TI, por outros departamentos ou sistemas da organização. Com o foco no ambiente corporativo, o reuso envolve a reaproveitamento de investimentos já feitos, seja na construção de módulos de sistema ou na compra de produtos específicos para a construção de uma solução. O reuso de serviços é uma das promessas mais desejadas em arquiteturas orientadas a serviços.

Assim como serviço é um elemento importante nessa arquitetura, a orquestração de serviços ou a combinação de chamadas de serviços em processos e workflows de decisão é outro elemento comum que aparece numa arquitetura SOA. Muitas vezes, um cenário de SOA nasce a partir de um cenário de integração de aplicações, ou seja, um EAI – Enterprise Application Integration. Ainda nesse artigo falaremos mais sobre cenários de integração.

Para a construção de interfaces de serviços, o .NET Framework 3.0 introduziu ao mercado o WCF – Windows Communication Foundation – que oferece um modelo de programação unificado para a construção de serviços na plataforma Microsoft.

A figura a seguir apresenta a anatomia de um serviço em WCF, com seus principais componentes:

Figura 9 – Anatomia de um serviço em WCF – Windows Communication Foundation.

A partir da figura acima, notamos diversos componentes presentes no modelo de programação do WCF, a saber:

Serviço: componente de software que irá publicar métodos e funcionalidades para outros componentes da solução. O serviço está hospedado em algum servidor ou motor de execução específico, além de apresentar comportamentos definidos de acordo com a necessidade da aplicação;
Cliente: componente de software que fará as chamadas aos métodos publicados pela interface WCF;
Mensagem: serviços são orientados a mensagens, ou seja, suportam estruturas de dados bem definidas que são utilizadas durante as trocas de dados entre cliente e servidor. Cada mensagem está associada a um método específico ou funcionalidade, assim como os resultados esperados;
ServiceHost: todo serviço está associado a um host específico, responsável pelo ambiente de execução previsto. É possível utilizar como host um serviço Windows, o IIS - Internet Information Server, o WAS – Windows Activation Services, um serviço doméstico construído pelo desenvolvedor, entre outros;
A+B+C do WCF: para a configuração da comunicação entre cliente e serviço, o WCF oferece três componentes básicos: o endereço do serviço (A=address), o mecanismo de entrega de mensagens (B=binding) e o contrato de operação (C=contract);
Address: o endereço do serviço é o componente de configuração que define o endereço de atendimento do serviço. O cliente necessita conhecer o endereço do serviço, para que seja feito o envio de mensagens para o disparo de métodos;
Binding: o binding do WCF é responsável pela configuração de transporte da comunicação entre cliente e serviço. O .NET framework 3.x oferece uma série de bindings pré-definidos, cada um responsável por uma configuração de transporte específica. Assim, existem bindings para transporte sobre HTTP, TCP, MSMQ, PIPES, etc. De acordo com a necessidade de desempenho, características de conectividade, sincronismo ou tratamento de mensagens, o arquiteto deve escolher o binding que melhor atende sua solução;
Contract: dentro dos conceitos A+B+C do WCF, o contrato é o mapeamento de métodos e parâmetros previstos para a comunicação entre cliente e serviço. Dos três conceitos, o contrato é o único que exige a recompilação do serviço em caso de alteração. Os demais permitem a configuração de forma dinâmica;
Behavior: cada serviço pode implementar comportamentos específicos para um melhor atendimento da solução alvo, como suporte a transações, múltiplas-instâncias, segurança, etc.;
Proxy: para que o cliente tenha acesso aos métodos descritos pelo contrato de serviço e realize o envio de mensagens, necessita de uma descrição dos componentes A+B+C. Essa descrição é feita em XML e é chamada proxy, fazendo parte do arquivo de configuração da aplicação.

Entre os componentes descritos destacamos o EndPoint, que fornecem parâmetros para a identificação e acesso a um serviço. Um exemplo de EndPoint é dado a seguir:

<endpoint address=https://localhost:57953/Service1.svc
binding="wsHttpBinding"
contract="ServiceReference1.IService1"
name="MyEndPointName">
</endpoint>

Listagem 1 – Exemplo código de endpoint para um serviço em WCF.

Através do trecho de código XML acima, podemos identificar corretamente um serviço exportado em nossa solução, onde notamos o address, o binding e o contract para operação do serviço em WCF.

Uma mensagem entre um cliente e um serviço WCF é tipicamente uma estrutura de dados que dispara uma operação do lado do serviço, gerando uma resposta para o chamador. Imagine uma mensagem enviada para um serviço WCF implementado como um Web Service. O código a seguir apresenta o trecho em SOAP/XML que forma essa mensagem:

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
            xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://tempuri.org/IWorkflow1/GetData
    </a:Action>
    <a:MessageID>urn:uuid:eeadf2ee-95e5-469f-8381-da0559fe8222</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
  </s:Header>
  <s:Body>
    <GetData xmlns="http://tempuri.org/">
      <value>123</value>
    </GetData>
  </s:Body>
</s:Envelope>

Listagem 2 – Exemplo de mensagem SOAP/XML mostrando o envelope de mensagem e conteúdo de uma requisição de cliente para consumo de um serviço.

A requisição acima ilustra uma mensagem típica em protocolo SOAP, onde vemos o envelope SOAP e seus dois componentes: HEADER e BODY. Através do HEADER SOAP, definimos a identificação da mensagem e os campos de controle da requisição. No campo BODY SOAP temos a mensagem destinada ao serviço, indicando o método destino GetData(int param) assim como os parâmetros envolvidos. Em nosso exemplo, notamos o parâmetro value com o valor 123 como parâmetro de entrada.

A partir da execução do método GetData(..), obtemos uma nova mensagem de resposta em SOAP/XML. Um trecho da resposta SOAP enviada pelo serviço é apresentada abaixo:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:a="http://www.w3.org/2005/08/addressing"
            xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header> …
  </s:Header>
  <s:Body u:Id="_0">
    <GetDataResponse xmlns="http://tempuri.org/">
      <GetDataResult>123</GetDataResult>
    </GetDataResponse>
  </s:Body>
</s:Envelope>

Listagem 3 – Exemplo de mensagem SOAP/XML mostrando a resposta do serviço para a requisição do cliente.

Veja no campo BODY SOAP destacado acima que a resposta do serviço é obtida pelo campo GetDataResponse, com o valor de retorno GetDataResult igual a “123”.

Com esse exemplo simples percebemos que as mensagens entre clientes e serviços respeitam uma série de padrões, permitindo uma maior clareza na integração entre os participantes, assim como facilidades para a subscrição de mensagens, auditoria, rastreamento, versionamento, publicação e subscrição, etc.

Na listagem 3 vemos o trecho de código com a configuração do endpoint de serviço, a interface de serviço, definindo o contrato de operação IMyInterface e a implementação do serviço, na classe MyService.

Um dos principais benefícios oferecidos pelo WCF é sem dúvida a simplicidade do modelo de programação oferecido, o que garante maior velocidade na implementação de código, assim como maior legibilidade e facilidade de manutenção no ambiente de desenvolvimento.

A seguir, veremos outro componente do .NET framework importante para uma solução de SOA, o workflow.

4.4 Camada de processos com WF

Podemos definir um workflow como um conjunto de atividades que coordena pessoas e/ou software, organizadas em alguma forma de fluxo de trabalho. Um workflow pode ser representado como um diagrama de fluxo (também chamado de flowchart) ou como um diagrama de estado, implementando atividades baseadas em transições de estados.

Introduzido com o .NET 3.0, o WF – Windows Workflow Foundation oferece um ambiente para a construção e execução de workflows de diferentes tipos, permitindo a criação de processos e orquestração de chamadas, resolvendo problemas comuns na implantação de processos em sistemas .NET.

Entre os principais elementos da arquitetura WF destacamos:

Visual Designer: módulo gráfico responsável pela construção e composição de atividades. O Visual Designer aparece como principal recurso para a construção de workflows dentro do Visual Studio 2008;
Base Activity Library: atividades “Out-of-box” ou fora-da-caixa, que são base para a construção de workflows sofisticados. Ainda, o WF suporta a extensão da Base Activity Library, conforma a necessidade em cenários mais complexos;
Runtime Engine: Gerenciamento de Workflowe estados de execução, coordenando a execução das várias atividades de um workflow;
Runtime Services: Camada de comunicação e conectividade entre workflows e serviços associados a um processo;

A figura a seguir apresenta esses principais componentes da arquitetura do WF, como oferecido pelo .NET 3.0 e superior:

Figura 10 – Anatomia de um processo em WF, apresentando os principais componentes de arquitetura.

A partir dessas funcionalidades, a Microsoft tem adicionado novas capacidades e templates ao Visual Studio, assim como nas novas versão do .NET Framework. Mais recentemente, o .NET 3.5 SP1 trouxe novos templates de projeto, ampliando as soluções possíveis para a camada de processos.

A figura a seguir ilustra um desses novos templates de projeto, o Sequential Workflow Services Library, que permite a construção de um serviço WCF através de atividades do WF, fornecendo uma maior agilidade no desenvolvimento de serviços sofisticados:

Figura 11 – Um serviço WCF implementado em WF com o template Sequential Workflow Services Library.

Na figura acima, note que o método GetData é implementado através de um workflow com três atividades: codeActivity1, codeActivity2 e codeActivity3.

O WF permite a construção de diagramas sequenciais de atividades, onde implementamos regras de negócio ou a coordenação de chamadas para outros workflows ou serviços de uma solução. O WF oferece também um conjunto completo de templates e caixas de atividades, suportando ações como atividades em paralelo, condições declarativas, escopo de transação, recuperação e compensação, entre outros.

Através de templates de integração WCF+WF, é possível a construção de soluções de maneira simples e rápida, realizando chamadas para serviços a partir de workflows ou implementando workflows como serviços em WCF. O desenho a seguir ilustra alguns desses cenários:

Figura 12 – Exemplos de integração entre serviços WCF e processos WF.

Na figura 12, vemos um cliente enviando mensagens para um workflow implementado na forma de um serviço. Usando uma interface WCF, o workflow é disparado com requisições enviadas através de seu EndPoint.

Esse tipo de implementação é facilmente obtido com templates do .NET 3.5 SP1, como o Sequential Workflow Service Library. Ainda, é possível a combinação de atividades de envio e recebimento de mensagens para serviços WCF através de atividades como SendActivity e ReceiveActivity, como vemos na figura a seguir.

Figura 13 – Atividades SendActivity e ReceiveActivity do .NET 3.5, para a integração entre workflows WF e serviços WCF.

A partir de frameworks como WCF e WF, a plataforma Microsoft oferece ferramentas importantes para a construção de serviços e workflows de forma programática, sendo elementos básicos de uma arquitetura de SOA.

Até este ponto, falamos de serviços, infra-estrutura, implementação e recursos de uma plataforma de execução disponibilizando funcionalidades para aplicações de negócio. Surge então a necessidade de consumir toda essa infra-estrutura e recursos com um tipo de aplicação conhecida como aplicação composta ou composite application.

4.5 Construindo aplicações compostas – Web 2.0

Quando falamos em aplicações de composição passamos por uma série de patterns que garantem a construção de layouts dinâmicos, combinando recursos de diferentes fontes de dados e serviços numa mesma interface. Como resultado da Web 2.0, tecnologias como mashups e aplicações RIA – Rich Internet Application estão cada vez mais presentes em nosso dia-a-dia, oferecendo uma maior navegabilidade e usabilidade, não só em aplicações Web mas também em interfaces desktop.

A construção de interfaces também tem evoluído ao longo do tempo. Passamos de cenários monolíticos, para os modelos cliente/servidor com múltiplos documentos (MDI – Multi-Document Interface) e formulários até interfaces Web com recursos ricos, como streaming, apresentação de imagens, áudios, vídeos, animações, controles gráficos sofisticados, etc.

Entende-se por uma aplicação de composição um conjunto de patterns que permite a construção de uma interface dinâmica, que possui componentes gráficos ou de composição em tela, permitindo que cada parte do layout seja desenvolvida em separado, simultaneamente, sendo possível sua substituição conforme a necessidade, sem impacto para os demais componentes da interface. Esse tipo de comportamento é altamente desejado quando nossas aplicações buscam capacidades de personalização dinâmica, suporte a constantes mudanças nas funcionalidades da aplicação ou ainda, rápida implementação de novos cenários de negócio atendidos pela solução.

Alguns desafios encontrados em aplicações compostas são apresentados a seguir:

Uma interface de composição deve suportar diferentes fontes de dados e serviços;
Uma interface de composição deve utilizar patterns de composição para seus diversos componentes de tela;
Uma interface de composição deve permitir o desenvolvimento simultâneo de seus componentes, a partir de equipes distintas e isoladas se for preciso;
Uma interface de composição deve suportar as novas necessidades de usabilidade e flexibilidade em interfaces UX, oferecendo facilidades de operação para seus usuários;
Uma interface de composição deve tratar layouts dinâmicos, suportando composição de funcionalidades também dinâmicas;
Uma interface de composição deve tratar pattens como eventos e subscrição de eventos, injeção de dependências, redirecionamento de funcionalidades, entre outros;

4.6 Composite Application Guidance for WPF and Silverlight

Para facilitar a construção de aplicações de composição, a Microsoft aproveitou o WPF – Windows Presentation Foundation e lançou entre 2005 e 2006 uma série de bibliotecas chamadas Smart Client Composite UI Application Block, ou CAB – Composite Application Block. O pacote CAB permitia a construção de interfaces de composição através de uma biblioteca sobre o WPF, oferecendo uma série de patterns implementados para contemplar os principais desafios e exigências de uma interface de composição. A partir da experiência com as primeiras aplicações CAB, a Microsoft lançou em abril de 2008 o pacote Smart Client Software Factory – SCFS, uma fábrica de software (ou software factory) que permitia a geração automática de interfaces respeitando o modelo de composição. Relembrando, uma fábrica de software consiste de um guia de automação específico, que realiza a geração de código automático, a partir de templates previamento definidos (os chamados artefatos). Finalmente, como terceira geração de recursos para a construção de aplicações de composição, a Microsoft lançou em julho de 2008 o Composite Application Guidance for WPF and Silverlight versão 1.0, com uma atualização para a versão 2.0 em fevereiro de 2009.

O Composite Application Guidance for WPF and Silverlight (conhecida também pelo nome PRISM) é uma biblioteca de templates e patterns criada pelo time do patterns&practices, oferecida gratuitamente pela Microsoft para a construção de aplicações de composição. Assim como o pacote CAB, o Composite Application Guidance é uma biblioteca, não uma fábrica de software, oferecendo assim uma organização de templates e patterns que podemos utilizar para a construção de interfaces na camada de apresentação.

O pacote PRISM 2.0 oferece uma série de recursos para o desenvolvedor, além da própria Composite Application Library, como:

Uma implementação de referência (StockTraderRI);
9 Quick starts de exemplos, 26 guias e How-Tos para estudo de conceitos;
Vários documentos sobre patterns de interfaces e arquiteturas clientes.

A figura a seguir apresenta a tela da implementação de referência StockTraderRI, que é oferecida com o pacote PRISM 2.0 (de fevereiro de 2009), veja:

Figura 14 – Tela principal da implementação de referência StockTraderRI, do pacote PRISM 2.0.

Cada região da interface é implementada através de um módulo independente, o que oferece grande flexibilidade para o desenvolvimento simultâneo, assim como o atendimento dos principais requisitos de uma aplicação de composição.

Finalmente, aproveitando os recursos de renderização e representação de controles gráficos obtidos com o WPF – Windows Presentation Foundation e o XAML – eXtensible Application Markup Language, uma interface implementada com o PRISM também pode navegar entre um alvo desktop (em WPF) e um alvo de projeto Web, implementado sobre Silverlight 2.0.

Essa flexibilidade de compilação entre WPF e Silverlight é obtida através do desacoplamento dos módulos que implementam as funcionalidades e comportamentos de tela de nossa interface de composição. Como cada funcionalidade é um projeto de módulo independente, podemos criar uma nova interface principal (chamada Shell), compondo os mesmo módulos, seja para desktop ou para web. De fato, o PRISM 2.0 é um grande recurso da plataforma Microsoft para a construção de interfaces de composição e consumo de serviços.

5. Considerações finais

Software + Serviços é uma visão que envolve diversos aspectos de uma arquitetura baseada em serviços, assim como o poder de escolha entre software local e software remoto. Essa combinação entre níveis de operação diferenciados, assim como a integração entre infra-estruturas locais (on-premise) e remotas (off-premise) fornece um novo cenário de composição de recursos de TI para as empresas. Sem dúvida, alguns recursos de TI serão alvo de um processo de “comoditização”, tornando-se componentes “plugáveis” conforme as necessidades da empresa.

Como vimos ao longo do artigo, uma arquitetura software+serviço envolve aspectos de SOA, SAAS e CLOUD COMPUTING, temas que ganham crescente importância na definição de soluções hoje em dia. Para o consumo das funcionalidades de uma arquitetura S+S, aplicações de composição e recursos nativos do ambiente WEB2.0, como personalização, interfaces dinâmicas, navegação com usabilidade e riqueza de recursos adicionam funcionalidades para as aplicações S+S. Essa capacidade de compor de forma dinâmica, consumindo serviços de infra-estruturas também dinâmicas e provisionáveis, permite um cenário de TI mais aderente às necessidades de negócio. Vivemos um período de desafios econômicos, que ampliam o impacto de uma TI mais eficiente para os negócios, com a busca por redução de custos, uso eficiente de recursos, otimização de infra-estrutura e criação de novos produtos sobre a mesma solução.

Por isso, cabe ao arquiteto de soluções conhecer e acompanhar essas várias tendências, assim como ferramentas e pacotes que facilitam a implementação de cenários típicos de uma TI dinâmica.

6. Referências

[1] “The Long Tail”, por Chris Anderson, July 2006.

Ref.: http://pt.wikipedia.org/wiki/A_Cauda_Longa

[2] “Architecture Strategies for Catching the Long Tail”, por Frederick Chong and Gianpaolo Carraro, April 2006.

Ref.: https://msdn.microsoft.com/pt-br/library/aa479069.aspx

[3] “Toward a Unified Ontology of Cloud Computing”, por Lamia Youseff, Maria Butrico, Dilma Da Silva.

Ref.: http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf

[4] “Multi-Tenant Data Architecture”, por Frederick Chong, Gianpaolo Carraro, and Roger Wolter

Ref.: https://msdn.microsoft.com/pt-br/library/aa479086.aspx

[5] “Introducing The Azure Services Platform An Early Look At Windows Azure, .Net Services, Sql Services, And Live Services”, por David Chappell October 2008.

Ref.: http://www.davidchappell.com/writing/white_papers/Azure_Services_Platform_v1.0--Chappell.pdf

[6] “Introducing Windows Azure”, David Chappell, March 2008

Ref.: https://download.microsoft.com/download/2/9/3/293F671C-203F-4208-9CD1-195463F7BCBE/ApresentandoPlataformaAzure.pdf

[7] “Composite Application Guidance for WPF and Silverlight”, patterns&practices, Feb 2009.

Ref.: https://compositewpf.codeplex.com/

7. Agradecimentos

Obrigado aos arquitetos Otávio Coelho, Markus Christen e Luciano Condé, pelos comentários que ajudaram na conclusão desse artigo.

8. Sobre o Autor

Waldemir Cambiucci trabalha na Microsoft Brasil como arquiteto de soluções, com foco na comunidade de arquitetos e clientes corporativos. É graduado em Engenharia de Computação, mestre em Engenharia Elétrica e Pós-Graduado em Finanças e Administração. Com mais de 14 anos de experiência em TI, atua na Microsoft há 7 anos, tendo participado de projetos importantes no Brasil e no exterior. Possui as certificações MCP, MCDBA, MCSA, MCSD, MCAD, MCP BizTalk 2006 e MSF. Você pode encontrar maiores informações sobre os assuntos aqui tratados em seu blog: https://blogs.msdn.com/wcamb/.

Compartilhar via