2.4
Considera¸c˜oes Finais
Neste cap´ıtulo foram introduzidos conceitos importantes sobre os quais foram desenvolvi- das as pesquisas para a concep¸c˜ao da solu¸c˜ao apresentada.
Foi aprentada a defini¸c˜ao de aplica¸c˜oes P2P, suas principais arquiteturas e deriva¸c˜oes, assim como sua localiza¸c˜ao dentro da taxonomia de sistemas computacionais.
Tamb´em foi apresentada uma vis˜ao inicial sobre o Desenvolvimento Baseado em Com- ponentes, al´em do modelo de representa¸c˜ao de ativos digitais adotado pelo OGM (RAS). O pr´oximo cap´ıtulo aborda o modelo de representa¸c˜ao adotado e implementado para armazenamento dos componentes nos reposit´orios distribu´ıdos. ´E um cap´ıtulo bastante relevante, considerando que o modelo adotado influencia diretamente nos servi¸cos exis- tentes nos reposit´orios e no protocolo de compartilhamento, apresentados no cap´ıtulo 4.
2.4. Considera¸c˜oes Finais 21
Classes específicas do profile.
2.4. Considera¸c˜oes Finais 22
Classe específica do profile
Cap´ıtulo 3
Modelo de Reposit´orio
No contexto de modelagem da arquitetura e do protocolo de transmiss˜ao de componentes de software, a defini¸c˜ao do modelo utilizado para se armazenar os componentes torna- se relevante, uma vez que esta modelagem pode influenciar nos servi¸cos oferecidos pelo reposit´orio e, conseq¨uentemente, nos servi¸cos dispon´ıveis na rede de compartilhamento.
Para que seja poss´ıvel conceber reposit´orios de componentes que sejam suficientemente flex´ıveis para armazenar diferentes tipos de componentes, ´e necess´ario que tenhamos a concep¸c˜ao de um modelo gen´erico, com flexibilidade para representar caracter´ısticas e funcionalidades dos componentes, ou pelo menos aquelas consideradas mais significativas. Uma vis˜ao que possibilita maior generalidade na representa¸c˜ao de ativos ´e a utiliza¸c˜ao de atributos flex´ıveis. Esta abordagem admite que novas caracter´ısticas sejam inseridas aos ativos sem necessidade de qualquer altera¸c˜ao no modelo de representa¸c˜ao.
Antes de detalharmos sobre a solu¸c˜ao, vale a pena discutir alguns aspectos que s˜ao relevantes na ado¸c˜ao de um modelo, considerando os objetivos do projeto. Estes aspectos s˜ao mostrados no t´opico a seguir, fatores cr´ıticos.
3.1
Fatores cr´ıticos
Alguns aspectos s˜ao considerados vitais e nortearam v´arias decis˜oes, sobretudo na mode- lagem e arquitetura da rede. N˜ao ´e diferente quando tratamos do modelo de representa¸c˜ao dos componentes.
Tais aspectos foram baseados nos requisitos iniciais da RCCS, que utiliza o modelo proposto. S˜ao considerados fatores cr´ıticos para o desenvolvimento do modelo: Padr˜oes abertos, distribui¸c˜ao, usabilidade, portabilidade, escalabilidade e simplicidade. Estes fa- tores s˜ao discutidos a seguir.
3.1. Fatores cr´ıticos 24
3.1.1
Padr˜oes abertos
Uma das principais raz˜oes para ado¸c˜ao de desenvolvimento baseado em componentes ´e a premissa do reuso. A id´eia ´e desenvolver softwares a partir de componentes existentes, atrav´es da integra¸c˜ao de partes inter oper´aveis. A implica¸c˜ao de reduzir o tempo de desenvolvimento e aumentar a qualidade do produto torna esta abordagem bastante atra- tiva [DW99].
Padr˜oes de software provˆeem um alto grau de reuso em arquiteturas e design de soft- ware. Com a utiliza¸c˜ao de padr˜oes, um sistema torna-se mais compreens´ıvel, simplificando o desenvolvimento e manuten¸c˜ao. Outro objetivo da utiliza¸c˜ao de padr˜oes de software ´e a facilidade na dissemina¸c˜ao da experiˆencia no desenvolvimento de solu¸c˜oes j´a padronizadas. Considerando a id´eia inicial de se propor uma solu¸c˜ao aberta, para que o modelo seja utilizado livremente, toda a modelagem foi feita em torno da ado¸c˜ao de padr˜oes abertos, para livre utiliza¸c˜ao sem a necessidade de adapta¸c˜ao para as necessidades de projeto espec´ıficas. Esta modelagem influencia inclusive no protocolo de comunica¸c˜ao entre os pontos da rede. Maiores informa¸c˜oes sobre este protocolo de comunica¸c˜ao ser˜ao mostradas na se¸c˜ao 4.3, que descreve a arquitetura da rede.
A utiliza¸c˜ao de padr˜oes abertos, como alguns propostos em [OMG06], [RAS06] e [IBM04] torna a proposta mais atrativa para novos desenvolvedores, e isso alavanca a possibilidade de novas implementa¸c˜oes utilizando o modelo concebido.
Considerando que o RAS ´e um padr˜ao j´a adotado pelo OMG como modelo de repre- senta¸c˜ao de ativos digitais, com flexibilidade para representa¸c˜ao de um modelo espec´ıfico de componentes, por´em com generalidade suficiente para que diferentes modelos sejam representados e armazenados em um mesmo reposit´orio, tal especifica¸c˜ao tornou-se a principal referˆencia na modelagem do reposit´orio. O reposit´orio e o protocolo de compar- tilhamento devem ser compat´ıveis com o modelo RAS.
Al´em da utiliza¸c˜ao de padr˜oes abertos, faz-se necess´aria a ado¸c˜ao de padr˜oes que j´a estejam estabelecidos e com boas referˆencias.
3.1.2
Distribui¸c˜ao
Outro fator cr´ıtico e de forte impacto no desenvolvimento de uma solu¸c˜ao para mode- lagem do reposit´orio ´e a distribui¸c˜ao. Ou seja, o reposit´orio deve estar modelado de forma que possibilite o desenvolvimento de servi¸cos de distribui¸c˜ao e comunica¸c˜ao entre os participantes da rede.
O objetivo de distribui¸c˜ao est´a enraizado no prop´osito inicial da rede de compartilha- mento, e desde o in´ıcio do projeto se pensou na existˆencia de reposit´orios distribu´ıdos, e que o compartilhamento de ativos aconte¸ca de forma totalmente distribu´ıda. E foram ado-
3.1. Fatores cr´ıticos 25
tadas tecnologias como Web Services e arquiteturas P2P, que facilitem o desenvolvimento de um sistema computacional que seja de fato distribu´ıdo, sem nenhuma dependˆencia central.
Deve-se identificar um padr˜ao suficientemente gen´erico, para que diferentes tecnologias e plataformas possam implement´a-lo, visando n˜ao comprometer a participa¸c˜ao de difer- entes usu´arios na RCCS, e que a rede possua diversos reposit´orios, implantados utilizando diferentes plataformas, por´em seguindo a mesma modelagem aqui proposta.
O fator cr´ıtico distribui¸c˜ao ´e fortemente considerado, e ´e resolvido com a imple- menta¸c˜ao da arquitetura P2P proposta na cap´ıtulo 4.
3.1.3
Portabilidade e interoperabilidade
Este ´e mais um aspecto que preza pela utiliza¸c˜ao de uma solu¸c˜ao aberta e padronizada. O modelo aqui proposto baseia-se no RAS, que ´e um modelo e que n˜ao ´e dependente de nenhuma plataforma. Al´em disso, a tecnologia adotada na transferˆencia de dados (Web Services) favorece a portabilidade e interoperabilidade da rede, criando uma nova camada de abstra¸c˜ao acima da plataforma [IBM04].
A interoperabilidade ´e uma caracter´ıstica complementar `a utiliza¸c˜ao de pad˜ores, e sua principal vantagem ´e a possibilidade de desenvolver uma solu¸c˜ao que funcione em diferentes plataformas, e desta forma a utiliza¸c˜ao de padr˜oes ´e imprescind´ıvel. Por´em, ´e importante que estes padr˜oes n˜ao sejam espec´ıficos de uma plataforma, para n˜ao tornar a solu¸c˜ao restrita e dificultar sua utiliza¸c˜ao.
3.1.4
Escalabilidade
Escalabilidade, de uma forma mais geral, ´e definida como “a habilidade ou eficiˆencia da solu¸c˜ao para um problema frente ao crescimento deste problema” [RS90]. Contextuali- zando esta defini¸c˜ao, escalabilidade pode ser entendida como a habilidade de uma rede de compartilhamento de componentes continuar funcionando frente ao crescimento do n´umero de pontos participantes desta rede.
Sem d´uvida, o compartilhamento de ativos na RCCS n˜ao pode ser comprometido frente a um crescente n´umero de pontos realizando buscas e n´umero de reposit´orios disponibi- lizando componentes. Sob este aspecto, torna-se necess´ario que a arquitetura montada n˜ao esteja restrita a um n´umero m´aximo de pontos, e que novos participantes possam entrar e sair livremente, sem que a rede fique inativa.
Como os recursos est˜ao distribu´ıdos, a desconex˜ao de um ponto da rede faz com que seus recursos fiquem indispon´ıveis, mas a rede deve continuar ativa e a troca de outros componentes entre os pontos restantes n˜ao pode ser prejudicada, a n˜ao ser pela ausˆencia dos recursos que seriam oferecidos pelo pontos ent˜ao inativos.