Aprenda a disciplina,

busque a arte e contribua THE

com idéias no:
www.ArchitectureJournal.net
Recursos nos quais você
ARCHITECTURE
pode confiar.
JOURNAL
Idéias para melhores resultados
TM

Journal 13

Software + Serviços

O Barramento de Serviços
para a Internet

Perfil do Architecture Journal:

Ray Ozzie

Projeto Astoria

Implicações do Consumo
de Software + Serviços do
TI Corporativo

Mashups Corporativos

Microsoft Office como

Plataforma de
Software + Serviços

Um Planeta Regido por

Arquiteturas de Software
 THE
Sumário ARCHITECTURE
JOURNAL TM

Idéias para melhores resultados

Journal 13

Apresentação 1
por Simon Guest

O barramento de serviços para a Internet 2

por Donald F. Ferguson, Dennis Pilarinos, John Shewchuk
Conheça os aspectos arquiteturais da transmissão de mensagens pela Internet utilizando um barramento de serviços para
Internet.

Perfil do Architecture Journal: Ray Ozzie 9

Ray Ozzie é arquiteto-chefe de software da Microsoft. Nesta edição, Ray nos apresenta a sua visão para um mundo feito de
software + serviços e algumas de suas idéias ao tornar-se um arquiteto de software.

Projeto Astoria 12
por Pablo Castro
Astoria é uma nova tecnologia para a criação de serviços que expõem dados na web. Conheça os detalhes dessa nova
tecnologia que se desdobra em software e serviço.

Implicações do consumo de software + serviços do TI corporativo 18

por Kevin Sangwell
Saiba quais são os pensamentos e as recomendações para o consumo de serviços dos departamentos de TI corporativos.

Mashups corporativos 24
por Larry Clarkin e Josh Holmes
Os mashups não são apenas para usuários e consumidores finais. Veja como criar mashups quando a empresa possui várias
fontes de dados.

Microsoft Office como plataforma de software + serviços 29

por Chip Wilson e Alan Josephson
Como plataforma cliente, o Microsoft Office pode trabalhar bem com a visão software + serviços. Investigue como isso tem
sido feito por meio de um conjunto de exemplos do mundo real.

Um planeta regido por arquiteturas de software 34

por Gianpaolo Carraro
Junte-se a nós para um tour por Architectopia, mundo no qual diferentes paradigmas de computação definem
as civilizações.

Recursos nos quais você pode confiar. www.architecturejournal.net

Fundador
Arvindra Sehmi
Microsoft Corporation
Editor-chefe
Simon Guest
Microsoft Corporation
Apresentação
Conselho Editorial Microsoft
Gianpaolo Carraro
John deVadoss
Neil Hutson
Eugenio Pace
Javed Sikander
Philip Teale Caro Arquiteto,
Tim O'Brien
Editor
Lisa Slouffman
Microsoft Corporation C omo arquitetos de software, muitas vezes nos defrontamos com decisões
tecnológicas bem no início do processo de desenvolvimento. Cliente gordo ou
magro? Computador portátil ou de mesa? Instalação local ou aplicativo web? Em lugar de
Design, impressão e distribuição
escolher uma opção "ou" outra, como seria se pudéssemos escolher algo usando "e"? Por
CMP Technology – Editora que nossas escolhas têm de ser forçadas a usar uma determinada tecnologia quando a
Chris Harding, diretor administrativo melhor solução é, quase sempre, um mix de duas? Este é o conceito que serve de base ao
Angela Duarte, gerente de publicação tema desta edição do The Architecture Journal: software + serviços.
Lisa Broscritto, gerente de projeto
Kellie Ferris, diretor corporativo de A organização dos artigos desta edição explora uma nova visão de software + serviços,
serviços criativos conforme exposto por Ray Ozzie, arquiteto-chefe da Microsoft, em seu discurso na MIX
Jimmy Pizzo, diretor de produção 07 deste ano.

Diagramação, finalização e impressão (BR)
Arthéria Comunicação & Multimídia
www.artheria.com.br
®
As informações contidas neste The Architecture Journal (“Jornal”)
têm finalidade informativa, apenas. As matérias do Jornal não
constituem a opinião da Microsoft Corporation (“Microsoft”) nem
da CMP Media LLC ("CMP") e, tampouco, são recomendações da
Microsoft ou da CMP; assim sendo, você não deve confiar em
nenhuma das matérias deste Jornal sem solicitar o aval de um
consultor independente. A Microsoft e a CMP não fazem
declarações nem oferecem garantias quanto à exatidão ou
adequação para determinada finalidade de qualquer matéria deste
Jornal e, em nenhuma circunstância, nem a Microsoft, nem a CMP
aceitará responsabilidade de qualquer tipo, inclusive
responsabilidade por negligência (salvo em caso de danos físicos
ou morte) com relação a quaisquer tipos de perdas ou danos
(incluindo, mas não se limitando, aos casos de perda de negócios,
de receita, de lucros ou prejuízo imprevisto) resultantes do uso das
informações deste Jornal. O Jornal pode ter imprecisões técnicas e
erros tipográficos. O Jornal pode ser atualizado periodicamente e,
às vezes, poderá estar desatualizado. A Microsoft e a CMP não se
responsabilizam pela atualização das informações deste Jornal
nem por deixar de fazê-lo. Este Jornal contém matérias
encaminhadas e criadas por terceiros. Até o máximo permitido
pela lei aplicável, a Microsoft e a CMP isentam-se de todas as
responsabilidades por qualquer ilegalidade decorrente de erro,
omissão ou imprecisão deste Jornal ; além disso, a Microsoft e a
CMP não se responsabilizam pelas matérias recebidas de terceiros.
As marcas comerciais a seguir são marcas comerciais registradas
da Microsoft Corporation: BizTalk, Microsoft, SharePoint, SQL
Server, Visual Studio, Windows, Windows NT e Windows Server.
Quaisquer outras marcas comerciais são de propriedade de seus
respectivos proprietários.
Todos os direitos autorais e outros direitos de propriedade
intelectual das matérias publicadas no Jornal pertencem à
Microsoft Corporation ou estão a ela licenciados. Copiar,
reproduzir, transmitir, armazenar, adaptar ou modificar o layout ou
o conteúdo deste Jornal são ações proibidas, a não ser que haja
autorização prévia, por escrito, da Microsoft Corporation e de cada
um dos seus autores.
Copyright © 2007 Microsoft Corporation. Todos os direitos
reservados.
Iniciamos esta edição com Don Ferguson, cujo perfil foi o destaque do Jornal 11, lembra-
se? Don compartilha suas idéias sobre os aspectos arquiteturais de como transmitir
mensagens pela Internet por meio de um barramento de serviços para a Internet ou ISB
(Internet Service Bus).
Depois do artigo do Don, e como parte de nossa série Perfil do Architecture Journal, é
com grande entusiasmo que compartilhamos uma entrevista com o próprio Ray Ozzie.
Nesta entrevista, Ray nos revela alguns dos detalhes da visão software + serviços e o que
representa ser arquiteto-chefe de software da Microsoft.
Depois da entrevista com Ray, Pablo Castro nos oferece uma síntese técnica do Projeto
Astoria. Astoria é um novo serviço que expõe dados para clientes da web no âmbito de
uma rede corporativa e pela Internet. Kevin Sangwell vem a seguir, com suas idéias sobre
as implicações do consumo de serviços pelo
TI corporativo e, este texto nos leva
diretamente a um artigo sobre mashups na
empresa, escrito por Larry Clarkin e Josh
Holmes.
Para fechar esta edição, Chip Wilson e Alan
Josephson investigam o uso do Microsoft
Office como plataforma para software +
serviços. Finalmente, temos a divertida
analogia escrita por Gianpaolo Carraro que
nos faz esta pergunta: E se a arquitetura
fosse um planeta? Nesse texto, Gianpaolo analisa uma perspectiva interna para revelar
mais sobre os benefícios de se utilizar o software + serviços.
Aqui no The Architecture Journal, gostamos de "praticar o que pregamos”. Para tanto,
temos prazer em anunciar uma nova experiência offline do Jornal, denominada "Journal
Reader" (Leitor do jornal).
Demonstrando muitos dos princípios destacados nesta edição, este novo leitor é um
aplicativo instalado localmente que possibilita transformar cada edição do Jornal em uma
experiência fácil de ler, imersiva, com pesquisa integrada. O aplicativo faz a sincronização
com nossos serviços de gerenciamento de conteúdo e, assim, será possível ter acesso
automático às mais recentes edições do Jornal, sem necessidade de fazer o download de
arquivos PDF ou ler online.
Recebemos grande volume de feedback dos leitores sobre como o jornal é lido e
esperamos que este novo serviço ofereça uma forma de leitura exclusiva e útil. Já no
início de novembro, você poderá fazer o download do leitor e obter mais detalhes em
nosso website: http://www.architecturejournal.net.
Simon Guest

THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net 1

 O Barramento de Serviços
para a Internet
por Donald F. Ferguson, Dennis Pilarinos, John Shewchuk
Resumo
Os aplicativos web têm como base um modelo
extremamente comum e eles se tornarão cada vez mais
dominantes. Praticamente todos os aplicativos para empresas
de médio a grande portes oferecem uma IU de web. Neste
artigo, empregaremos o termo empresa para englobar
negócios de médio a grande portes, o fornecedor de
software e as empresas integradoras. Aplicativos para
desktop e cliente/servidor cada vez mais usam o navegador
para o mecanismo da IU e fazem chamadas para obter
dados e serviços pelos protocolos web.
Software, modelos de aplicativos e a própria web estão
passando por uma transformação revolucionária. O efeito
dessa transformação será tão grande para a computação
como foi o modelo cliente/servidor ou o surgimento inicial
da web. A web evoluirá da função de conectar usuários aos
aplicativos fornecidos por sites para um modelo em que:
"
o aplicativo é executado "na web";
"
os usuários finais desenvolvem os próprios aplicativos para acessar a
web, transformando-a em um espaço de trabalho desenvolvido pelo
usuário final para acesso aos Web Services.
Este artigo tem como enfoque um pequeno número de
elementos dessa transformação. Outros artigos ampliarão a
visão.
V árias tecnologias e tendências oferecem a força propulsora para a
transformação revolucionária descrita acima. Alguns exemplos são:
processadores de vários núcleos; virtualização; cenários de aplicativos
que fazem a federação de muitos dispositivos como celulares e mesas
digitalizadoras; arquitetura orientada a serviço (SOA) e Web Services;
Web 2.0; e software como serviço (SaaS).
Discutiremos o efeito de algumas dessas tendências, mas nossos
principais enfoques são SOA, Web 2.0 e SaaS. Esses conceitos e as
respectivas relações ainda não estão bem compreendidos. As
tecnologias freqüentemente parecem ser antagônicas. O artigo
descreve os elementos de uma arquitetura de referência de alto nível
que reúne os conceitos em um todo consistente.
Muitas das tendências tecnológicas precedentes são completamente
conhecidas e aceitas. Este artigo discute uma terceira tendência, mais
controversa: a capacidade de programação universal. Grande parte de
graduados do nível médio e das universidades possuem qualificações
de programação básica quando passam a integrar a força de trabalho;
muitos alunos já desenvolveram aplicativos PHP ou Visual Basic simples
2 THE ARCHITECTURE JOURNAL
e construíram websites. As responsabilidades básicas do cargo dos
profissionais talvez nem inclua programação, mas em muitos casos eles
criarão programações simples se isso aumentar a sua produtividade.
Também podem desenvolver aplicativos simples só por que é legal.
Para este conceito, utilizaremos a expressão programação feita pelo
usuário final.
A programação feita pelo usuário final é um caso extremo de
desenvolvimento oportunista, que ocorre em departamentos e linhas de
negócio (LOBs) nas empresas. As LOBs e as equipes quase sempre
desenvolvem aplicativos SharePoint ou PHP simples, de modo "rápido e
sujo", que resolvem um problema imediato do negócio, ampliando os
aplicativos comerciais ou aqueles de base usados por toda a empresa.
O desenvolvimento oportunista é o oposto do desenvolvimento
sistemático. O desenvolvimento sistemático é dirigido a modelo, cheio
de exigências de coleta, casos de uso e entrevistas com as partes
interessadas, um ciclo de vida do desenvolvimento do aplicativo que
inclui qualidade, garantia, etc. O desenvolvimento sistemático é o
modelo predominante da equipe de desenvolvimento corporativo
("equipe CIO"). Muitos programadores de aplicativos comerciais (ISVs ou
fornecedores de software independentes) e integradores de sistemas
(SIs) também produzem soluções sistemáticas.
Existe uma tensão nas empresas entre os desenvolvimentos oportunista
e sistemático. Essa tensão aumentará se a programação feita pelo
usuário final vier a ser comum. Os usuários finais não se contentarão
em esperar pelas equipes de desenvolvimento sistemático para
desenvolver ou modificar soluções. A arquitetura de referência que
descrevemos oferece uma abordagem para reconciliar os extremos dos
desenvolvimentos oportunista e sistemático.
Usamos um cenário para ilustrar a arquitetura de referência. Um
elemento básico que surge e serve de base para a arquitetura é um
barramento de serviços para a Internet ou ISB. A arquitetura de
referência abrange muitos elementos; contudo, este artigo detalha
apenas o ISB. Outros artigos descreverão outros elementos.
O cenário e os desenvolvimentos oportunista e sistemático
Dave viaja muito a negócio e utiliza os serviços de hotéis e empresas
aéreas preferenciais. Aluga carros nas locadoras das cidades que visita e
faz reservas em restaurantes. A colaboração com amigos, família e
colegas também é importante. Dave utiliza vários websites de agências
de viagem para elaborar e modificar planos de viagens.
Administrar as viagens do Dave envolve muitas tarefas manuais para
interagir com as agências de viagens por meio dos respectivos websites.
Ele precisa coordenar tarefas manualmente em vários sites e
copiar/colar dados entre campos. Existe também alguma lógica
seqüencial, por exemplo, fazer reserva em um restaurante e alugar um
carro para chegar até o restaurante. As atitudes de Dave são
• Journal 13 • www.architecturejournal.net

similares a um aplicativo composto ou solução de integração de
aplicativo corporativo (EAI - Enterprise Application Integration). O
trabalho manual é entediante e passível de erros. Dave conhece
programação básica e decide escrever um pequeno mashup. O mashup
usa os websites das agências de viagens por meio de um script de
página web do lado do cliente ou clipping de HTML simples (Figura
1(a)). O mashup facilita a vida do Dave, acrescentando produtividade ao
seu trabalho, pois o tempo que economizará na administração de suas
viagens poderá usar no seu trabalho. O mashup também é legal e isso
impressiona seus amigos.
Mary e Ludwig gostam do aplicativo e Dave lhes oferece o código.
Desejam uma IU diferente, mas compartilham o código. Assim sendo,
aprimoram o aplicativo separando a IU do acesso ao website,
scripting, fazendo o cache pela implementação de uma versão simples
de modelo-visão-controlador (Figura 1(b)). Este aprimoramento
também permite a reutilização do código para acesso por meio de
outros dispositivos como PDAs ou celulares (Figura 1(c)). Por fim,
decidem deslocar a camada do modelo para um servidor web de
departamento e implementam um aplicativo web simples. Esse
procedimento permitirá que várias pessoas tenham acesso às
informações, por exemplo, os assistentes.
Os amigos construíram nessa oportunidade um aplicativo composto:
uma simples solução pseudo-EAI. Na medida em que programadores
qualificados são admitidos para integrar a força de trabalho, esses
aplicativos específicos e ocasionais serão cada vez mais comuns. Existe
o aspecto "legal" que dá destaque aos criadores e os aplicativos
simplificarão as tarefas entediantes. Os profissionais também podem
construir aplicativos ocasionais para problemas de curta duração do
negócio como uma convenção. Os aplicativos desempenham funções
análogas às das planilhas, quando o usuário executa uma tarefa do
negócio e acessa bancos de dados e aplicativos de base existentes.
Aplicativos de situação oportunista terão efeito profundo sobre a
distribuição sistemática dos aplicativos corporativos. Um efeito
acontecerá sobre o desenvolvimento do aplicativo corporativo. Os
aplicativos de situação podem "forçar" os aplicativos corporativos
básicos ou utilizá-los de modos inesperados. Isso fará com que a
organização de TI transfira algumas das "camadas de modelo" para os
servidores corporativos, para aprimorar o desempenho e a
integridade. Resumindo: os aplicativos de situação têm casos de uso
definidos que podem conduzir a transformação sistemática do
aplicativo corporativo. Os aplicativos de situação podem substituir
modelos simples para documentar casos de uso e orientar a
modelagem formal.
Muitas pressões tratarão de transferir os aplicativos de situação, tanto
quanto possível, para os servidores corporativos. Poderá haver
Figura 1: Evolução do mashup
A com ordens de compra e aprovação de contas de
C despesas, por exemplo. O cenário é um exemplo
D restaurante, a locadora e outros sistemas
B
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
O Barramento de Serviços para a Internet
parceiros que precisam usar o aplicativo e isso exige a segurança da
empresa. Alguns aplicativos podem fazer parte de importantes
decisões do negócio, como a aprovação de empréstimos. Governança
e conformidade exigirão acesso e entrada de dados de registro, assim
como gravar as versões do código desses aplicativos. Transferir os
aplicativos de situação para a central de dados traz implicações
profundas. As centrais de dados precisarão dar suporte a centenas ou
milhares de aplicativos que mudam constantemente, além das
soluções básicas do negócio. A central de dados precisa administrar
dezenas de servidores de aplicativos básicos supercarregados,
acessados por milhares de usuários e milhares de servidores virtuais
raramente acessados por equipes pequenas que usam aplicativos
específicos.
Existem muitos cenários em que as soluções sistemáticas consomem
aplicativos oportunistas. O Dave achará bem legal se o departamento
de TI utilizar um de seus aplicativos.
Em resumo, os aplicativos oportunistas incentivam as soluções
sistemáticas e estas solidificam os aplicativos oportunistas (como o
Representational State Transfer (REST) -> Web Services). Essas
dinâmicas também movimentam o software como serviço ou mais
precisamente, software + serviços. O conceito de software + serviços
oferece uma plataforma que une os desenvolvimentos de aplicativos
sistemático e oportunista com a distribuição.
Software + serviços, e um barramento de serviços para a
Internet
Barramento de serviço corporativo
Imagine o que acontece se a empresa aérea cancela o vôo de conexão
do Dave, no trecho Dallas-São Francisco, enquanto ele faz o trecho
Nova York-Dallas. Dave não conseguirá chegar em São Francisco e
precisará passar a noite na cidade do aeroporto de conexão. Será
preciso alterar todas as reservas: hotel, aluguel de carro e restaurante.
Dave poderia usar o seu mashup para simplificar essas mudanças
quando desembarcar. Seria ainda melhor ("mais legal") se fosse
possível refazer a reserva automaticamente, durante o vôo. As
empresas aéreas e os sites que monitoram vôos emitem “feeds” com
atualizações dos horários de vôo. De modo ideal, o aplicativo do Dave
estaria sempre sendo executado em algum lugar "da nuvem". O
aplicativo faria a monitoração dos “feeds” e usaria lógica simples para
reagir a eventos e modificar o itinerários e os planos.
Não é provável que um simples aplicativo de usuário final pudesse
sempre ajustar o itinerário, mas a maioria dos ajustes é, muitas vezes,
bastante simples. Dave só teria de interferir manualmente nos casos
complexos e poderia, também, aprovar as alterações feitas
automaticamente pelo seu aplicativo durante o vôo.
O cenário geral do aplicativo para ajustar o
itinerário é um tipo de problema comum nas
empresas. Problemas similares podem acontecer
de aplicativo composto que implementa um
padrão de processamento direto (STP - Straight-
Through-Processing) (vide Referências). As
empresas implementam uma abordagem
sistemática para resolver esses problemas. A
Figura 2 oferece uma visão geral de como seria o
aplicativo composto se a empresa aérea, o hotel,
3
 O Barramento de Serviços para a Internet

3. Os aplicativos das empresas aéreas e dos hotéis são externos à

Figura 2: Um processo corporativo do negócio
Feed
Serv
Converte Inf
Autos
Recebe Filtra
Converte Cancela
Mensagem C RPC
SQL
sobre MQ COBOL
Vôos Itinerário Hotéis
estivessem no âmbito do firewall corporativo. Um processo de
orquestração de execução relativamente longa inscreve-se em eventos
que o sistema de gerenciamento de vôo emite. O processo envia
mensagens de/para e chama os aplicativos existentes para cancelar
reservas, consultar disponibilidades e fazer novas reservas. As empresas
são heterogêneas e os aplicativos existentes possuem diversos
formatos de mensagens (C, COBOL etc.) e de protocolos de
comunicação (WebSphere MQ, SAP RFC, por exemplo).
O projeto do processo de ajuste apresentado na figura 2 é frágil. O
processo do negócio deve modificar se, por exemplo, outro aplicativo
de empresa aérea tiver sido adicionado. O processo do negócio
também pode ser acoplado a formatos e linguagens de mensagem
específicos dos aplicativos existentes. Seria difícil adicionar um
mecanismo geral para o registro de mensagens que correspondesse a
determinadas condições, por exemplo, registro de todas as mensagens
se o viajante for um executivo. Essa fragilidade levou as arquiteturas de
aplicativos corporativos a evoluírem para um barramento de serviço
corporativo (ESB - Enterprise Service Bus).
A Figura 3 oferece uma visão geral de um barramento de serviço
corporativo. Os adaptadores de aplicativos convertem formatos e
protocolos existentes em Web Services padrão. Isso transforma o
problema do mapeamento de protocolo/formato N N para conectar
uma coisa à outra em um problema de mapeamento N 1, ou seja,
tudo dentro de um padrão. O ESB oferece funções adicionais que
processam o fluxo de mensagens entre serviços. Exemplos incluem
conversão, registro e roteamento das mensagens.
Se a área de desenvolvimento corporativo e as unidades de negócio
empresa. As empresas são bastante ponderadas e cautelosas
quanto a estabelecer conexões B2B. Ainda que o parceiro de
negócios implemente Web Services, a empresa precisará definir
regras de autorização e auditoria para interações de Web Services
com os parceiros. A empresa precisará ter suporte para
gerenciamento, federação e provisionamento de identidades de
Nova
reserva Sucesso usuário pois os funcionários terão uma identidade na empresa e
hotel
outras nas empresas aéreas e hotéis.
Nova
reserva
hotel
Sucesso 4. A personalização da solução para aceitar preferências dos
funcionários é complexa. Ao funcionário falta habilidade para fazer
a personalização "faço eu mesmo". O aplicativo reside em
servidores corporativos centralizados. Os profissionais de TI
RFC SAP
definem e modificam o processo do negócio, não o Dave.
Seria de fato muito legal se o Dave pudesse criar uma versão simples e
pessoal da solução sistemática. Se generalizarmos o ESB e o
considerarmos um tipo de barramento de serviço otimizado para o
Locadora
desenvolvimento empresarial sistemático, poderíamos também
imaginar um tipo de barramento de serviço otimizado para
desenvolvimento oportunista. Este é o barramento de serviços para a
Internet (ISB). O ISB parece mais com um tecido universal. O ISB faz a
ligação dos dispositivos entre si, dispositivos e servidores locais, entre
websites e ESBs e é, em si, um ESB. O ISB é uma plataforma para
aplicativos compostos e processos do negócio do tipo "faça você
mesmo". O ISB é também um exemplo de software como serviço
(Saas).
Barramento de serviço de Internet
A Figura 4 oferece uma visão geral do conceito de barramento de
serviços para a Internet. (O BizTalkServices é um dos primeiros
exemplos de ISB; vide Referências.) Um provedor ISB é análogo a uma
empresa que hospeda websites PHP. Ambos fornecem uma plataforma
de aplicativos na "nuvem". Um site que hospeda web PHP fornece
basicamente uma plataforma para o desenvolvimento de websites
dinâmicos e Web Services que interagem com um banco de dados.
Por outro lado, o ISB fornece uma plataforma para criação e
implantação de aplicativos compostos que integram serviços
Figura3: Um barramento de serviço corporativo
Feed
Serv
Converte Inf
Autos
Recebe Filtra
Nova
Converte Cancela reserva Sucesso
hotel

da empresa do Dave tivessem decidido que a implementação do Nova

aplicativo de viagem construído por ele era bastante importante para reserva Sucesso
hotel
ser capitalizado, a equipe corporativa poderia implementar um
aplicativo similar àquele da Figura 3. O desenvolvimento dessa solução
sistemática apresenta vários problemas:
Mapeia Routeia
1. Não há garantia de que a empresa resolveria investir no
SQL SNA RFC SAP
aplicativo composto. Pode haver outros problemas mais PL/1
prioritários para o negócio.
2. O desenvolvimento sistemático envolve casos de uso, algum
tipo de modelagem de processo e entrevistar os participantes.
Tudo isso leva tempo. Vôos Itinerário Hotéis Locadora Locadora

4 THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net


Figura 4: Um barramento de serviços para a internet
Serviços de
Conectividade Workflow
Identidade
fornecidos por outros sites. ISBs, empresas que hospedam web PHP e
armazenamento como serviço, tipo S3 da Amazon, são exemplos de
infra-estrutura de implementação de aplicativo de SaaS. Isso contrasta
com Salesforce.com o qual, de início, era aplicativo SaaS comercial.
O conceito básico do ISB está construído ao redor do espaço URI
(Uniform Resource Identifier). A equipe de Dave que trabalha no
aplicativo registra e é "proprietária" do site URI
O ISB oferece uma função de identidade e acesso para controlar quais
http://ISB.net/DaveAndTeam. URIs abaixo dessa raiz representam
pontos de integração do aplicativo e são similares a destinos nas filas
do Java Messaging Service em middleware orientado a mensagem ou
tópicos em sistemas com o padrão publicação/assinatura. A equipe
desenvolve um aplicativo ISB pela associação de diretiva e função com
URIs. O aplicativo composto é um conjunto de URIs, diretivas e
funções.
O ISB oferece uma função de identidade e acesso para controlar quais
mensagens podem ser enviadas a um URI e por quem. A função de
identidade e acesso é um exemplo de associação de diretiva com um
URI.
Como exemplo, Dave poderia escolher manter uma página wiki em
um website público que mostrasse suas reservas de viagens. Ele
desejará controlar o acesso à página wiki. Configurar e atualizar
bancos de dados de autenticações e autorizações em seu website
pessoal pode ser entediante. O problema ficará mais complexo se
Dave tiver páginas e dados em vários websites, por exemplo:
Figura 5: Processamento de mensagem ISB
XML HTML
E-mail
"LE-"
XML
"OL"
Cancela
HTTP POST
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
O Barramento de Serviços para a Internet
"
seu site PHP pessoal dirigido a banco de dados;
"
portal de colaboração familiar por meio do http://www.twiki.org/;
"
presença em espaços como no Windows Live Spaces (http://home.
services.spaces.live.com/).
Don, amigo do Dave, pode inscrever-se com o componente de
identidade do ISB e criar uma ID de usuário don@foo.bar. Dave pode
usar a IU web do componente da identidade para especificar quais
URIs ISB podem ser acessadas pelo Don. Dave também pode definir
grupos e conceder acesso aos grupos. Don pode ter acesso aos URIs
depois de estar conectado no ISB. O ISB simplifica o gerenciamento de
segurança do Dave porque ele pode manter um banco de dados
centralizado e, depois, autorizar o "ISB" a acessar sua página wiki e
outros recursos. O ISB protege os recursos atuais por meio do controle
de acesso dos URIs ISB que os antecedem. O ISB tem como benefício
um único espaço para que Dave defina e atualize identidades, grupos,
recursos e diretivas de acesso para todos os seus "serviços" na web.
Acabamos de descrever ações explícitas de usuário por meio de
páginas da web. Outra abordagem bastante comum será a de ter
aplicativos nas extremidades que participem das APIs de Web Services
que utilizam o aplicativo composto para ter acesso ao ISB.
O componente da identidade também dará suporte às funções do STS
(Security Token Service) do WS-Security, e fará a federação com outros
STSs. Isso permite ao Dave gerenciar o acesso a identidades não
registradas no ISB. Se foo.bar fosse uma empresa em que Dave confia
e se esta implementar um STS, Dave poderá definir diretivas de acesso
para identidades autenticadas em foo.bar.
Com o tempo, os ISBs oferecerão outras diretivas e implementações
que podem ser aplicadas aos URIs. Os exemplos podem incluir WS-
ReliableMessaging (troca confiável de mensagens em Web Services) ou
registro implícito de mensagens. O conceito é similar à associação de
diretivas de qualidade de serviço com conexões em middleware
orientado a mensagem.
O ISB aproveita as capacidades de identidade e acesso para fornecer
"conectividade universal segura" aos aplicativos – mesmo para aqueles
protegidos por firewalls. Isso inclui suporte para ampla gama de
padrões e protocolos de conectividade. Entre os exemplos incluem-se
HTTP orientado a REST, WS-* e padrões dirigidos a evento
encontrados em muitos aplicativos corporativos. Especificamente, o
componente de conectividade do ISB oferece três funções básicas:
1. Transmissão: possibilita a comunicação entre o ISB e os
aplicativos protegidos por firewalls. Existem muitas técnicas para
realizar esta capacidade (BizTalk Labs, vide Referências). A função
de transmissão elimina a necessidade de configurar conexões
sistemáticas em toda a empresa para cenários simples.
2. Protocolo: oferece um conjunto de protocolos comuns para a
troca de mensagens, como WS-* ou REST. O ISB também fornece
mapeamento de protocolo para conexão automática de
extremidades utilizando protocolos diferentes. Por exemplo, é
possível conectar um “feed” RSS a uma conexão de mensagens
WS-*, sem necessidade de modificar nenhum dos aplicativos.
3. Funções: oferecem suporte para associar funções simples tipo
ESB ao URL. Entre os exemplos seria possível incluir distribuição
múltipla (multicast), WS-Eventing (eventos de Web Services), troca
de mensagens persistentes, etc.
5
 O Barramento de Serviços para a Internet
A camada de conectividade opera no nível da infra-estrutura de
tecnologia. Simplifica o desenvolvimento da solução removendo a
complexidade graças a vários "encanamentos", por exemplo, REST vs
WS-*. Os projetos que devem implementar a integração da infra-
estrutura neste nível incorrem em custo e risco significativos. O ISB
elimina esses problemas.
A camada de conectividade desconhece os elementos no nível do
aplicativo e os formatos das mensagens. A construção de um
aplicativo composto exige adaptação entre formatos diferentes de
mensagens implementados pelos serviços conectados. Um exemplo
das funções do ISB poderia ser a conversão de parâmetros de um
comando HTTP GET em elementos de uma mensagem XML. O ISB
oferece um workflow simples (coreografia do serviço) que fornece
suporte para mapeamento no nível do aplicativo (Figura 5).
O ISB oferece um conjunto de "atividades-modelo" para funções
simples. Um workflow é um gráfico composto de modelos de atividade
de instanciação. Suponha que a empresa aérea emita status de vôos por
meio de um feed RSS e parte do aplicativo do Dave espera receber
notificações das atualizações pelo WS-Eventing. A camada de
conectividade é compatível com a integração de RSS e WS-*. Ainda é
necessário converter a carga da mensagem do formato RSS para o
formato de evento XML esperado pelo aplicativo do Dave. Em geral, o
ISB oferecerá um modelo de atividade configurável e reutilizável para o
mapeamento RSS para XML.
Outro modelo de atividade comum será o roteamento baseado em
seleção. O aplicativo do Dave pode emitir uma mensagem de
cancelamento: cancel car reservation ID=1234. Se os códigos de reserva
de uma locadora de autos começam com "LE-" e os de outra com "OL",
o aplicativo do Dave pode enviar eventos de cancelamento para um
único URI ISB. A seguir, o seletor processa a mensagem roteando-a para
a extremidade correta.
Combinar atividades de processamentos de mensagens mais
complexos pode ser útil e será uma função comum dos ISBs. Como
exemplo, a Figura 6 apresenta as atividades do URL que Dave define
para recebimento da mensagem de cancelamento da reserva do carro:
1. Recebe a mensagem de cancelamento em XML utilizando WS-*.
2. Possui uma atividade que extrai o elemento de ID da reserva e
consulta o prefixo em uma tabela.
Figura 6: Processamento de mensagem ISB
Feed
Serv
Converte Inf.
Autos
Recebe Filtra
Nova
Converte Cancela reserva
hotel
Nova
reserva
hotel
6 THE ARCHITECTURE JOURNAL
3. Converte a mensagem para o formato esperado pela locadora,
ou seja:
a) e-mail em HTML para um provedor
b) HTTP POST para o segundo provedor
Construir funções para processamento de mensagens pode ser
bastante simples. Muitos dos cenários de aplicativos comuns são
instanciações simples de padrões e modelos. Um provedor de ISB
oferecerá uma simples ferramenta de desenvolvimento de aplicativo
baseada em web que permite aos programadores selecionar modelos
de atividade e definir parâmetros de configuração por meio de um
formulário web. No caso do roteamento, o formulário web permitiria
ao programador especificar o campo da mensagem para roteamento e
os valores da respectiva tabela. Com o tempo, os ISBs oferecerão
ferramentas mais poderosas, como as ferramentas de processamento
de mensagens do BizTalk. O processamento de mensagens
(roteamento, conversão, etc.) é suficientemente robusto para muitos
cenários de aplicativos. Contudo, para outros cenários, é preciso ter
seqüenciamento simples e fluxo de controle. Imagine a tarefa de fazer
uma reserva de hotel em Dallas quando Dave estiver atrasado. Uma
descrição simples do processo poderia ser:
“SOFTWARE COMO SERVIÇO" TOTAL É UM MITO.
TODAS AS SOLUÇÕES SAAS REPRESENTATIVAS
INCLUIRÃO, EM ALGUM MOMENTO, UM ITEM DE
SOFTWARE INSTALADO NO LOCAL: UM HÍBRIDO.
QUASE TODOS OS CENÁRIOS QUE UTILIZAM ISB
E SAAS SÃO, NA VERDADE, HÍBRIDOS DE
SOFTWARE INSTALADOS NO LOCAL E
EXTERNAMENTE. SOFTWARE + SERVIÇOS É O
TERMO PARA O MODELO HÍBRIDO".
1. Enviar um pedido de reserva para a cadeia de hotel AAA
2. Receber uma resposta.
3. Se bem-sucedido, sair
4. Enviar um pedido de reserva para a cadeia de hotel BBB
5. Se bem-sucedido … …
As atividades de workflow ampliam o processamento de
mensagens com modelos de atividades de fluxo de controle
como while, if ... then …, etc. Os ISBs acrescentarão suporte,
por incrementos, para workflow simples para ampliar o
processamento básico de mensagens.
O workflow pode parecer um conceito complexo e as
soluções corporativas de workflow sistemático são robustas
e complexas. Por outro lado, os workflows para aplicativos
específicos e oportunistas, em sua maioria, são
extremamente simples. A estrutura não é significativamente
Sucesso mais complexa do que diagramas simples do PowerPoint.
Existe uma pequena coleção de figuras para conexões e
formatos para que o programador defina propriedades aos
formatos, expressando o comportamento da atividade
Sucesso
Muitos dos processos de workflow tendem a ter a estrutura
de uma lista aninhada. Isso permite que ferramentas
simples possam construir os XSD simples pode fornecer a
estrutura para documentos XML que definem um workflow
• Journal 13 • www.architecturejournal.net
 O Barramento de Serviços para a Internet

Se a empresa reutilizar o aplicativo específico para várias

Figura 7: Um ecossistema e modelo do negócio
conferências, uma solução sistemática poderá emergir da
solução oportunista. A solução oportunista proporciona um
Modelos
conjunto concreto de casos de uso para a solução sistemática.
Instanciar
Fornecedores de Também pode fornecer métricas para determinar quais
software aspectos do aplicativo são utilizados com mais freqüência.
Integradores
Comunidades Feed

Transform
Inform
Car
Terceiros farão a conexão de serviços de valor agregado ao
Service
Feed

Feed

Inform
Receive

Receive
Filter

Transform
Filter
Transform

Feed
Cancel
Inform
Car
Service
New
Hotel
Reservation
Success
ISB. O primeiro tipo serão os serviços de infra-estrutura como
Transform Car Inform
Service New
Transform New
Car

um mecanismo de workflow mais robusto ou um banco de

Transform CancelHotel Hotel
Succes
Service s Success
Reservation Reservation
Receive Filter
Receive Filter
New
New Hotel Success
Transform Cancel Hotel Success Reservation New
Reservation Transform Cancel Hotel Success
Reservation

dados em XML com consulta integrada. Os programadores

New
Hotel Success New
Reservation Hotel Success
Reservation

podem incluir esses serviços em suas soluções conectando-os

Barramento de serviços para Internet
S1
de lista aninhada. Uma ferramenta visual permite ao programador
especificar as atividades e seus implementos ou conexões com serviços
externos. Muitos programadores conhecem esse modelo pois os
frameworks de IU da web quase sempre fornecem um conceito similar
para fluxos e transições de páginas (Struts, por exemplo).
Quase sempre, as soluções sistemáticas de workflow são complexas
porque são de missão crítica e dão suporte a aplicativos utilizados por
milhares de pessoas. A modelagem e o mecanismo do processo devem
ter condições de expressar todas as funções do processo e administrar
condições de erro mais complexas, aprovações, etc. Em contraposição,
para soluções mais oportunistas e específicas, um pequeno grupo de
pessoas usa o workflow e a equipe está constantemente estudando suas
possibilidades para aprimorá-las.
Objetivos de nível de serviço
aos URIs dos seus aplicativos. Esses serviços de infra-estrutura
são um exemplo de como terceiros podem fazer parte do
... ecossistema fornecendo infra-estrutura avançada como
S2 S3 S3 serviço.
... O segundo tipo serão os serviços reutilizáveis do negócio, por
exemplo, um serviço pré-construído para atualização das
informações e catálogos de produto. Outro exemplo poderia
ser a programação da sala de conferências para convenções. Como,
por exemplo, um terceiro que passa a fazer parte do ecossistema pela
adição de um serviço de "bloco de construção" de aplicativo. O
aplicativo composto do ISB pode usar o bloco de construção
conectando um URI do aplicativo composto ao bloco de construção.
Por fim, os integradores do sistema e os fornecedores de soluções
oferecerão produtos configuráveis e extensíveis como modelos. Um
terceiro pode oferecer uma solução configurável que dá suporte a
muitas funções de gerenciamento de conferências/convenções. Um
fornecedor de aplicativo comercial pode oferecer a vantagem do "teste
e compre". Em lugar de entregar um CD que exige instalação do
aplicativo e pré-requisitos, o provável cliente pode simplesmente
instanciar uma versão na "nuvem".

Empresas que implantam aplicativos no ISB desejarão definir contratos A comunidade é um importante aspecto da Web 2.0. Pode ser, na
de nível de serviço (SLAs) especificando tempo de resposta, taxa de verdade, o aspecto mais importante. Os serviços de infra-estrutura,
transferência, disponibilidade, etc. O SLA determinará o custo cobrado blocos básicos de construção de aplicativos e modelos de solução
pelo provedor de ISB. O problema geral de se executar SLAs para também surgirão em meio a uma comunidade associada com ISBs,
aplicativos arbitrários é enorme. Contudo a tarefa do ISB é mais que oferece e compartilha código. A comunidade também
simples, pois não implanta código de usuário arbitrário. Instanciar e proporciona um fórum de suporte de auto-atendimento e estabelece
configurar modelos pré-construídos para atividades de diretiva, o renome de provedores de "software como serviço".
publicação/assinatura e workflow, por exemplo, restringem os Software + serviços
aplicativos. Isso simplifica executar SLAs, custo previsível e integridade.
"Software como serviço" total é um mito. Todas as soluções SaaS
Uma arquitetura de referência de software + serviços para representativas incluirão, em algum momento, um item de software
aplicativos oportunistas litantes. instalado no local: um híbrido. Alguns elementos de uma solução
A Figura 7 apresenta uma visão geral de extremo alto nível sobre instanciada residirão no barramento (workflows, por exemplo); outros,
como se juntam as peças deste artigo. Primeiramente, o barramento em serviços conectados ao barramento (como um sistema de
de serviços para a Internet é universal e faz a conexão de todos os gerenciamento de conteúdo XML) e alguns serão "instalados" no local.
sistemas e servidores. Haverá muitos aplicativos compostos nos quais
Quase todos os cenários que utilizam ISB e SAAS são, na verdade,
alguns elementos estão no "ESB" e outros, no ISB. Aplicativos
híbridos de software instalados no local e externamente.
compostos multiorganizacionais são um exemplo óbvio que
implantaria elementos em um ISB na "nuvem". Outra possibilidade são Em outro exemplo, imagine um provedor de armazenamento de
os aplicativos compostos uniorganizacionais, de curta duração. Por dados usado por Dave para armazenar os itinerários do seu aplicativo.
exemplo, um aplicativo composto que a empresa utiliza para Ler/atualizar o itinerário sempre por acesso remoto fragiliza o
administrar uma conferência interna. Reutilizar uma plataforma de processo. Provavelmente, o fornecedor de armazenamento fornecerá
software pré-configurada e instalada na "nuvem" pode ser mais um pacote de software instalado no local e no PC para otimizar o
eficiente do que adquirir, instalar, configurar e dar suporte a itens de acesso aos dados por meio de cache, replicação, controle de versões,
hardware e software para executar o aplicativo internamente. etc. Software + serviços é o termo para o modelo híbrido.

THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net 7

 O Barramento de Serviços para a Internet
Conclusão
Várias tendências se agrupam para transformar de modo radical o
modelo de aplicativo web. Atualmente, a web primária possibilita a
conexão de pessoas a documentos e aplicativos. A transformação
fundamental trata de imaginar a Internet e a web como uma
plataforma na qual os aplicativos podem ser executados. Os
profissionais com habilidades básicas de programação escrevem
aplicativos pessoais que aumentam a eficiência do uso que fazem da
web. Eles compartilharão esses aplicativos com amigos e colegas que
entendem um pouco menos de computadores. Comunidades surgirão
e proporcionarão outra abordagem da disseminação de uma solução
pessoal que se multiplica na comunidade.
Inevitavelmente, os elementos dos aplicativos pessoais se "transferirão
para a nuvem”. A principal fonte será o uso amplo de PCs "virtuais" que
se instalam com base nos dispositivos próximos e do usuário. Em lugar
de usar um notebook em um quarto de hotel, o PC se instalará a partir
do celular do viajante que usará o teclado, a conexão da TV e da
Internet no quarto. É possível instalar uma máquina virtual (VM -
Virtual Machine) que tenha apenas o software necessário para
implementar um cenário específico. A VM ainda oferece:
"
isolamento do aplicativo;
"
administração do usuário final da implementação de um modelo
conceitual similar ao modo como o usuário gerencia Pcs;
"
exploração natural de processadores escalados com base em
processadores de vários núcleos.
As vantagens para a empresa da convergência dessas tendências
inclui:
"
aprimoramento significativo na produtividade e no moral do
funcionário. O trabalho fica menos entediante, mais concentrado nas
tarefas importantes do negócio e, provavelmente, mais divertido.
Maior agilidade e capacidade de ação pois o desenvolvimento e a
modificação do aplicativo podem acontecer em horas, não em meses.
Uma tecnologia-chave que possibilitará essas transformações será um
barramento de serviços para a Internet. A SOA, os Web Services e
mashups permitem o rápido desenvolvimento de aplicativos
compostos que integram, personalizam e ampliam os blocos de
construção dos aplicativos básicos. Possibilitar que esses compostos
cheguem à web é o próximo maior salto e um aspecto primordial da
Web 2.0. O elemento crítico para cumprimento da promessa é um
barramento de serviços para a Internet. Além disso, para permitir o
desenvolvimento de um aplicativo flexível, o ISB permite a existência
de um ecossistema de provedores de software. As capacidades do ISB
oferecem suporte à emergente população de profissionais com
conhecimentos de programação admitidos na força de trabalho,
especialmente o desenvolvimento crescente pela comunidade de
aplicativos tipo cauda longa (long tail)
(http://www.microsoft.com/brasil/msdn/Tecnologias/arquitetura/Long
Tail.mspx). A teoria unificadora do universo computacional é a de
software + serviços e o ISB é a pedra fundamental desse novo modelo
de aplicativo.
Referências
BizTalk Adapter
http://msdn2.microsoft.com/EN-US/library/aa744368.aspx
8 THE ARCHITECTURE JOURNAL
Biztalk Labs
http://labs.biztalk.net
Enterprise Application Integration (EAI)
http://en.wikipedia.org/wiki/Enterprise_application_integration
Barramento de serviço corporativo
http://en.wikipedia.org/wiki/Enterprise_application_integration
Mashup
http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)
Modelo-Visão-Controlador
http://en.wikipedia.org/wiki/Enterprise_application_integration
OASIS Web Services Reliable Messaging (WSRM) TC
www.oasis-open.org/committees/wsrm/
SAP RFC
http://en.wikipedia.org/wiki/ABAP
Processamento direto (STP - Straight-Through-Processing)
http://en.wikipedia.org/wiki/Enterprise_application_integration
Struts
http://struts.apache.org/
Casos de uso
http://en.wikipedia.org/wiki/ABAP
WS-Eventing
http://www.w3.org/Submission/WS-Eventing/
WS-Security Security Token Service
http://sts.labs.live.com/
Zorro's ISB Blog
http://zorroisb.spaces.live.com
Sobre os autores
Dr. Donald Ferguson é Technical Fellow da Microsoft em plataformas
e estratégia na função de CTO. O seu enfoque está no papel evolutivo
e revolucionário da tecnologia da informação nos negócios. Antes de
ingressar na Microsoft, Don era Fellow da IBM e arquiteto-chefe do
grupo de software do SWG (Software Group) da IBM e presidiu o SWG
Architecture Board (SWG AB) que se concentrava na integração de
produtos, iniciativas de produtos inter-relacionados e tecnologia
emergente incluindo Web Services, padrões, Web 2.0 e
desenvolvimento dirigido a negócio. O principal hobby de Don é
caratê (Kenpo). Em dezembro de 2005 ele tornou-se faixa preta.
Dennis Pilarinos é diretor técnico sênior de Connected Systems, uma
divisão da Microsoft. Para conhecer outros detalhes do trabalho que
ele realiza, visite o seu blog em www.dennispi.com.
John Shewchuk dirige a equipe de estratégia de tecnologia de
Connected Systems (CSD), uma divisão da Microsoft. Na CSD, John
trabalhou no desenvolvimento da plataforma de aplicativos da
Microsoft inclusive nas tecnologias de troca de mensagens como o
produto Windows Communication Foundation, especificações para a
interoperabilidade de Web Services como o WS-Security e em
tecnologias de identidade e acesso como o InfoCard. John foi co-
fundador da equipe Indigo e foi um condutor-chave da
interoperabilidade entre setores. Com outros componentes da equipe
Indigo, John liderou o desenvolvimento da arquitetura e das
especificações dos Web Services e gerenciou as negociações técnicas
com ampla gama de parceiros do setor.
• Journal 13 • www.architecturejournal.net
Perfil do The Architecture
Journal: Ray Ozzie

Ray Ozzie é arquiteto-chefe de software da Microsoft, e

assumiu a função de Bill Gates em junho de 2006.
Coincidindo com o tema desta edição do The
Architecture Journal, nós nos encontramos com Ray para
saber qual é a sua visão do tema software + serviços e
conhecer algumas de suas idéias sobre o que é tornar-se
um arquiteto de software
AJ: Muitos leitores talvez tenham ouvido o seu discurso na MIX
deste ano sobre software + serviços. Poderia dissertar um pouco
sobre a sua visão?
RO: Existem mudanças fundamentais que continuamente acontecem
em nosso setor, com relação ao preço dos diferentes tipos de
componentes e o custo da comunicação. Há cerca de cinco anos, mais
ou menos, descobrimos a necessidade de reavaliar as arquiteturas
corretas para sistemas baseados nas mudanças que ora ocorrem. Hoje,
a confluência do processamento barato, com o armazenamento
barato e as comunicações baratas está nos forçando a reavaliar a
posição em que colocamos a computação para produzirmos soluções
e resolvermos problemas. armazenam suas músicas, etc. Até as câmaras de vídeo digitais estão
Inicialmente, a web foi construída para um mundo de largura de aumentando. Isso quer dizer que todos os seus filmes pessoais estarão
banda de baixa velocidade, utilizando cliente magro ou terminal nos PCs? Ou replicados entre os seus PCs? Acredito que esta é uma
smart, e assumiu largura de banda bastante lenta sendo a maior parte enorme oportunidade para o nosso setor de estudar, solução por
do poder de computação aplicado ao nível de serviço. Na era cliente- solução, e perguntar qual a melhor forma de equilibrar o uso de
servidor, tivemos uma rede de largura de banda de alta velocidade no código de cliente e serviço.
âmbito corporativo que equilibrou o processamento no cliente e no AJ: Parece que muitas dessas soluções se ajustariam a um
servidor. Em vista das mudanças em computação, armazenamento e espectro de clientes baseados em navegador e interação rica. No
comunicações, como setor e empresa, estamos refletindo sobre o valor âmbito desse espectro você vislumbra o surgimento de tipos de
que entregamos aos nossos clientes e analisando qual a melhor forma padrões arquiteturais diferentes?
de equilibrar o que acontece no cliente, no servidor corporativo e nos
RO: Vários padrões estão surgindo, embora não saibamos, ainda, o
serviços para atender aos vários cenários. que serão exatamente. Os padrões para escala horizontal são os mais
Estamos passando por uma mudança bastante radical no modo de desafiadores e interessantes neste momento, acredito. O que está
produzirmos soluções. Acredito, verdadeiramente, que a resposta muito claro é que, para qualquer serviço de alta escala, é preciso ter
nunca está nos extremos, a não ser que realmente haja forte restrição, em mente a imagem de uma máquina virtual que você escala de
como um canal de comunicação magro. Existem algumas soluções acordo com as suas necessidades. Neste momento, refatorar o seu
que serão entregues como serviços puros. Basta ir a um navegador: aplicativo para uma expansão horizontal e não vertical, fazendo-o
também extensível em termos de escopo muito largo ou estreito é,
você realiza a transação, obtém as informações desejadas e faz o que
provavelmente, o mais interessante.
precisa ser feito. Existem outras situações nas quais, estando em
trânsito, a conectividade com a Internet é menos confiável Determinados padrões de projeto, como MapReduce, são, claramente,
dependendo do local. Nesses ambientes, o extremo oposto é padrões de projeto escaláveis horizontalmente, mas estes resolvem um
conjunto relativamente pequeno de problemas se comparado ao
verdadeiro: você deseja transportar o maior volume de dados possível
grande número de aplicativos corporativos que temos hoje em dia.
no seu enorme disco rígido e ter pronto acesso a ele.
Com o tempo, finalmente, descobriremos um meio termo e
Por exemplo, no começo o PC armazenava principalmente acabaremos com frameworks que pensam sobre seu aplicativo em
documentos. Agora, lógico, tudo tem a ver com a mídia. As pessoas camadas. Essas camadas, desde que ajustadas ao padrão, devem ser
tiram fotos digitais, carregam enormes bibliotecas nos discos rígidos, escaláveis horizontalmente.

THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net 9

 Perfil do The Architecture Journal: Ray Ozzie
AJ: Na medida em que esses padrões surgem ou os frameworks
são disponibilizados, na sua opinião, qual a diferença da visão
software + serviços dos consumidores em relação à visão das
corporações?
RO: Essa é uma boa pergunta. Não tenho certeza de que os padrões
sejam todos assim tão diferentes, exceto a única coisa na empresa que
não existe no espaço do consumidor: o servidor corporativo. Se você
estiver na empresa e construir sistemas para seus clientes, será igual a
construir sistemas para consumidores. Se estiver construindo para
funcionários, haverá mais problemas de integração de sistemas.
Provavelmente você desejará construir soluções com algum tipo de
afinidade com outro servidor local, na mesma geografia, e localizar
esses servidores com base em padrões de acesso a dados pode ser
bastante significativo. Mas, com o tempo, cada vez mais vejo empresas
adotarem a prestação de serviços; inicialmente para infra-estrutura
como serviços de e-mail e outros de nível básico, antes de passar para
os aplicativos corporativos.
AJ: Na medida em que os leitores pensam mais sobre adotar o
modelo software + serviços, onde devem começar hoje? E como
saberão que serão bem-sucedidos?
RO: Vou começar pela última. Se estiverem tentando alcançar metas e
objetivos, serão bem-sucedidos. Agora, quanto a onde começar, no
meu ponto de vista, recomendaria tornar-se extremamente fluente em
tecnologias, tanto da perspectiva de desenvolvedor como de designer.
Para a plataforma Microsoft, isso significa entender de Expression
Studio e Visual Studio. Depois, continue, explore e faça protótipos de
coisas em WPF (Windows Presentation Foundation) no Vista: é uma
ferramenta surpreendentemente robusta. Como você sabe, comecei a
Ray Ozzie
Arquiteto-chefe de estratégia (CSA), Microsoft Corporation
Ray Ozzie, visionário do setor e
pioneiro no trabalho cooperativo
apoiado por computador, é
arquiteto-chefe de software da
Microsoft. Ray assumiu o cargo de
arquiteto-chefe de software em
junho de 2006, quando o
Ray Ozzie
presidente Bill Gates anunciou seu
desejo de abdicar de suas
responsabilidades diárias na Microsoft até julho de 2008. No seu
cargo de CSA, Ray é responsável pela supervisão da estratégia
técnica e a arquitetura de produtos da empresa. Ray também
supervisiona o desenvolvimento da próxima geração de plataformas
de serviços de software da empresa.
Anteriormente, de abril de 2005 a junho de 2006, Ray era executivo
de infra-estrutura da área de tecnologia (CTO – Chief Technology
Officer). Assumiu o seu cargo em abril de 2005, depois que a
Microsoft adquiriu a Groove Networks, uma empresa de software
colaborativo de próxima geração fundada por ele em 1997.
Antes da Groove, Ray fundou e era presidente da Iris Associates,
empresa na qual criou e liderou o desenvolvimento do Lotus Notes.
Antes disso, contribuiu para o desenvolvimento do Lotus Symphony
e dos produtos TK!Solver e VisiCalc da Software Arts; além disso,
10
programar na década de 1960 e, nesse tempo, havia um modelo de
programa na cabeça da gente. Começava com o comando main e a
partir daí você escrevia. Em dado momento, o comando passou a ser
WinMain e transformou-se mais em um modelo baseado em evento.
O novo modelo de programação começa quando você pensa em um
modelo declarativo, iniciando com XAML e uma tela para construir o
seu aplicativo nessa base.
"NESTE MOMENTO, REFATORAR O SEU
APLICATIVO PARA UMA EXPANSÃO HORIZONTAL
E NÃO VERTICAL, FAZENDO-O TAMBÉM
EXTENSÍVEL EM TERMOS DE ESCOPO MUITO
LARGO OU ESTREITO É, PROVAVELMENTE, O
MAIS INTERESSANTE".
Este novo modelo é diferente: a gente começa fazendo o protótipo
com ele, sem imaginar o poder e o nível de produtividade que se
adquire assim que adotar esta nova forma de pensar. A prototipagem
o leva para uma nova perspectiva em que se começa a pensar...
"Nossa"! Agora entendo como pude construir algo em Silverlight e
implantá-lo rapidamente em todos os sistemas com um navegador".
Seguir essa abordagem será muito mais fácil do que descobrir como
escrever em JavaScript para os vários tipos de navegadores.
AJ: Você mencionou uma relação entre designers e
desenvolvedores. Historicamente, eu diria que esses profissionais
não se comunicaram tão bem quanto deveriam. Você vê
mudanças nesse comportamento com essa nova onda
tecnológica?
esteve envolvido com o desenvolvimento dos primeiros sistemas
operacionais distribuídos da Data General Corp.
Ray formou-se em ciência da computação pela University of Illinois,
Urbana-Champaign, e lá conheceu a natureza e o significado dos
sistemas colaborativos e o trabalho em equipe apoiado por
computador durante o trabalho desenvolvido no projeto
embrionário da universidade denominado PLATO. Esse trabalho teve
grande influência na sua visão dos sistemas colaborativos e nos
projetos que assumiu em toda a sua carreira. Ao final do curso, teve
a honra de ser reconhecido como um dos melhores alunos da
escola.
Reconhecido também como um dos sete "Pioneiros do Windows",
Ray foi nomeado "Pessoa do ano" em 1995 pela PC Magazine, e foi
conduzido ao Hall da Fama do Computer Museum Industry e ao
Hall da Fama do InfoWorld. Em novembro de 2000 ele recebeu o
prêmio W. Wallace McDowell do Institute for Electrical and
Electronics Engineers (IEEE) Computer Society e, em 2001, foi
considerado um pioneiro em tecnologia do World Economic Forum.
Atuou como membro do Computer Science and
Telecommunications Board do Nacional Research Council e fez parte
do comitê do NRC, que produziu o memorável relatório CRISIS
sobre o impacto social da criptografia.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

RO: Em qualquer solução efetiva que tenha um elemento de projeto,
ambos precisarão encontrar uma forma de entender-se. Não há nada
que a Microsoft possa fazer para mudar o DNA, ou seja, o tipo de
pessoa que é um designer ou um desenvolvedor.
O que eu tenho observado é que desenvolvedores e designers se
esforçam de formas diferentes. Alguns designers podem se aprofundar
no entendimento dos desafios enfrentados pelos desenvolvedores. E
alguns desenvolvedores podem entender mais efetivamente os
desafios enfrentados pelos designers. Ter ferramentas onde há
sobreposição, onde não existe uma fronteira absoluta entre uma
ferramenta de programação e outra, de desenvolvimento, é
extremamente importante e útil. O núcleo do Microsoft Expression
está realmente orientado para o designer. O trabalho realizado pelos
programadores traduz-se em XAML, o qual pode ser importado e
usado no Visual Studio por um desenvolvedor. Estou entusiasmado e
otimista sobre como ferramentas como essa unirão desenvolvedores e
designers resultando em benefício para o usuário.
AJ: Atualmente, temos vários leitores do The Architecture Journal
ocupando cargos de desenvolvedores que aspiram tornar-se
arquitetos de software. Tendo em conta as suas
responsabilidades, como é o dia na vida de um arquiteto-chefe
de software da Microsoft?
RO: No meu ponto de vista, a profissão de arquiteto trata de
compatibilizar padrões. Refere-se a estar exposto a ferramentas e
técnicas do ramo suficientes para que, com o tempo, você comece a
desenvolver um conjunto de padrões diferentes que trabalham em
diferentes situações. Isso é válido para a arquitetura de software e,
provavelmente, também para outros tipos de arquitetura. Quer você
construa pontes ou projete edifícios, está tentando aplicar padrões a
uma determinada situação.
O meu cargo na Microsoft é interessante porque existem arquitetos de
peso nos diferentes grupos de produtos, nas várias divisões da
empresa e eles estão realizando um ótimo trabalho com os seus
produtos. O meu papel é essencialmente relacional. Quero dizer, devo
entender como os clientes estão utilizando os vários produtos juntos
e, depois, me pergunto quais os padrões que vejo. Qual é a menor
coisa possível que eu poderia sugerir para uma equipe de produto,
para que pudesse refazer a arquitetura do produto para minimizar os
pontos de contato com outros produtos? Ou, por uma perspectiva do
negócio, qual a menor coisa possível que seria possível passar para
esses produtos para agregar valor para os nossos clientes e criar uma
vantagem competitiva para as nossas soluções no mercado. No nível
mais alto, meu conselho aos arquitetos aspirantes é o seguinte: pense
duas vezes. É preciso passar um tempo como programador para
entender os vários padrões existentes e reconhecer os atributos de
sistemas bem arquitetados para, então, passar para o próximo nível de
abstração das soluções que você estiver construindo.
AJ: Parece, então, que a habilidade de compatibilizar padrões
deve realmente passar pela experiência?
RO: Totalmente. Trata-se especialmente das coisas que ninguém gosta
de pensar no nível arquitetural. Por exemplo, características de
desempenho, E/S, confiabilidade... Você pode ter tido experiência com
um sistema que trabalha bem, frente a determinado nível de
complexidade, mas se utilizado em um ambiente mais dinâmico
poderia apresentar-se muito frágil. Isso só se aprende com a
experiência.
"NO NÍVEL MAIS ALTO, MEU CONSELHO AO
ARQUITETO ASPIRANTE É DESCOBRIR O
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Perfil do The Architecture Journal: Ray Ozzie
EQUILÍBRIO CERTO DO ENFOQUE SOBRE
TENDÊNCIAS INTERNAS E EXTERNAS QUE LHE
DARÃO A PERSPECTIVA QUE PRECISA".
AJ: Você está no setor de software há mais de 25 anos e,
nitidamente, é uma apaixonado por software e tecnologia. O que
mantém a constante motivação? O que o motiva a se levantar
pela manhã?
RO: Gosto de resolver problemas. Gosto do que é complexo e de
tecnologia. Tenho tido sorte porque logo no início da minha carreira
tive a oportunidade de trabalhar em sistemas implantados em larga
escala. Assim, de certa forma, sou um escravo do pensamento de
causar um grande impacto nas coisas que fazemos. Cada indivíduo
acorda pela manhã com diferentes motivações. Para mim, trata-se de
ser um construtor. Gosto de resolver problemas que possam
influenciar positivamente as vidas das pessoas.
AJ: Imagino que para fazer isso você deve ter um grande cabedal
em várias tecnologias. Posto isso, e considerando as equipes de
produto com as quais interage diariamente, como você se
mantém atualizado?
RO: É realmente uma combinação interessante. A coisa mais fácil e
natural é simplesmente falar com as pessoas na sua área de influência
e entrar em contato com várias tecnologias, como parte do seu
trabalho. Mas, para ter sucesso a longo prazo, é preciso estar em
contato com as tendências e com o que está acontecendo
externamente, especialmente saber o que os clientes ou cada um dos
usuários está dizendo e fazendo.
Dedico boa parte do meu tempo à leitura de blogs, acompanhando
influenciadores específicos cujas opiniões são muito interessantes,
tanto as relacionadas aos nossos produtos como aquelas totalmente
dissociadas.
Compareço a uma combinação de conferências que denomino
"cabeça" e "cauda". Durante o ano, participo de algumas em que se
reúnem os influenciadores conhecidos do setor. Essas me permitem
rastrear as principais questões da concorrência ou, no mínimo,
conhecer as apresentações do que os concorrentes estão falando e
fazendo. Mas, eu também aprecio as conferências de cauda, onde é
possível ter uma noção mais próxima do que realmente está
acontecendo. Gosto de encontrar pessoas recém-formadas, que têm
idéias e entendem os tipos de escolhas tecnológicas que fazem e por
quê. No nível mais alto, meu conselho ao arquiteto aspirante é
descobrir o equilíbrio certo do enfoque sobre tendências internas e
externas que lhe darão a perspectiva que precisa.
AJ: Esse é, sem dúvida, um ótimo conselho. Em relação a isso, na
sua opinião, quais são as características que definem um
arquiteto de software eficiente?
RO: Os arquitetos mais eficientes com os quais já trabalhei são aqueles
que cumpriram suas obrigações. São aqueles que passaram muito
tempo nas "trincheiras" construindo e depurando sistemas bastante
complexos. Aprende-se muitas coisas consertando os defeitos das
outras pessoas. Quando alguma coisa falha e o responsável já saiu da
empresa, é possível aprender muito fazendo engenharia reversa ou
estudando a documentação. Quanto mais sistemas você puder
conhecer pelo lado de dentro, mais será possível desenvolver e
entender o que são boas e más práticas em padrões de programação.
Como disse antes, é essa biblioteca de padrões da sua mente que o
definirá como um arquiteto.
11
 Projeto Astoria
por Pablo Castro
Resumo
O projeto Astoria produz um conjunto de padrões e
também uma infra-estrutura concreta para a criação e o
consumo de serviços de dados utilizando tecnologias da
web. Este artigo explora a mudança dos modernos
aplicativos e serviços web centralizados e o papel que o
Astoria pode desempenhar nessas novas arquiteturas.
O s dados tornam-se cada vez mais disponíveis, como um
elemento de primeira classe na web. A proliferação de novos
tipos de aplicativos dirigidos a dados, como os mashups, indica
claramente que a ampla disponibilidade de dados auto-suficientes,
independentes de qualquer IU, está mudando a forma com que os
sistemas são construídos e, também, o aproveitamento dos dados.
Mais ainda, tecnologias como a do Asynchronous JavaScript and XML
(AJAX) e do Microsoft Silverlight estão introduzindo a necessidade de
mecanismos para a troca de dados independentemente da
apresentação de informações para dar suporte a experiências de
usuário altamente interativas.
O projeto Astoria oferece a arquitetos e desenvolvedores um conjunto
de padrões para a interação com serviços de dados sobre HTTP
utilizando formatos simples como POX (Plain Old XML) e JavaScript
Object Notation (JSON). O cumprimento à risca do protocolo HTTP
resulta em excelente integração com a infra-estrutura existente de
web, da autenticação a proxies e cache. Além dos padrões e formatos,
fornecemos uma implementação concreta que pode fazer surgir
automaticamente um esquema de modelo de dados de entidades
(EMD - Entity Data Model) ou outras fontes de dados por meio da
interface HTTP.
Figura 1: Fluxo de conteúdo tradicional (à esquerda) e como o fluxo se modifica nos aplicativos web modernos (á direita)
Servidor Web
Cliente
Apresentação +
dados (por
exemplo, HTML
com dados
incorporados)
Servidor de
banco de dados
12
Ainda que a infra-estrutura de software oferecida pelo Astoria possa
ser uma peça útil do quebra-cabeça para a construção de novos
aplicativos e serviços web, é apenas uma peça. Outros elementos
desses aplicativos precisam ser organizados para permitir a interação
com dados pela web.
Neste artigo, tratarei dos aspectos arquiteturais que sofrem o impacto
das abordagens modernas do desenvolvimento de aplicativos
preparados para web, com enfoque em como os serviços de dados se
integram no quadro.
Separando os dados da apresentação
A nova geração de aplicativos web utiliza tecnologias como AJAX,
Microsoft Silverlight ou outras infra-estruturas de apresentação rica.
Uma característica comum de todas essas tecnologias é que elas
impõem uma mudança com respeito à forma com que os aplicativos
web são construídos.
A Figura 1 compara o fluxo de conteúdo nos tipos tradicional e
moderno de aplicativos web. Aplicativos web tradicionais dirigidos a
dados compreendem, tipicamente, um conjunto de páginas ou scripts
do lado do servidor, executado quando chega uma solicitação;
durante o processo, as páginas ou scripts executam algumas consultas
ao banco de dados e, então, processam o HTML que contém
informações de apresentação e dados nele incorporados.
Um aplicativo baseado em AJAX ou Silverlight não segue esse modelo
de interação. As informações de apresentação são despachadas para o
navegador web com o código para acionar a IU, mas sem os dados
verdadeiros. Essas informações de apresentação são, em geral, uma
combinação de aplicativos HTML, Cascading Style Sheets (CSS),
JavaScript for AJAX e Extensible Application Markup Language
(XAML)/ DLLs para Silverlight. Depois que o código está ativo e em
execução no cliente, a IU inicial é apresentada e os dados são
recuperados na medida em que o usuário interage com a interface.
Dados
010
1
010 01
1
101 00
1
101
011
0 Servidor Web
0 10
Cliente
Apresentação
(por exemplo, HTML)
Servidor de
banco de dados
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
 Projeto Astoria

Curiosamente, este novo ciclo de tecnologias está agindo como uma As etapas detalhadas para a criação de serviços de dados Astoria,
função de força para transferir a organização do aplicativo na direção assim como farta documentação sobre o URI Astoria e os formatos de
de uma meta comum em muitas arquiteturas de aplicativos: separação carga podem ser encontrados no documento “Using Microsoft
rígida entre dados e apresentação. Codename Astoria”, disponível no website Astoria no endereço
Pela perspectiva do servidor, apresentar os elementos da IU é http://astoria.mslivelabs.com.
relativamente fácil. Na maioria das vezes, são simples recursos de Depois que o serviço estiver ativo e operacional, os URIs poderão ser
arquivo no servidor, como arquivos HTML ou CSS e arquivos de mídia. utilizados para examinar os recursos expostos pela interface de dados.
Apresentar os dados é outra história. Até agora, a interação com Os exemplos a seguir utilizam o serviço experimental do Astoria on-
dados era algo que acontecia entre o servidor web e o servidor do line que hospeda alguns serviços de dados read-only. Por exemplo:
banco de dados; não havia necessidade de expor pontos de entrada http://astoria.sandbox.live.com/northwind/northwind.rs
acessíveis do código, executado em toda a web, em um navegador e/Customers
web ou algum outro agente de software. É neste ponto que entra o retornaria todos os recursos do container recurso de clientes. No
projeto Astoria. formato XML-padrão, teria esta aparência:
Interfaces de dados flexíveis
<DataService xml:base=”http://astoria.sandbox.live.
Há várias formas de expor dados aos clientes que os consumirão pela com/northwind/northwind.rse”>
web. Uma abordagem, possibilitada pelas tecnologias existentes, é <Customers>
usar uma conduta similar à chamada de procedimento remoto (RPC - <Customer uri=”Customers[ALFKI]”>
<CustomerID>ALFKI</CustomerID>
Remote Procedure Call): as funções são expostas por meio da interface
<CompanyName>Alfreds Futterkiste</CompanyName>
como os Web Services (por exemplo, interface baseada no protocolo <ContactName>Maria Anders</ContactName>
SOAP ou uma convenção simples baseada em UTI para chamar <ContactTitle>Sales Representative</ContactTitle>
métodos e parâmetros de transferência). O Microsoft Visual Studio <Address>Obere Str. 57</Address>
oferece um conjunto de ferramentas comprovado, que facilita criar e <City>Berlin</City>
<Region />
consumir interfaces construídas dessa forma. O conjunto de
<PostalCode>12209</PostalCode>
ferramentas do ASP.NET AJAX leva isso para o próximo nível, <Country>Germany</Country>
permitindo que Web Services criados com o Visual Studio trabalhem <Phone>030-0074321</Phone>
com clientes AJAX. <Fax>030-0076545</Fax>
<Orders href=”Customers[ALFKI]/Orders” />
O principal problema desta abordagem é a flexibilidade. Se a interação
</Customer>
com dados acontece apenas por meio de pontos de entrada fixos e <Customer uri=”Customers[ANATR]”>
predefinidos, qualquer cenário novo ou variação dos existentes, com ...properties
dados pouco diferentes, exigirá, tipicamente, a criação de novos
</Customer>
pontos de entrada. Ainda que este nível de controle seja conveniente ...more customer entries
em determinadas ocasiões, na maioria dos casos, maior flexibilidade </Customers>
aumentará a produtividade do desenvolvimento e contribuirá para um </DataService>
aplicativo mais dinâmico.
Pode-se também apontar para uma entidade específica utilizando
O projeto Astoria apresenta uma alternativa à abordagem RPC,
estas chaves:
baseada na semântica simples do HTTP. O Astoria adota uma definição
http://astoria.sandbox.live.com/northwind/northwind.rs
de esquema que descreve cada uma das entidades com as quais o seu
e/Customers[ALFKI]
aplicativo lida, mais as associações entre entidades expondo-as sobre
retornaria um recurso de cliente específico; novamente, utilizando o
uma interface HTTP. Cada entidade pode ser endereçável com um
formato XML no exemplo:
identificador de recurso uniforme (URI - Uniform Resource Identifier) e
a convenção do URI permite aos aplicativos atravessar as associações <DataService xml:base=”http://astoria.sandbox.live.
entre entidades, pesquisar entidades e executar outras operações com/northwind/northwind.rse”>
normalmente exigidas com dados. <Customers>
<Customer uri=”Customers[ALFKI]”>
A definição do esquema utilizado pelo Astoria é o esquema de <CustomerID>ALFKI</CustomerID>
modelo de dados de entidades (EMD - Entity Data Model), <CompanyName>Alfreds Futterkiste</CompanyName>
diretamente compatível com o ADO.NET Entity Framework. O Entity <ContactName>Maria Anders</ContactName>
Framework também inclui um robusto mecanismo de mapeamento <ContactTitle>Sales Representative</ContactTitle>
<Address>Obere Str. 57</Address>
que permite aos desenvolvedores mapear o esquema EDM em um
<City>Berlin</City>
banco de dados relacional para o armazenamento efetivo. <Region />
Para demonstrar a interação com os serviços do Astoria, utilizarei um <PostalCode>12209</PostalCode>
exemplo com base no conhecido banco de dados Northwind. É <Country>Germany</Country>
possível configurar um serviço de dados sobre o Northwind criando <Phone>030-0074321</Phone>
<Fax>030-0076545</Fax>
um aplicativo ASP.NET, importando o esquema Northwind do banco <Orders href=”Customers[ALFKI]/Orders” />
de dados em um esquema EDM, por meio do assistente ADM e,
</Customer>
depois, criar um serviço de dados Astoria voltado para aquele </Customers>
esquema EDM. </DataService>

THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net 13

 Projeto Astoria

Se o URI apontar para um recurso específico, como o que acabamos inclui um URI que representa o seu local canônico (no atributo do URI
de discutir, é possível não apenas recuperar o recurso utilizando um do elemento "Customer" acima).
comando HTTP GET, mas também atualizá-lo, utilizando HTTP PUT, ou Interação com dados da camada de apresentação
excluí-lo utilizando HTTP DELETE.
Existem várias opções para interação com fontes de dados da camada
Como a descrição do esquema fornecido ao Astoria inclui associações
de apresentação. O primeiro aspecto que definirá o escopo das
entre as entidades, estas podem também ser aproveitadas na interface
opções disponíveis para um determinado cenário é a natureza do
HTTP. Continuando com o exemplo, se cada recurso de cliente estiver
cliente (por exemplo, navegador vs cliente rico).
associado a um conjunto de recursos de pedidos, o seguinte URI
representará o conjunto de pedidos relacionado a um determinado Como a interface do Astoria é apenas HTTP puro, quase todos os
cliente: ambientes com biblioteca de cliente em HTTP podem ser utilizados
para consumir serviços de dados. A interface foi especificamente
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers[ALFKI]/Orders projetada para ser fácil de usar no nível HTTP; os padrões de URI são
simples e legíveis por humanos e os formatos de carga usam JSON ou
Além de ser capaz de apontar para recursos específicos e listar os um subconjunto de XML que o mantém direto e simples.
recursos de um container, também é possível filtrar, ordenar e paginar Para aplicativos .NET, o conjunto de ferramentas Astoria inclui uma
os dados para facilitar a criação de IUs sobre o serviço de dados. Por biblioteca de cliente executável no ambiente do .NET Framework e
exemplo, para listar todos os recursos de clientes da cidade de
apresenta resultados provenientes dos serviços Astoria como objetos
Londres, ordenados pelo nome do contato, o aplicativo pode usar este
.NET; não apenas é o mais fácil para os desenvolvedores, para uso no
URI:
âmbito da base de códigos do aplicativo cliente, mas também se
http://astoria.sandbox.live.com/northwind/northwind.rs integra bem com componentes que já operam sobre objetos .NET
e/Customers[City eq 'London']?$orderby=ContactName normais. A biblioteca oferece serviços ricos como gerenciamento de
gráfico, rastreamento de modificações e tratamento de atualizações.
O formato real do URI do Astoria ainda pode estar sujeito a mudanças,
(Vide Exemplo 1.)
mas a semântica e as capacidades devem permanecer relativamente
estáveis. A biblioteca de cliente do Astoria é executável tanto no .NET
Framework como no Microsoft Silverlight. Isso permite a criação de
Em qualquer dos casos, os dados são trocados em formatos simples
como XML ou JSON. O formato real pode ser controlado pelo cliente- aplicativos de desktop e baseados no Silverlight utilizando a mesma
agente utilizando negociação do tipo de conteúdo HTTP normal. Os API, por simples referência ao respectivo conjunto Astoria no
dados são codificados como recursos que simplesmente mapeiam ambiente de destino.
propriedades de entidades EDM em elementos XML ou propriedades
JSON, as quais estão vinculadas por hyperlinks a outros recursos com Exemplo 1: Acessar um serviço Astoria do código .NET utilizando a
os quais estão associadas. Por exemplo, o URI do exemplo anterior: biblioteca de cliente do Astoria
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers[ALFKI]
WebDataContext ctx = new WebDataContext(
resultaria na seguinte resposta (em XML): “http://astoria.sandbox.live.com/
Northwind/Northwind.rse”);
<DataService xml:base=”http://astoria.sandbox.live.
WebDataQuery<Customer> customers = ctx.
com/northwind/northwind.rse”>
CreateQuery<Customer>(“/Customers?$orderby=CompanyNa
<Customers>
me”);
<Customer uri=”Customers[ALFKI]”>
foreach(Customer c in customers) {
<CustomerID>ALFKI</CustomerID>
Console.WriteLine(c.CompanyName);
<CompanyName>Alfreds Futterkiste</CompanyName>
<ContactName>Maria Anders</ContactName>
}
<ContactTitle>Sales Representative</ContactTitle>
<Address>Obere Str. 57</Address>
<City>Berlin</City>
<Region />
<PostalCode>12209</PostalCode>
<Country>Germany</Country>
<Phone>030-0074321</Phone>
<Fax>030-0076545</Fax>
<Orders href=”Customers[ALFKI]/Orders” />
</Customer>
</Customers>
</DataService>

Você pode ver que a resposta inclui propriedades simples e hyperlinks

com outros recursos (“Orders” no exemplo). Cada recurso também

14 THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net


Exemplo 2: Acessar um serviço Astoria de um aplicativo AJAX (o
exemplo usa a biblioteca ASP.NET AJAX)
function ListCustomers() {
var req = new Sys.Net.WebRequest();
req.set_url(“Northwind.svc/Customers?$orderby=Co
mpanyName”);
req.get_headers()[“Accept”] = “application/json”;
req.add_completed(onCustomersCompleted);
req.invoke();
} foreach (Customer c in q.EndExecute(ar)){
function onCustomersCompleted(response) { }
if(response.get_statusCode() != 200)
alert(“Error retrieving customers: “ +
response.get_responseData());
else {
var res = response.get_object();
var html = “<ul>”;
for(var i = 0; i < res.length; i++) {
html += “<li>” +
res[i].CompanyName + “</
li>”;
} Além desses, os desenvolvedores podem definir as operações de
html += “</ul>”;
// “Customers” is a DIV element defined in
the HTML document
$get(“Customers”).innerHTML = html;
} haver um requisito em que os usuários pudessem recuperar, de cada
} vez, os clientes de uma determinada cidade. O desenvolvedor pode
No caso dos aplicativos web estilo AJAX, a maioria dos frameworks
AJAX inclui invólucros fácil de usar para acesso de HTTP para recursos
externos. Esses invólucros são até compatíveis com a materialização da
resposta em objetos JavaScript se você indicar que a resposta será
dada no formato JSON. (Vide Exemplo 2.)
Independentemente do tipo, os aplicativos serão executados em
ambientes com latência relativamente alta entre o cliente e o serviço
de dados, portanto o uso de técnicas típicas de execução assíncrona
deverá ser a norma. A API cliente tem suporte incorporado para
execução de requisição assíncrona. Para o caso de aplicativos AJAX, a
interface XMLHTTP, com a maioria dos invólucros, oferece suporte
para requisições de envio de modo assíncrono. (Vide Exemplo 3.)
Introdução à lógica do negócio
Com o Astoria, basta que o desenvolvedor aponte para um banco de
dados ou esquema EDM pré-construído para que uma visão HTTP seja
automaticamente gerada. Embora isso seja ótimo para as iterações
iniciais de um aplicativo, essa interface totalmente aberta quase nunca
será adequada à produção de aplicativos.
Em muitos bancos de dados, existe uma divisão relativamente clara
entre os dois tipos de dados (quase sempre, dois tipos de tabelas): há
uma parte dos dados com suficiente semântica implícita em si (isto é
válido para conceitos mais simples como a "categoria de produto").
Nesses casos, a lógica do negócio (em geral magra ou inexistente) e a
interface direta para os dados é o quanto basta. A outra parte dos
dados só faz sentido com alguma lógica do negócio à volta dela; por
exemplo, os dados apresentados precisam ficar restritos com base no
contexto, ou as modificações precisam transferir validações externas
ou, ainda, quando um determinado valor é alterado, outro efeito
colateral precisa acontecer, e assim por diante.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Projeto Astoria
Exemplo 3: Utilizar a API assíncrona no cliente Astoria para .NET
WebDataContext ctx = new WebDataContext(
“http://astoria.sandbox.
live.com/Northwind/Northwind.rse”);
WebDataQuery<Customer> q = ctx.
CreateQuery<Customer>(“/Customers[City eq 'London']”);
q.BeginExecute(
delegate(IAsyncResult ar)
{
// process each customer
},
null);
Para tratar do requisito que permite a introdução da lógica do
negócio, rigidamente vinculada a determinadas peças de dados, o
Astoria é compatível com dois mecanismos de personalização:
operações e interceptores de serviço.
O serviço padrão do Astoria consiste inteiramente em containers de
recursos localizados nos pontos de entrada do gráfico de recursos
como, por exemplo, /Customers (clientes) ou / Products (produtos).
serviço que encapsulam a lógica do negócio e as consultas. Por
exemplo, em um determinado aplicativo, talvez não se queira listar
todos os clientes; em lugar disso, o aplicativo poderia oferecer um
ponto de entrada para listar os "meus clientes" e, ainda assim, poderia
definir uma operação de serviço "MyCustomersByCity" (meus clientes
por cidade), que obtém a identidade dos usuários do contexto (da
propriedade ASP.NET's HttpContext.User, por exemplo), e depois
formular uma consulta que fatore a identidade do usuário e o nome
da cidade, transferida como um argumento. Por exemplo:
[WebGet]
public static IQueryable<Customer> CustomersByCity(No
rthwindEntities db, string city)
{
if (city == null || city.Length < 3) throw new
Exception(“bad city”);
var q = db.Customers.Where(“it.City = @city”,
new
ObjectParameter(“city”, city));
// add user-based filter condition to q
return q;
}
seria então invocável (callable) com um URI seguindo este padrão:
/MyCustomersByCity?city=Seattle
Um recurso interessante do Astoria é que as operações de serviço
podem optar por retornar uma consulta em lugar dos resultados reais,
como apresentado no exemplo anterior. Quando o objeto da consulta
retorna, o restante do padrão URI ainda pode ser usado; assim, por
exemplo, o cliente ainda poderia acrescentar uma opção "orderby"
(pedido por) ao URI.
/MyCustomersByCity?city=Seattle&$orderby=CompanyName
15
 Projeto Astoria
A operação de serviço também pode conter código para realizar
validações, atividade de registro ou qualquer outra necessidade. Tal
condição oferece um bom meio termo entre o RPC rígido, que
dificulta a construção de IUs flexíveis e as interfaces de dados
totalmente abertas, que não permitem controlar os dados que fluem
pelo sistema.
Nos cenários para os quais se deseja preservar a interface centrada em
recursos, os interceptores podem ser usados. Um interceptor é um
método invocado sempre que uma determinada ação acontece em
um recurso no âmbito de um dado container de recursos. Por
exemplo, um desenvolvedor poderia registrar um interceptor para ser
invocado sempre que houver mudança (POST/PUT/DELETE) no
container de recursos dos produtos ("Products"). O interceptor pode
desempenhar validações, modificar valores e até escolher abortar a
requisição.
Extensibilidade e fontes de dados alternativas
Até o momento, falei do Astoria no contexto do EDM e do ADO.NET
Entity Framework. Utilizar o Astoria para revelar dados em um banco
de dados é, sem dúvida, a melhor opção; entretanto, nem todos os
dados estão em um banco de dados.
Na primeira CTP (Community Technology Preview) pública do Astoria,
tínhamos nos voltado apenas para o Entity Framework. Na medida em
que fazemos iterações do design do produto, estamos mudando isso
para oferecer mais opções. Especificamente, para criar cenários onde
se deseja expor fontes de dados, não bancos de dados, o suporte será
dado utilizando qualquer fonte de dados preparados para LINQ, a
serem expostos por meio da interface HTTP.
LINQ define uma interface geral denominada IQueryable: permite aos
consumidores compor consultas de modo dinâmico sem precisar
saber quaisquer detalhes sobre a natureza do alvo da consulta. É
responsabilidade da implementação atual da IQueriable de cada fonte
interpretar ou converter as consultas de modo apropriado. Isso
permite ao runtime do Astoria ter uma "consulta base" para compor
com operações como ordenação e paginação. (Vide Figura 2.)
Com a adoção desse ponto de extensibilidade, os desenvolvedores
poderão contar com um amplo conjunto de fontes de dados no
cenário, expondo-as por meio da interface HTTP. Isso vai do acesso a
Figura 2: Diagrama da arquitetura do Astoria ilustrando a
estrutura em camadas baseada em IQueryable
Canal de comunicação
(ex: HTTP por meio de WCF)
Interface de host
Adaptador de host Astoria
Runtime Astoria (tradução,
formato, diretivas URL...) Iqueryable
(+ outras interfaces)
Entity Outras fontes
Framework de dados...
Armazenamento
de dados
16
repositórios de dados especializados ao uso de bibliotecas de acesso
baseadas em LINQ para serviços online (por exemplo, existem
implementações informais do LINQ para a Amazon e LINQ para o
Flickr que fornecem capacidades limitadas de consulta àqueles sites
da Internet).
Cenários de implantação: aplicações e serviços
Hoje, um aplicativo web típico, dirigido a dados, terá o seu próprio
banco de dados além de um ou mais servidores web. Para aplicativos
corporativos, esses servidores fazem parte da infra-estrutura de TI e
para aplicativos hospedados em ISPs, a maioria destes oferece serviços
de banco de dados.
Seguindo o mesmo pensamento, espera-se que muitos aplicativos
que usem o Astoria como o seu serviço de dados, construídos com
base no AJAX ou Silverlight, ainda assim tenham banco de dados
próprio. Nesses cenários, o serviço de dados do Astoria pode fazer
parte do próprio aplicativo web e, assim, serão implantados com os
demais componentes do aplicativo. Este é um dos cenários que temos
com alvo para o Astoria, mas não é o único que pretendemos.
O Astoria como tecnologia para construir serviços de dados para o
consumo de outros sistemas é outra forma de considerá-lo. Os
provedores de dados podem configurar servidores Astoria com os
quais outros aplicativos podem interagir, consumindo e atualizando
dados, conforme necessário e permitido pelas diretivas de segurança.
O provedor de dados pode ser o mesmo proprietário do aplicativo
que consome os dados ou pode ser um serviço consumível por
terceiros.
Ainda mais uma forma de considerar o Astoria é como um serviço de
uso geral para armazenamento de dados. Para explorar essa idéia,
configuramos um serviço online experimental que hospeda vários
conjuntos de dados de exemplo, inclusive os bancos de dados
Northwind e AdventureWorks, um subconjunto de artigos do
Microsoft Encarta e um snapshot de dados compatíveis com o site
social de marcadores Microsoft TagSpace. Transformar isso em um
serviço para o mundo real exige tecnologia muito além da interface e
dos padrões HTTP, e esse é um espaço fora do escopo do projeto
Astoria; todavia, ainda consideramos que o serviço experimental tem
valor como ferramenta de aprendizado, só para ver o que os
desenvolvedores de aplicativos poderiam construir tendo-o como
base.
Segurança
Expor uma interface de dados webfacing exige elaboração cuidadosa
com relação ao acesso seguro, para confirmar que apenas os dados
que devem ficar disponíveis estejam efetivamente acessíveis pela
interface HTTP. Isso envolve uma infra-estrutura de autenticação e
diretivas de autorização adequadas.
Embora muitos pontos de design do Astoria apliquem-se igualmente
ao Astoria como componente de aplicativo e como serviço, a
autenticação é uma das áreas à qual essa afirmação não se aplica.
REST e Astoria
O acrônimo REST significa Representational State Transfer
(Transferência de estado representacional) e foi criado por Roy
Fielding. Refere-se, de forma livre, a um estilo arquitetural em que
os sistemas apresentam uma abstração bastante simples,
orientada a recurso para o estado do aplicativo e uma interface
uniforme para agir sobre esses recursos. Existem também aspectos
como estrutura em camadas e armazenamento em cache que se
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

ajustam muito naturalmente no modelo e permitem a criação de
sistemas de grande porte, altamente escaláveis. A World Wide Web
é quase sempre citada como exemplo de aplicação do protocolo
REST e o nível de escalabilidade que proporciona.
Acredito que o Astoria pode ser considerado um bom cidadão
REST, pois transforma entidades e registros em recursos e estes
recursos são endereçáveis por meio do espaço URI apresentado
pelo servidor. Todos os recursos podem ser obtidos e manipulados
por meio da interface uniforme HTTP, e o sistema permite
estabelecimento simples de camadas e cache por meio de métodos
tradicionais usados pela WWW. Como qualquer outra peça de
infra-estrutura de sistemas, alguns pragmatismos precisam ser
considerados: quando necessário, o Astoria permite aos
desenvolvedores deixar o universo de interação usando recursos e
possibilitar a introdução de alguns RPCs os quais, algumas vezes,
são necessários para a construção de aplicativos do mundo real.
Se o Astoria for utilizado como serviço de dados fazendo parte de um
aplicativo web personalizado, a autenticação, em geral, se aplica a
todos os recursos presentes em determinada área, inclusive o acesso
aos dados. Os usuários fariam a autenticação quando estivessem no
website e o sistema precisa ter condições de aplicar as credenciais ao
serviço de dados, assim como ao restante do aplicativo. O Astoria
consulta a API do ASP.NET para saber se o usuário foi autenticado e
para descobrir outros detalhes e, assim, aplicativo que use qualquer
esquema de autenticação, adequadamente integrado ao ASP.NET,
automaticamente trabalhará com o Astoria.
A integração com a autenticação ASP.NET significa que em casos
típicos, mecanismos comuns de autenticação sobre HTTP funcionarão.
Incluem-se aí "autenticação de formulários", autenticação integrada
(útil no âmbito das redes corporativas) e esquemas de autenticação
personalizados; é ainda mais fácil estabelecer uma implementação
personalizada de autenticação "básica" de HTTP, que pode ser muito
boa se usada sobre conexões SSL, dependendo da natureza do
aplicativo.
Para serviços online isso se torna um desafio muito maior. Além da real
problemática tecnológica de como acontece a autenticação, existem
diferenças de nível mais alto que precisam ser cuidadas em primeiro
lugar: se o aplicativo e o serviço de dados provêm de fontes diferentes,
os dados do serviço de dados são de propriedade do usuário do
aplicativo? Em caso afirmativo, o aplicativo não deveria ter acesso às
credenciais do usuário para o serviço de dados? O que é preciso, nesse
cenário, é ter um esquema pelo qual o usuário faz a sua autenticação
no serviço de dados, independentemente do aplicativo (o qual
também precisará ser autenticado). Estamos explorando este espaço
como parte do esforço de projeto do Astoria e, embora tenhamos um
conhecimento razoável dos cenários, ainda não projetamos uma
tecnologia concreta para o seu suporte.
Depois de implantado o esquema de autenticação, é preciso ter um
modelo de autorização adequado. A versão atual do Astoria (lançada
na CTP de maio, 2007) tem uma implementação super simples: as
diretivas de autenticação podem ser configuradas no nível do
container de recursos ( /Customers, por exemplo); em cada uma delas,
a configuração pode indicar se é preciso autenticação para ler os
recursos do container e para escrever neles. Este procedimento não é
suficientemente flexível para a maior parte dos aplicativos; assim sendo,
fica claro que é preciso providenciar um esquema mais sofisticado.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Projeto Astoria
Notas de encerramento: escopo e planos do projeto Astoria
A maneira pela qual os aplicativos são escritos está mudando. Uma das
principais características desses aplicativos web emergentes são as
novas formas pelas quais interagem com seus dados. Aqui, existe uma
clara oportunidade de introduzir tecnologia básica para ajudar a
comunidade de desenvolvimento a assumir este novo espaço.
Com o projeto Astoria, pretendemos dar condições para o uso de
dados como um modelo de primeira classe na web e em toda a pilha
de aplicativos. Queremos fornecer a infra-estrutura para a criação de
serviços de dados na web e também contribuir para a criação de um
ecossistema no qual os provedores e consumidores de serviços usem
uma interface uniforme para os dados. Gostaríamos de ver
fornecedores de controles de IU, escritores de bibliotecas de cliente e
outros participantes aproveitarem o poder de reutilização das
interfaces de dados para construir ferramentas melhores para a criação
de aplicativos web.
Estamos iniciando esta visão em casa. Na Microsoft, estamos em
estreita colaboração com muitos grupos para explorar os vários
aspectos em que o Astoria pode participar.
No lado dos serviços, estamos trabalhando com a organização do
Windows Live, colegas da Web3S especificamente (eles são
responsáveis pelas interfaces de dados das propriedades do Live), para
explorar um mundo em que cada interface de dados seja uma
interface Web3S/Astoria e possa ser consumida pelas várias
ferramentas e controles que eles utilizam.
No lado das ferramentas, as equipes do ASP.NET, WCF e Astoria, assim
como os vários colegas envolvidos com o Silverlight, estão trabalhando
juntos para fornecer uma história sólida, ponta a ponta, para o
desenvolvimento de aplicativos web incluindo ferramentas e
bibliotecas de primeira classe para interação com dados dos aplicativos
e serviços web.
O projeto Astoria anda rápido e se concentra em resolver desafios do
mundo real que existem na web e com os dados. Planejamos
completar o processo de projeto de forma transparente para que todos
possam ver o que pretendemos. Têm sido muito bons os momentos de
trabalho neste espaço; eu incentivaria qualquer um que tenha interesse
no tema, a visitar o blog da equipe do Astoria, acompanhar as
discussões de projeto e participar, sempre que tiver algo a dizer.
Referências
Blog da equipe Astoria:
http://blogs.msdn.com/astoriateam
Blog do Pablo:
http://blogs.msdn.com/pablo
Projeto Astoria
http://astoria.mslivelabs.com
Sobre o autor
Pablo Castro é líder técnico da equipe do SQL Server. Contribuiu muito
em várias áreas do SQL Server e do .NET Framework inclusive na
integração SQL-CLR, extensibilidade (type system), no protocolo
cliente-servidor do TDS e na API do ADO.NET. Atualmente, Pablo está
envolvido com o desenvolvimento do ADO.NET Entity Framework e
também lidera o projeto Astoria, estudando como juntar dados e
tecnologias web. Antes de ingressar na Microsoft, Pablo trabalhou em
várias empresas, lidando com amplo conjuntos de temas, dos sistemas
de inferência distribuídos, para análise de pontuação/risco de crédito,
aos aplicativos colaborativos (groupware).
17
 Implicações do Consumo
de Software + Serviços
do TI Corporativo
por Kevin Sangwell

Resumo negócio sentem-se frustrados em relação aos projetos de TI por

Muitos artigos desta edição usam a expressão Software +
Serviços (S+S) para referir-se ao cliente (desktop,
navegador e dispositivo) e aos aplicativos baseados em
servidor que consomem um ou mais serviços da Internet
(nuvem). Embora este modelo compartilhe algumas
características com o software como serviço (SaaS), as
diferenças são significativas para o TI corporativo.
Este artigo compara os desafios de se adotar o S+S em
relação ao SaaS; ficará claro que o consumo de um serviço
externo bem definido é menos desafiador para as
empresas do que o consumo de um serviço acabado.
levarem meses e investimento significativo, para oferecer vantagens
que aparecem na Internet, prontas para serem utilizadas. Os usuários
encontram na Internet capacidades de pesquisa, colaboração e
publicação muito superiores às capacidades internas de muitas
empresas. Um número cada vez maior de aplicativos tem sido
colocado à disposição na Internet como serviços, oferecendo ao
negócio um modelo alternativo de suprimento de TI.
Neste artigo, colocarei em discussão as implicações do consumo de
serviços de software externo com base na infra-estrutura e operações
corporativas existentes, comparando os desafios do modelo SaaS com
aqueles do modelo S+S no que se refere ao consumo de todos os
aplicativos de linha de negócio amplamente adotados em toda a
empresa. Utilizo a expressão "serviços de software" para fazer referência
aos serviços dos dois modelos, Saas e S+S, pois podemos considerar a

H oje, a maioria dos aplicativos distribuídos como serviço pela

Internet (ou seja, SaaS) destina-se aos mercados consumidor e
das empresas de pequeno porte. O modelo usado de monetização do
negócio, quer seja custeado por assinaturas ou publicidade é, em
grande parte, aquele do tipo long tail: vender um pouco de alguma
coisa a inúmeros clientes por meio de um canal de distribuição
escalável, conforme descrito por Chris Anderson (vide Referências).
Entretanto, as demandas corporativas são significativamente diferentes
das demandas desses segmentos (consumidor e pequena empresa) e,
por isso, determinadas premissas que dão apoio à economia e à
distribuição (e ao consumo) de serviço simplesmente não se aplicam ao
contexto corporativo. Por exemplo, os consumidores não precisam se
preocupar com conformidade e integração de aplicativo corporativo
(EAI - Enterprise Application Integration) e tudo o que isso implica é, na
maioria dos casos, irrelevante para as pequenas empresas.
distribuição de software como um continuum com software
convencional hospedado in-house, construído ou comprado, de um
lado, e serviços acabados distribuídos pela Internet (ou seja, Saas), do
outro. A configuração híbrida, software in-house mais serviços na
nuvem, cobre a parte intermediária do continuum (ou seja, S+S). A
Figura 1 ilustra o continuum da distribuição de software. Neste artigo,
"
Software convencional refere-se aos aplicativos instalados na infra-
estrutura e acessados exclusivamente pelos usuários internos.
"
Serviços de bloco de construção oferecem capacidades de nível baixo,
consumidos pelos desenvolvedores na construção de um aplicativo
composto. Esses serviços existem na nuvem.
"
Serviços vinculados fornecem um nível mais alto de funcionalidade
se comparados aos serviços de bloco de construção. Os aplicativos
aproveitam os serviços vinculados para adicionar funcionalidade.

Assim sendo, os serviços de software analisados pela perspectiva

corporativa levanta várias perguntas. A quem pertencem os dados? Figura 1: Continuum da distribuição de sotfware e taxonomia
O que é o contrato de nível de serviço (SLA)? As identidades internas dos serviços de software
podem ser levadas para além do firewall para ter acesso aos serviços
da nuvem? Existem implicações normativas? Instalado no local SaaS
Histórico
Software Serviços de bloco Serviços Serviços
Aproximadamente 70% dos orçamentos de TI são gastos na convencional de construção vinculados acabados
manutenção dos sistemas existentes, e apenas 30% são aplicados em Serviços a partir dos Serviços que
Instalado e
soluções novas. Por outro lado, o custo de hardware e software operado
quais aplicativos fornecem Aplicativos entregues
podem ser funcionalidade auto- via SaaS
no local
diminui e o custo do gerenciamento e suporte cresce. As empresas construídos contida
esperam do setor de TI mais do que nunca, em parte devido à Interessante
Interessante para
Interessante para programadores e Interessante para
confiança recuperada ocorrida após a queda das empresas pontocom, para usuários
programadores pessoal de infra- usuários finais
finais
assim como à crescente demanda das capacidades estilo Web 2.0 estrutura

dentro do firewall. P. ex., P. ex., P. ex.,

Por exemplo, Exchange Hosted
Serviços Amazon S3 Safesforce.com ou
Microsoft Services ou
ou Windows Liveapis Microsoft Dynamics
Ao mesmo tempo, o TI corporativo passa por uma crise de percepção, Exchange Windows Update CRM Live
conforme evidenciado pelo feedback do ensaio de Nicholas Carr de
Software + Serviços
2003 "IT Doesn't Matter" (vide Referências). Muitas vezes os líderes do

18 THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

 Implicações do Consumo de Software + Serviços do TI Corporativo

"
Serviços acabados são análogos aos aplicativos totalmente
desenvolvidos, distribuídos pela Internet, utilizando o modelo SaaS.
" específico. O AD é proprietário e o seu modelo de confiança não é
S+S refere-se ao uso de aplicativos que consomem serviços
vinculados ou àquele construído com os serviços de bloco de
construção.
Ao analisar uma infra-estrutura de TI ou modelo de suprimento de
aplicativo, é importante conhecer os objetivos do negócio. Por
exemplo, a terceirização é motivada pela necessidade de obter uma
relação positiva entre custo e eficiência, transferindo o custo e o risco
de entregar um aplicativo existente, maduro, a um terceiro, em troca
de pagamentos contratados. Por outro lado, a adoção de um serviço
de software satisfaz a necessidade do negócio, como gerenciamento
de cliente mais eficiente (no caso de CRM). Pela perspectiva do
gerente do negócio, SaaS parece ser o melhor dos dois mundos: o
beneficio para o negócio é concretizado a um custo proporcional ao
uso (ou até de graça), sem investimento prévio de capital, ou adicional,
em recursos de TI. Ainda que o negócio esteja melhor posicionado
para determinar a qualidade com que o serviço resolve o seu
problema, a não ser que a área de TI faça parte da discussão, muitas
das implicações mais abrangentes para a área de TI da empresa (custos
não visíveis da adoção dos serviços de software) passarão
despercebidas.
Serviços de software: novos desafios de integração
Ao adotar serviços de software, um conjunto de desafios fica sob a
responsabilidade do provedor: distribuição e suporte para os serviços.
Entretanto, ao adotar um novo modelo, a área de TI enfrenta um
conjunto adicional de desafios e, portanto, novo (Figura 2).
Ignorar esses novos desafios não é uma opção. Como veremos, pode
haver custos diretos e indiretos, implicações de recursos e questões de
conformidade. Em outras palavras, a adoção de um serviço de
software representa um projeto híbrido de aquisição/integração para a
área de TI interna. A integração precisa ser analisada no âmbito de três
áreas amplas:
"
gerenciamento de identidades e acesso
"
dados
"
operações
Figura 2: O consumo de serviços de software acrescenta novos desafios
Regulamentos e obrigações legais também devem ser analisados.
Gerenciamento de identidades e acesso
O gerenciamento de identidades e acesso é um problema perene
Nem os produtos Active Directory (AD) ou os metadiretórios como o
Microsoft Identity Lifecycle Manager resolvem esse problema
suficientemente granular e os metadiretórios não são extensamente
implantados e não operam em tempo real. Algo baseado em padrões,
como federação, oferece um conjunto de capacidades que a
qualificam como uma boa escolha especificamente para a integração
com um aplicativo ou serviço externo. Apesar do baixo acoplamento,
opera em tempo real e não por meio de programação, simplificando o
provisionamento e o (des)provisionamento. As relações de confiança
da federação possuem alto nível de granularidade, permitindo à
organização do consumidor expor apenas um subconjunto do dos
respectivos diretórios (baseado em regras); e um mapeamento de
atributos em tempo real para "declarações", reduzindo a necessidade
de mudanças internas de diretório. (vide a Figura 3; para conhecer
mais sobre federação e ADFS “Active Directory Federation Services”,
vide Referências.)
Em contraposição com SaaS, os aplicativos S+S podem ter um serviço
back-end rodando no firewall e, nesse caso, uma única empresa ou
identidade proxy poderia ser transferida ao serviço na nuvem. A
integração de identidades é uma capacidade comum de muitos
aplicativos corporativos e, assim, o serviço back-end pode integrar-se
com o Active Directory ou diretórios LDAP (Lightweight Directory
Access Protocol) prontos para usar.
Controle de acesso
O gerenciamento de autorização e acesso é outro aspecto que deve
ser considerado. Muitos aplicativos oferecem capacidades diferentes,
de acordo com o usuário. Por exemplo, um aplicativo que gerencia
despesas pode permitir ao gerente autorizar reembolsos de até
$4.000; valores superiores precisam da aprovação da diretoria.
Atualmente, muitos aplicativos instalados atrás do firewall corporativo
definem permissões de acordo com cada usuário; na verdade, o
aplicativo contém um mapeamento entre o usuário e a respectiva
autorização. Contudo, inúmeras organizações começam a se afastar
das autorizações baseadas em usuário para a autorização baseada em
função. As vantagens são evidentes: custos de administração menores,
autorização consistente de acordo com a função e conformidade
transparente
TI Corporativo Service Provider
(responsabilidades existentes)

que afeta muitos aspectos da TI: dos custos de suporte técnico, • Distribuição de serviço • Distribuição de serviço
Software Convencional

Serviços de Software

produtividade do usuário à segurança dos dados. Também é uma • Gerência de nível de serviço • Gerência de nível de serviço
área para a qual a TI corporativa deveria fornecer uma experiência • Gerência de capacidade • Gerência de capacidade
• Gerência de disponibilidade • Gerência de disponibilidade
de usuário melhor, se comparada à da Internet (e, ainda assim, • Gerência de continuidade de TI • Gerência de continuidade de TI
muitas empresas têm dezenas de diretórios de usuários). Análises • Suporte do serviço • Suporte do serviço
feitas por organizações especializadas atestam, com freqüência, que • Suporte técnico • Suporte técnico
• Treinamento • Treinamento
as redefinições de senha são responsáveis por 30%, em média, das
chamadas de suporte técnico.
A adição de um serviço acabado, com o seu correspondente
Novos desafios na adoção

diretório externo, exige extensões do processo de provisionamento e

dos serviços de software

• Integração
(des)provisionamento, ainda que este seja um processo humano. Por • Gerência de identidades
exemplo, quando um funcionário sai da empresa, muitas • Dados
• Operações
organizações lutam para concretizar o (des)provisionamento ou
• Segurança
desativação de contas internas em tempo hábil; o risco de exposição • Gerência de contratos
no caso de um aplicativo ou serviço externo é significativo porque • SLAs
não há firewall corporativo que impeça o usuário de ter acesso ao • Conformidade

aplicativo e aos seus dados.

THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net 19

 Implicações do Consumo de Software + Serviços do TI Corporativo
Figura 3: Integração de identidades oferecidas por federação:
Rede Corporativa Provedor do Serviço
Servidor de Servidor de
federação federação
Serviços
Servidor de
de autenticação
diretório
Usuário final
Servidores de
aplicativo
Quando um serviço acabado possui vários níveis de autorização,
existem duas opções: atribuir a alguém da empresa a tarefa de mapear
manualmente os usuários e respectivos níveis de autorização, ou
ampliar o modelo interno baseado em funções para o aplicativo
externo. O primeiro quase sempre acaba no suporte técnico: um custo
oculto da adoção de serviços acabados. O último, mapear uma função
externa para um aplicativo externo, poderia ser feito por meio da
federação; por exemplo, a associação de um grupo do Active Directory
poderia ser mapeada para um par nome-valor em um cookie, utilizado
pelo aplicativo externo.
A autorização no bloco de construção ou nos serviços vinculados (o
híbrido Software + Serviços) poderia seguir o modelo federação e, na
verdade, as seguintes vantagens poderiam ser obtidas: gerenciamento
estrito da integridade no provedor do serviço e isso poderia ajudar na
conformidade. Quanto mais flexível o modelo do S+S, maior a
possibilidade de a autorização ser executada por um servidor local,
antes de qualquer solicitação do serviço externo. Ter controle local da
diretiva e de sua aplicação significa que a empresa tem condições de
reagir às mudanças do negócio mais rapidamente. Além disso,
simplifica a integração: a empresa pode modificar a configuração da
parte local do aplicativo do fornecedor para adaptá-lo ao seu
ambiente.
Resumo das implicações do gerenciamento de identidades e
acesso
"
Se o serviço externo depende da identidade do usuário (muito
provável para SaaS, possível para S+S), o provisionamento e o
(des)provisionamento precisa ser ampliado. A integração poderia
ser feita por um processo tecnológico ou manual e ambos
possuem implicações de custo.
"
As diretivas para conta de usuário do provedor de serviços
precisam ser avaliadas comparando-as com as diretivas internas
(por exemplo, complexidade da senha, bloqueios, etc.).
Dados
É pouco provável que haja um aplicativo de linha de negócio isolado
como uma ilha, ainda que seja de origem externa. Um bom exemplo é
a folha de pagamento. O provedor de serviço de folha de pagamento
20
precisa de dados não processados: nome do funcionário, valor do
pagamento, etc. para o processamento mensal da folha. Neste
exemplo, os dados poderiam ser fornecidos por meio de um simples
extrato das informações relevantes do sistema interno de RH.
Obviamente, enviar por e-mail um arquivo XLS ou CSV para o
provedor da folha de pagamento não oferecerá os níveis de segurança
e confidencialidade exigidos; assim, é preciso ter outra forma para a
troca de dados e espera-se que o setor de TI ofereça essa alternativa.
Em outras palavras, a área de TI se defronta com o projeto de
integração de aplicativo corporativo (EAI).
Pela perspectiva de EAI, o bloco de construção e os serviços vinculados
devem ser de fácil integração; afinal, são projetados para o consumo
de desenvolvedores como extensões de um aplicativo local. O
Exchange Hosted Services for Filtering é um exemplo de serviço
vinculado (para mais informações sobre o Exchange Hosted Services,
vide Referências). A integração nessa situação possui duas partes:
1. DNS: Registro MX modificado para apontar para o provedor de
serviços (Microsoft neste caso)
2. Regras de firewall alteradas para só permitir a entrada de SMTP
do provedor de serviço (aumentando a segurança).
Como o foco deste artigo é a infra-estrutura, não me aprofundarei em
mais detalhes sobre a EAI. Contudo, analisaremos as implicações da
infra-estrutura para dados de algumas outras perspectivas:
"
regras e filtros de firewall
"
criptografia e assinatura
"
visão do usuário
Firewall
Para entender as implicações de firewall no consumo de serviços
acabados, precisamos investigar quais aplicativos internos serão
integrados ao serviço de software e qual a forma de integração.
Quantos aplicativos internos devem ser integrados: um ou vários?
Quais regras de firewall precisam ser criadas para permitir a publicação
e o fluxo de tráfego? Se os aplicativos estão trocando XML, esse
procedimento precisa ser validado no firewall e o firewall pode
fornecer essa capacidade? Os dados precisam se integrar com alguma
forma de workflow e, se assim for, como esse workflow abrange a
infra-estrutura interna/externa? Se a integração acontecer sobre HTTP
(SOAP, por exemplo), pode haver algumas implicações no firewall além
da criação de regras.
Com bloco de construção e serviços vinculados, provavelmente haverá
alguma infra-estrutura de back-end que, naturalmente, passa a ser o
principal enfoque para a integração e segurança dos dados. Na
verdade, alguns fornecedores de SaaS estão percebendo que as
empresas estarão mais abertas à assinatura quando seus dados estão
armazenados no firewall corporativo (assim, estão desenvolvendo seus
serviços acabados para o modelo S+S, instalando um aparelho dentro
das centrais de dados do cliente).
Criptografia e assinatura
A forma mais efetiva de trocar dados criptografados pela Internet é a
de adotar certificados de uma autoridade pública de certificação. Se os
certificados forem instalados em clientes, será preciso ter uma infra-
estrutura de chave pública (PKI - Public Key Infrastructure), com todas
as suas implicações, como gerenciamento do ciclo de vida do
certificado e publicação da lista de revogação do certificado. Não se
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
 Implicações do Consumo de Software + Serviços do TI Corporativo
trata de um empreendimento trivial, mas uma vez concluído, permitirá
à infra-estrutura realizar outras capacidades como e-mail assinado e
autenticação via Smart Card.
Obviamente, com uma infra-estrutura de back-end local em
implementações S+S, provavelmente a criptografia e a assinatura
ficarão muito mais simples (menor número de extremidades).
Visão do usuário
Outra perspectiva sobre os dados é a visão do usuário. Certo ou
errado, muitas pessoas querem continuar a trabalhar com as
ferramentas com as quais estão familiarizados: aplicativos do Microsoft
Office. Analise o número de vezes que um novo aplicativo não alcança
todo o seu potencial porque os usuários do negócio insistem em
extrair os dados e usar o Excel para a administração diária. Raramente
esses dados voltam para o aplicativo. Vários fornecedores
independentes de software iniciaram a construção de seus clientes de
aplicativo como OBAs (Office Business Applications) utilizando
essencialmente o Office como plataforma de aplicativos. Em geral, isso
resulta na adoção mais rápida e em menor sobrecarga de
treinamento, mas representa problemas de implantação e manutenção
para a área de TI. Pontos a serem considerados: O serviço de software
oferece todas as capacidades que o negócio exige ou os usuários
precisarão extrair os dados para serem manipulados/analisados em
ferramenta ou sistema local? A adoção do serviço de software resultará
na construção de mais aplicativos departamentais em Access e Excel?
Operações
O problema da integração operacional na obtenção externa de
aplicativos ou serviços é incongruente, de certa forma: afinal, o
principal benefício de ser um consumidor é que as operações ficam
sob a responsabilidade do provedor e, no entanto, as operações e os
processos internos serão impactados pelo aplicativo ou serviço
externo, em várias áreas, sendo as mais significativas o suporte técnico
e o treinamento do usuário.
Resumo das implicações de dados
"
Análises serão necessárias para determinar as necessidades de
integração de dados e ETL.
"
Regras de firewall talvez sejam necessárias para permitir a
integração.
"
O firewall talvez precise ser atualizado para possibilitar a filtragem
dos dados do aplicativo (por exemplo, validação de esquema
XML).
"
Talvez seja preciso comprar certificados ou implementar PKI para
dar suporte às exigências de autenticação, criptografia e
assinatura.
Suporte técnico
Muitos consumidores se sentem frustrados pela ineficiência e
confusão existentes nas centrais de chamadas. Para evitar problemas
similares, as equipes internas do suporte técnico devem ser
informadas sobre os novos aplicativos e serviços a serem integrados às
operações de TI. Os usuários corporativos dependem de inúmeros
sistemas internos de TI para acessar um aplicativo externo: rede, DNS,
servidores proxy. O suporte técnico corporativo é responsável pelo
atendimento desses itens e não o provedor de serviços. Muitas
organizações percebem, agora, a importância de simplificar o
processo de suporte do negócio e fornecer, por exemplo, um único
número de telefone e um site intranet para fazer a comunicação com
a equipe adequada, de primeira linha.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Treinamento
O treinamento do usuário é um aspecto importante na introdução de
qualquer aplicativo novo, independentemente do local em que está
hospedado. Os serviços acabados têm uma vantagem: em geral, o
provedor oferece treinamento quando necessário. Contudo, a
empresa tem pouco controle sobre a qualidade desse treinamento e,
treinamento sofrível aumenta o custo do suporte e reduz a
produtividade do negócio. A introdução de atualizações como parte
do serviço, um dos benefícios de ser assinante de serviços acabados, é
outro problema em potencial: se a empresa não tem a capacidade de
adiar a implementação da atualização até que todo o pessoal tenha
sido treinado, o suporte técnico interno talvez tenha de lidar com
picos de chamadas de suporte. Uma questão correlata é se os recursos
individuais do serviço acabado podem ser desativados de modo
seletivo: Se a capacidade já estiver disponível internamente, o TI
precisa certificar-se de que todos os usuários estejam utilizando essa
capacidade interna.
“QUANTO MAIOR A IMPORTÂNCIA DO
APLICATIVO PARA O NEGÓCIO, MAIS
IMPLICAÇÕES PRECISARÃO SER
CONSIDERADAS. UM APLICATIVO DE LINHA DE
NEGÓCIO DISTRIBUÍDO COMO SERVIÇO
ACABADO REPRESENTA TAREFA DE
INTEGRAÇÃO SIGNIFICATIVA".
Implantação
Se o serviço acabado utilizar o navegador como seu cliente, aplicam-
se os cuidados normais de compatibilidade: versão do navegador e
configurações de segurança, mais os plug-ins instalados e respectivas
versões. Com um aplicativo convencional, a empresa pode determinar
quando passar para a nova versão, o que é de importância crítica, caso
a nova versão exija o navegador mais recente. Quando o aplicativo é
externo, esta opção talvez não esteja disponível.
Se o cliente do serviço não tem o navegador como base, a área de TI
interna será responsável pela implantação e por suas implicações
(testes de compatibilidade, planejamento de implantação, distribuição,
etc.).
Se for um serviço de bloco de construção ou vinculado, será preciso
implantar infra-estrutura de back-end na central de dados da empresa
ou do cliente ou em ambos. Para a implantação de back-end, existem
desafios comuns não funcionais: Qual servidor, rede e capacidade de
armazenamento são adequados para a carga? Podem ser utilizados
serviços compartilhados como o servidor SQL existente ou os web
farms do servidor? De que forma são fornecidas flexibilidade e
capacidade de recuperação de desastres? Podem ser
executadas em várias centrais de dados? As respostas dependerão
mais dos componentes do local do aplicativo do que do serviço
vinculado na nuvem: ou seja, podem ser abordadas, em grande parte,
como uma implantação de back-end normal.
Operações do provedor/continuidade do negócio
É tentador concentrar-se simplesmente no conteúdo do SLA quandose
trata de selecionar, monitorar e avaliar um provedor de serviço. É
importante considerar como o SLA será formalizado: um SLA que
estabeleça que o serviço será restaurado em 24 horas após o desastre
parece bom em princípio; entretanto, a definição de desastre e a
forma de restauração têm importância crítica. Para o consumidor do
serviço, desastre pode ser a exclusão acidental de registros do
21
 Implicações do Consumo de Software + Serviços do TI Corporativo

aplicativo, mas provavelmente o provedor do serviço terá uma visão
diferente. Analisando melhor este exemplo, a restauração de dados do
aplicativo é um processo complicado para muitos aplicativos
corporativos. Por exemplo, restaurar uma única caixa de correio ou
mensagem do Exchange ou um simples site ou documento do
Sharepoint era um desafio significativo, até o amadurecimento destes
aplicativos. Agora, aplicar esse desafio a um aplicativo SaaS com vários
locatários, ainda que restauração granular seja possível, fará com que
o provedor fique relutante, devido aos custos operacionais.
Outra preocupação que ouvi de vários arquitetos trata do risco de o
provedor do serviço falir ou reter dados para evitar a migração para
um concorrente. Colocar o código do aplicativo em garantia é uma
etapa na direção correta mas, na verdade, não é suficiente.
Resumo das implicações de operações
"Os procedimentos de suporte técnico precisam ser atualizados
para a execução de diagnóstico de primeira linha para aplicativos
novos e os processos de escalação precisam ser definidos com o
provedor do serviço.
"Revisar os SLAs do suporte técnico interno para confirmar se ainda
podem ser atendidos quando dependentes do provedor de
serviço para suporte escalado.
Pressupondo que um consumidor corporativo pudesse obter esses
dados, reconstruir o aplicativo na central de dados sem instalar
instruções ou dar acesso aos desenvolvedores talvez não seja viável.
Ainda não há uma solução para isso: é uma questão de ter confiança
no provedor, que este fará a coisa certa caso aconteça o pior, e de que
o provedor tenha boas qualidades de administrativas e comerciais.
Emissão de relatórios
Como com qualquer SLA, os grupos comerciais e de TI devem analisar
os relatórios de desempenho e investigar quais os pontos não
atendidos pelos SLAs.
Regulamentos e obrigações legais
Proporcionar conformidade com regulamentos e obrigações legais
terá um impacto na infra-estrutura e garantir a conformidade de um
processo do negócio, que abrange sistemas internos e serviços
externos, pode ser especialmente desafiador. Além disso, apresenta
uma solução em potencial com referência à conformidade: se o
aplicativo ou o serviço estiver alinhado com o setor, existe uma boa
possibilidade de estar de acordo com os regulamentos relevantes dos
principais mercados; este talvez não seja o caso de serviços genéricos.
Mesmo em situações nas quais a conformidade é um ponto de venda
do serviço, as diretivas de segurança interna da empresa ou as leis
específicas da região, como as de proteção de dados do parlamento
europeu (European Parliament Data Protection Laws), podem ser
incompatíveis com as políticas do provedor de serviço.
Propriedade de dados
Obviamente, as empresas desejam manter a propriedade dos dados
do negócio, sempre; o contrato deve definir isso, explicitamente. Além
do mais, seria prudente confirmar que os dados podem ser extraídos
quando solicitado.
Privacidade
As empresas devem avaliar cuidadosamente as diretivas de privacidade
e as condições de uso do provedor para confirmar se seus dados são
mantidos em confidencialidade e não são utilizados para marketing
nem vendidos para terceiros, especialmente importante nos casos em
que os serviços acabados têm o suporte de anúncios publicitários.

Tabela 1: Resumo das recomendações

Gerenciamento "Considerar se é válido adotar o suporte de federação nos critérios de seleção de provedor.
de identidade "Analisar se a administração baseada em funções é uma forma de reduzir complexidade e custo.
e acesso
"O caso de negócio para integração deveria ser construído sobre segurança aprimorada para obter conformidade além da
redução de custo.
"Iniciar um período de amadurecimento nas tecnologias de identidade, como federação e CardSpace.
"Produzir uma arquitetura para simplificar a integração de identidades dos serviços de software futuros.

Operações "Incluir exigências para padrões abertos (por exemplo, WS-*) nos critérios de seleção de provedor.
de dados "Induzir o monitoramento leve do serviço para dar suporte à medição do SLA.
"Se os dados ficarem residentes no provedor, determinar se restaurações físicas são necessárias/possíveis.
"Avaliar o uso de frameworks operacionais formais (por exemplo, MOF/ITIL) nos critérios de seleção de provedor.
"Confirmar se não há dúvidas sobre a estrutura de custos relativa às operações (por exemplo, existem custos adicionais para
restaurações, relatórios, etc.).
"Avaliar se o provedor oferece treinamento. É de boa qualidade e disponível em todos os idiomas necessários? Quanto demora
para receber material atualizado quando um novo recurso é lançado?
"Se for preciso implementação no cliente, decompor a programação de lançamentos do provedor (patches e versões novas) nos
processos e planos de engenharia dos desktops existentes.
"Avaliar as necessidades da implantação e suas dependências (por exemplo, testes de compatibilidade do aplicativo de desktop,
espaço na central de dados, compra de produtos de integração).
"Peça aos seus desenvolvedores para avaliar a documentação entregue pelo provedor. É de boa qualidade e disponível em todos
os idiomas necessários?
"Analisar a flexibilidade, as políticas e os procedimentos de recuperação de desastre do provedor.
Regulamentos/ "Determinar se a conformidade se aplica ao provedor e, em caso afirmativo, decidir quais relatórios/diretivas/credenciais são
legal necessários para comprovar a conformidade.
"Considerar a automatização da criação de relatórios de conformidade híbridos: interno e do provedor. Isso pode significar que
o provedor de serviço tenha de expor APIs de relatório e não apenas fornecer um relatório estático.
"Se os dados ficarem residentes no provedor, analisar o contrato para confirmar que você detém a propriedade dos dados.
"Estender os seus dados de arquitetura de integração para dar suporte à integração do serviço externo. Adicionar credenciais de
segurança para os critérios de seleção de provedor.

Geral "Criar uma arquitetura de integração de infra-estrutura para oferecer um framework para a integração do serviço de software.

22 THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

 Implicações do Consumo de Software + Serviços do TI Corporativo
Figura 4: Mapa de calor (heatmap) das considerações
Propriedade Conformidade SLAs
de dados contratuais
Aplicativos de linhas de negócios
Aplicativo tático
Considerar obrigatoriamente
Resumo das implicações legais
"A conformidade pode se estender ao provedor de serviço; como é
possível provar a conformidade ainda assim?
"Os relatórios de conformidade podem representar um custo.
Programas-selo de privacidade podem ser úteis para definir a
credibilidade de um provedor; os provedores licenciados da TRUSTe,
por exemplo, terão uma diretiva publicada e foram auditados por
firma independente, para garantir a conformidade com um conjunto
de princípios de privacidade.
Conclusão
Atualmente, o mercado de SaaS está repleto de ofertas destinadas aos
consumidores e às empresas de pequeno porte, pois este segmento de
mercado se beneficia do modelo de distribuição, sem a necessidade
de integração. Consumir um aplicativo de linha de negócio desses
provedores é arriscado para qualquer empresa, pois muitos dos pontos
de integração discutidos neste artigo não serão abordados.
Quanto maior for a importância do aplicativo para o negócio, mais
implicações deverão ser consideradas. Um aplicativo de linha de
negócio distribuído como um serviço acabado representa tarefa de
integração significativa se comparada ao pouco esforço associado à
aplicação tática em que a principal preocupação refere-se a questões
contratuais como a propriedade dos dados. O mapa de calor da
relação está representado na Figura 4.
Referências
European Parliament Data Protection Laws
http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm
Exchange Hosted Services
http://www.microsoft.com/exchange/services/default.mspx
“IT Doesn't Matter,” Nicholas G. Carr, Harvard Business Review,
Maio, 2003
http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_
detail.jhtml?id=R0305B
The Long Tail: Why the Future of Business Is Selling Less of More,
Chris Anderson (Hyperion, 2006
Microsoft Privacy Guidelines for Developing Software Products
and Services
http://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-
6e87-48f5-83ec-a18d1ad2fc1f&displaylang=en
Microsoft Regulatory Compliance Planning Guide (embora este guia
tenha como enfoque a área de TI interna, pode também ser útil para
avaliação de um provedor externo)
http://www.microsoft.com/technet/security/guidance/
complianceandpolicies/compliance/rcguide/default.mspx?mfr=true
WS-Federation é uma versão do padrão OASIS, adotada por vários
fornecedores incluindo Microsoft, IBM, RSA, BEA e VeriSign. O suporte
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Credenciam. de API's de Web Integração de Integração de RBAC
Segurança Services Operações Identidades
Deveria considerar
Hoje, os departamentos de TI da empresa têm mais experiência e
confiança no consumo de bloco de construção ou serviços vinculados
do que em aplicativos completos. Seja um "feed" de dados para um
aplicativo rico, como o Reuters 3000, ou um serviço de infra-estrutura,
como o que oferece filtragem de spams, este modelo é bem
compreendido.
Na medida em que o modelo de distribuição SaaS amadurece e ganha
maior notoriedade, torna-se natural um aumento das necessidades
corporativas tais como a integração a ser atendida e, assim, crescerá a
faixa de capacidades para as quais as empresas estão preparadas para
buscar como serviços. O resultado será software mais aplicativos de
serviços: um equilíbrio natural do software instalado no local e serviços
na nuvem.
Como Gianpaolo Carraro e Fred Chong declaram em seu artigo “SaaS:
An Enterprise Perspective”, SaaS e S+S são ferramentas adicionais que
CIOs experientes podem utilizar para oferecer mais valor ao negócio.
Em lugar de sentirem-se ameaçados, os gerentes de IT deveriam
considerar SaaS e S+S pelo que são: modelos de suprimento
alternativo para o benefício do negócio e uma abordagem arquitetural
diferente para as soluções de construção.
Manipulados corretamente, os serviços de software ajudarão a
modificar a percepção que o negócio tem da área de TI.
para o WS-Federation da Microsoft transforma-se em Active Directory
Federation Services (ADFS), um componente do Windows Server 2003 R2
"OASIS
http://www.oasis-open.org/committees/documents.php?wg_
abbrev=wsfed
"Active Directory Federation Services (ADFS)
http://www.microsoft.com/WindowsServer2003/R2/Identity_
Management/ADFSwhitepaper.mspx
Sobre o autor
Kevin Sangwell é arquiteto de infra-estrutura do Developer and
Platform Group da Microsoft. Esteve à frente de vários cargos técnicos
e de liderança no setor de TI por mais de 16 anos, incluindo cinco anos
como consultor principal do setor de Consulting Services da Microsoft.
Kevin foi líder de arquitetura e projeto de infra-estruturas corporativas
e de eCommerce nos setores públicos e privados do Reino Unido,
incluindo a infra-estrutura distribuída da Microsoft para uma
organização com 120.000 usuários e uma plataforma de aplicativos
extranet com 1,2 milhão de usuários educacionais. Como arquiteto de
infra-estrutura, ele presta serviços de aconselhamento e consultoria
para clientes corporativos e se apresenta em eventos internacionais.
23
 Mashups Corporativos
por Larry Clarkin e Josh Holmes
Resumo
Mashup é uma técnica para a construção de aplicativos
que combina dados de várias fontes para criar uma
experiência integrada. Atualmente, há muitos mashups
hospedados em sites da Internet que oferecem
representações visuais de dados abertos ao público. Este
artigo descreve o histórico e a arquitetura dos mashups e
explora como é possível criar mashups para uso na
empresa. Além disso, compartilhamos algum
conhecimento obtido de projetos com clientes e
integradores de sistemas que implementaram mashups
corporativos.
Histórico dos mashups
Os mashups ganharam aceitação nos últimos anos, impulsionados pela
Web 2.0. Inicialmente, os mashups adotaram dados de fontes como
Craigslist (http://www.craigslist.org), combinando-os com serviços de
mapeamento ou fotografia, para criar visualizações dos dados (por
exemplo, http://housingmaps.com). Muitos desses primeiros mashups
tinham o consumidor como objetivo mas, em anos recentes, a
empresa também começou a se interessar e aceitar os mashups
corporativos. As organizações começam a perceber que podem
colocar seus serviços bem definidos para produzir bits distintos de
lógica do negócio com outros serviços existentes, internos ou externos
à organização, para fornecer visões novas e interessantes dos dados.
Figura 1: Arquitetura de um aplicativo mashup típico
Serviços de
Web Services “Feeds” RSS Plataforma
Aplicativo
mashup
Dados
Aplicativo cliente
24
Na medida em que as técnicas para a criação de mashups
amadureceram, começamos a ver nas empresas a construção de
modelos do negócio baseados em mashups. No mercado imobiliário
norte-americano, Redfin (http://www.redfin. com) e Zillow
(http://www.zillow.com) utilizam grandes volumes de dados
imobiliários, públicos e privados, (de fontes como autarquias de
registro municipais e Multiple Listing Service) combinados com
serviços internos de "valor agregado", cujo resultado é apresentado ao
usuário em um mapa (utilizando o Virtual Earth da Microsoft e o
Google Maps, respectivamente). Há muitos outros tipos de infomações
que podem ser acrescentadas a um site do setor imobiliário: outras
listagens similares, informações sobre escolas e hospitais locais, índices
recentes de criminalidade, classificados para colocações de trabalho e
muito mais.
Arquitetura de um mashup prototípico
Embora haja grande variação na IU e nas fontes de dados de muitos
mashups, ainda assim podemos derivar padrões arquiteturais comuns,
compartilhados por todos. Por exemplo, todos os mashups são de
natureza RESTful (obedecem aos princípios do protocolo de
transferência de estado representacional). A Figura 1 ilustra um
processamento arquitetural de um mashup típico.
Dados
Dados agregados e apresentados ao usuário são o principal elemento
de qualquer mashup. Embora o diagrama acima descreva a fonte de
dados como um banco de dados, o conceito de mashup não exige
esse recurso no local, nem para o software mashup nem para o cliente.
Os dados podem vir estritamente dos Web Services em que são
serializados para XML ou JSON (este é o padrão mais comum em
mashups baseados em Internet). Existem compensações arquiteturais a
serem feitas, do armazenamento de dados primários no local ao
acesso aos dados feito a cada solicitação. Na medida em que os
mashups deixam de ser aplicativos baseados em Internet para serem
internos à empresa, tendem a depender menos dos locais externos de
armazenamento de dados.
"Feeds" RSS
O uso de "feeds" RSS (Really Simple Syndication) é uma fonte comum
de dados primários ou suplementares para mashups. Os "feeds" RSS
são fáceis de serem consumidos pois são documentos XML e muitas
bibliotecas existem para manipular esses "feeds". O formato e a
especificação de RSS está bem documentada e entendida com apenas
poucas variações de uma versão para outra. A extensibilidade do RSS
também é bastante conhecida, como demonstra a quantidade de
extensões em uso atualmente, como a adição de vínculos aos "feeds",
informações de localização e licenciamento da Creative Commons.
Web Services
É também comum incluir chamadas para Web Services dentro dos
mashups. É fácil ver Web Services baseados em WSDL e outros,
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

Figura 2: Uso do BizTalk Services como um serviço de plataforma
para a transmissão de informações
“BizTalk Services”
Serviço de
Identidade
Confiança
Serviço de
Autenticar 3
conectividade
Abrir
Conectar
2 Direção futura dos mashups
4 Conexão
Confiável
Serviço
Cliente
baseados em REST, com alguns serviços expondo os dois estilos. Os
Web Services podem ser usados para oferecer dados adicionais ou
transformar os dados submetidos ao mashup. Para um mashup
baseado em mapa, os dados só podem conter endereços de ruas e
uma chamada para Web Service baseado em WSDL ou REST pode ser
feita para converter o endereço de rua em uma coordenada
longitudinal/latitudinal para o mapa.
Serviços da plataforma
A Figura 2 representa uma classe especial de serviços, usadas para
criar mashups. Estamos chamando estes serviços de plataforma
porque fornecem funcionalidade além do modelo típico
solicitação/resposta dos Web Services tradicionais. Um exemplo típico
disso é o mapeamento de serviços fornecido pelo Virtual Earth. Inclui
uma lista completa de capacidades de processamento dos dois lados,
cliente e servidor, assim como "serviços na nuvem". Estamos
presenciando o surgimento de serviços de bloco de construção
baseados na nuvem que começam a criar valor. Por exemplo, o serviço
Amazon S3 oferece armazenamento "na nuvem": facilita a exposição
de todos os dados estáticos por meio de upload para provedor de
armazenamento hospedado. O BizTalk Services da Microsoft é uma
plataforma de serviços que oferece uma capacidade diferente:
transmite comunicações da Internet por meio de um firewall
corporativo e, assim, expõe serviços internos para o consumo de
parceiros de negócio ou terceiros que constroem os próprios mashups
corporativos. Comunicações transmitidas como fornecidas pelo BizTalk
Services é também um serviço útil mesmo dentro de uma única
empresa, com muitas unidades de negócio ou com inúmeros
segmentos de rede. Uma transmissão de comunicações baseada em
Internet pode eliminar a topologia de rede física como um obstáculo
às comunicações.
Aplicativos mashup
Até este pondo, identificamos muitos tipos de serviços que podem ser
utilizados na criação de mashups, mas não abordamos a importância
do software que cria e distribui a experiência de mashup. Pense no
aplicativo mashup como uma combinação de serviços de camada
intermediária e de lógica leve do negócio. Para mashups baseados na
Internet, o software é usualmente escrito utilizando tecnologias web
(como PHP ou ASP. NET), mas estamos começando a ver a demarcação
entre o processamento do servidor e a indefinição do aplicativo
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Mashups Corporativos
cliente, com o surgimento das Rich Internet Applications (RIAs). As
RIAs são aplicativos executados no navegador com funcionalidade
rica, similar àquela de muitos aplicativos de desktop. Tipicamente, não
exigem uma instalação do lado do cliente, além de um plugin
genérico, como o Adobe Flash ou Microsoft Silverlight.
Aplicativo cliente
O mashup é distribuído e apresentado ao usuário como aplicativo
cliente. Para mashups públicos de Internet, o aplicativo cliente mais
comum é um navegador web que recebe HTML e JavaScript
distribuídos de um servidor web sobre HTTP. Contudo, começamos a
ver mashups sendo distribuídos também com plataformas RIA. Neste
modelo, o cliente pode fornecer mais riqueza visual e até algum
processamento do mashup no lado do cliente.
1 Autenticar
Nas primeiras versões dos mashups, grande parte da implementação
era muito entediante e demorada. Muitos deles usavam o
processamento do lado do servidor (quase sempre com PHP ou PERL)
e o cansativo scripting do lado do cliente, na forma de JavaScript, para
criar a experiência de mashup. Era comum para a pessoa que criava os
mashups criar código personalizado para analisar os conjuntos de
retorno XML que recebiam das respectivas fontes de dados.
Na medida em que o tempo passou e o processo de desenvolvimento
amadureceu, uma boa parte do trabalho entediante de codificação foi
substituída por frameworks e melhores padrões de codificação. Os
scripts personalizados no lado do servidor começam a serem
substituídos por bibliotecas padronizadas que automaticamente
gerarão o necessário script do lado do cliente. Presenciamos também
a padronização dos formatos de mensagens. Um exemplo disso é a
extensão GeoRSS, para o padrão RSS, que permite especificar a
longitude e a latitude correlatas dos itens do "feed". Os três principais
provedores de serviço de mapeamento (Google, Microsoft e Yahoo)
são compatíveis com GeoRSS e isso significa que os mashups com essa
extensão RSS praticamente não exigem codificação.
A criação de mashups foi domínio exclusivo do desenvolvedor, mas
existe um movimento para colocar a habilidade de criar mashups
diretamente nas mãos do cliente final. Como os frameworks para criar
mashups tornam-se cada vez mais simples de usar e os formatos de
mensagens tornam-se mais padronizados, o próximo passo lógico será
o de construir ferramentas que possam criar mashups. Algumas dessas
ferramentas serão destinadas ao consumidor final dos mashups. Pipes
da Yahoo e Popfly da Microsoft são exemplos de frameworks e
ferramentas que permitem aos usuários criar os próprios mashups.
Observamos um crescimento na importância do esquema comum e
dos metadados no desenvolvimento de mashups. Na seção anterior,
descrevemos como o esquema comum dos "feeds" RSS facilitam a sua
incorporação nos mashups. Os mesmos princípios também precisarão
ser aplicados a outros tipos de dados (robusto como é o RSS, não é
possível modelar todos os dados nesse formato). Atualmente, já
observamos o surgimento de outros esquemas-padrão, como a
linguagem de marcação de keyhole (KML - Keyhole Markup
Language) para descrever dados geoespaciais. Ainda mais interessante
será o Microformats, framework de grante potencial, destinado à
distribuição de significado semântico, que pode ser facilmente lido
por software do tipo mashup.
Mashups na empresa
Uma ótima forma de explorar mashups na empresa é com um
exemplo. Imagine-se arquiteto de aplicativos de um sistema de call
center que recebe chamadas sobre assistência técnica de garantia e
peças sobressalentes. Utilizando o número de telefone do chamador,
25
 Mashups Corporativos
poderíamos exibir os registros desse usuário, incluindo um histórico
de compras. Esse interessante aplicativo já está implementado em
muitas centrais de chamadas, atualmente. Mas e se, além de pesquisar
as informações do cliente, pudéssemos plotar o número do telefone
em um mapa, utilizando um serviço disponível ao público e também
exibir uma lista de centros de assistência técnica do local ou
fornecedores de peças dos produtos incluídos no mapa? Com esses
dados em mãos, poderíamos responder as perguntas dos clientes em
segundos. E se também pesquisássemos as condições atuais do tempo
nessa área ou as equipes de esportes do local e os resultados dos seus
jogos recentes como início de conversação ou passatempo em
chamadas de longa duração?
Utilizando este exemplo, a Figura 3 apresenta um mashup simulado
de atendimento ao cliente que poderia ser usado por um atendente
no momento do recebimento de uma chamada. Combinando dados
de serviços públicos (como a previsão do tempo e o noticiário) com
fontes de dados internas (um blog de alertas do atendimento ao
cliente e um banco de dados de locais de assistência técnica), este
aplicativo combina os elementos de mashup com a acessibilidade de
um portal.
Como mostra a Figura 3, o mashup incorporado coloca um volume
extraordinário de informações nas mãos do agente do serviço de
chamadas: dos principais itens de serviço, para que as perguntas
possam ser rapidamente respondidas, até pesquisas reversas de
chamadas passadas para ter assunto para iniciar uma conversação. Este
tipo de mashup é estritamente interno mas proporciona valor
significativo na primeira chamada, com qualquer cliente.
Existem vários elementos-chave para o êxito deste mashup. Acima de
tudo, deve ser contextual à tarefa em questão. Em segundo lugar,
deve dar prioridade às informações na ordem em que,
provavelmente, serão mais úteis. É preciso saber com quem estamos
lidando, quais produtos estão registrados, quais os principais itens do
serviço que se destinam a esses produtos e, então, começar tentando
responder as perguntas do usuário como, por exemplo, qual o
Figura 3: Exemplo de mashup para a nossa central de chamadas
26
endereço dos centros de assistência técnica do local do cliente. Em
terceiro lugar, após sabermos as informações e a localidade do cliente,
cada um dos
painéis de conteúdo são independentes e não exigem interação com
as outras partes. Esse procedimento permite reunir e agregar os dados
de cada uma das partes a serem executadas, de modo assíncrono.
Concretizar o retorno sobre o investimento (ROI) é uma preocupação
comum das implantações da arquitetura orientada a serviço (SOA).
Muitas organizações consideram difícil justificar o investimento inicial
da criação de serviços para diferentes funcionalidades, quando seria
mais fácil criar um aplicativo simples. Os mashups corporativos são um
grande exemplo de como um investimento em SOA pode
proporcionar grande valor. (Vide na barra lateral "Mashups deliver ROI
for IDV Solutions".)
Aproveitar os serviços já construídos por você
O retorno imediato de uma SOA pode ser concretizado quando as
organizações começam a mesclar e fazer a correspondência desses
serviços entre objetivos novos e existentes. Pode ser instigante iniciar
o aproveitamento dos serviços ou aplicativos nos modos jamais
imaginados no momento em que foram escritos. (Vide na barra lateral,
“Quicken Loans leverages mashups for fast results” - Quicken Loans
aproveita mashups para resultados mais rápidos)
Aproveitar os serviços construídos por terceiros
É importante compreender que não se pode ter todas as informações
do mundo e que há um retorno sobre o investimento bastante alto
quando você simplesmente aproveita o trabalho árduo de outra
pessoa, em lugar de reinventar a roda.
Construir serviços que terceiros possam aproveitar
Outra oportunidade para as empresas, na medida em que os mashups
tornam-se cada vez mais populares, é a de construir serviços que
possam ser facilmente consumidos por aplicativos mashups. Voltando
ao exemplo que citamos, o atendente do serviço de chamadas pode
deixar o cliente feliz informando o endereço da loja
mais próxima. Mas, imagine se as próprias lojas
expusessem seus inventários e disponibilidade de
produtos para o mashup. Agora, o atendente do
serviço de chamadas pode fornecer informações
ainda mais detalhadas e valiosas ao cliente. Esse tipo
de serviço seria importante para o cliente, para a
central de chamadas e para a própria loja.
Plataforma ágil
Como discutido anteriormente, muitos mashups
foram criados para distribuição na plataforma web
baseada em padrões (HTML e Java Script). Isto não é
uma limitação dos próprios mashups, mas apenas a
forma padrão de distribuir aplicativos na Internet. À
medida que vemos os mashups entrarem na empresa,
observamos também um número crescente de
mashups construídos em plataformas RIA (como o
Flash da Adobe e o Silverlight da Microsoft) e até
mesmo o surgimento de mashups para desktop ricos,
completos, construídos em Windows Presentation
Foundation. O processamento em 3-D completo, em
plataforma de cliente rica, pode aumentar o apelo
visual do mashup. Os mashups corporativos podem
aproveitar totalmente essas plataformas mais ricas
pois muitas terão maior controle dos desktops.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

A Quicken Loans aproveita os mashups para resultados
rápidos
Durante a confecção deste artigo, falamos com Keith Elder da
Quicken Loans. Keith é arquiteto de um aplicativo interno que
utiliza mashups e serviços existentes para oferecer qualidade rápida
aos seus clientes. Esses serviços foram construídos nos últimos anos
como parte da iniciativa SOA da empresa.
Levamos informações e combinamos nossas telas com base em
todos os tipos de serviços. Nossos usuários finais não têm idéia de
que estamos aproveitando os serviços de toda a empresa para
extrair dados, verificar a validação de endereço, visualizar a
atividade de chamadas, enviar faxes e muito mais. Para os membros
de nossa equipe, o aplicativo é apenas um produto apropriado que
lhes fornece a funcionalidade que precisam, na hora em que
precisam.
Keith acrescenta que na Quicken Loans falou-se muito, no início,
sobre a granularidade dos serviços ali construídos. Existem
compensações a serem feitas entre os serviços de uso específico e
aqueles de multiuso. Eles escolheram os serviços de uso específico,
que ofereceram funcionalidade bastante específica. Houve uma
compensação: talvez tenham de chamar vários serviços como parte
de um único mashup.
Tempo de resposta rápido
Se você estiver aproveitando Web Services existentes e serviços de
plataforma robustos, o tempo de desenvolvimento dos mashups pode
ser medido em horas ou dias, em lugar de semanas ou meses . O
tempo de resposta rápido dos mashups pode mudar a forma de
interação dos departamentos de TI com os usuários em suas organiza-
ções. O desenvolvimento conjunto e as várias iterações dos aplicativos
entregues a curto prazo podem tornar-se metas mais realistas.
Visualização rica dos dados de seus usuários
O maior benefício obtido pelos mashups é, talvez, a visualização que
criam para os usuários. Os dados de natureza visual são muito mais
fáceis de entender e podem criar maior significado para o cliente. Isto
não se limita aos exemplos de mapeamento que discutimos até agora.
Outras técnicas, como os mapas de calor e os mapas em árvore,
também podem ser criadas como visualizações de dados em mashups.
Principais fatores de sucesso
Procure serviços utilitários de consumo (simples e não complexos).
Quanto mais coisas um determinado serviço faz, mais difícil será o
amálgama com outros serviços. Os serviços certos fazem uma coisa e
fazem isso muito bem. Por exemplo, um serviço cujo resultado inclui
dados de pessoal com seus endereços, empréstimos, automóveis, trens,
aviões e automóveis pode estar oferecendo um volume de dados
muito grande. Talvez você queira criar um subconjunto do serviço cujo
resultado traga apenas nomes e endereços para o mashup, pois é uma
perda de largura de banda e de processamento extrair dados que não
serão utilizados.
Manter os mashups no modo somente leitura
Os mashups são visões ágeis dos dados que apresentam. Não são uma
superfície de edição toda-poderosa, capaz de editar todas as informa-
ções recebidas. Se alguém quiser editar esses dados, deverá voltar para
o aplicativo que criou os dados para tal. O mecanismo para a edição
deve ser óbvio também. Este procedimento reduzirá drasticamente a
complexidade (e aprimorará a agilidade dos aplicativos mashup.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Mashups Corporativos
A atualização dos dados é importante
As decisões do negócio serão tomadas com base nos mashups
corporativos. Extrair dados de várias fontes pode ser perigoso, pois os
dados podem estar ultrapassados. Como com qualquer relatório que
sirva de base para decisões, é importante ter carimbo de data/hora
para identificação da última atualização. Esta característica aprimorará
muito a clareza e a utilidade dos dados do mashup e a confiança com
que as decisões podem ser tomadas.
Não tente resolver os problemas dos dados corporativos
À medida que os mashups entram na empresa, é inevitável incorrer
em fragmentação de dados e questões de normalização, em
decorrência de anos de desenvolvimento de aplicativo legado. Por
exemplo, fazer um mashup de vendas por área geográfica poderia ser
como criar um mashup lógico para o seu gerente geral de vendas.
Mas, e se os dados estiverem armazenados em três sistemas diferentes,
por linha de produto, tendo, cada sistema, diferentes regras de
controle das estruturas de dados e do negócio? Recomendamos
descobrir um candidato melhor para tecnologias de mashup e deixar
que um projeto mais tradicional (como um esforço de consolidação de
sistemas) resolva os problemas mais complexos.
Compreender as questões de autenticação e autorização
Autenticação e autorização podem ser impedimentos imensos para
fazer um mashup de vários serviços, caso todos exijam autenticação de
acordo com esquemas diferentes. Por exemplo, poderá haver
problemas se você tiver um serviço que exija nome de usuário e senha
e, outro, que exija um certificado X509. Essa situação não é
insuperável, mas pode ser uma grande barreira que deve ser
ultrapassada. Existem várias estratégias de ataque a esse problema.
Você pode evitar serviços que exijam autenticação ou autenticação
por métodos incompatíveis com o sistema. Ainda que você possa
iniciar o processo dessa forma, a realidade é que há serviços que você
precisa aproveitar mas que não consegue, sem autenticação. Você
poderia tentar forçar terceiros, ou pagá-los, para oferecer o tipo de
autenticação que lhe seja conveniente. A realidade, entretanto, é que
o seu aplicativo provavelmente terá de ser compatível com a
autenticação do serviço utilizando muitos mecanismos diferentes, e
todos devem ser considerados.
Riscos
Ao implementar mashups, quatro áreas de risco devem ser
consideradas:
Dependências dos serviços
Um dos principais riscos da criação de mashups corporativos ocorre
quando se cria uma dependência dos serviços externa à sua empresa
(como "serviços na nuvem”). Os termos dos acordos de serviço
deveriam ser analisados antes de se criar uma dependência. Por
exemplo, alguns serviços exigem que o software que usa o serviço seja
um site da Internet de acesso público; isto pode ocorrer quando o
serviço tem um modelo de receita baseada em publicidade. Os termos
do serviço também podem estar sujeitos às mudanças, em alguns
casos, de formas que poderiam impedi-lo de usar esse serviço. Para
minimizar essa preocupação, procure provedores de serviço cujo
modelo que se adapte ao seu uso.
Perda de fidelidade dos dados
A perda de fidelidade dos dados exibidos é outro risco-chave. Na
medida em que os dados são visualizados, existe uma tendência de
adaptar os dados aos limites da superfície de apresentação. Haverá
uma tendência natural de não visualizar pequenos volumes de dados
ou de agrupar dados em coleções maiores para economizar espaço na
superfície de apresentação. Isso pode "distorcer" a visão que o usuário
final tem dos dados.
27
 Mashups Corporativos
Mashups geram ROI para a IDV Solutions
Recentemente, falamos com Ian Clemens da IDV Solutions
(integrador de sistemas que desenvolve aplicativos mashups para
clientes corporativos) sobre a velocidade com que os mashups são
desenvolvidos. "Nossos clientes têm experimentado ROI
significativos decorrentes de mashups, não só devido a custos
menores de implementação (se comparados ao desenvolvimento
de software personalizado convencional) mas, também, devido a
aplicativos mais ricos e amigáveis, que simplificam muito os
workflows do negócio", disse Ian.
Política
A política também pode ser um obstáculo à criação de mashups. Se o
serviço foi criado por terceiros, talvez faça (ou não) exatamente o que
você desejou e, para fazer com que o originador do serviço
modifique-o de acordo com suas necessidades, demora muito. Essa
mentalidade não-foi-inventado-aqui é fatal para os mashups. Isso
também se manifesta em confiança. Se não confia no provedor do
serviço, você também não confiará nesse serviço para o seu aplicativo
de missão crítica.
"Consumerização" não controlada
De acordo com um recente relatório do Gartner, Inc. as tecnologias de
consumo estão cada vez mais sendo utilizadas pelas empresas sem
consciência, governança ou TI corporativo. Ferramentas voltadas ao
consumidor têm enfoque rígido na criação e visualização de um
mashup, assim, pode ser muito fácil criar o mashup inicial, mas a
manutenção de mais longo prazo não é considerada. Veja, também,
como seria perigoso ter um usuário final carregando dados
corporativos em uma ferramenta pública de mashup como Pipes ou
Popfly.
Existem muitas formas de minimizar esses riscos. Primeiramente, para
serviços internos ou externos, implemente um contrato de nível de
serviço (SLA) que descreva claramente as responsabilidades das duas
partes, tempos de resposta para requisições de mudança, exigências
de tempo de processamento, restrições de largura de banda e todos
os outros detalhes relevantes. Depois, esquematize as possíveis
exigências de emergência do seu aplicativo, caso haja falha na
chamada de determinado serviço. Para alguns serviços, pode ser
aceitável simplesmente não apresentar esses dados; com outros
serviços, você pode deixar os dados em cache aos quais poderá
recorrer sempre que houver uma falha. Talvez seja preciso ter um
serviço secundário alinhado como backup, a ser chamado caso
alguma coisa horrível aconteça.
Por fim, será preciso abordar as questões e a política de
consumerização. Ao contrário da crescente confiabilidade e
redundância dos serviços, isto exige um processo de governança. Se a
sua organização tiver um processo amadurecido para governar o uso
dos serviços, esse processo também deverá ser aproveitado para a
criação e o consumo de mashups.
Conclusão
Em pesquisa de janeiro de 2007 feita pela McKinsey perguntou-se a
clientes corporativos qual o nível de adoção das tecnologias de Web
2.0. Como seria de se esperar, muitos deles investiram ou estavam
planejando investir em uma ou mais tecnologias de Web 2.0. Para nós,
a parte surpreendente da pesquisa foi que os mashups estavam em
uso ou sendo considerados para uso por 21% dos entrevistados e a
maioria deles, 54%, sequer pensavam em adotá-los.
28
Acreditamos que a baixa aceitação dos mashups na empresa deve-se à
relativa inovação da tecnologia comparada a outras incluídas na
pesquisa (como Web services, podcasts e "feeds" RSS). O fato de que
as ferramentas para a construção de mashups estão apenas
começando a surgir também faz a diferença (no momento em que
escrevemos este artigo, muitas das mencionadas neste artigo estão
nos estágios beta e alfa). Estamos certos de que as técnicas serão mais
comuns e as ferramentas amadurecerão. Conceitos como o do
barramento de serviços para a Internet (página 2) devem facilitar a
construção desses mashups corporativos, tornando-os mais úteis.
Acreditamos que os mashups têm um lugar na empresa e nós o
incentivamos a considerar a sua adoção.
Referências
“Consumerization Gains Momentum: The IT Civil War,” Gartner
Special Report, 2007 (resumo)
http://www.gartner.com/it/products/research/consumerization_it/
consumerization.jsp
“How Businesses are Using Web 2.0: A McKinsey Global Survey,” The
McKinsey Quarterly, Agosto, 2007
http://www.mckinseyquarterly.com/article_abstract_visitor.
aspx?ar=1913
Mashup (Web application hybrid), Wikipedia
http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29
Redfin - http://redfin.com
“Web 2.0 na empresa”, Michael Platt, The Architecture Journal,
Jornal 12
Zillow - http://zillow.com
Sobre os autores
Larry Clarkin é architect evangelist da Microsoft. A experiência de
Larry em projeto e construção de aplicativos em várias tecnologias e
setores é superior a 15 anos. Ele se especializou na integração de
tecnologias web com sistemas legados e ERP, tarefa que vem
realizando há mais de 10 anos. Quando não está trabalhando com
seus clientes, Larry poderá ser encontrado realizando palestras sobre
tecnologia para grupos locais de usuários. Para falar com Larry, visite o
seu blog no endereço http://larryclarkin.com.
Josh Holmes é architect evangelist da Microsoft. Antes de ingressar na
Microsoft, em outubro de 2006, Josh era consultor e trabalhava com
vários tipos de clientes, desde as grandes empresas mencionadas na
Fortune 500 às empresas de pequeno porte. Josh é palestrante
freqüente e líder de equipe em conferências nacionais e internacionais
sobre desenvolvimento de software com enfoque nas tecnologias
emergentes, projeto e desenvolvimento de software com ênfase em
mobilidade e RIA (Rich Internet Applications). Preocupado com a
comunidade, Josh fundou e/ou administra muitas organizações
tecnológicas do Great Lakes Area .NET Users Group à Ann Arbor
Computer Society; também fez parte do comitê que instituiu o
CodeMash. Para falar com Josh, visite o seu blog no endereço
http://www.joshholmes.com.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Microsoft Office
como Plataforma de
Software + Serviços
por Chip Wilson e Alan Josephson
Resumo
Software + serviços (S+S) é uma visão para criar
arquiteturas de aplicativo que aproveitam ao máximo
recursos de ponta - os recursos dos dispositivos do
cliente - para fornecer aos usuários finais experiências
ricas e intuitivas. Esta visão representa uma etapa
incremental na direção do processamento universal, em
que a tecnologia não mais interferirá nos processos de
raciocínio das pessoas, permitindo a humanos entender
melhor como máquinas funcionam e, a partir disto,
poderem realizar as suas tarefas. O Microsoft Office com
sua interface bastante conhecida, rico conjunto de
serviços e base estabelecida de usuários corporativos é
uma fundação natural para a criação de aplicativos
corporativos S+S.
E mbora os recursos do dispositivo de processamento do cliente
possam ser aproveitados para oferecer uma interface de usuário
rica, não são adequados à execução da lógica e dos processos do
negócio, críticos para a empresa. Os recursos do sistema, idealmente
adequados para processos e armazenamento de dados do negócio
cuja hospedagem é de missão crítica estão, em geral, centralizados em
ambientes administrados, seguros, sob os olhos atentos da equipe de
operações das áreas de TI. As interfaces de serviço são
importantíssimas no aproveitamento dessas capacidades fundamentais
do negócio a partir dos inúmeros dispositivos do cliente que oferecem
ricas interfaces de usuários.
Muitas tecnologias e plataformas de cliente constroem o universo da
computação de ponta, desde simples interfaces de navegador Web 1.0
aos aplicativos .NET totalmente desenvolvidos, executados em
desktops ou laptops. Muito já se fez a partir dos últimos anúncios da
Microsoft sobre o Silverlight e os anunciados mecanismos do Google:
novos lançamentos no espaço de processamento do cliente. Embora
acrescentem capacidades novas e instigantes a muitas plataformas,
existem outras tecnologias comprovadas que a base de usuários
existente conhece melhor. Um caso irrefutável pode ser criado para
permitir que as plataformas de cliente existentes sejam o "Software" no
padrão arquitetural software + serviços.
Praticamente todos os knowledge workers de todas as empresas
conhecem o mesmo conjunto de aplicativos de produtividade:
Microsoft Office. O simples fato de que tantas pessoas tenham
aprendido como utilizá-lo, transforma-o em uma base natural para a
criação de aplicativos corporativos.
Lançamentos recentes incorporaram funcionalidades ao Office
transformando-o em algo muito maior do que um conjunto
independente de aplicativos de produtividade. Agora, o Office é uma
plataforma de desenvolvimento de aplicativos madura que oferece um
rico conjunto de serviços sobre a qual constroem-se aplicativos
corporativos. Considerando que tantos knowledge workers já utilizam
esses aplicativos para implementar processos corporativos de missão
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
crítica, existe um formidável impulso por trás de uma classe de soluções
emergente conhecida como Office Business Applications (OBA).
Desde o Microsoft Office 2003, é possível construir-se aplicativos
maduros sobre os aplicativos cliente do Office. Esta capacidade vai bem
além do que era possível com o Visual Basic for Applications (VBA).
Embora mecanismos para integração de conjuntos de módulos
(assemblies) .NET em aplicativos Office estejam bem documentados, os
padrões de projeto específicos necessários para o aproveitamento pleno
e aprimorado da IU ainda não são bem compreendidos pelo setor.
No momento em que as técnicas para casar a IU do Office com os
conjuntos de módulos do .NET estiverem dominadas (permitindo ao
código transferir informações de/para os documentos gerenciados
pelo Office), conectar esses documentos a sistemas de back-end via
serviços não será apenas lógico mas também relativamente simples,
presumindo-se que o trabalho de expor a lógica do negócio como um
serviço já tenha sido realizada. Isso supera uma das maiores
desvantagens de se implementar lógica do negócio significativa no
Office: o efeito colateral de se criarem ilhas de dados ou os chamados
"Excel Hell". Depois que os documentos estiverem conectados e
atuando sobre dados ao vivo nos sistemas de registro, eles se
transformarão em ferramentas em tempo real para automação dos
processos do negócio.
Conectar esses documentos diretamente a sistemas corporativos traz a
vantagem adicional de permitir o acesso às informações-fonte via
serviços, liberando o usuário final da tarefa entediante de fazer a
entrada manual dos dados dos sistemas e relatórios da empresa nos
documentos do Office. Depois que as etapas do processo
automatizadas pelo Office estiverem concluídas, as informações
resultantes poderão ser novamente armazenadas nos sistemas
corporativos, mais uma vez via serviços, eliminando as tarefas
adicionais de entrada de dados e garantindo a exatidão e a
temporalidade dos dados.
Um problema comum do negócio
Para que os negócios possam se desenvolver e manter vantagem
sobre a concorrência, é preciso elaborar a modelagem e as análises
financeiras com informações em tempo real, sem exigir que os
usuários acessem vários locais de armazenamento de dados. Os OBAs
agilizam o acesso às informações em tempo real, eliminando
processos manuais para a aquisição de dados e a obtenção de
definições de cálculo. Essas soluções permitem aos usuários do
Microsoft Excel executar análises complexas com dados extraídos
diretamente de data warehouses centrais, aplicativos ERP (Enterprise
Resource Planning) ou de sistemas externos, via web.
Algumas limitações do modelo Office desconectado surgem das ilhas
de dados armazenados em discos rígidos individuais e
compartilhamentos de redes. Em primeiro lugar porque, de modo
típico, não há trilha de auditoria dos dados. Esse fato pode ser
especialmente verdadeiro quando os documentos são enviados por e-
mail e alterações são introduzidas por várias pessoas, criando versões
paralelas do documento. Depois, como os dados não são agregados,
fica difícil ou até impossível executar qualquer tipo de análise de
tendência. Por último, pesquisar muitos documentos para obter
informações específicas pode ser extremamente difícil e demorado.
29
 Microsoft Office como Plataforma de Software + Serviços
Figura 1: Como o Excel atua na versão Software + Serviços
UI (Excel)
Painéis de
gerencia-
mento
Web
Service
Ferramenta de cálculo
Serviços essenciais
Segurança Validação Agendamento
Definição Relatórios
de cálculo Auditoria Notificação Emissão de
(excel) relatórios
Exemplos do mundo real
Para compreender melhor as características do problema do negócio,
examinar alguns exemplos do mundo real pode ser útil. Apresentamos
três cenários em que padrões arquiteturais foram utilizados para
resolver problemas similares do negócio em contextos e setores bem
diferentes.
A “Empresa A” oferece planos de benefícios a funcionários de bancos
norte-americanos de pequeno porte e cooperativas de crédito que
desejam atrair e reter os melhores talentos executivos possíveis. Para se
destacar da concorrência, a Empresa A oferece planos muito
personalizados, que exigem intenso processo administrativo para
garantir o nível mais alto de serviço ao cliente.
Contudo, oferecer esse nível de serviço personalizado cria desafios.
Benefícios como planos de seguro de vida são, em geral, registrados
como ativos dos bancos que os compram para seus funcionários.
Assim, os planos precisam ser tratados como outros ativos financeiros
importantes que refletem a completa saúde financeira da instituição, a
qual pode ser afetada por variáveis externas como as taxas de juros
mutáveis. A Empresa A deve monitorar os planos e as ferramentas de
financiamento continuamente e oferecer atualizações periódicas a seus
clientes. Para tanto, emprega administradores treinados para
acompanharem de perto os detalhes da política e do plano de
benefícios como, por exemplo, as mudanças de beneficiários,
flutuações da taxa de juros, cálculos de aposentadorias e outros fatores.
Historicamente, esses administradores de planos trabalharam com
vários sistemas e software, inclusive os bancos de dados Microsoft
Access e SQL Server, programas do Microsoft Office como o Excel e
inúmeros outros processos documentais, incluindo formulários em
papel. (Vide Figura 1.)
A "Empresa B" é representada por uma empresa de serviços de suporte
e administradora de investimentos imobiliários que presta serviços
completos, gerenciando investimentos em total superior a $20 bilhões
na América do Norte, Ásia e Europa. A equipe de gerenciamento de
risco tem por enfoque maximizar o potencial do portfólio global da
empresa pela monitoração contínua dos instrumentos de
financiamento e das propriedades que possui. O grupo mantém um
banco de dados abrangente para o gerenciamento dos ativos e
depende muito do Microsoft Excel para elaborar análises de suas
inúmeras e variadas propriedades.
A equipe queria ter condições de executar análises complexas de
gerenciamento de risco com dados obtidos diretamente dos sistemas
corporativos. A solução OBA permite aos usuários do gerenciamento
Para cada produto, a equipe de gerenciamento de capacidade de risco
recuperar informações de forma transparente dos sistemas
30
corporativos de registro, levando-as para um aplicativo familiar,
baseado em Excel. Os dados em tempo real permitem a melhor
tomada de decisão ao oferecer um acesso mais preciso e imediato às
informações.
A "Empresa C" é representada por um banco comercial, com uma
abrangente iniciativa de gerenciamento de capacidade. A iniciativa tem
por objetivo reunir a gerência de produto e vendas com as operações
bancárias e de TI e, como uma equipe transfuncional e unificada,
identificar novas oportunidades de receita incremental para o banco
que aproveitem a capacidade não utilizada, medida e disponível.
As equipes transfuncionais, organizadas de acordo com uma estrutura
corporativa de gerenciamento de linha opera em um ciclo contínuo de
gerência de desempenho do negócio na qual as projeções agrupadas e
as metas de desempenho são definidas e confirmadas a cada trimestre
e, posteriormente, revisadas com o comitê diretivo do gerenciamento
de capacidade de acordo com novas projeções para o trimestre ou
ciclo subseqüente.
Para cada produto, a equipe de gerenciamento de capacidade
construiu modelos em Microsoft Excel para os cálculos mensais e
geração dos resultados para painéis ou scorecards das informações de
gerenciamento. A conexão desses modelos diretamente aos sistemas
corporativos que contêm os dados de custo e produção necessários
para realizar os cálculos de capacidade não apenas eliminou a entrada
manual dos dados nas planilhas, como permitiu aos analistas executar
as análises de capacidade em tempo real, oferecendo feedback via
painel, continuamente, e não apenas mensal ou trimestralmente.
Solução
Generalizando, essas três soluções recaem no padrão arquitetural
software + serviços, uma solução OBA utilizando o Excel como um
cliente conectado a sistemas corporativos distribuídos via Web Services.
Os Web Services recuperam informações atuais imediata e diretamente
na planilha do usuário. Os usuários autorizados podem fazer e aplicar
mudanças nos sistemas corporativos, assegurando que informações
precisas estejam imediatamente disponíveis em toda a empresa.
Todos os diagramas, gráficos, tabelas e outras ferramentas para
emissão de relatórios que usam os dados modificados são
automaticamente atualizados de modo a refletir as informações atuais,
corretas. Esta solução permite aos usuários recuperar informações dos
sistemas corporativos de forma transparente levando-as para um
aplicativo familiar, baseado em Excel. As informações em tempo real
permitem a melhor tomada de decisão ao oferecer um acesso mais
preciso e imediato às informações. A administração e a manutenção do
aplicativo OBA são simplificadas pela implantação das alterações de
uma biblioteca central de documentos.
Benefícios no mundo real
Vamos ver como essa solução geral forneceu valor concreto ao
negócio nos três cenários mencionados acima.
A Empresa A simplificou os principais processos do negócio
organizando melhor e centralizando seus documentos. As tecnologias
de Web Services criaram flexibilidade nos sistemas de TI da empresa,
ajudando os gerentes a incluir e modificar características do plano para
administradores, sem prejudicar os recursos internos. E o que é mais
importante, a empresa continua em seu curso anual de crescimento,
firme, com acréscimos mínimos de pessoal.
O tempo economizado pela solução aparece igualmente em outros
processos do negócio, inclusive naqueles que afetam diretamente as
comunicações regulares da Empresa A com bancos. Se um banco
chama a Empresa A e deseja experimentar um cenário "what-if" de
determinada política - digamos que o banco deseja analisar os custos
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
 Microsoft Office como Plataforma de Software + Serviços
Figura 2: Componentes do framework da lógica do negócio
Módulo do processador de IU do
processador de
cálculo
• Intérprete de metadados
cálculo
• Gerente de conectividade
• Mecanismo de execução Pasta de trabalho do
Excel, Office Open XML
• Local (modelo de objeto Excel)
• Excel Services
Metadados
• Gerente de persistência de cálculo
Serviço do
processador do Armazenamen- IU do agendador de
trabalho de to de dados trabalhos de cálculo
cálculo do trabalho de
cálculo
associados à antecipação da data de aposentadoria de determinado
executivo - agora leva dois minutos, ou menos, porque todos os dados
estão agregados e facilmente acessíveis. No passado, esse processo
poderia ter levado até três dias pois o administrador teria de pesquisar
as planilhas relevantes para extrair os dados adequados.
Os analistas da Empresa B continuam a usar a interface familiar do
Microsoft Excel para modelar o seu portfólio imobiliário. Utilizando o
Excel como cliente em um OBA proporcionou-lhes um ambiente rico e
robusto para interação com os sistemas corporativos. Aprimorou e
simplificou os processos de análise dos usuários, oferecendo-lhes os
dados que precisam, na forma em que já estão acostumados a
trabalhar.
Os Web Services oferecem uma forma transparente para a troca de
grandes volumes de informações pela rede, simplificando a forma com
que aplicativos cliente geram solicitações para os sistemas corporativos
e permitindo aos desenvolvedores construir inteligência no aplicativo.
A Empresa C aproveitou o Excel para fornecer uma interface de cliente
rica para que os analistas de negócio possam construír modelos de
utilização fundamentados nos princípios do cálculo de custos baseado
em atividade. Ao permitir que esses modelos extraiam dados ao vivo de
recursos e custos dos sistemas de back-end, a Empresa C pôde
automatizar o processo para determinar quais pontos de capacidade
não utilizada poderiam gerar receita adicional sem afetar os custos fixos
associados ao produto e, assim, aumentar as suas margens. Ao fornecer
informações de utilização calculadas aos sistemas corporativos, os
painéis de gerenciamento puderam apresentar não apenas as
informações de utilização de capacidade atuais e periódicas, mas
executar análises de tendências que ajudam a gerência a tomar
decisões sobre onde concentrar recursos futuros de marketing e
vendas.
Solução técnica
Ao solucionar três problemas diferentes com a mesma abordagem
arquitetural, várias características comuns tornaram-se aparentes e
vários frameworks implementados são suficientemente gerais para
serem utilizados em projetos futuros.
O framework da lógica do negócio permite aos designers de pastas de
trabalho (usuários Excel qualificados que conhecem as relações dos
dados de uma pasta de trabalho e sua apresentação) modificar as regras
do negócio do sistema sem incluir um desenvolvedor para recompilar e
reimplantar o código. O acesso baseado em função para metadados da
pasta de trabalho proporcionam uma IU especial para esses designers,
permitindo-lhes executar tarefas tais como modificar o comportamento
de uma pasta de trabalho, alterar itens de menu, controlar como os
dados dos sistemas corporativos são mapeados por meio de Web
Services para campos das pastas de trabalho e ocultando ou exibindo
planilhas ou linhas e colunas individuais baseadas em dados.
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
O framework de segurança faz uso do recurso segurança de acesso a
código do .NET. O uso desse recurso reduz a probabilidade de que o
aplicativo possa ser utilizado inadequadamente por código malicioso
ou mal programado. Outra vantagem é a sua capacidade de permitir
aos administradores do sistema especificar os recursos que podem ser
utilizados por um aplicativo e restringir o acesso do usuário a pastas de
trabalho ou servidores específicos, de acordo com a sua função.
Para abordar o problema de manter simultaneamente várias versões da
pasta de trabalho do Excel em toda a empresa, criou-se um framework
para controle de versões de uso geral que permite aos desenvolvedores
atualizar os conjuntos de módulos associados aos documentos e aos
dados ali contidos. Antes de os resultados poderem ser submetidos aos
sistemas corporativos, o componente cliente do OBA determina se
existe uma versão mais nova do documento por meio de consulta via
Web Service. Se este for o caso, os conjuntos de módulos do .NET são
descarregados para atualização dos dados, da lógica do negócio e IU
da pasta de trabalho. Se os dados da pasta de trabalho satisfizerem sua
lógica de validação atualizada, o carregamento continua com os dados
colocados na versão correta.
Para executar as regras do negócio e os mapeamentos de dados
especificados no framework da lógica do negócio, um framework de
execução lê na pasta de trabalho a lógica do negócio, armazenada
como metadado. A seguir, o framework interpreta e executa as
instruções com base em um simples conjunto de instrução extensível.
Esta abordagem interpretada permite aos desenvolvedores adicionar
facilmente novos tipos de instrução, conforme necessário, entregando-
os a designers de pasta de trabalho, não desenvolvedores, por meio de
assistentes amigáveis.
Aplicativo de otimização de capacidade
Para entender melhor a arquitetura da solução, examinaremos a
solução de gerenciamento de capacidade da Empresa C mais
detalhadamente. O enfoque, neste caso, estará em como um
desenvolvedor de pasta de trabalho aproveita o framework que contém
a lógica do negócio para fazer a conexão de pastas de trabalho com
sistemas corporativos via Web Services e "executar" as tarefas de cálculo
criadas para a pasta de trabalho nos cenários de cliente e servidor. A
solução geral compreende quatro componentes (vide a Figura 2):
"
Módulo processador de cálculo para configurar, salvar e executar
uma tarefa de cálculo (usados nos dois cenários: cliente e servidor);
"
IU do processador de cálculo que implementa a IU do módulo
processador de cálculo;
"
Serviço do processador do trabalho de cálculo para cálculos em
execução no servidor utilizando os serviços Excel chamados de um
serviço Windows;
"
Agendador de trabalhos de cálculo para configurar a execução
baseada em tempo dos trabalhos de cálculo.
Criação de tarefa de cálculo
O módulo processador de cálculo é responsável por modelar e
seqüencialmente executar as etapas que formam uma tarefa de cálculo.
Tarefa de cálculo é uma unidade de execução assim denominada por
compreender um conjunto simples de etapas de cálculo que descrevem
como:
"
chamar métodos de Web Service para transferir dados de/para a
pasta de trabalho;
"
transferir dados dentro da própria pasta de trabalho;
"
conectar eventos de IU do Excel para reagirem às interações do
usuário (executado apenas quando a pasta de trabalho está aberta
no cliente).
31
 Microsoft Office como Plataforma de Software + Serviços

Figura 3: Criação de etapa de cálculo com base em método Figura 4: Mapeamento de um esquema gerado do método do
do Web Service Web Service
Add Web Service Method Invocation Step

et Expenses Rename / Dele

Delete / Run
Web Service URL
Make sure to provide a simple, but explanatory name for this input eld .
t FTEs Rename / Dele
Delete /
http://companyc.com/Services/CalculationReslts.asmx?wsdl Retrieve Methods
t Product Stats Rename / Dele
Delete / Run

Web Service Method

t Resource Cost Driver Stats Rename / Dele
DeleteSelect
/ Runa method to call from this web service.

SaveFunctionalCalculation
Add a Step Description: Transmits results of a functional calculation to the system of
record for a product, site, and reporting period.
Inputs: Reporting Period Start <datetime>
2 Steps) Edit / Delete Reporting Period End <datetime>
Product Code <string>
> Site Code <string>
Capacity Metric By Function Calcs <object>
Capacity Based Unit Cost Calcs <object>
(4
4 Steps) Edit / Delete Hour Rate Calcs <object>
Capacity Based Unit Cost Summary Calc <object>
Hour Rate Summary Calc <object>

Outputs: Status <string>

Updated <datetime>

Step Name
Make sure to provide a simple, but explanatory name for this step.
Save Functional Calculation Results

Add this Step

Além disso, uma tarefa de cálculo possui um conjunto de entradas Adicionalmente à criação de etapas de cálculo, o designer da pasta de
fornecidas pelo usuário para acionar a execução da tarefa. trabalho também especifica entradas bem tipadas para configurar
Um designer de pasta de trabalho usa o assistente de conexão para uma tarefa de cálculo utilizando um assistente de entrada de tarefa de
adicionar chamadas de método do Web Service específicas para uma cálculo para especificar nomes de entrada e seus respectivos tipos de
tarefa de cálculo (vide Figura 3). Ao especificar o identificador de dados. O processador de cálculo gera de modo dinâmico uma XSD
recurso uniforme (URI) para uma WSDL (Web Service Definition correspondente às entradas a qual é, depois, adicionada à pasta de
Language) do Web Service, seus métodos e respectivas assinaturas são trabalho como um mapa XML Excel e mapeada para as células da
recuperados e apresentados ao designer da pasta de trabalho que, planilha, como anteriormente mostrado na Figura 4. Quando a tarefa
depois, acrescenta um método de interesse para a tarefa de cálculo de cálculo é executada no cliente Excel, o sistema apresenta ao usuário
como uma etapa do cálculo. um formulário gerado que solicita os valores das entradas (vide Figura
5). Quando executado pelo processador do trabalho de cálculo no
Uma vez acrescida, o processador de cálculo gera, de modo dinâmico, servidor, são usados os valores das entradas especificados pelo
uma definição de esquema XML (XSD) correspondente às entradas e agendador de trabalho de cálculo.
saídas do método do Web Service, incluindo-a na pasta de trabalho
Execução de tarefa de cálculo
como um mapa XML do Excel. A seguir, o designer da pasta de
O mecanismo de execução é o coração do módulo processador de
trabalho faz o mapeamento dos elementos individuais do mapa XML
cálculo. É responsável por interpretar a chamada do método do Web
para as planilhas utilizando o recurso arrastar-e-soltar do painel de
Service, copiar as etapas de dados e executá-las na ordem especificada
tarefas-fonte XML (vide Figura 4). Essas tarefas serão valores escalares
pelo designer da pasta de trabalho em uma tarefa de cálculo. Quando
mapeados para células individuais ou coleções de elementos que se
o Excel é executado em um cliente, o mecanismo de execução acessa
repetem, mapeados para tabelas do Excel 2007, anteriormente
diretamente o modelo de objeto Excel, utilizando os mapas XML para
conhecidas no Excel 2003 como listas Excel. Enquanto os mapas XML vincular dados de/para planilhas. Quando executado no servidor,
preservam a estrutura hierárquica dos objetos proxy do Web Service, utiliza o Excel Services para realizar a vinculação, o cálculo e a
estes ficam desnormalizados quando mapeados para tabelas ou pastas recuperação dos dados.
de trabalho do Excel.
Ao colocar em serviço pastas de trabalho existentes, quase sempre
Figura 5: Execução de uma tarefa de cálculo
recomenda-se preservar a apresentação dos dados na pasta de
trabalho. Muitas vezes, dados similares não são apresentados na forma All Workbook
Workbook Tasks
Tasks
T Create a New Task
de tabela, como exigido pelo mapeamento de elementos que se
repetem nos mapas XML. Além disso, existe um limite para mapas - Run Capacity Management Calculation (4 Steps) Edit / Delete Run Task
XML do Excel, ou seja, as células de mapeamento não podem se Performs the capacity management calculation for a
reporting period, site, and product. Debug Task
sobrepor àquelas de outros mapas XML. Nesses casos, algumas vezes é
Run Capacity Management Calculation
preciso transferir dados de uma faixa de células da planilha para outra,
1. Reporting Period Start / Date
e Edit / Delete
para fazer com que as entradas e saídas do serviço "fiquem em linha". Reporting Period Start
Um tipo de etapa de cálculo denominada copiar dados permite ao 2. Reporting Period End / Date Edit / Delete

designer da pasta de trabalho especificar como duplicar dados para Reporting Period End 3. Product Code / List Edit / Delete

outros locais de uma pasta.

4. Site Code / List Edit / Delete
Nos cenários em que o Excel é usado no cliente para edição e Product Code

atualização de dados, algumas vezes a lógica do negócio em dados Add an Input

Site Code
recuperados exige mudanças dinâmicas na IU do Excel. Tal etapa de
manipulação de dados da pasta de trabalho poderá, por exemplo,
ocultar e exibir dados das planilhas com base em valores específicos Continue1. Get Expenses Rename / Delete / Run

dos dados. Um tipo de etapa modificar IU permite ao designer da 2. Get FTEs Rename / Delete / Run
pasta de trabalho fazer a conexão dessas interações.
3. Get Product Stats Rename / Delete / Run

32 THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net

 Microsoft Office como Plataforma de Software + Serviços

Programação e execução de trabalho de cálculo

Figura 6: Programação de um trabalho de cálculo
O agendador de trabalhos de cálculo é um aplicativo pelo qual
Edit Job usuários administrativos configuram pastas de trabalho e os
respectivos trabalhos de cálculo para execução em hora marcada (vide
Name
Create a New Jo b
ed Jobs View Job Logs Make sure to provide a simple, but explanatory name for calling this task.
View Figura 6). As informações fornecidas são:
Monthly Cap Man - Dalla s
Scheduled
Schedul Jobs
s Edit / Delete
T.
elete
Document to Use Run Job
"
caminho da pasta de trabalho;
Monthly Cap Man - Dalla Select the spreadsheet that you'd like to use with this job.
Monthly Cap Man - Dalla
T on 1/1/2007
This task runs daily at 6:00am CS CapMan.xls x Browse Load
"
identificação de qual tarefa de cálculo da pasta de trabalho deve ser
Last run at 6:00am CS
Tulsa Edit / Delete
Tulsa Task to Run
Run Job
executada;
Weekly Cap Man - T
T
T.. Run Capacity Management Calculation
d Last run at 2:00am CS T on 1/1/2007
ly Disabled
This task runs weekly on Sunday at 2:00am CS
1
Schedule
T. Run Job
Provide Input Values
"
programação da execução (recorrente ou data de execução única);
Currently
Current Disable
Cap Man - Kansas City Edit / Delete
y on Januar y 1st at 2:00am C
You should provide a fairly detailed description of the purpose of this task
and a high-level overview of the steps involved. "
entradas iniciais para o trabalho de cálculo conforme determinado
Annual Cap Man - Kansas City
T on 1/1/2007 Daily at 00 : 00 UTC pelos metadados da tarefa de cálculo;
This task runs annually
annuall on January 1st at 2:00am CS
Weekly on Sunday at 00 : 00 UTC "
caminho da pasta na qual os instantâneos de auditoria da pasta de
Monthly on the 1st at 06 : 00 UTC trabalho devem ser armazenados.
Once on January at 00 : 00
1st 2007 UTC
O serviço do processador do trabalho de cálculo é executado como um
Save/Create this Jo b
serviço do Windows e chama o módulo do processador de cálculo
sempre que um critério de programação de um trabalho de cálculo for
satisfeito. As entradas iniciais fornecidas no momento em que o
Limitações atuais do Excel Services proíbem que pastas de trabalho trabalho foi programado são transferidas para o cálculo e o trabalho
com mapas XML sejam abertas no servidor. Para contornar essa de cálculo da pasta é executado utilizando o Excel Services.
limitação, o módulo processador de cálculo extrai as informações de Opcionalmente, um instantâneo da pasta de trabalho (depois de
vinculação armazenadas nos mapas XML de uma pasta de trabalho, concluída a tarefa de cálculo) pode ser gravado em local
remove os mapas XML e apresenta uma cópia "limpa" ao Excel predeterminado para fornecer uma trilha de auditoria do trabalho de
Services. As etapas de chamada do método do Web Service utilizam cálculo.
estas informações de vinculação para determinar como configurar e Conclusão
obter faixas de células dentro da pasta de trabalho por meio da API do Esta abordagem arquitetural para resolver problemas do negócio
Excel Services. Esta abordagem é similar ao modelo "push" em que os
extremamente comuns tem sido utilizada muitas vezes, ultimamente.
dados são alimentados para o documento utilizando a estrutura de
Provou-se robusta e confiável, agregando incrível valor ao negócio.
controle explícita na tarefa de cálculo. Uma abordagem alternativa que
Em um dos casos, esta solução revolucionou completamente o
aproveita as funções definidas pelo usuário (UDFs - User Defined
modelo de negócio da empresa, permitindo uma oferta de serviços da
Functions) do Excel para encapsular as chamadas do Web Service
qual que nenhum outro concorrente poderia sequer se aproximar.
também é possível, mas apresenta várias limitações, inclusive:
A visão software + serviços de IUs ricas em dispositivos do cliente
"
ter de confiar no gráfico de dependência da planilha para o chamando serviços na nuvem adapta-se muito bem ao sistema do
seqüenciamento das chamadas do método do serviço (sem controle Microsoft Office, especialmente porque a IU oferecida pelo Office é
explícito);
absolutamente universal e conhecida.
"
apenas um volume predeterminado de dados pode advir das UDFs
pois a lista de tipos de valor de retorno deve estar vinculada a faixas
fixas do Excel; Referências
Denise Partlow, EMC Global Services (ex-Geniant, LLC). “Improving
"
exige manutenção adicional para implantar e fidelizar UDFs nos
Data Integrity in Financial Analyses”. Abril, 2006.
termos do Excel Services.
Denise Partlow, EMC Global Services (ex-Geniant, LLC). “Real Estate
O gerente de persistência abstrai o armazenamento dos metadados do
Firm Simplifies Risk Analyses with Web Services and Excel Smart
processador de cálculo. Os metadados serializados ficam armazenados
Clients”. Abril, 2006.
como uma parte XML personalizada (recurso novo do Excel 2007)
dentro do pacote Office Open XML que representa a pasta de Microsoft Office Business Applications http://office.microsoft.com/en-
trabalho. Dessa forma, todas as informações sobre o trabalho de us/products/FX102204261033.aspx
cálculo ficam armazenadas na própria pasta de trabalho, disponível
para o serviço do processador do trabalho de cálculo.
Sobre os autores
A IU do cliente de cálculo pode ser implementada como um add-in do
Chip Wilson é arquiteto corporativo da EMC Global Services. Seu mais
Excel ou como uma personalização do Excel que acrescenta itens de
recente livro publicado, Transparent IT: Building Blocks for an Agile
menu para que a IU do Excel tenha acesso a um jogo de formulários
Enterprise (www.TransparentIT.com), descreve um framework e
do Windows. Esses formulários ampliam a IU do Excel por meio de um
roadmap detalhados para a adoção de uma arquitetura orientada a
conjunto de assistentes para que um designer de pasta de trabalho,
serviço e a criação de uma empresa ágil.
não desenvolvedor, possa configurar, salvar, expor uma tarefa de
cálculo para execução, executá-la diretamente ou examinar suas Dr. Alan Josephson é consultor sênior de prática da EMC Global
etapas de cálculo. Outra classe de usuário, sem autorização para Services, especializado no desenvolvimento do sistema Microsoft
modificar o cálculo, poderia ter acesso restrito apenas para a interface Office. Criou soluções personalizadas de Smart Client e Office
de execução. Automation para clientes nos setores financeiro, de seguros e energia.

THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net 33

 Um Planeta Regido por
Arquiteturas de Software
por Gianpaolo Carraro
O mundo da arquitetura de software deu um passo "gigante" à
frente quando passou dos acrônimos de três letras (SOA e ESB)
para os acrônimos de quatro letras (AJAX e SaaS). Como você pôde
testemunhar nesta edição, agora temos um novo acrônimo que inclui
um caractere não alfanumérico: S+S (software + serviços). Agora, duas
perguntas povoam nossas mentes:
1. Os analistas se sentirão ameaçados por esta nova geração de
acrônimos e aumentarão a aposta introduzindo outros que exijam
codificação Unicode?
2. Como posso transmitir de modo eficaz a visão S+S em minha
organização?
A resposta da primeira pergunta é: só o tempo dirá! Tentando
responder a segunda, entretanto, quis explorar uma analogia, a de um
planeta com eras imaginárias em que cada uma delas é dominada por
uma civilização específica, metaforicamente representando um estilo
de arquitetura. Faz sentido? Espero que sim. Vamos começar…
A época da escuridão
Architectopia nem sempre foi um lugar feliz como hoje. Não faz muito
tempo, a maior parte de suas terras era dominada pelo império Big-
Iron. Embora não sendo maligno, o império Big-Iron impunha regras
muito rígidas sobre as populações locais; naqueles dias, a liberdade de
expressão era bastante limitada. Nessa época da escuridão, não havia
outra opção a não ser cumprir respeitosamente a autoridade central
do imperador Mainframe I.
A renascença
A renascença foi um tempo de inovação rápida que viu o surgimento
de novos sistemas políticos, o início da ciência moderna e a
exploração geográfica. Nesse tempo, os Architectopianos acalentavam
um forte desejo de emancipação que trouxe certo declínio ao império
Big-Iron e a criação de vários Estados poderosos, notadamente: a
República de Desktopistan e o Grão-ducado de Enterprisia.
A República de Desktopistan
A República de Desktopistan foi instituída com base nos princípios da
individualidade e da independência. Chegou aonde as regras limitam
a expressão. Agora, todos podem ter acesso à literatura, matemática e
arte; para que isso ficasse garantido a todos, um livro, um ábaco e
uma tela podiam ser encontrados sobre as mesas de cada lar.
Nenhuma casa da república é igual à outra, todas têm layout
personalizado, papel de parede feito em casa e equipamentos
adicionais diferentes como espaço extra de armazenamento,
iluminação ativada por voz e, como norma, TVs de tela grande. Em
Desktopistan, espera-se que os artesãos produzam artefatos que se
adaptem a esses ambientes e equipamentos adicionais personalizados.
Muitos detestam cortador de cookies e abordagens de denominador
comum.
Contudo, a forte individualidade da cultura tem um preço: é uma
sociedade muito solitária. Reuniões sociais e compartilhamento de
34
experiências não fazem parte de suas tradições. A Tabela 1 compara os
prós e os contras da vida em Desktopistan.
Grão-ducado de Enterprisia
Forte aliado do império Big-Iron durante a época da escuridão, o
Grão-ducado de Enterprisia reinventou a si mesmo durante a
renascença. A dependência do império esvaiu-se dada a maior
influência de Desktopistan. As motivações não foram filosóficas mas,
sim, fundamentadas na vantagem econômica dessa mudança. Tal fato
não surpreende pois o Grão-ducado foi sempre dirigido como uma
"economicracia", ou seja, todas as decisões políticas devem resultar em
maior valor para o total dos ativos do Grão-ducado. De acordo com
essas regras, algum descontentamento da população é aceitável,
especialmente se a felicidade for considerada muito cara.
Ainda que apenas em princípio, o Grão-ducado está aberto à adoção
de novos modelos para vantagens globais aprimoradas, mas adota
posição bastante conservadora para aceitar tais modelos, ferramentas
e equipamentos. Essa lenta adoção, usada como um mecanismo de
proteção, é fiscalizada pelo influente "comitê pragmático de novas
adoções" formado por 27 membros resolutos. De acordo com os
governantes do ducado, a adoção lenta é um preço pequeno a se
pagar pelo rigor e controle permitidos pela disseminação disciplinada
de tecnologia nova. Posto isto, pode-se observar que muitos chefes de
vilas não se queixam do lento processo de adoção e assumem novos
modelos localmente, sem a permissão do Grão-duque. Em geral, é
sempre muito tarde para que o Grão-duque altere qualquer coisa no
momento em que fica sabendo do fato.
Observando-se o lado positivo, elevados padrões de qualidade são
prevalentes em todas as disciplinas. A infra-estrutura do ducado
(estradas e energia elétrica) embora antiga, é bastante confiável e
raramente passa por períodos de interrupção. O sistema legal também
é bastante desenvolvido e os acordos de serviço contratual são, em
geral, bastante respeitados.
Ultimamente, como parte do seu plano de crescimento de cinco anos,
o próprio duque concedeu autorização à Sociedade da Ordem e
Abundância (SOA) para reformar grande parte do modo de operação
do ducado. Ainda não se sabe ao certo se benefícios substanciais serão
obtidos sem reformas mais fundamentais do Grão-ducado, mas as
esperanças são grandes. A Tabela 2 apresenta os prós e os contras da
vida no Grão-ducado de Enterprisia.
Tabela 1: Prós e contras da vida em Desktopistan
Prós Contras
• Experiências ricas • Experiência isolada
• Pleno uso dos recursos locais
• Extensibilidade
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
 Um planeta regido por arquiteturas de software
Tabela 2: Prós e contras da vida no Grão-Ducado de Enterprisia
Prós Contras
• Padrões de qualidade elevados • Adoção lenta, aceitação lenta
• Contratos e acordos de nível de • Falta de agilidade
serviço baseados na economia • Muitos dados legados
• Governança
A erupção do monte Web
A República Popular do Mundo On-line é uma jovem nação instituída
em um novo continente criado pelas violentas erupções do monte
Web. Em muitos aspectos, a República Popular se rege por valores
opostos aos do Grão-ducado de Enterprisia. Na mesma medida em
que Enterprisia é dirigida a processo, com sistemas centralizados, a
República Popular caminha rápido e é centrada nas pessoas. Em lugar
de confiar em práticas definidas e bem comprovadas, os cidadãos da
República Popular preferem o procedimento tentativa-e-erro. Outro
ponto divergente trata da habilidade artesanal. Fica claro que as
qualidades leve e funcional são as preferências da República Popular
para seus produtos artesanais, em detrimento da elegância ou
durabilidade. Até mesmo no tempo parecem diferentes pois o restante
de Architectopia rege-se por anos orbitais longos e na República
Popular o tempo é contado em dias lunares meridionais, muito mais
curtos.
Um ditado popular desse país (considerado herege em Enterprisia) diz
“vamos tentar e ver o que acontece”. Explosões são freqüentes nos
laboratórios da República Popular. Muitos nem se surpreendem pois
os cientistas, em sua maioria, são adolescentes que aspiram ser
alquimistas e que se recusaram a cursar as melhores universidades do
Grão-ducado de Enterprisia. Em vez de irem à escola, preferem
dedicar sua energia inesgotável procurando pela pedra filosofal a qual,
no dialeto local, denomina-se "IPO". Pela perspectiva sociológica, é
interessante notar que muitas dessas experimentações são
patrocinadas por uma sociedade secreta conhecida por duas letras:
C.R. (capital de risco). Entretanto, nem todos os experimentos
terminam em explosões: os poucos que tiveram êxito, em geral,
modificam a face de Architectopia e tornam-se modelos para todos os
outros países, ainda que adaptados às culturas locais.
Um valor fundamental da cultura da República Popular é o enfoque
nas formas de trabalho centradas nas pessoas, que permitiu o
estabelecimento de uma infra-estrutura de comunicações muito
avançada. Nesse país, muito pouco parece ser divertido, se não for
feito em grupo. O trabalho é feito em grupo, reuniões sociais em
massa são comuns e alcançar todas as pessoas é o principal estandarte
de sua filosofia.
Um aspecto final do interesse cultural da República Popular é a noção
de que todas as compras deveriam ser grátis, de acordo com os seus
cidadãos.
Tabela 3: Prós e contras da vida na República Popular do
Mundo On-Line
Prós Contras
• Alcance • Sem contratos, todas as transações
seguem o “Farei o possível”
• Coletividade
• Tende a satisfazer uma
• Inovação rápida (técnica e
experiência de denominador
nos modelos de negócio)
comum
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
Tabela 4: Prós e contras a vida em Deviceland
Prós Contras
• Mobilidade
• Fator forma pode degradar
• Acesso em qualquer lugar toda a experiência
• Fator forma
A única exigência é passar algum tempo ao final da experiência de
compras na frente de uma grande tela na qual exibe-se propaganda
(ironicamente, do Grão-ducado de Enterprisia). O tempo que você
deve passar assistindo a propaganda é diretamente proporcional ao
valor estimado da sua experiência de compra. A Tabela 3 apresenta os
prós e os contras da vida na República Popular do Mundo On-line.
Deviceland
Kermit-TTY, o primeiro governante de Deviceland, chegou atrasado na
reunião do Tratado de Divisão de Architectopia, pelo qual os vários
continentes foram alocados às várias civilizações antigas
(supostamente porque "não recebeu o memorando"). Desde então, os
habitantes de Deviceland são obcecados por ter acesso às informações
a qualquer hora, em qualquer lugar.
Formados por tribos nômades de guerreiros errantes, os residentes de
Deviceland adaptaram plenamente seus hábitos para acomodar-se ao
estilo de vida apressado, sempre em alta velocidade. A perspicácia das
tribos não deve ser subestimada: é prática comum para eles observar o
que está acontecendo nos outros países e adaptar os avanços que
encontram à sua vida nômade - quase sempre, entretanto, à custa da
riqueza da experiência.
Em Deviceland, as tribos vivem muito felizes em territórios isolados,
mas mantêm contato constante entre si e com a cidade da capital. O
lugar mais provável no qual se encontram membros das tribos são
pontos específicos conhecidos como Hot Spots. São muito populares
em Deviceland pois fornecem "o suco", uma fonte de energia
necessária para todos, assim como "sinal forte", campo
eletromagnético quase-místico, que fornece um profundo sentimento
de paz às pessoas. Os Hot Spots são o tema central do hino de
Deviceland: "Agora você me escuta?" A Tabela 4 lista os prós e os
contras da vida em Deviceland.
O novo mundo
A recente colonização de Servicetopia, anteriormente territórios hostis
de Architectopia, lançou algo novo. Em lugar de viverem isolados em
cidades-Estado como era o hábito em sua terra natal, os colonizadores
do velho mundo, especialmente a República de Desktopistan, o Grão-
ducado de Enterprisia, a República Popular do Mundo On-line e
Deviceland estabeleceram casamentos inter-raciais e mesclaram seus
valores.
Tabela 5: Os atributos centrais da Federação Unida de S+S
e a influência da origem
Atributo Influenciado por
Padrões elevados e SLAs Grão-Ducado de Enterprisia
Individualidade e experiências ricas República de Desktopistan
Alcance, coletividade e inovação República Popular do Mundo
rápida On-Line
Fatores de forma e mobilidade de Deviceland
hardware otimizado
35
 Um planeta regido por arquiteturas de software
Figura 1: Bandeira da Federação Unida de S+S
A diversidade e o respeito pela escolha tornaram-se o principal
conjunto de características do povo de Servicetopia. Assim, não é de
se surpreender que quando Servicetopia tornou-se a Federação Unida
de Software + Serviços (UF S+S), a diversidade e a escolha tornaram-se
elementos centrais da sua constituição. Na verdade, como
representado pela sua bandeira, pode-se pensar que a Federação
Unida de S+S é uma mescla do que cada cultura do velho mundo
tinha a oferecer (Figura 1).
Em sua essência, a UF S+S é uma sociedade que baniu a tirania que
obrigava a escolha de um modo de vida ou outro e, em lugar disso,
adotou o poder da fusão. Os padrões elevados de Enterprisia e a
liberdade de experimentação da República Popular são desejados;
procura-se ter as experiências ricas dos nativos de Desktopistan e a
mobilidade normalmente encontrada em Deviceland. Opiniões
dogmáticas e vacas sagradas são substituídas por tomada de decisão
pragmática, processo linear para se fazer a escolha certa, no momento
certo. A Tabela 5 apresenta os atributos centrais da Federação Unida
de S+S e a influência originada.
O que tudo isso quer dizer, realmente?
O objetivo da história irônica anterior foi o de transmitir a premissa
fundamental da visão software + serviços: arquiteturas híbridas são
boas.
Similar à fusão musical em que os estilos pop, folclore e reggae são
misturados, ou à fusão culinária que coloca patê de fígado sobre um
sushi, software + serviços combina padrões arquiteturais encontrados
na empresa, na web, nos aplicativos para desktop e nos dispositivos.
Em lugar de escolher um ou outro, a visão software + serviços agrupa-
os e aceita todos os padrões de cada domínio trazendo oportunidades
únicas para uma solução global.
Portanto, propomos um distanciamento do modelo "tamanho único"
e, em seu lugar, combinar várias arquiteturas na mesma solução, para
tentar conseguir a abordagem "o melhor de todos os mundos".
Não se trata mais de comprometer a riqueza pelo maior alcance, mas
oferecer ambos; tampouco comprometer controle rígido e
propriedade dos dados de uma solução interna por estrutura de custo
para vários locatários, mais econômica, mas conseguir ambos.
Atualmente, existem muitos exemplos de software + serviços. A
combinação Xbox / Xbox Live oferece um exemplo perfeito:
proporciona ricas experiências em 3-D, maximizando o poder de
processamento gráfico do console local (influência “Desktopistana”) e,
ao mesmo tempo, permite experiências participativas por meio do
serviço Xbox Live (influência da "República Popular do Mundo On-
36
Figura 2: Um padrão S+S possível para empresa
Solução
contábil
SaaS
Solução Contabilidade
CRM Saas
Arquitetura
Arquitetura
CRM de integração
de
composição
Usuário
Portal Colaboração corporativo
E-mail
line"). Este padrão, claro, não é utilizado apenas pela Microsoft, mas
está se tornando uma tendência do setor. As combinações
iPod/iTunes da Apple, Salesforce.com/Salesforce.com Offline Edition
também são exemplos deste modelo.
Contudo, a visão software + serviços não se limita a clientes locais
ricos que acessam aplicativos Saas. Outro exemplo poderia ser o
modelo estendido da arquitetura orientada a serviço (SOA) em que as
empresas executam parte do seu portfólio localmente e parte dele na
nuvem, conforme ilustrado pela Figura 2.
Sob a proteção do guarda-chuva software + serviços pode-se admitir
um número maior de cenários e eu diria que as três realizações mais
freqüentes (pelo menos inicialmente) serão:
1. Software local complementando um serviço na nuvem (por
exemplo, uma interface baseada em Outlook para o CRM Live).
Este modelo combina a experiência rica, ágil, familiar do usuário
local com economia de escala e distribuição SaaS um-para-muitos.
2. Software local ampliado por um serviço na nuvem (por
exemplo, um serviço anti-spam, anti-phishing baseado na nuvem,
ampliando um servidor de mensagens executado no local). Este
modelo permite que uma incrível variedade de serviços de valor
agregado seja acrescentada na nuvem, liberando os sistemas
existentes que controlam os dados considerados preferenciais para
ficarem intramuros.
3. Consumo de serviço independente de local, muitos-para-um no
TI corporativo (por exemplo, cenário de “SOA estendida”). Este é
um cenário típico de otimização de TI.
Por fim, para concluir esta narrativa fantasiosa, deixo-os com a
recomendação que teria sido, estou certo, a afirmação da hipotética
da constituição da Federação Unida de Software + Serviços: “Aceite a
diversidade, exija escolher”.
Agradecimentos
Agradeço muito aos meus irmãos de armas, Eugenio Pace e Frederick
Chong, pelas conversas que tivemos que nos levaram aos vários países
fictícios.
Sobre o autor
Gianpaolo Carraro é diretor de Distribuição de serviço – Estratégia de
arquitetura da Microsoft. Para saber mais sobre ele, visite o blog do
Gianpaolo: http:// blogs.msdn.com/gianpaolo
THE ARCHITECTURE JOURNAL • Journal 13 • www.architecturejournal.net
ARC THE
ARCHITECTURE
JOURNAL
Inscreva-se no endereço: www.architecturejournal.net