O Barramento de Serviços para a Internet

Publicado em: 14 de janeiro de 2008

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.

Nesta página

O cenário e os desenvolvimentos oportunista e sistemático
Software + serviços, e um barramento de serviços para a Internet
Conclusão
Referências
Sobre os autores

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 seviço (SOA) e Web Services; Web 2.0; e software como serviço (SaaS).

Discutiremos o efeito de algumas dessas tendências, mas nossos principais enfoques são SOA, Web 2.0 e SaaS. Esses conceitos e as respectivas relações ainda não estão bem compreendidos. As tecnologias freqüentemente parecem ser antagônicas. O artigo descreve os elementos de uma arquitetura de referência de alto nível que reúne os conceitos em um todo consistente.

Muitas das tendências tecnológicas precedentes são completamente conhecidas e aceitas. Este artigo discute uma terceira tendência, mais controversa: a capacidade de programação universal. Grande parte de graduados do nível médio e das universidades possuem qualificações de programação básica quando passam a integrar a força de trabalho; muitos alunos já desenvolveram aplicativos PHP ou Visual Basic simples 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 p ara ilustrar a arquitetura de referência. Um elemento básico que surge e serve de base para a arquitetura é um barramento de serviços para a Internet ou ISB. A arquitetura de referência abrange muitos elementos; contudo, este artigo detalha apenas o ISB. Outros artigos descreverão outros elementos.

O cenário e os desenvolvimentos oportunista e sistemático

Dave viaja muito a negócio e utiliza os serviços de hotéis e empresas aéreas preferenciais. Aluga carros nas locadoras das cidades que visita e faz reservas em restaurantes. A colaboração com amigos, família e colegas também é importante. Dave utiliza vários websites de agências de viagem para elaborar e modificar planos de viagens.

Administrar as viagens do Dave envolve muitas tarefas manuais para interagir com as agências de viagens por meio dos respectivos websites. Ele precisa coordenar tarefas manualmente em vários sites e copiar/colar dados entre campos. Existe também alguma lógica seqüencial, por exemplo, fazer reserva em um restaurante e alugar um carro para chegar até o restaurante. As atitudes de Dave são 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 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 - Straight-Through-Processing) (vide Referências). As empresas implementam uma abordagem sistemática para resolver esses problemas. A Figura 2 oferece uma visão geral de como seria o aplicativo composto se a empresa aérea, o hotel, restaurante, a locadora e outros sistemas estivessem no âmbito do firewall corporativo. Um processo de orquestração de execução relativamente longa inscreve-se em eventos que o sistema de gerenciamento de vôo emite. O processo envia mensagens de/para e chama os aplicativos existentes para cancelar reservas, consultar disponibilidades e fazer novas reservas. As empresas são heterogêneas e os aplicativos existentes possuem diversos formatos de mensagens (C, COBOL etc.) e de protocolos de comunicação (WebSphere MQ, SAP RFC, por exemplo).

O projeto do processo de ajuste apresentado na figura 2 é frágil. O processo do negócio deve modificar se, por exemplo, outro aplicativo de empresa aérea tiver sido adicionado. O processo do negócio também pode ser acoplado a formatos e linguagens de mensagem específicos dos aplicativos existentes. Seria difícil adicionar um mecanismo geral para o registro de mensagens que correspondesse a determinadas condições, por exemplo, registro de todas as mensagens se o viajante for um executivo. Essa fragilidade levou as arquiteturas de aplicativos corporativos a evoluírem para um barramento de serviço corporativo (ESB - Enterprise Service Bus).

A Figura 3 oferece uma visão geral de um barramento de serviço corporativo. Os adaptadores de aplicativos convertem formatos e protocolos existentes em Web Services padrão. Isso transforma o problema do mapeamento de protocolo/formato N N para conectar uma coisa à outra em um problema de mapeamento N 1, ou seja, tudo dentro de um padrão. O ESB oferece funções adicionais que processam o fluxo de mensagens entre serviços. Exemplos incluem conversão, registro e roteamento das mensagens.

Se a área de desenvolvimento corporativo e as unidades de negócio 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:

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.

2. O desenvolvimento sistemático envolve casos de uso, algum tipo de modelagem de processo e entrevistar os participantes. Tudo isso leva tempo.

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 Internet (ISB). O ISB parece mais com um tecido universal. O ISB faz 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 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:

• seu site PHP pessoal dirigido a banco de dados;

• portal de colaboração familiar por meio do http://www.twiki.org/;

• presença em espaços como no Windows Live Spaces (http://home.services.spaces.live.com/).

Don, amigo do Dave, pode inscrever-se com o componente de identidade do ISB e criar uma ID de usuário don@foo.bar. Dave pode usar a IU web do componente da identidade para especificar quais URIs ISB podem ser acessadas pelo Don. Dave também pode definir grupos e conceder acesso aos grupos. Don pode ter acesso aos URIs depois de estar conectado no ISB. O ISB simplifica o gerenciamento de segurança do Dave porque ele pode manter um banco de dados centralizado e, depois, autorizar o "ISB" a acessar sua página wiki e outros recursos. O ISB protege os recursos atuais por meio do controle de acesso dos URIs ISB que os antecedem. O ISB tem como benefício um único espaço para que Dave defina e atualize identidades, grupos, recursos e diretivas de acesso para todos os seus "serviços" na web.

Acabamos de descrever ações explícitas de usuário por meio de páginas da web. Outra abordagem bastante comum será a de ter aplicativos nas extremidades que participem das APIs de Web Services que utilizam o aplicativo composto para ter acesso ao ISB.

O componente da identidade também dará suporte às funções do STS (Security Token Service) do WS-Security, e fará a federação com outros STSs. Isso permite ao Dave gerenciar o acesso a identidades não registradas no ISB. Se foo.bar fosse uma empresa em que Dave confia e se esta implementar um STS, Dave poderá definir diretivas de acesso para identidades autenticadas em foo.bar.

Com o tempo, os ISBs oferecerão outras diretivas e implementações que podem ser aplicadas aos URIs. Os exemplos podem incluir WS ReliableMessaging (troca confiável de mensagens em Web Services) ou registro implícito de mensagens. O conceito é similar à associação de diretivas de qualidade de serviço com conexões em middleware orientado a mensagem.

O ISB aproveita as capacidades de identidade e acesso para fornecer conectividade universal segura" aos aplicativos – mesmo para aqueles protegidos por firewalls. Isso inclui suporte para ampla gama de padrões e protocolos de conectividade. Entre os exemplos incluem-se HTTP orientado a REST, WS-* e padrões dirigidos a evento encontrados em muitos aplicativos corporativos. Especificamente, o componente de conectividade do ISB oferece três funções básicas:

1. Transmissão: possibilita a comunicação entre o ISB e os aplicativos protegidos por firewalls. Existem muitas técnicas para realizar esta capacidade (BizTalk Labs, vide Referências). A função de transmissão elimina a necessidade de configurar conexões sistemáticas em toda a empresa para cenários simples.

2. Protocolo: oferece um conjunto de protocolos comuns para a troca de mensagens, como WS-* ou REST. O ISB também fornece mapeamento de protocolo para conexão automática de extremidades utilizando protocolos diferentes. Por exemplo, é possível conectar um “feed” RSS a uma conexão de mensagens WS-*, sem necessidade de modificar nenhum dos aplicativos.

3. Funções: oferecem suporte para associar funções simples tipo ESB ao URL. Entre os exemplos seria possível incluir distribuição múltipla (multicast), WS-Eventing (eventos de Web Services), troca de mensagens persistentes, etc.

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 mapeamento RSS para XML.

Outro modelo de atividade comum será o roteamento baseado em seleção. O aplicativo do Dave pode emitir uma mensagem de cancelamento: cancel car reservation ID=1234. Se os códigos de reserva de uma locadora de autos começam com "LE-" e os de outra com "OL", o aplicativo do Dave pode enviar eventos de cancelamento para um único URI ISB. A seguir, o seletor processa a mensagem roteando-a para a extremidade correta.

Combinar atividades de processamentos de mensagens mais complexos pode ser útil e será uma função comum dos ISBs. Como exemplo, a Figura 6 apresenta as atividades do URL que Dave define para recebimento da mensagem de cancelamento da reserva do carro:

1. Recebe a mensagem de cancelamento em XML utilizando WS-*.

2. Possui uma atividade que extrai o elemento de ID da reserva e consulta o prefixo em uma tabela.

3. Converte a mensagem para o formato esperado pela locadora, ou seja:

a) e-mail em HTML para um provedor

b) HTTP POST para o segundo provedor

Construir funções para processamento de mensagens pode ser bastante simples. Muitos dos cenários de aplicativos comuns são instanciações simples de padrões e modelos. Um provedor de ISB oferecerá uma simples ferramenta de desenvolvimento de aplicativo baseada em web que permite aos programadores selecionar modelos de atividade e definir parâmetros de configuração por meio de um formulário web. No caso do roteamento, o formulário web permitiria ao programador especificar o campo da mensagem para roteamento e os valores da respectiva tabela. Com o tempo, os ISBs oferecerão ferramentas mais poderosas, como as ferramentas de processamento de mensagens do BizTalk. O processamento de mensagens roteamento, conversão, etc.) é suficientemente robusto para muitos cenários de aplicativos. Contudo, para outros cenários, é preciso ter seqüenciamento simples e fluxo de controle. Imagine a tarefa de fazer uma reserva de hotel em Dallas quando Dave estiver atrasado. Uma descrição simples do processo poderia ser:

“SOFTWARE COMO SERVIÇO" TOTAL É UM MITO. TODAS AS SOLUÇÕES SAAS REPRESENTATIVAS INCLUIRÃO, EM ALGUM MOMENTO, UM ITEM DE SOFTWARE INSTALADO NO LOCAL: UM HÍBRIDO. QUASE TODOS OS CENÁRIOS QUE UTILIZAM ISB E SAAS SÃO, NA VERDADE, HÍBRIDOS DE SOFTWARE INSTALADOS NO LOCAL E EXTERNAMENTE. SOFTWARE + SERVIÇOS É O TERMO PARA O MODELO HÍBRIDO".

1. Enviar um pedido de reserva para a cadeia de hotel AAA

2. Receber uma resposta.

3. Se bem-sucedido, sair

4. Enviar um pedido de reserva para a cadeia de hotel BBB

5. Se bem-sucedido … …

As atividades de workflow ampliam o processamento de mensagens com modelos de atividades de fluxo de controle como while, if ... then …, etc. Os ISBs acrescentarão suporte, por incrementos, para workflow simples para ampliar o processamento básico de mensagens.

O workflow pode parecer um conceito complexo e as soluções corporativas de workflow sistemático são robustas e complexas. Por outro lado, os workflows para aplicativos específicos e oportunistas, em sua maioria, são extremamente simples. A estrutura não é significativamente 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 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.

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.

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.

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)

(https://www.microsoft.com/brasil/msdn/Tecnologias/arquitetura/Long Tail.mspx). A teoria unificadora do universo computacional é a de software + serviços e o ISB é a pedra fundamental desse novo modelo de aplicativo.

Referências

BizTalk Adapter

https://msdn2.microsoft.com/EN-US/library/aa744368.aspx

Biztalk Labs

http://labs.biztalk.net

Enterprise Application Integration (EAI)

http://en.wikipedia.org/wiki/Enterprise_application_integration

Barramento de serviço corporativo

http://en.wikipedia.org/wiki/Enterprise_application_integration

Mashup

http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

Modelo-Visão-Controlador

http://en.wikipedia.org/wiki/Enterprise_application_integration

OASIS Web Services Reliable Messaging (WSRM) TC

www.oasis-open.org/committees/wsrm/

SAP RFC

http://en.wikipedia.org/wiki/ABAP

Processamento direto (STP - Straight-Through-Processing)

http://en.wikipedia.org/wiki/Enterprise_application_integration

Struts

http://struts.apache.org/

Casos de uso

http://en.wikipedia.org/wiki/ABAP

WS-Eventing

http://www.w3.org/Submission/WS-Eventing/

WS-Security Security Token Service

http://sts.labs.live.com/

Zorro's ISB Blog

http://zorroisb.spaces.live.com

Sobre os autores

Dr. Donald Ferguson é Technical Fellow da Microsoft em plataformas e estratégia na função de CTO. O seu enfoque está no papel evolutivo e revolucionário da tecnologia da informação nos negócios. Antes de ingressar na Microsoft, Don era Fellow da IBM e arquiteto-chefe do grupo de software do SWG (Software Group) da IBM e presidiu o SWG Architecture Board (SWG AB) que se concentrava na integração de produtos, iniciativas de produtos inter-relacionados e tecnologia emergente incluindo Web Services, padrões, Web 2.0 e desenvolvimento dirigido a negócio. O principal hobby de Don é caratê (Kenpo). Em dezembro de 2005 ele tornou-se faixa preta.

Dennis Pilarinos é diretor técnico sênior de Connected Systems, uma divisão da Microsoft. Para conhecer outros detalhes do trabalho que ele realiza, visite o seu blog em www.dennispi.com.

John Shewchuk dirige a equipe de estratégia de tecnologia de Connected Systems (CSD), uma divisão da Microsoft. Na CSD, John trabalhou no desenvolvimento da plataforma de aplicativos da Microsoft inclusive nas tecnologias de troca de mensagens como o produto Windows Communication Foundation, especificações para 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.