1. Introdução
Hoje em dia, todas as empresas procuram formas de melhorar a sua eficiência produtiva e também exploram activamente a reorganização dos activos de TI. As organizações de TI fizeram algum progresso na superação desses problemas com a ajuda de tecnologias de arquitetura orientada a serviços (SOA). No entanto, na maioria dos casos, apenas uma pequena parte de todo o portfólio de serviços de TI é implementada; Atualmente, a maioria dos esforços nesta área está apenas alcançando um estado "suficiente" de adoção de SOA – melhorando a capacidade de construir aplicativos e integrá-los ao mercado de forma mais rápida, melhor e mais barata. E, como aprendemos, é mais fácil falar do que fazer alcançar esses objetivos.
2. Aplicativos compostos tradicionais baseados em middleware
O fato é que SOA é um tipo de middleware - e em casos tradicionais, o middleware geralmente depende de mais middleware para traduzir os dados em um estado amigável ao consumidor. Quando você finalmente descobrir que construir um aplicativo composto que incorpore a tecnologia SOA não requer apenas o uso de um portal (middleware), mas também pode exigir o uso de um mecanismo BPEL (ou mesmo middleware) para orquestrá-lo, é claro que isso faz com que você esteja muito decepcionado. Pior ainda, você pode trabalhar em uma organização que publica registros UDDI e registra vários serviços da web. Infelizmente, na maioria dos casos, existem poucos aplicativos que realmente consomem esses serviços. Como poderia ser esse o caso?
A incapacidade de construir aplicativos que consomem esses serviços SOA nos leva a concluir que algo está errado? Será que é muito difícil para os desenvolvedores de conteúdo de negócios criarem aplicativos que consomem diretamente os serviços SOA? confiar em outras organizações de TI para criar tais aplicativos para nós? A falta de uma estrutura de governança SOA está nos impedindo? Acho que a resposta para todas as perguntas acima é “sim”. E há uma razão muito importante: é muito difícil apenas para os desenvolvedores de negócios consumirem e utilizarem esses serviços SOA expostos pela organização de TI. Na verdade, o verdadeiro problema é a falta de uma maneira fácil de adicionar uma interface SOA - e! esta é a vantagem de combinar a tecnologia AJAX com SOA.
Normalmente, um serviço SOA é implementado como um serviço Web fracamente acoplado que encapsula e expõe funcionalidades de negócios. Isto pode parecer muito simples, mas é muito complexo e difícil de implementar. Os desenvolvedores frequentemente debatem a granularidade de desenvolvimento dos serviços SOA, entretanto, a maioria dos desenvolvedores agora concorda que a granularidade de desenvolvimento no “nível de negócios” é a mais apropriada. No entanto, isso ainda exige que um grande número de especialistas relevantes do domínio participem e trabalhem com conteúdo comercial para finalizar o tamanho desses serviços.
3. O renascimento da SOA
Felizmente, recentemente as pessoas ficaram profundamente interessadas em SOA. Talvez as empresas estejam finalmente percebendo que SOA pode realmente ajudá-las tremendamente. Talvez isso se deva às melhores ferramentas de desenvolvimento e serviços web promovidos pela Amazon, Yahoo e eBay. Talvez seja AJAX? Sim, é por isso que estou escrevendo este artigo. Sério, eu acho que o AJAX se tornou uma força motriz importante na renovação da compreensão das pessoas sobre SOA, especialmente nos atuais campos de aplicação híbrida de diversas novas tecnologias. No entanto, como essas duas tecnologias tão diferentes deveriam ser combinadas e conectadas para liberar maior poder? Vamos primeiro dar uma olhada na definição da Wikipédia da atual tecnologia AJAX. Estão envolvidas páginas da Web, mas SOA não é mencionada. A descrição é:
"AJAX, que significa 'Asynchronous JavaScript + XML', é uma tecnologia de desenvolvimento web para a criação de aplicativos web interativos. Seu objetivo é facilitar o front-end da página web, trocando uma pequena quantidade de dados com o servidor em segundo plano. Parece mais responsivo; portanto, toda vez que um usuário faz uma alteração, a página inteira não precisa ser recarregada. O objetivo final é melhorar ainda mais a interatividade, a capacidade de resposta e a usabilidade da página.
SOA não é mencionado nesta definição. Não é surpreendente, uma vez que os primeiros aplicativos AJAX se concentravam em melhorar a funcionalidade e a usabilidade das páginas. Isso foi comprovado em vários aplicativos, como Google Maps, Flickr e Yahoo Mail. No entanto, não são esses aplicativos voltados para o consumidor que me entusiasmam com o potencial do AJAX, são os aplicativos de negócios executados atrás do firewall de uma empresa que realmente aproveitam o que há de bom no AJAX, porque nos mostra duas características principais: Uma é um cliente modelo de programação lateral e o outro é uma implementação fácil de chamadas assíncronas ao servidor. Esses dois recursos principais – a capacidade de aplicar lógica no cliente (navegador) e a capacidade de acessar dados do servidor sem interromper a página da Web – abrem a porta para a construção de aplicativos empresariais Web 2.0 novos e mais ricos. .
Anteriormente, mencionei que o SOA não possui uma interface. É aqui que entra o AJAX - ele adiciona uma aparência decente ao SOA. Aqui, permita-me explicar um pouco mais. Poderíamos também pensar no que aconteceria se os serviços SOA aparecessem on-line. Esses serviços geralmente precisam ser registrados em um registro ou depósito (se tivermos sorte) e então podem ser usados para consumo. Por exemplo, vamos dar uma olhada no que está disponível no site da StrikeIron ( www.StrikeIron.com ). StrikeIron criou com sucesso um “mercado de serviços Web” para o público em geral. À primeira vista, o mecanismo de diretório no StrikeIron se parece muito com uma lista fornecida em um aplicativo para pequenas empresas. Mais tarde, porém, você perceberá que não se trata apenas de aplicativos – na verdade, são serviços da Web. O conceito de uma única empresa fornecendo serviços Web WSDL/REST para uma ampla gama de consumidores tem muitas implicações. Mas, por enquanto, vamos dar uma olhada no que esta empresa está vendendo. De acordo com informações fornecidas pela StrikeIron (que fornece acesso a esses serviços), os serviços web mais populares que ela fornece incluem:
· Verificação de endereço nos EUA
· Serviço global de SMS
· Imposto sobre vendas e uso
· Verificação de e-mail
· Pesquisa reversa de telefone
Nada Sem dúvida, todos esses serviços da Web são bastante úteis e podem ser usados em diversas áreas. Mas, ao mesmo tempo, são muito “mercadorias”. Em outras palavras, posso não me importar com quem fornece esses serviços, mas apenas querer obter as informações que desejo. Por outro lado, eu simplesmente usaria qualquer serviço da web para transferir dinheiro da minha conta corrente para minha conta poupança? Primeiro preciso estabelecer confiança neste serviço, por isso tenho que estabelecer um certo relacionamento com o fornecedor que o fornece. Esse “círculo de confiança” que existe entre mim (o consumidor) e o prestador de serviço também representa o relacionamento dentro da empresa e seus parceiros.
4. Combinando tecnologia AJAX + SOA
O mesmo método acima também pode ser adotado por empresas para fornecer seus serviços Web a uma base de usuários mais ampla. Através de um mercado de serviços Web, as empresas podem registrar vários serviços Web – e esses serviços Web geralmente estão disponíveis apenas dentro da empresa ou para parceiros. Os fornecedores do mercado obviamente querem que isso aconteça, mas o mais importante é que vemos uma oportunidade de aplicar a tecnologia AJAX+SOA para impulsionar uma nova classe de aplicações comerciais da Web 2.0.
Pela primeira vez, as pessoas começaram a sentir que o desenvolvimento de aplicações e a SOA estavam finalmente se unindo. Temos funcionalidades de negócios descritas de forma reutilizável - um serviço SOA. Temos conectividade onipresente – a Web. Temos navegadores que estão provando ser os novos contêineres de aplicativos. Temos um modelo de programação neste tipo de contêiner/navegador de aplicação - JavaScript. E todos eles usam padrões abertos! O que mais pedimos? Na verdade, há outras coisas!
Eu gostaria particularmente de ver uma forma mais rápida de desenvolver aplicações baseadas em todas as tecnologias acima - uma forma de construir aplicações sem ter que depender de middleware integrado com serviços SOA. Isso é exatamente o que eu quero que um aplicativo da web seja capaz - "conexão direta com SOA". Essa "conexão direta com SOA" deve ser capaz de contornar as barreiras tradicionais dos portais e mecanismos de processos pesados para acessar diretamente (pelo menos conceitualmente; aprenderemos mais sobre isso mais tarde) os serviços SOA. Com isso, não me refiro apenas a serviços da web, também podem ser serviços de orquestração BPEL, serviços POJO de granulação grossa, feeds RSS ou qualquer outra coisa que possa ser exposta como um "serviço". É claro que as interfaces devem ser expostas utilizando padrões abertos.
Este novo modelo de desenvolvimento e tempo de execução cria uma nova maneira de construir aplicativos compostos orientados por aplicativos. Ele tem o apelo de um tipo cliente/servidor sem a bagagem pesada dos tradicionais clientes/servidores pesados. Ele roda no lado do navegador e pode ser implementado de acordo com requisitos específicos.
5. Aplicações Compostas Baseadas no Usuário
Nos últimos anos, todos nós ouvimos falar do conceito de “aplicações compostas”. No entanto, a maioria dos fornecedores tem falado sobre “serviços compostos” – como uma forma de reestruturar seus serviços de host em outros serviços ou aplicativos de portal mais úteis. Deixe-me fazer uma analogia para explicar melhor.
AcmeGrid, nosso fornecedor fictício de grid computing neste artigo, fornece um serviço – grid computing – que permite que seus aplicativos sejam executados como um serviço. Os clientes da empresa disseram que queriam uma maneira de combinar muitos serviços em um serviço de granulação grossa. Então, naturalmente, a AcmeGrid lançou um AcmeGrid Composite Application Builder (CAB) baseado em Eclipse. Curiosamente, o CAB se parece muito com um designer BPEL, mas está mais integrado aos serviços publicados pela AcmeGrid. Apesar de muito bonito, porém, não é um aplicativo real, na melhor das hipóteses é apenas um serviço. Em essência, o CAB é mais como um construtor de serviços. Mas quem precisa de um construtor de serviços quando estamos tentando construir aplicativos? Em breve, outro fornecedor fictício, vamos chamá-lo de AcmePortal, anunciou seu Portal Composite Application Builder (PCAB). Ele também vem com um designer baseado em Eclipse; embora também pareça um designer BPEL, este programa "sabe" como construir portais. Em muitos casos, um portal funciona tão bem quanto um aplicativo. Porém, se você insistir em converter um portal em um aplicativo, será em vão.
Na verdade, eu realmente quero implementar um aplicativo composto baseado em usuário, em vez de um aplicativo composto baseado em middleware. Para fazer isso, eu precisava de uma plataforma de desenvolvimento e tempo de execução que pudesse não apenas usar AJAX e SOA, mas também gerenciar ambos. Alguns fornecedores levaram o conceito de aplicativos AJAX um passo adiante - chamando serviços Web baseados em WSDL diretamente do navegador, o que é essencialmente uma chamada SOAP. Essa abordagem ainda tem um nome - "Cliente/SOA". Isso pode ser adequado para aplicações simples não empresariais ou de consumo, mas não para programas verdadeiramente empresariais. Por quê? Porque quando você chama um serviço Web diretamente do navegador, a função de supervisão equivale a ser entregue ao navegador - o que significa simplesmente que não há nenhum problema de supervisão. A Figura 1 mostra o diagrama de blocos do consumo não supervisionado de serviços Web. Nunca conheci uma empresa que não fiscalizasse seus serviços e não acredito que as empresas permitiriam que isso acontecesse só porque somos tecnicamente muito eficientes nisso. Se você não acredita em mim, lembre-se de que as empresas nunca abrem seus firewalls para aplicativos que não sejam HTTP e SSL. Não importa o quanto convençamos os administradores do sistema, eles não abrirão outras portas.
6. Precisamos de um novo tipo de plataforma
Como pode ser visto acima, o que estamos discutindo não é apenas sobre tecnologias AJAX e SOA. Na verdade, o que realmente precisamos é de uma plataforma que possa fornecer os recursos de supervisão necessários para que AJAX e SOA coexistam na empresa. Esta plataforma também oferece a capacidade de consumir serviços SOA da perspectiva do cliente, podendo também monitorar o consumo de serviços. A Figura 2 mostra como os serviços Web podem ser gerenciados por meio de um gateway de serviço. Um gateway de serviço é na verdade uma abstração do lado do servidor que monitora e regula o acesso ao serviço em nome do cliente, que no caso que acabamos de discutir é um aplicativo AJAX baseado em navegador. A vantagem de usar um gateway de serviço é que você não fica restrito a acessar apenas serviços em execução na empresa. Este gateway de serviço pode supervisionar qualquer serviço registrado na empresa. Em um serviço Web baseado em WSDL, a empresa registrará o WSDL e o WSDL fornecerá ligação ao serviço em tempo de execução. Este pode ser um serviço executado no data center de uma empresa, mas também poderia facilmente ser um serviço executado no data center de uma parceria. Se uma empresa permite (através de regulamentação) que aplicações acessem serviços, não importa onde esses serviços estão sendo executados.
7. Conclusão
Depois de ler este artigo, espero que você tenha começado a apreciar o poder de unir AJAX e SOA — especialmente como os dois podem coexistir e permitir novos tipos de aplicativos baseados na Web com os recursos regulatórios exigidos pelo aplicativo de serviço corporativo. . Acredito firmemente que estamos às vésperas de uma nova era de oportunidades incríveis. Na era da Web 2.0, as redes sociais, a partilha de imagens e diversas tecnologias de anotação são excelentes, mas o que é verdadeiramente influente é a resposta da Web 2.0 às empresas.