Este capítulo apresentou os principais conceitos que caracterizam o paradigma de componentes de software e que são necessários para o entendimento dos demais capítulos.
Os modelos de componentes apresentados neste capítulo consistem, atualmente, dos dois modelos abertos mais difundidos e que são capazes de interoperar entre si e com outros padrões abertos. A separação entre os aspectos funcionais e não-funcionais, apresentados por estes modelos, mostra uma maturidade quanto ao suporte para um rápido desenvolvimento de aplicações com a incorporação de serviços tais como transação, persistência e segurança direcionados para aplicações no contexto de negócios.
Apesar da evolução das tecnologias de middleware com a adoção de modelos de componentes, constata-se que os requisitos impostos pelas aplicações emergentes tais como aplicações telemáticas e ubíquas não são atendidos. Tendo como base as deficiências constatadas nos atuais modelos de componentes, propõe-se no próximo capítulo um novo modelo de componentes capaz de atender aos requisitos impostos por tais aplicações.
O Modelo de Componentes CM-tel
O surgimento de novas categorias de aplicações centradas na Internet como, por exemplo, apli- cações telemáticas e aplicações ubíquas, vem demandando novas tecnologias de desenvolvimento de
software. Durante os últimos dez anos, vários padrões abertos surgiram com o intuito de facilitar o de-
senvolvimento de aplicações distribuídas. A evolução mais recente destes padrões foi a incorporação do paradigma de componentes, conforme discutido no Capítulo 2.
No entanto, com base nas avaliações da literatura apresentadas no capítulo anterior e apesar da maturidade dos modelos de componentes constatamos algumas deficiências com relação ao suporte fornecido por estes modelos aos requisitos impostos pelas aplicações consideradas neste trabalho. Entre estas deficiências, destacam-se:
1. Os modelos de componentes são vinculados a uma determinada tecnologia de middleware, por exemplo, CCM está vinculado à tecnologia CORBA, EJB à tecnologia Java e COM+ à tecnologia Windows. A utilização destes modelos implica, necessariamente, na utilização das respectivas tecnologias vinculadas.
2. Os modelos de componentes existentes são direcionados para o domínio de aplicações com- erciais1 e carecem de suporte para requisitos impostos por outros domínios, por exemplo, su- porte a interfaces de fluxo contínuo (stream). Isto torna os modelos de componentes atuais inapropriados para a transmissão de mídias contínuas tempo-real, requisito fundamental para o desenvolvimento de aplicações que utilizam comunicação multimídia distribuída.
3. Os modelos de componentes não oferecem mecanismos que contemplem alguns aspectos não- funcionais importantes, notadamente a qualidade de serviço para fluxos contínuos, um requisito fundamental para as aplicações telemáticas interativas.
1Razão pela qual enfatizam o processamento de transações, segurança e a persistência de componentes.
4. Os modelos de componentes não fornecem um processo de instalação flexível para a adap- tação dinâmica das aplicações às suas necessidades, requisito fundamental para o suporte às aplicações ubíquas.
5. Os modelos de componentes não permitem a instalação de componentes em dispositivos com pequeno poder computacional tais como computadores de mão (handhelds) e telefones celu- lares.
A falta de suporte aos requisitos citados restringe a utilização dos modelos de componentes exis- tentes, bem como das suas plataformas, em muitas aplicações modernas. As deficiências constatadas e as experiências adquiridas no desenvolvimento de serviços telemáticos no âmbito do projeto do laboratório virtual REAL (Remotely Accessible Laboratory) (Capítulo 5), motivaram-nos a desen- volver um novo modelo de componentes de software e uma plataforma de suporte a este modelo, com o objetivo de contribuir para o desenvolvimento de novas aplicações disponibilizadas através da Internet, em particular aplicações telemáticas e aplicações que necessitam de requisitos relacionados à mobilidade (de código, de terminal ou de usuário) e ao acesso ubíquo. Este novo modelo, deno- minado CM-tel (Component Model for telematic applications), será apresentado neste capítulo. No Capítulo 4, apresentamos uma plataforma de suporte ao modelo baseada nas tecnologias CORBA e Java.
3.1
Visão Geral do Modelo de Componentes CM-tel
O modelo de componentes CM-tel não visa substituir os modelos de componentes existentes, mas sim complementá-los em algumas de suas principais deficiências. O desenvolvimento do modelo CM-tel foi orientado pelos seguintes princípios:
• o modelo deve ser neutro, ou seja, não vinculado a uma tecnologia específica;
• o modelo deve ser centrado em padrões abertos;
• o modelo deve oferecer mecanismos simples de especificação, instalação, configuração e com- posição de componentes;
• o modelo deve suportar um conjunto de aspectos funcionais e não-funcionais necessários às aplicações telemáticas e ubíquas, ausentes nos modelos de componentes existentes;
• o modelo deve permitir a utilização de qualquer metodologia de desenvolvimento de software baseada na linguagem UML;
• o modelo deve permitir geração automática de código em larga escala.
Dos princípios acima, o mais original é a independência de tecnologia (modelo neutro). A moti- vação para um modelo neutro é a capacidade de se desenvolver plataformas de suporte para o modelo sobre diferentes tecnologias tais como CORBA, Java/RMI, Java/WebService, RT-CORBA, DCOM, etc. Neste aspecto, a abordagem adotada para o desenvolvimento do modelo CM-tel é diferente da abordagem convencional, onde a tecnologia de suporte dita toda a concepção do modelo de com- ponentes. Nossa proposta consiste em especificar um modelo de componentes em dois níveis de abstração. O primeiro nível define um modelo de componentes genérico, estável e neutro em termos de tecnologia (independente de linguagens de programação, plataformas de middleware, plataformas de hardware, sistemas operacionais, protocolos de rede, etc.). O segundo nível consiste em mapear este modelo para uma determinada tecnologia de suporte. Um dos benefícios dessa estratégia de dois níveis é a flexibilidade obtida, uma vez que a especificação do modelo de componentes bem como dos componentes e contêineres da aplicação permanecem estáveis, ao passo que a implementação destes em uma tecnologia pode evoluir ou ser substituída de forma independente.
O requisito que impõe mecanismos simples de especificação, instalação, configuração e com- posição de componentes tem como motivação a construção de plataformas de suporte leves para o modelo. Por exemplo, uma plataforma que implemente o modelo CM-tel pode executar em um dispositivo móvel com baixo poder de processamento, o que seria impossível para plataformas que suportam CCM ou EJB, devido à complexidade destes modelos e de suas plataformas de suporte.
O requisito de suporte a um conjunto de aspectos funcionais e não-funcionais necessários às aplicações telemáticas e ubíquas visa atender aos requisitos impostos pelas aplicações emergentes identificados na Seção 1.2. Neste contexto, CM-tel fornece soluções para estes requisitos como, por exemplo, o suporte para comunicação multimídia distribuída com facilidades de qualidade de serviço (no nível da aplicação, do serviço de gerência de fluxo contínuo e da infra-estrutura de rede), código móvel e um processo de instalação flexível que permite a adaptação dinâmica das aplicações a ambientes com características distintas.
A nossa opção pela linguagem UML deve-se a esta ser a notação padrão para modelagem visual, disponível na maioria das ferramentas de desenvolvimento atuais e amplamente utilizada pela indús- tria. Além disso, UML proporciona mecanismos de extensão (perfis UML) para o uso de construções em UML, que permitem adaptar a linguagem para aplicações ou tecnologias específicas.
Um modelo de componentes especifica os padrões e convenções impostos por este modelo aos de- senvolvedores de componentes, definindo como componentes individuais são construídos, bem como as regras que permitem a interação e composição entre componentes [11]. Para apresentarmos tais padrões e convenções oferecidos pelo modelo CM-tel, tomamos como base as principais caracterís- ticas que um modelo de componentes deve fornecer ao desenvolvedor de componentes, conforme
descrito na Seção 2.2. Os elementos básicos independentes de tecnologia, notadamente a composição e interação de componentes, serão descritos neste capítulo. No próximo capítulo serão fornecidas soluções tecnológicas para todos os elementos básicos no âmbito de uma plataforma de suporte ao modelo CM-tel.
Em adição, para descrevermos como componentes e contêineres aderentes ao modelo CM-tel são suportados e construídos, adotamos o conceito de modelagem segundo níveis semânticos [83]. Nesta abordagem, o nível semântico de um modelo determina o nível de detalhes (abstração) que o modelo expõe. Por exemplo, modelos segundo três diferentes níveis semânticos são comumente utilizados na modelagem de sistemas de software em UML: modelos conceituais, modelos de especificação e modelos de implementação [83].
CM-tel define três modelos de diferentes níveis semânticos, ou perspectivas, para especificar e para apresentar as regras impostas pelo modelo CM-tel para os seus componentes e contêineres: modelo de especificação, modelo de projeto e modelo de implementação física. Estes três modelos foram escolhidos com o intuito de oferecer representações para componentes e contêineres nas fases de análise, projeto e implementação encontrados na maior parte dos processos de desenvolvimento de
software. A linguagem UML2é utilizada por estes três modelos como uma linguagem de modelagem
para auxiliar a apresentação do modelo CM-tel. A Figura 3.1 ilustra os três modelos em uma seqüên- cia de etapas que conduzem a especificação, projeto, implementação, empacotamento e instalação do componente e do contêiner CM-tel.