Visando selecionar um modelo de componentes orientados a serviços de código aberto para ser utilizado como base, estabelecemos um conjunto de critérios.
7.2.1 Critérios
De imediato, um critério fundamental diz respeito ao suporte nativo aos conceitos de componentes e serviços e, consequentemente, ao padrão arquitetural SOA, o qual se ba- seia no conceito de registro de serviços para viabilizar a descoberta e a ligação dinâmica. Conforme vimos na Seção 2.2.3.3, um registro de serviços ideal deve, além de manter a descrição dos serviços disponíveis, suportar as operações de publicação, retirada, e atuali- zação de serviços, assim como permitir a consulta dos serviços disponíveis e a notificação quando da publicação, retirada, ou modificação dos serviços registrados.
Em geral, nos modelos de componentes orientados a serviços, o código de negócio das aplicações não acessa diretamente o registro de serviços. Nesses modelos, o acesso a esse registro é realizado a partir de um contêiner, o qual é responsável por publicar, descobrir, e selecionar os serviços utilizados pelos componentes das aplicações. Esses contêineres implementam um mecanismo de injeção de dependências, através do qual as aplicações informam as características dos serviços requeridos, cabendo ao contêiner a seleção e injeção desses serviços na própria aplicação.
Neste contexto, um aspecto importante diz respeito à extensibilidade do contêiner. De fato, esse contêiner deve ser aberto e projetado para permitir a definição de extensões per- sonalizadas, sem que essas tenham que ser embutidas diretamente no modelo original. Em particular, deve ser possível criar extensões que redefinam as interações entre o contêiner e o registro de serviços, assim como entre provedor e consumidor de serviços, permitindo a incorporação de características que não são nativamente suportadas por esse registro. No contexto da plataforma DSOA, a intenção dessas extensões é tornar o registro de serviços “ciente de qualidade”.
Para viabilizar a reconfiguração dinâmica das aplicações, uma característica fundamen- tal do modelo de componentes utilizado como base é a oferta de capacidades reflexivas, as quais, combinadas com o fraco acoplamento decorrente do uso de serviços, permitem a substituição dinâmica dos elementos de uma aplicação. De forma geral, uma extensão
de um contêiner permite que este seja capaz de tratar um aspecto não-funcional que não é nativamente suportado (e.g., desempenho, persistência, e segurança). Neste cenário, é essencial que o mecanismo utilizado para estender o contêiner permita que as próprias extensões possam definir novas capacidades reflexivas, as quais estão relacionadas à reifi- cação dos aspectos tratados.
Considerando-se a natureza das QSBAs, outra característica importante é que o mo- delo utilizado como base não imponha grandes requisitos em termos de capacidade de memória e processamento, inviabilizando a execução dessas aplicações em dispositivos com poucos recursos. Um outro aspecto relacionado diz respeito ao desempenho. Em particular, é importante que tanto a plataforma utilizada como base, quanto as extensões implementadas pela plataforma DSOA, introduzam um impacto pequeno no desempenho, de forma a não comprometer significativamente a experiência dos usuários, em virtude, por exemplo, de uma redução na responsividade das aplicações.
Do ponto de vista do gerenciamento de mudanças, um aspecto considerado essencial é que não deve ser necessária a modificação do código fonte do modelo de componentes utilizado como base. Em geral, modificações dessa natureza inviabilizam a execução de aplicações construídas diretamente sobre essa plataforma. Mais ainda, provocam uma ne- cessidade recorrente de manutenção em função de evoluções na plataforma adotada. Nesse contexto, uma característica importante diz respeito à capacidade de “modularização”, ou seja, espera-se que eventuais extensões possam ser tratadas através da introdução de módulos separados, os quais devem ser facilmente integráveis.
Outro aspecto importante diz respeito ao modelo de programação associado ao modelo de componentes. Como vimos anteriormente, os modelos de componentes são concebidos em torno de um modelo abstrato responsável por definir os elementos conceituais supor- tados pelo modelo. Para que esses conceitos possam ser utilizados no desenvolvimento de aplicações, eles devem ser representados em alguma linguagem de programação. Essa representação é materializada em um modelo de programação, o qual estabelece a API utilizada no desenvolvimento. Visando simplificar o desenvolvimento e tornar as aplica- ções mais portáveis, a plataforma DSOA propõe que os componentes sejam desenvolvidos com base em um modelo de programação fundamentado em objetos Java puros, normal- mente referenciados como POJO, sendo as dependências dos componentes em termos de serviços tratadas através de um mecanismo de injeção de dependências.
Por fim, considerando-se o papel fundamental do conceito de eventos na plataforma DSOA, espera-se que uma plataforma de suporte ofereça facilidades para a representação e comunicação desses eventos.
7.2.2 Plataforma iPojo
Como vimos na Seção 2.2.4.1, iPojo é uma plataforma de código aberto, fundamentada em um modelo de componentes orientados a serviço baseado em objetos Java puros. Nesse
modelo, os componentes são gerenciados por contêineres customizáveis e extensíveis, os quais foram projetados para serem “leves”, consumindo poucos recursos de memória e processamento.
Apesar da grande flexibilidade decorrente das diferentes possibilidades de configuração, a plataforma iPojo possui importantes limitações no contexto das QSBAs. Como vimos, a própria plataforma assume controle total sobre os serviços providos e requeridos, restando às aplicações a possibilidade de escolha de parâmetros que pareçam adequados. Observa- se ainda, que há um forte viés na plataforma quanto ao tratamento da característica de disponibilidade. Se por um lado, essa abordagem minimiza a possibilidade de erros decorrentes de acesso a serviços não mais disponíveis, por outro, limita a capacidade das aplicações de definir novos critérios de seleção.
De fato, para que se tenha um maior controle dos serviços providos e requeridos, é necessária a implementação de novos tratadores, os quais devem ser utilizados em substi- tuição àqueles utilizados por padrão na plataforma. Contudo, o desenvolvimento de tra- tadores é delicado, uma vez que esses elementos participam ativamente do gerenciamento das instâncias de componentes, devendo tratar aspectos complexos como validação e in- validação das instâncias e controle de concorrência. Delegar esses aspectos às aplicações vai de encontro ao princípio de separação de interesses.
A despeito dessa limitação, a plataforma iPojo atende aos demais critérios relacio- nados, fornecendo uma plataforma de baixo custo computacional e com um modelo de programação simples e intuitivo. De fato, ao estabelecer um mecanismo capaz de injetar os serviços necessários em uma aplicação, a plataforma iPojo permite que o desenvolvimento seja focado no negócio, de forma que a gerência dos serviços utilizados pela aplicação é realizada sem que ela tenha conhecimento da plataforma.
Em função dessas características, o presente trabalho propõe que a plataforma iPojo seja utilizada como base para a criação da visão de componentes e serviços definida pelos modelos da plataforma DSOA. Nesse contexto, a plataforma DSOA estende a plataforma iPojo, ampliando a capacidade de gerenciamento automático das aplicações, ao permitir que estas adotem outros critérios de qualidade, além da disponibilidade, como gatilho para o processo de adaptação. Ao mesmo tempo, pretende-se manter essas aplicações sob con- trole da plataforma, evitando que elas manipulem diretamente os serviços e minimizando os riscos inerentes ao dinamismo. Por fim, espera-se que o conjunto de características de qualidade compreendidas pela plataforma resultante seja dinamicamente extensível, e que as aplicações possam definir como essas características devem ser dinamicamente avaliadas.