SOA (Service Oriented Architecture) é um termo que pode ter vários significados para públicos diferentes. Podemos encontrar inúmeros artigos descrevendo a ambigüidade de termos [5], a necessidade de separarmos SOA de suas implementações e vários debates recorrentes sobre esses temas. De acordo com Jason Bloomberg [4], temos que fazer uma clara distinção entre SOA e a especificação de Web Services - às vezes eles são confundidos. SOA é uma arquitetura para computação distribuída que trata software como serviços disponibilizados através da rede, enquanto a especificação Web Service define uma plataforma interoperável que oferece suporte à SOA. Nesse sentido, este artigo descreve uma nova abordagem para implementação de SOA através da disponibilização de serviços Jini e JavaSpaces.
Arquitetura Orientada a Serviços
De maneira geral, pode-se dizer que SOA é uma arquitetura para computação distribuída que trata software como serviços disponibilizados através da rede. SOA não é completamente novo; CORBA e DCOM são exemplos de orientação a serviços. Alguns aspectos individuais da arquitetura orientada a serviços vêm sendo usados há bastante tempo. Por exemplo, empresas usam tecnologia de troca de mensagem há décadas para integrar aplicações, acoplando-as fracamente. Pode-se dizer que SOA é uma arquitetura de sistemas distribuídos caracterizada pelas seguintes propriedades:
- Visão Lógica: o serviço é uma visão abstrata e lógica de programas, bancos de dados, processos de negócio, entre outros, definido em termos do que ele faz, tipicamente executando uma operação de negócio.
- Orientação à mensagem: o serviço é formalmente definido em termos das mensagens trocadas entre agentes fornecedores e agentes consumidores. A estrutura interna e a implementação são propositalmente abstraídas. Usando a disciplina de SOA, um usuário não pode e não deveria precisar conhecer detalhes de implementação de um agente.
- Orientação à descrição: um serviço é descrito por meta-dados processáveis por máquinas. Apenas os detalhes expostos ao público que são importantes para o uso do serviço devem ser descritos. A semântica do serviço deve ser documentada direta ou indiretamente por sua descrição.
- Granularidade: serviços tendem a usar um número pequeno de operações com uma complexidade relativamente grande nas operações realizadas.
- Orientação à rede: serviços podem ser usados através de uma rede, embora isso não seja obrigatório.
- Neutralidade da plataforma: mensagens são enviadas em formato padronizado independente de plataforma através das interfaces. XML é o formato mais óbvio que atende a essa restrição.
SOA com Jini e JavaSpaces
Espaço de Tupla é um paradigma de computação distribuída proposto por David Gelernter em meados dos anos 80 baseado no conceito de DSM (Distributed Shared Memory). Neste modelo, o espaço de tupla é caracterizado como uma abstração de um ambiente computacional baseado no conceito de uma única memória virtual compartilhada, responsável por armazenar as tuplas a serem processadas [1]. A principal característica do espaço de tupla é o desacoplamento entre processos. Quando dois processos precisam se comunicar, eles não trocam mensagens ou compartilham variáveis; em vez disso, o processo produtor insere uma tupla no espaço e o processo consumidor consome a tupla do espaço. Alguns anos após a proposição do modelo baseado em espaço de tupla, a Sun Microsystems lançou o JavaSpaces [2]. A especificação JavaSpaces foi criada como parte do projeto Jini. Diferente dos tradicionais modelos de programação distribuída baseados em troca de mensagens, o modelo do JavaSpaces utiliza uma coleção de processos que cooperam através de fluxos de objetos que são inseridos/removidos de um ou mais espaços de tupla. Assim como na especificação original do modelo baseado em espaço de tuplas, os processos no JavaSpaces interagem com o espaço através de quatro operações simples: write(), insere objetos no espaço; take(), recupera objetos do espaço; read(), lê objetos do espaço, sem removê-los. Adicionalmente, a especificação JavaSpaces implementa um modelo de eventos baseado em notificação, através da operação notify(). Uma implementação comercial cujo middleware é baseado em JavaSpaces é o servidor de aplicações Gigaspaces XAP [7]. Sua arquitetura baseada em espaços de tupla é totalmente orientada a serviços. Um cliente que execute em diferentes plataformas podem acessar o espaço de tuplas diretamente através das operações descritas acima ou serviços bem definidos. Neste caso, a plataforma Gigaspaces se encarrega de transformar as chamadas em tuplas de forma transparente.
Jini™ é uma tecnologia com uma arquitetura orientada a serviços que define um modelo de programação que explora e estende a tecnologia Java™ para permitir a construção de sistemas distribuídos seguros, consistindo de federações de redes de serviços bem definidos e clientes [3]. A tecnologia Jini pode ser usada para construir sistemas de rede adaptáveis, escaláveis e flexíveis, que podem ser gradativamente evoluídos, suportando os requisitos de ambientes de computação dinâmica. Um aspecto importante de Jini é o entendimento de que, inevitavelmente, haverá alguma falha na rede, ou em clientes, ou mesmo nos serviços oferecidos. Por definição, Jini oferece portabilidade de plataforma, mobilidade de código e segurança. Pode ser utilizado em aplicações com acesso completo ao ambiente de execução da plataforma JSE ou dispositivos menores, sistemas embarcados e mesmo em aplicações escritas em outras linguagens. Contrariando a propaganda feita pela Sun Microsystems há alguns anos, Jini vai muito além de fazer aplicações para geladeiras e torradeiras trocarem informações.
Jini e JavaSpaces têm sido usados em vários projetos de grande porte. A junção dessas duas tecnologias suporta as características de SOA descritas anteriormente da seguinte forma:
- Visão Lógica: em Jini, o contrato entre o consumidor de um serviço e o fornecedor é garantido através de uma interface Java bem determinada. Uma interface pode representar um banco de dados, um dispositivo qualquer ou abstrair o acesso a outros serviços.
- Orientação à mensagem e descrição: um serviço abstrai completamente sua implementação. Uma implementação de serviço pode ser um script, um Web Service, um servidor de aplicações JEE ou um simples POJO. Entretanto, os serviços têm uma interface Java que os define e atributos que podem ser usados para descrição de suas funcionalidades, características e busca. É possível que em uma rede existam várias implementações de um mesmo serviço, porém, com características totalmente diferentes.
- Granularidade: serviços podem ser implementados das mais diferentes formas possíveis, desde um simples POJO que será executado na JVM do cliente quanto um proxy que acesse um EJB. A complexidade e o fluxo da informação não são pré-definidos pela tecnologia e sim determinados pelo projeto.
- Orientação à rede: Jini foi concebido para funcionar bem em um ambiente crítico, sujeito à falhas e lentidão: as redes de computadores. Além disso, serviços como suporte à transação, ativação e troca de mensagens que são base para a maioria das aplicações também estão sujeitos a falhas e isto está previsto na arquitetura e concepção de Jini.
- Neutralidade de plataforma: Jini realmente não define nenhum protocolo específico para troca de mensagens entre clientes e provedores de serviço. SOAP, raw XML, sockets entre outros podem ser naturalmente utilizados.
Assim como em Web Services, para um cliente fazer uso de um serviço, ele deve inicialmente fazer a busca utilizando um ou mais serviços de busca que já fazem parte da tecnologia. No entanto, ao contrário dos Web Services, o cliente pode, em tempo de execução, fazer o "download" automático do serviço na máquina virtual e executá-lo localmente ou utilizar um proxy para um serviço que será executado em outra máquina virtual.
Conclusões
A popularização da orientação a serviços através de SOA tem causado muita confusão em relação a conceitos e tecnologias. A proposta deste artigo foi desmistificar a idéia que SOA é Web Services e vice-versa, e apresentar uma forma de implementar SOA através de outras tecnologias, como Jini e JavaSpaces. Este artigo mostrou também que Jini/Javaspaces tem muito a oferecer e que estão sendo utilizados apesar de não estarem constantemente na mídia. Além disso, acreditamos que Jini, JavaSpaces e Web Services não são excludentes: são tecnologias que podem e devem ser combinadas.
Referências
[1] D. Gelernter. Generative Communication in Linda. ACM Trans. Program. Lang. Syst., 7(1):80–112, 1985.
[2] E. Freeman, S. Hupfer, and K. Arnold. JavaSpaces Principles, Patterns, and Practice. Sun Microsystems, Inc., 1999.
[3] J. Newmarch. Foundations of Jini 2 Programming. Appress, 2006.
[4] J. Bloomberg. Divorcing SOA and Web services. 2007
[5] D. Ing Dude, Where's my SOA.
[6] D. Booth et. el. Web Services Architecture. W3C Working Group, 2004.
[7] N. Shalom. Space-Based Architecture and The End of Tier-based Computing. Gigaspaces whitepaper.