Aprenda a disciplina,
busque a arte e contribua
com idéias no:
www.ArchitectureJournal.net
Recursos nos quais você
pode confiar.
THE
ARCHITECTURE
JOURNAL
Idéias para melhores resultados
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
TM
Sumário
THE
ARCHITECTURE
JOURNAL
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
TM
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
Tim O'Brien
Caro Arquiteto,
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
escolher uma opção "ou" outra, como seria se pudéssemos escolher algo usando "e"? Por
que nossas escolhas têm de ser forçadas a usar uma determinada tecnologia quando a
melhor solução é, quase sempre, um mix de duas? Este é o conceito que serve de base ao
tema desta edição do The Architecture Journal: software + serviços.
Design, impressão e distribuição
CMP Technology – Editora
Chris Harding, diretor administrativo
Angela Duarte, gerente de publicação
Lisa Broscritto, gerente de projeto
Kellie Ferris, diretor corporativo de
serviços criativos
Jimmy Pizzo, diretor de produção
A organização dos artigos desta edição explora uma nova visão de software + serviços,
conforme exposto por Ray Ozzie, arquiteto-chefe da Microsoft, em seu discurso na MIX
07 deste ano.
Iniciamos esta edição com Don Ferguson, cujo perfil foi o destaque do Jornal 11, lembrase? 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).
Diagramação, finalização e impressão (BR)
Arthéria Comunicação & Multimídia
www.artheria.com.br
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.
®
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.
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.
Copyright © 2007 Microsoft Corporation. Todos os direitos
reservados.
THE ARCHITECTURE JOURNAL
• Journal 13 •
Simon Guest
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).
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
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.
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.
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
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
2
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
O Barramento de Serviços para a Internet
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
C
D
B
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
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
com ordens de compra e aprovação de contas de
despesas, por exemplo. O cenário é um exemplo
de aplicativo composto que implementa um
padrão de processamento direto (STP - StraightThrough-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,
restaurante, a locadora e outros sistemas
3
O Barramento de Serviços para a Internet
Figura 2: Um processo corporativo do negócio
Feed
Recebe
Mensagem C
sobre MQ
Converte
Serv
Inf
Autos
Converte
Cancela
Filtra
Sucesso
Nova
reserva
hotel
Sucesso
RPC
COBOL
SQL
Vôos
Nova
reserva
hotel
Itinerário
Hotéis
RFC SAP
Locadora
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.
3. Os aplicativos das empresas aéreas e dos hotéis são externos à
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
usuário pois os funcionários terão uma identidade na empresa e
outras nas empresas aéreas e hotéis.
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
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
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
Converte
Cancela
Mapeia
1. Não há garantia de que a empresa resolveria investir no
aplicativo composto. Pode haver outros problemas mais
prioritários para o negócio.
4
Serv
Inf
Autos
Filtra
Recebe
Se a área de desenvolvimento corporativo e as unidades de negócio
da empresa do Dave tivessem decidido que a implementação do
aplicativo de viagem construído por ele era bastante importante para
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:
2. O desenvolvimento sistemático envolve casos de uso, algum
tipo de modelagem de processo e entrevistar os participantes.
Tudo isso leva tempo.
Converte
Itinerário
THE ARCHITECTURE JOURNAL
Sucesso
Nova
reserva
hotel
Sucesso
Routeia
SQL
Vôos
Nova
reserva
hotel
SNA
PL/1
Hotéis
• Journal 13 •
RFC SAP
Locadora
Locadora
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.
Figura 4: Um barramento de serviços para a internet
services.spaces.live.com/).
Serviços de
Identidade
Conectividade
Don, amigo do Dave, pode inscrever-se com o componente de
identidade do ISB e criar uma ID de usuário [email protected]. 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.
Workflow
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
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 WSReliableMessaging (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 infraestrutura 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:
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.
1. Recebe a mensagem de cancelamento em XML utilizando WS-*.
3. Se bem-sucedido, sair
2. Possui uma atividade que extrai o elemento de ID da reserva e
consulta o prefixo em uma tabela.
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.
Figura 6: Processamento de mensagem ISB
Feed
Recebe
6
Converte
Serv
Inf.
Autos
Converte
Cancela
Filtra
Nova
reserva
hotel
Sucesso
Nova
reserva
hotel
Sucesso
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
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
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
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
O Barramento de Serviços para a Internet
Se a empresa reutilizar o aplicativo específico para várias
conferências, uma solução sistemática poderá emergir da
solução oportunista. A solução oportunista proporciona um
conjunto concreto de casos de uso para a solução sistemática.
Também pode fornecer métricas para determinar quais
aspectos do aplicativo são utilizados com mais freqüência.
Figura 7: Um ecossistema e modelo do negócio
Modelos
Instanciar
Fornecedores de
software
Integradores
Comunidades
Feed
Transform
Feed
Receive
Inform
Car
Service
Filter
Transform
Feed
Receive
Receive
Transform
Inform
Car
Service
Transform
Cancel
Transform
Cancel
Filter
Feed
Transform
Filter
Receive
New
Hotel
Reservation
New
Hotel
Reservation
Inform
Car
Service
New
Hotel
Reservation
New
Transfor
m
Cancel
Hotel
Reservation
Filter
Success
Transform
Success
Inform
New
Car
Hotel
Succes
Servic
e s
Reservation
New
Hotel
Reservation
Cancel
Success
Success
New
Hotel
Reservation
New
Hotel
Reservation
Success
Success
Success
Barramento de serviços para Internet
...
S1
S2
S3
S3
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
Empresas que implantam aplicativos no ISB desejarão definir contratos
de nível de serviço (SLAs) especificando tempo de resposta, taxa de
transferência, disponibilidade, etc. O SLA determinará o custo cobrado
pelo provedor de ISB. O problema geral de se executar SLAs para
aplicativos arbitrários é enorme. Contudo a tarefa do ISB é mais
simples, pois não implanta código de usuário arbitrário. Instanciar e
configurar modelos pré-construídos para atividades de diretiva,
publicação/assinatura e workflow, por exemplo, restringem os
aplicativos. Isso simplifica executar SLAs, custo previsível e integridade.
Uma arquitetura de referência de software + serviços para
aplicativos oportunistas litantes.
A Figura 7 apresenta uma visão geral de extremo alto nível sobre
como se juntam as peças deste artigo. Primeiramente, o barramento
de serviços para a Internet é universal e faz a conexão de todos os
sistemas e servidores. Haverá muitos aplicativos compostos nos quais
alguns elementos estão no "ESB" e outros, no ISB. Aplicativos
compostos multiorganizacionais são um exemplo óbvio que
implantaria elementos em um ISB na "nuvem". Outra possibilidade são
os aplicativos compostos uniorganizacionais, de curta duração. Por
exemplo, um aplicativo composto que a empresa utiliza para
administrar uma conferência interna. Reutilizar uma plataforma de
software pré-configurada e instalada na "nuvem" pode ser mais
eficiente do que adquirir, instalar, configurar e dar suporte a itens de
hardware e software para executar o aplicativo internamente.
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
...
Terceiros farão a conexão de serviços de valor agregado ao
ISB. O primeiro tipo serão os serviços de infra-estrutura como
um mecanismo de workflow mais robusto ou um banco de
dados em XML com consulta integrada. Os programadores
podem incluir esses serviços em suas soluções conectando-os
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
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".
A comunidade é um importante aspecto da Web 2.0. Pode ser, na
verdade, o aspecto mais importante. Os serviços de infra-estrutura,
blocos básicos de construção de aplicativos e modelos de solução
também surgirão em meio a uma comunidade associada com ISBs,
que oferece e compartilha código. A comunidade também
proporciona um fórum de suporte de auto-atendimento e estabelece
o renome de provedores de "software como serviço".
Software + serviços
"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. Alguns elementos de uma solução
instanciada residirão no barramento (workflows, por exemplo); outros,
em serviços conectados ao barramento (como um sistema de
gerenciamento de conteúdo XML) e alguns serão "instalados" no local.
Quase todos os cenários que utilizam ISB e SAAS são, na verdade,
híbridos de software instalados no local e externamente.
Em outro exemplo, imagine um provedor de armazenamento de
dados usado por Dave para armazenar os itinerários do seu aplicativo.
Ler/atualizar o itinerário sempre por acesso remoto fragiliza o
processo. Provavelmente, o fornecedor de armazenamento fornecerá
um pacote de software instalado no local e no PC para otimizar o
acesso aos dados por meio de cache, replicação, controle de versões,
etc. Software + serviços é o termo para o modelo híbrido.
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.
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.
BizTalk Adapter
http://msdn2.microsoft.com/EN-US/library/aa744368.aspx
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 cofundador 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.
8
THE ARCHITECTURE JOURNAL
Referências
• 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.
Inicialmente, a web foi construída para um mundo de largura de
banda de baixa velocidade, utilizando cliente magro ou terminal
smart, e assumiu largura de banda bastante lenta sendo a maior parte
do poder de computação aplicado ao nível de serviço. Na era clienteservidor, tivemos uma rede de largura de banda de alta velocidade no
âmbito corporativo que equilibrou o processamento no cliente e no
servidor. Em vista das mudanças em computação, armazenamento e
comunicações, como setor e empresa, estamos refletindo sobre o valor
que entregamos aos nossos clientes e analisando qual a melhor forma
de equilibrar o que acontece no cliente, no servidor corporativo e nos
serviços para atender aos vários cenários.
Estamos passando por uma mudança bastante radical no modo de
produzirmos soluções. Acredito, verdadeiramente, que a resposta
nunca está nos extremos, a não ser que realmente haja forte restrição,
como um canal de comunicação magro. Existem algumas soluções
que serão entregues como serviços puros. Basta ir a um navegador:
você realiza a transação, obtém as informações desejadas e faz o que
precisa ser feito. Existem outras situações nas quais, estando em
trânsito, a conectividade com a Internet é menos confiável
dependendo do local. Nesses ambientes, o extremo oposto é
verdadeiro: você deseja transportar o maior volume de dados possível
no seu enorme disco rígido e ter pronto acesso a ele.
Por exemplo, no começo o PC armazenava principalmente
documentos. Agora, lógico, tudo tem a ver com a mídia. As pessoas
tiram fotos digitais, carregam enormes bibliotecas nos discos rígidos,
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
armazenam suas músicas, etc. Até as câmaras de vídeo digitais estão
aumentando. Isso quer dizer que todos os seus filmes pessoais estarão
nos PCs? Ou replicados entre os seus PCs? Acredito que esta é uma
enorme oportunidade para o nosso setor de estudar, solução por
solução, e perguntar qual a melhor forma de equilibrar o uso de
código de cliente e serviço.
AJ: Parece que muitas dessas soluções se ajustariam a um
espectro de clientes baseados em navegador e interação rica. No
âmbito desse espectro você vislumbra o surgimento de tipos de
padrões arquiteturais diferentes?
RO: Vários padrões estão surgindo, embora não saibamos, ainda, o
que serão exatamente. Os padrões para escala horizontal são os mais
desafiadores e interessantes neste momento, acredito. O que está
muito claro é que, para qualquer serviço de alta escala, é preciso ter
em mente a imagem de uma máquina virtual que você escala de
acordo com as suas necessidades. 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.
Determinados padrões de projeto, como MapReduce, são, claramente,
padrões de projeto escaláveis horizontalmente, mas estes resolvem um
conjunto relativamente pequeno de problemas se comparado ao
grande número de aplicativos corporativos que temos hoje em dia.
Com o tempo, finalmente, descobriremos um meio termo e
acabaremos com frameworks que pensam sobre seu aplicativo em
camadas. Essas camadas, desde que ajustadas ao padrão, devem ser
escaláveis horizontalmente.
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
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?
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
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
Perfil do The Architecture Journal: Ray Ozzie
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.
EQUILÍBRIO CERTO DO ENFOQUE SOBRE
TENDÊNCIAS INTERNAS E EXTERNAS QUE LHE
DARÃO A PERSPECTIVA QUE PRECISA".
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: 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ã?
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?
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: 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
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.
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.
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.
Figura 1: Fluxo de conteúdo tradicional (à esquerda) e como o fluxo se modifica nos aplicativos web modernos (á direita)
Dados
010
1
010 01
1
101 00
101
0
1
Servidor Web
011
0
Servidor Web
10
Cliente
Cliente
Apresentação +
dados (por
exemplo, HTML
com dados
incorporados)
Apresentação
(por exemplo, HTML)
Servidor de
banco de dados
12
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
função de força para transferir a organização do aplicativo na direção
de uma meta comum em muitas arquiteturas de aplicativos: separação
rígida entre dados e apresentação.
Pela perspectiva do servidor, apresentar os elementos da IU é
relativamente fácil. Na maioria das vezes, são simples recursos de
arquivo no servidor, como arquivos HTML ou CSS e arquivos de mídia.
Apresentar os dados é outra história. Até agora, a interação com
dados era algo que acontecia entre o servidor web e o servidor do
banco de dados; não havia necessidade de expor pontos de entrada
acessíveis do código, executado em toda a web, em um navegador
web ou algum outro agente de software. É neste ponto que entra o
projeto Astoria.
Interfaces de dados flexíveis
Há várias formas de expor dados aos clientes que os consumirão pela
web. Uma abordagem, possibilitada pelas tecnologias existentes, é
usar uma conduta similar à chamada de procedimento remoto (RPC Remote Procedure Call): as funções são expostas por meio da interface
como os Web Services (por exemplo, interface baseada no protocolo
SOAP ou uma convenção simples baseada em UTI para chamar
métodos e parâmetros de transferência). O Microsoft Visual Studio
oferece um conjunto de ferramentas comprovado, que facilita criar e
consumir interfaces construídas dessa forma. O conjunto de
ferramentas do ASP.NET AJAX leva isso para o próximo nível,
permitindo que Web Services criados com o Visual Studio trabalhem
com clientes AJAX.
O principal problema desta abordagem é a flexibilidade. Se a interação
com dados acontece apenas por meio de pontos de entrada fixos e
predefinidos, qualquer cenário novo ou variação dos existentes, com
dados pouco diferentes, exigirá, tipicamente, a criação de novos
pontos de entrada. Ainda que este nível de controle seja conveniente
em determinadas ocasiões, na maioria dos casos, maior flexibilidade
aumentará a produtividade do desenvolvimento e contribuirá para um
aplicativo mais dinâmico.
O projeto Astoria apresenta uma alternativa à abordagem RPC,
baseada na semântica simples do HTTP. O Astoria adota uma definição
de esquema que descreve cada uma das entidades com as quais o seu
aplicativo lida, mais as associações entre entidades expondo-as sobre
uma interface HTTP. Cada entidade pode ser endereçável com um
identificador de recurso uniforme (URI - Uniform Resource Identifier) e
a convenção do URI permite aos aplicativos atravessar as associações
entre entidades, pesquisar entidades e executar outras operações
normalmente exigidas com dados.
A definição do esquema utilizado pelo Astoria é o esquema de
modelo de dados de entidades (EMD - Entity Data Model),
diretamente compatível com o ADO.NET Entity Framework. O Entity
Framework também inclui um robusto mecanismo de mapeamento
que permite aos desenvolvedores mapear o esquema EDM em um
banco de dados relacional para o armazenamento efetivo.
Para demonstrar a interação com os serviços do Astoria, utilizarei um
exemplo com base no conhecido banco de dados Northwind. É
possível configurar um serviço de dados sobre o Northwind criando
um aplicativo ASP.NET, importando o esquema Northwind do banco
de dados em um esquema EDM, por meio do assistente ADM e,
depois, criar um serviço de dados Astoria voltado para aquele
esquema EDM.
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
As etapas detalhadas para a criação de serviços de dados Astoria,
assim como farta documentação sobre o URI Astoria e os formatos de
carga podem ser encontrados no documento “Using Microsoft
Codename Astoria”, disponível no website Astoria no endereço
http://astoria.mslivelabs.com.
Depois que o serviço estiver ativo e operacional, os URIs poderão ser
utilizados para examinar os recursos expostos pela interface de dados.
Os exemplos a seguir utilizam o serviço experimental do Astoria online que hospeda alguns serviços de dados read-only. Por exemplo:
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers
retornaria todos os recursos do container recurso de clientes. No
formato XML-padrão, teria esta aparência:
<DataService xml:base=”http://astoria.sandbox.live.
com/northwind/northwind.rse”>
<Customers>
<Customer uri=”Customers[ALFKI]”>
<CustomerID>ALFKI</CustomerID>
<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>
<Customer uri=”Customers[ANATR]”>
...properties
</Customer>
...more customer entries
</Customers>
</DataService>
Pode-se também apontar para uma entidade específica utilizando
estas chaves:
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers[ALFKI]
retornaria um recurso de cliente específico; novamente, utilizando o
formato XML no exemplo:
<DataService xml:base=”http://astoria.sandbox.live.
com/northwind/northwind.rse”>
<Customers>
<Customer uri=”Customers[ALFKI]”>
<CustomerID>ALFKI</CustomerID>
<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>
13
Projeto Astoria
Se o URI apontar para um recurso específico, como o que acabamos
de discutir, é possível não apenas recuperar o recurso utilizando um
comando HTTP GET, mas também atualizá-lo, utilizando HTTP PUT, ou
excluí-lo utilizando HTTP DELETE.
Como a descrição do esquema fornecido ao Astoria inclui associações
entre as entidades, estas podem também ser aproveitadas na interface
HTTP. Continuando com o exemplo, se cada recurso de cliente estiver
associado a um conjunto de recursos de pedidos, o seguinte URI
representará o conjunto de pedidos relacionado a um determinado
cliente:
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers[ALFKI]/Orders
Além de ser capaz de apontar para recursos específicos e listar os
recursos de um container, também é possível filtrar, ordenar e paginar
os dados para facilitar a criação de IUs sobre o serviço de dados. Por
exemplo, para listar todos os recursos de clientes da cidade de
Londres, ordenados pelo nome do contato, o aplicativo pode usar este
URI:
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers[City eq 'London']?$orderby=ContactName
O formato real do URI do Astoria ainda pode estar sujeito a mudanças,
mas a semântica e as capacidades devem permanecer relativamente
estáveis.
Em qualquer dos casos, os dados são trocados em formatos simples
como XML ou JSON. O formato real pode ser controlado pelo clienteagente utilizando negociação do tipo de conteúdo HTTP normal. Os
dados são codificados como recursos que simplesmente mapeiam
propriedades de entidades EDM em elementos XML ou propriedades
JSON, as quais estão vinculadas por hyperlinks a outros recursos com
os quais estão associadas. Por exemplo, o URI do exemplo anterior:
http://astoria.sandbox.live.com/northwind/northwind.rs
e/Customers[ALFKI]
resultaria na seguinte resposta (em XML):
<DataService xml:base=”http://astoria.sandbox.live.
com/northwind/northwind.rse”>
<Customers>
<Customer uri=”Customers[ALFKI]”>
<CustomerID>ALFKI</CustomerID>
<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>
inclui um URI que representa o seu local canônico (no atributo do URI
do elemento "Customer" acima).
Interação com dados da camada de apresentação
Existem várias opções para interação com fontes de dados da camada
de apresentação. O primeiro aspecto que definirá o escopo das
opções disponíveis para um determinado cenário é a natureza do
cliente (por exemplo, navegador vs cliente rico).
Como a interface do Astoria é apenas HTTP puro, quase todos os
ambientes com biblioteca de cliente em HTTP podem ser utilizados
para consumir serviços de dados. A interface foi especificamente
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
um subconjunto de XML que o mantém direto e simples.
Para aplicativos .NET, o conjunto de ferramentas Astoria inclui uma
biblioteca de cliente executável no ambiente do .NET Framework e
apresenta resultados provenientes dos serviços Astoria como objetos
.NET; não apenas é o mais fácil para os desenvolvedores, para uso no
âmbito da base de códigos do aplicativo cliente, mas também se
integra bem com componentes que já operam sobre objetos .NET
normais. A biblioteca oferece serviços ricos como gerenciamento de
gráfico, rastreamento de modificações e tratamento de atualizações.
(Vide Exemplo 1.)
A biblioteca de cliente do Astoria é executável tanto no .NET
Framework como no Microsoft Silverlight. Isso permite a criação de
aplicativos de desktop e baseados no Silverlight utilizando a mesma
API, por simples referência ao respectivo conjunto Astoria no
ambiente de destino.
Exemplo 1: Acessar um serviço Astoria do código .NET utilizando a
biblioteca de cliente do Astoria
WebDataContext ctx = new WebDataContext(
“http://astoria.sandbox.live.com/
Northwind/Northwind.rse”);
WebDataQuery<Customer> customers = ctx.
CreateQuery<Customer>(“/Customers?$orderby=CompanyNa
me”);
foreach(Customer c in customers) {
Console.WriteLine(c.CompanyName);
}
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
Projeto Astoria
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();
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)
{
}
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>”;
}
html += “</ul>”;
// “Customers” is a DIV element defined in
the HTML document
$get(“Customers”).innerHTML = html;
}
}
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
foreach (Customer c in q.EndExecute(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).
Além desses, os desenvolvedores podem definir as operações de
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
haver um requisito em que os usuários pudessem recuperar, de cada
vez, os clientes de uma determinada cidade. O desenvolvedor pode
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)
Adaptador de host
Runtime Astoria (tradução,
formato, diretivas URL...)
Interface de host
Astoria
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.
Iqueryable
(+ outras interfaces)
REST e Astoria
Entity
Framework
Outras fontes
de dados...
Armazenamento
de dados
16
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
Projeto Astoria
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
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
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.
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.
Assim sendo, os serviços de software analisados pela perspectiva
corporativa levanta várias perguntas. A quem pertencem os dados?
O que é o contrato de nível de serviço (SLA)? As identidades internas
podem ser levadas para além do firewall para ter acesso aos serviços
da nuvem? Existem implicações normativas?
negócio sentem-se frustrados em relação aos projetos de TI por
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
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 infraestrutura 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.
Figura 1: Continuum da distribuição de sotfware e taxonomia
dos serviços de software
Aproximadamente 70% dos orçamentos de TI são gastos na
manutenção dos sistemas existentes, e apenas 30% são aplicados em
soluções novas. Por outro lado, o custo de hardware e software
diminui e o custo do gerenciamento e suporte cresce. As empresas
esperam do setor de TI mais do que nunca, em parte devido à
confiança recuperada ocorrida após a queda das empresas pontocom,
assim como à crescente demanda das capacidades estilo Web 2.0
dentro do firewall.
Ao mesmo tempo, o TI corporativo passa por uma crise de percepção,
conforme evidenciado pelo feedback do ensaio de Nicholas Carr de
2003 "IT Doesn't Matter" (vide Referências). Muitas vezes os líderes do
18
SaaS
Instalado no local
Histórico
Software
convencional
Serviços de bloco
de construção
Serviços
vinculados
Serviços
acabados
Instalado e
operado
no local
Serviços a partir dos
quais aplicativos
podem ser
construídos
Serviços que
fornecem
funcionalidade autocontida
Aplicativos entregues
via SaaS
Interessante
para usuários
finais
Interessante para
programadores
Interessante para
programadores e
pessoal de infraestrutura
Interessante para
usuários finais
P. ex.,
Serviços Amazon S3
ou Windows Liveapis
P. ex.,
Exchange Hosted
Services ou
Windows Update
P. ex.,
Safesforce.com ou
Microsoft Dynamics
CRM Live
Por exemplo,
Microsoft
Exchange
Software + Serviços
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.
"
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
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
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
Nem os produtos Active Directory (AD) ou os metadiretórios como o
Microsoft Identity Lifecycle Manager resolvem esse problema
específico. O AD é proprietário e o seu modelo de confiança não é
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.)
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
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
• Distribuição de serviço
• Gerência de nível de serviço
• Gerência de capacidade
• Gerência de disponibilidade
• Gerência de continuidade de TI
• Suporte do serviço
• Suporte técnico
• Treinamento
Service Provider
Serviços de Software
Software Convencional
(responsabilidades existentes)
A adição de um serviço acabado, com o seu correspondente
diretório externo, exige extensões do processo de provisionamento e
(des)provisionamento, ainda que este seja um processo humano. Por
exemplo, quando um funcionário sai da empresa, muitas
organizações lutam para concretizar o (des)provisionamento ou
desativação de contas internas em tempo hábil; o risco de exposição
no caso de um aplicativo ou serviço externo é significativo porque
não há firewall corporativo que impeça o usuário de ter acesso ao
aplicativo e aos seus dados.
Novos desafios na adoção
dos serviços de software
TI Corporativo
O gerenciamento de identidades e acesso é um problema perene
que afeta muitos aspectos da TI: dos custos de suporte técnico,
produtividade do usuário à segurança dos dados. Também é uma
área para a qual a TI corporativa deveria fornecer uma experiência
de usuário melhor, se comparada à da Internet (e, ainda assim,
muitas empresas têm dezenas de diretórios de usuários). Análises
feitas por organizações especializadas atestam, com freqüência, que
as redefinições de senha são responsáveis por 30%, em média, das
chamadas de suporte técnico.
• Distribuição de serviço
• Gerência de nível de serviço
• Gerência de capacidade
• Gerência de disponibilidade
• Gerência de continuidade de TI
• Suporte do serviço
• Suporte técnico
• Treinamento
• Integração
• Gerência de identidades
• Dados
• Operações
• Segurança
• Gerência de contratos
• SLAs
• Conformidade
19
Implicações do Consumo de Software + Serviços do TI Corporativo
Figura 3: Integração de identidades oferecidas por federação:
Rede Corporativa
Serviços
de
diretório
Servidor de
federação
Servidor de
autenticação
Provedor do Serviço
Servidor de
federação
Usuário final
Servidores de
aplicativo
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)
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.).
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
É 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
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 infraestrutura 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
20
THE ARCHITECTURE JOURNAL
Dados
• 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, aplicamse 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
de identidade
e acesso
"Considerar se é válido adotar o suporte de federação nos critérios de seleção de provedor.
"Analisar se a administração baseada em funções é uma forma de reduzir complexidade e custo.
"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
de dados
"Incluir exigências para padrões abertos (por exemplo, WS-*) nos critérios de seleção de provedor.
"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?
Regulamentos/
legal
"Analisar a flexibilidade, as políticas e os procedimentos de recuperação de desastre do provedor.
"Determinar se a conformidade se aplica ao provedor e, em caso afirmativo, decidir quais relatórios/diretivas/credenciais são
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
22
"Criar uma arquitetura de integração de infra-estrutura para oferecer um framework para a integração do serviço de software.
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
de dados
SLAs
contratuais
Conformidade
Credenciam. de API's de Web
Services
Segurança
Integração de
Operações
Integração de
Identidades
RBAC
Aplicativos de linhas de negócios
Aplicativo tático
Considerar obrigatoriamente
Deveria considerar
Hoje, os departamentos de TI da empresa têm mais experiência e
Resumo das implicações legais
"A conformidade pode se estender ao provedor de serviço; como é
possível provar a conformidade ainda assim?
confiança no consumo de bloco de construção ou serviços vinculados
"Os relatórios de conformidade podem representar um custo.
aplicativo rico, como o Reuters 3000, ou um serviço de infra-estrutura,
do que em aplicativos completos. Seja um "feed" de dados para um
como o que oferece filtragem de spams, este modelo é bem
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
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
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=c48cf80f6e87-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
compreendido.
• Journal 13 •
www.architecturejournal.net
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
Web Services
Dados
“Feeds” RSS
Aplicativo
mashup
Serviços de
Plataforma
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
Aplicativo cliente
24
É 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
Mashups Corporativos
Figura 2: Uso do BizTalk Services como um serviço de plataforma
para a transmissão de informações
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.
“BizTalk Services”
Serviço de
Identidade
Confiança
Autenticar
Serviço de
conectividade
3
Abrir
Conectar
4
2
1 Autenticar
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 •
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.
www.architecturejournal.net
Direção futura dos mashups
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
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.
26
THE ARCHITECTURE JOURNAL
• Journal 13 •
www.architecturejournal.net
Mashups Corporativos
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
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 email 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
gerenciamento
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.
Web
Service
Ferramenta de cálculo
Serviços essenciais
Definição
de cálculo
(excel)
Segurança
Auditoria
Validação
Agendamento
Notificação
Emissão de
relatórios
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.
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
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.
Para cada produto, a equipe de gerenciamento de capacidade de risco
recuperar informações de forma transparente dos sistemas
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
30
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
IU do
processador de
cálculo
Módulo do processador de
cálculo
• Intérprete de metadados
• Gerente de conectividade
• Mecanismo de execução
• Local (modelo de objeto Excel)
• Excel Services
• Gerente de persistência
Serviço do
processador do
trabalho de
cálculo
Pasta de trabalho do
Excel, Office Open XML
Metadados
de cálculo
Armazenamento de dados
do trabalho de
cálculo
IU do agendador de
trabalhos 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.
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, entregandoos a designers de pasta de trabalho, não desenvolvedores, por meio de
assistentes amigáveis.
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.
Aplicativo de otimização de capacidade
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.
"
Módulo processador de cálculo para configurar, salvar e executar
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
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):
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
do Web Service
Figura 4: Mapeamento de um esquema gerado do método do
Web Service
Add Web Service Method Invocation Step
Rename / Dele
Delete / Run
Web Service URL
Make sure to provide a simple, but explanatory name for this input eld .
Rename / Dele
Delete /
Retrieve Methods
http://companyc.com/Services/CalculationReslts.asmx?wsdl
et Expenses
t FTEs
t Product Stats
Rename / Dele
Delete / Run
t Resource Cost Driver Stats
Web Service Method
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
Reporting Period End
Product Code
Site Code
Capacity Metric By Function Calcs
Capacity Based Unit Cost Calcs
Hour Rate Calcs
Capacity Based Unit Cost Summary Calc
Hour Rate Summary Calc
<datetime>
<datetime>
<string>
<string>
<object>
<object>
<object>
<object>
<object>
Outputs:
Status
Updated
<string>
<datetime>
2 Steps) Edit / Delete
>
(4
4 Steps) Edit / Delete
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
fornecidas pelo usuário para acionar a execução da tarefa.
Um designer de pasta de trabalho usa o assistente de conexão para
adicionar chamadas de método do Web Service específicas para uma
tarefa de cálculo (vide Figura 3). Ao especificar o identificador de
recurso uniforme (URI) para uma WSDL (Web Service Definition
Language) do Web Service, seus métodos e respectivas assinaturas são
recuperados e apresentados ao designer da pasta de trabalho que,
depois, acrescenta um método de interesse para a tarefa de cálculo
como uma etapa do cálculo.
Uma vez acrescida, o processador de cálculo gera, de modo dinâmico,
uma definição de esquema XML (XSD) correspondente às entradas e
saídas do método do Web Service, incluindo-a na pasta de trabalho
como um mapa XML do Excel. A seguir, o designer da pasta de
trabalho faz o mapeamento dos elementos individuais do mapa XML
para as planilhas utilizando o recurso arrastar-e-soltar do painel de
tarefas-fonte XML (vide Figura 4). Essas tarefas serão valores escalares
mapeados para células individuais ou coleções de elementos que se
repetem, mapeados para tabelas do Excel 2007, anteriormente
conhecidas no Excel 2003 como listas Excel. Enquanto os mapas XML
preservam a estrutura hierárquica dos objetos proxy do Web Service,
estes ficam desnormalizados quando mapeados para tabelas ou pastas
de trabalho do Excel.
Ao colocar em serviço pastas de trabalho existentes, quase sempre
recomenda-se preservar a apresentação dos dados na pasta de
trabalho. Muitas vezes, dados similares não são apresentados na forma
de tabela, como exigido pelo mapeamento de elementos que se
repetem nos mapas XML. Além disso, existe um limite para mapas
XML do Excel, ou seja, as células de mapeamento não podem se
sobrepor àquelas de outros mapas XML. Nesses casos, algumas vezes é
preciso transferir dados de uma faixa de células da planilha para outra,
para fazer com que as entradas e saídas do serviço "fiquem em linha".
Um tipo de etapa de cálculo denominada copiar dados permite ao
designer da pasta de trabalho especificar como duplicar dados para
outros locais de uma pasta.
Nos cenários em que o Excel é usado no cliente para edição e
atualização de dados, algumas vezes a lógica do negócio em dados
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
dos dados. Um tipo de etapa modificar IU permite ao designer da
pasta de trabalho fazer a conexão dessas interações.
32
Adicionalmente à criação de etapas de cálculo, o designer da pasta de
trabalho também especifica entradas bem tipadas para configurar
uma tarefa de cálculo utilizando um assistente de entrada de tarefa de
cálculo para especificar nomes de entrada e seus respectivos tipos de
dados. O processador de cálculo gera de modo dinâmico uma XSD
correspondente às entradas a qual é, depois, adicionada à pasta de
trabalho como um mapa XML Excel e mapeada para as células da
planilha, como anteriormente mostrado na Figura 4. Quando a tarefa
de cálculo é executada no cliente Excel, o sistema apresenta ao usuário
um formulário gerado que solicita os valores das entradas (vide Figura
5). Quando executado pelo processador do trabalho de cálculo no
servidor, são usados os valores das entradas especificados pelo
agendador de trabalho de cálculo.
Execução de tarefa de cálculo
O mecanismo de execução é o coração do módulo processador de
cálculo. É responsável por interpretar a chamada do método do Web
Service, copiar as etapas de dados e executá-las na ordem especificada
pelo designer da pasta de trabalho em uma tarefa de cálculo. Quando
o Excel é executado em um cliente, o mecanismo de execução acessa
diretamente o modelo de objeto Excel, utilizando os mapas XML para
vincular dados de/para planilhas. Quando executado no servidor,
utiliza o Excel Services para realizar a vinculação, o cálculo e a
recuperação dos dados.
Figura 5: Execução de uma tarefa de cálculo
All Workbook
Workbook Tasks
Tasks
T
-
Create a New Task
Run Capacity Management Calculation (4 Steps) Edit / Delete
Performs the capacity management calculation for a
reporting period, site, and product.
Run Task
Debug Task
Run Capacity Management Calculation
1. Reporting Period Start / Date
e
Edit / Delete
Reporting Period Start
Reporting Period End
2. Reporting Period End / Date
Edit / Delete
3. Product Code / List
Edit / Delete
4. Site Code / List
Edit / Delete
Product Code
Add an Input
Site Code
Continue1. Get Expenses
Rename / Delete / Run
2. Get FTEs
Rename / Delete / Run
3. Get Product Stats
Rename / Delete / Run
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
Edit Job
Name
Create a New Jo b
V
iew Job Logs Make sure to provide a simple, but explanatory name for calling this task.
View
ed Jobs
Monthly Cap Man - Dalla s
Scheduled
Schedul Jobs
s
Edit / Delete
elete
T.
Monthly Cap Man - Dalla
Monthly Cap Man - Dalla
T on 1/1/2007
This task runs daily at 6:00am CS
Last run at 6:00am CS
Tulsa
Tulsa Edit / Delete
Document to Use Run Job
Select the spreadsheet that you'd like to use with this job.
Browse
CapMan.xls x
Task to Run
Load
Sunday
Monthly on the
1st
Once on January
at
at
00 : 00
06 : 00
1st
2007
UTC
at
00 : 00
UTC
Limitações atuais do Excel Services proíbem que pastas de trabalho
com mapas XML sejam abertas no servidor. Para contornar essa
limitação, o módulo processador de cálculo extrai as informações de
vinculação armazenadas nos mapas XML de uma pasta de trabalho,
remove os mapas XML e apresenta uma cópia "limpa" ao Excel
Services. As etapas de chamada do método do Web Service utilizam
estas informações de vinculação para determinar como configurar e
obter faixas de células dentro da pasta de trabalho por meio da API do
Excel Services. Esta abordagem é similar ao modelo "push" em que os
dados são alimentados para o documento utilizando a estrutura de
controle explícita na tarefa de cálculo. Uma abordagem alternativa que
aproveita as funções definidas pelo usuário (UDFs - User Defined
Functions) do Excel para encapsular as chamadas do Web Service
também é possível, mas apresenta várias limitações, inclusive:
"
ter de confiar no gráfico de dependência da planilha para o
seqüenciamento das chamadas do método do serviço (sem controle
explícito);
"
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;
"
exige manutenção adicional para implantar e fidelizar UDFs nos
termos do Excel Services.
O gerente de persistência abstrai o armazenamento dos metadados do
processador de cálculo. Os metadados serializados ficam armazenados
como uma parte XML personalizada (recurso novo do Excel 2007)
dentro do pacote Office Open XML que representa a pasta de
trabalho. Dessa forma, todas as informações sobre o trabalho de
cálculo ficam armazenadas na própria pasta de trabalho, disponível
para o serviço do processador do trabalho de cálculo.
A IU do cliente de cálculo pode ser implementada como um add-in do
Excel ou como uma personalização do Excel que acrescenta itens de
menu para que a IU do Excel tenha acesso a um jogo de formulários
do Windows. Esses formulários ampliam a IU do Excel por meio de um
conjunto de assistentes para que um designer de pasta de trabalho,
não desenvolvedor, possa configurar, salvar, expor uma tarefa de
cálculo para execução, executá-la diretamente ou examinar suas
etapas de cálculo. Outra classe de usuário, sem autorização para
modificar o cálculo, poderia ter acesso restrito apenas para a interface
de execução.
• Journal 13 •
"
programação da execução (recorrente ou data de execução única);
"
entradas iniciais para o trabalho de cálculo conforme determinado
pelos metadados da tarefa de cálculo;
"
caminho da pasta na qual os instantâneos de auditoria da pasta de
trabalho devem ser armazenados.
UTC
Save/Create this Jo b
THE ARCHITECTURE JOURNAL
"
caminho da pasta de trabalho;
"
identificação de qual tarefa de cálculo da pasta de trabalho deve ser
executada;
Run Job
T
T..
Provide Input Values
Run Capacity Management Calculation
Weekly Cap Man - T
d Last run at 2:00am CS T on 1/1/2007
1
ly Disabled
Run Job
This task runs weekly on Sunday at 2:00am CS
Schedule
T.
Currently
Current Disable
You should provide a fairly detailed description of the purpose of this task
Cap Man - Kansas City Edit / Delete
and a high-level overview of the steps involved.
y on Januar y 1st at 2:00am C
Annual Cap Man - Kansas City
T on 1/1/2007
Daily at 00 : 00 UTC
This task runs annually
annuall on January 1st at 2:00am CS
Weekly on
O agendador de trabalhos de cálculo é um aplicativo pelo qual
usuários administrativos configuram pastas de trabalho e os
respectivos trabalhos de cálculo para execução em hora marcada (vide
Figura 6). As informações fornecidas são:
www.architecturejournal.net
O serviço do processador do trabalho de cálculo é executado como um
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
trabalho foi programado são transferidas para o cálculo e o trabalho
de cálculo da pasta é executado utilizando o Excel Services.
Opcionalmente, um instantâneo da pasta de trabalho (depois de
concluída a tarefa de cálculo) pode ser gravado em local
predeterminado para fornecer uma trilha de auditoria do trabalho de
cálculo.
Conclusão
Esta abordagem arquitetural para resolver problemas do negócio
extremamente comuns tem sido utilizada muitas vezes, ultimamente.
Provou-se robusta e confiável, agregando incrível valor ao negócio.
Em um dos casos, esta solução revolucionou completamente o
modelo de negócio da empresa, permitindo uma oferta de serviços da
qual que nenhum outro concorrente poderia sequer se aproximar.
A visão software + serviços de IUs ricas em dispositivos do cliente
chamando serviços na nuvem adapta-se muito bem ao sistema do
Microsoft Office, especialmente porque a IU oferecida pelo Office é
absolutamente universal e conhecida.
Referências
Denise Partlow, EMC Global Services (ex-Geniant, LLC). “Improving
Data Integrity in Financial Analyses”. Abril, 2006.
Denise Partlow, EMC Global Services (ex-Geniant, LLC). “Real Estate
Firm Simplifies Risk Analyses with Web Services and Excel Smart
Clients”. Abril, 2006.
Microsoft Office Business Applications http://office.microsoft.com/enus/products/FX102204261033.aspx
Sobre os autores
Chip Wilson é arquiteto corporativo da EMC Global Services. Seu mais
recente livro publicado, Transparent IT: Building Blocks for an Agile
Enterprise (www.TransparentIT.com), descreve um framework e
roadmap detalhados para a adoção de uma arquitetura orientada a
serviço e a criação de uma empresa ágil.
Dr. Alan Josephson é consultor sênior de prática da EMC Global
Services, especializado no desenvolvimento do sistema Microsoft
Office. Criou soluções personalizadas de Smart Client e Office
Automation para clientes nos setores financeiro, de seguros e energia.
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 BigIron. 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
Contras
Prós
• Experiências ricas
• Pleno uso dos recursos locais
• Extensibilidade
THE ARCHITECTURE JOURNAL
• Experiência isolada
• 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
• Contratos e acordos de nível de
serviço baseados na economia
• Governança
• Adoção lenta, aceitação lenta
• Falta de agilidade
• Muitos dados legados
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
• Alcance
• Coletividade
• Inovação rápida (técnica e
nos modelos de negócio)
THE ARCHITECTURE JOURNAL
Tabela 4: Prós e contras a vida em Deviceland
Prós
• Mobilidade
• Acesso em qualquer lugar
• Fator forma
Contras
• Fator forma pode degradar
toda a experiência
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ãoducado 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
Contras
Individualidade e experiências ricas
República de Desktopistan
• Sem contratos, todas as transações
seguem o “Farei o possível”
Alcance, coletividade e inovação
rápida
República Popular do Mundo
On-Line
• Tende a satisfazer uma
experiência de denominador
comum
Fatores de forma e mobilidade de
hardware otimizado
Deviceland
• Journal 13 •
www.architecturejournal.net
35
Um planeta regido por arquiteturas de software
Figura 1: Bandeira da Federação Unida de S+S
Figura 2: Um padrão S+S possível para empresa
Solução
contábil
SaaS
Solução
CRM Saas
Contabilidade
CRM
Portal
Arquitetura
de integração
Colaboração
Arquitetura
de
composição
Usuário
corporativo
E-mail
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 agrupaos 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 On36
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