Introdução ao Service Component Architecture

Voltando a falar sobre componentes após um bom tempo trabalhando com interfaces gráficas, farei uma introdução ao SCA – Service Component Architecture – visando criar uma base nesse site com os conceitos fundamentais sobre a área de componentes. Além de preparar o terreno para os artigos mais avançados (meu objetivo e interesse), você ainda ganha de presente aqui um resumo bem legal que o ajudará a compreender esse ramo da engenharia de software.

Se você tem o mínimo de experiência com desenvolvimento de software, você já deve ter percebido que uma aplicação é, na verdade, um conjunto de componentes que cooperam para realizar um determinado objetivo. Mesmo que o seu código seja o pior dos macarrões ou um verdadeiro ninho de ratos (o Code Comics que o diga), ele ainda sim apresenta conceitos de serviços independentes.

Em linhas gerais, não importa se o seu sistema só tem uma ou duas classes e roda na mesma máquina, ou está espalhado por diversos servidores e se comunicam usando diferentes protocolos. A questão por trás é sempre a mesma e o que muda é a granularidade do serviço. Portanto, o conceito de arquitetura de componentes deve ser escalável e atender a diversos tipos de aplicação, e é aí que a SCA entra em cena.

Service Component Architecture (SCA)

A SCA é uma especificação mantida pela OASIS e foi originalmente criada por um grupo de empresas, incluindo BEA, IBM, Oracle, SAP e outros. Dentre as principais contribuições, temos a organização de boa parte dos conceitos trazidos pela engenharia de software baseada em componentes (CBSE). Além disso, uma especificação não-proprietária ajuda muito na redução de monopólios e possíveis corvardias na indústria de software.

A SCA define como criar componentes e como conectá-los para montar aplicações. Os componentes podem ser criados em linguagens diferentes ou até mesmo com tecnologias diferentes (Spring Framework, BPEL, etc.). O que importa mesmo são as fronteiras que esses componentes disponibilizam para cooperarem entre si, algo imprescindível em qualquer arquitetura de componentes.

Componentes e Composições

Toda aplicação SCA é composta por um ou mais componentes. Sob um ponto de vista simples, podemos ver alguns componentes em java rodando em um mesmo processo. Complicando um pouco mais, poderíamos ter componentes distribuídos que se comunicam por uma LAN através de um protocolo qualquer. Em um caso mais extremo, poderíamos ter componentes em java e C++, somados de mais outros em BPEL rodando em máquinas distantes. Independente do caso, precisamos de um jeito de definir componentes e descrever como eles se comunicam.

Para fazer isso, a SCA apresenta uma definição genérica de componente. Ela também define como esses componentes podem ser combinados para criar composições. Uma composição é uma estrutura lógica que pode ser executada em uma mesma máquina ou distribuída pela rede. Além disso, uma aplicação completa pode ser feita com apenas uma composição ou pode ser uma combinação de diversas composições. Em uma composição, os componentes podem ser implementados em linguagens diferentes ou tecnologias diferentes, desde que eles obedeçam às regras preestabelecidas.

Figura 1: Exemplo de composição.

Conforme mostrado na Figura 1, a composição SCA pode ser acessada por software que não está definido dentro dos padrões SCA. Isso pode incluir páginas JSP, uma aplicação desktop ou qualquer outra coisa. Os componentes também podem acessar dados assim como qualquer outra aplicação. Uma forma de fazer isso é utilizar Service Data Objects para trocar dados, os quais são construídos a partir de tecnologias padrão como JDBC ou JPA. Mas você pode fazer os componentes acessarem diretamente o banco de dados ou os arquivos que você quiser. A SCA não força nenhuma implementação específica nesse sentido.

As composições de uma SCA precisam ser definidas em um arquivo chamado Service Component Definition Language (SCDL), o qual termina com a extensão ".composite". O arquivo SCDL – pronunciado como "skiddle" – possui o formato XML e descreve quais componentes a composição possui e como eles estão relacionados. Para o exemplo da Figura 1, teríamos uma configuração SCDL que pareceria com:

Componentes e composições são elementos fundamentais de qualquer aplicação SCA. Entretanto, eles precisam estar definidos dentro de um domínio.

Domínios

Domínios são usados para agrupar composições e evitar que elas se misturem com composições de outros fornecedores. Como a SCA é um padrão seguido por diferentes fornecedores, essa idéia de domínio facilita a vida do desenvolvedor por limitar o escopo do software e evitar as complexidades das configurações que envolvem múltiplos fornecedores.

Figura 2: Domínio, composições, máquinas e processos.

O domínio mostrado na Figura 2 possui três composições. A composição vista na parte de cima da imagem é formada por dois computadores e roda em três processos. As outras duas composições (parte inferior da imagem) rodam em uma mesma máquina, dividida também em três processos.

É importante lembrar que composições não podem atravessar as fronteiras do domínio, englobando componentes de outros fornecedores. Não confunda isso com interoperabilidade com outros domínios, o que é perfeitamente normal. Em outras palavras, podemos ter dois domínios que se comunicam, mas cada um possui as suas próprias composições e componentes.

A comunicação entre componentes de um mesmo domínio pode ser implementada da forma que o fornecedor quiser. A SCA não impõe limitações nesse aspecto. Já a comunicação entre domínios (ou com software que não é SCA) precisa ser feita por algum padrão aceito pelo mercado, como web services, etc. A Figura 3 ilustra um exemplo.

Figura 3: Comunicação entre domínios.

Essa foi apenas uma visão geral sobre a especificação Service Component Architecture, a qual está ganhando terreno rapidamente na indústria de software. Em breve voltarei para falar mais sobre essa especificação, incluindo mais detalhes sobre os itens explicados nessa introdução.

Comments