Decisões de Implementação

Sob a influência do ponto de vista tecnológico do RM-ODP (vide Seção 2.1), as resoluções mais proeminentes tomadas quando da implementação da estrutura do SGPOM compõem o rol a seguir:

1. Emprego de Java como linguagem e plataforma de implementação. 2. Construção de servidores multithreaded.

3. Uso de sockets como mecanismo padrão de comunicação (transmissão) de OMs. 4. Uso do Object Serialization (Java) como o protocolo usual de serialização e de

armazenagem dos estados dos OMs e dos subcomponentes Centrais das camadas. 5. Emprego de estruturas de dados cujos tamanhos podem ser incrementados

“indefinidamente”.

6. Cada uma das entidades do serviço (subcomponentes e Coordenador) possui uma interface IDL definida num módulo apropriado.

Endossando o que foi discutido nas Seções 3.6 e 4.2 e na Subseção 2.2.6, Java, por decisões de projeto, apresenta um suporte robusto, de alto nível, às tarefas de distribuição, persistência e comunicação de dados. Parte do seu conjunto de classes (em uma coleção de pacotes) provê um alicerce útil para a abstração de sockets, threads e estruturas de dados de uso comum, como tabelas de hashing (hashtables) e vetores (vectors). Por conseguinte, o ambiente SGPOM (composto tanto pelas aplicações-cliente como pelo próprio serviço) foi construído inteiramente em Java.

Ainda que tenham sido especificados os Serviços de Relações e de Externalização [OMG94b] [OMG94c] como instrumentos padronizados para o tratamento de composições e de streams de objetos CORBA, a sua coexistência, ajustada ao POS, foi desaconselhada por Kleindienst et al. [Klei96b]. O “desacoplamento” e as interdependências cíclicas entre as especificações são, decerto, as maiores pendências a serem ainda resolvidas. Como os OMs (consoante a visão do SGPOM) não precisam definir interfaces IDL, optou-se pelo emprego do protocolo de serialização [Sun97a] proposto para Java em sua versão 1.1.

Cada camada do SGPOM é composta por quatro tipos de subcomponentes, os quais, em um dado momento, poderão estar atendendo a requisições (de E/S, de criação, de monitoração...) provenientes de clientes distintos. Como todos esses subcomponentes estão sob um mesmo processo (modo de ativação compartilhado — ver Subseção 2.2.3), é imprescindível a construção de servidores CORBA com múltiplas threads de atendimento às invocações. Sob essa prerrogativa, lançou-se mão de um recurso adicional, baseado no uso de filtros, o qual é oferecido pelo produto OrbixWeb (implementação CORBA). Um filtro é uma entidade que realiza alguma operação (ou transformação) fixa sobre as requisições que chegam ou saem de um dado processo. Com ele, tornou-se factível o devido encaminhamento (em paralelo) das requisições a partir da identificação dos seus objetos-alvo. Outros dois tipos de recursos utilizados foram o locator — solução proprietária paliativa e alternativa ao Serviço de Nomes do OMG — e o loader — espécie de filtro especial que provê transparências de acesso e falha ao cliente do objeto CORBA, na medida em que este é resgatado de uma fonte persistente [IONA97a].

A Figura 5.11 traz a hierarquia dos módulos IDL que compõem e descrevem o SGPOM. Da mesma forma que para o POS, optou-se por manter cada subcomponente da estrutura associado a uma interface, mesmo que isso incorra em uma especificação longa — trazida no Apêndice A deste documento — e em algumas redundâncias evitáveis (por exemplo, as definições dos códigos das exceções e dos typedefs).

5.4 Considerações Finais

O quadro a seguir (Tabela 5.3) apresenta um palco comparativo entre o SGPOM e o POS, elucidando as funcionalidades suportadas pelas duas propostas. A ilação decorrente dessa comparação leva à constatação de que o SGPOM exibe uma abordagem modificada para persistência de dados, a qual lida, prioritariamente, com as restrições trazidas com a classe de objetos multimídia. Em suma, o projeto do SGPOM teve como objetivo básico dirimir as deficiências apresentadas pelo POS (Subseção 4.3.6), introduzindo um arranjo mais adequado às necessidades de gerência e acesso a objetos multimídia, dentro do ambiente Multiware.

v Sgpom

Sgpom_om Sgpom

Sgpom_po

Po Po_child Om_base Om_leader

Sgpom_ds

Ds Ds_child Om_type Om_subtype Om_generic

Om Om_child Om Om_child Om Om_child Om Om_child Om Om_child

Figura 5.11: Arranjo dos módulos IDL que compõem o SGPOM.

No capítulo que se segue (Capítulo 6), é apresentado o ambiente de execução de um arquétipo do serviço anunciado nesta parte, trazendo, para efeito de análise, um conjunto de medidas de desempenho relativas a configurações distintas de seus componentes. O Apêndice B, por sua vez, expõe as séries de possíveis interações entre os elementos do serviço, segundo a notação MSC (Message Sequence Chart). Essas interações compreendem as tarefas de orquestração (instanciação, monitoração e checkpoint) dos subcomponentes, bem como as operações de E/S entre as camadas. Além disso, pode-se depreender, mesmo que de maneira parcial, os fluxos de informação entre os componentes do serviço, o que auxilia no processo de especificação do sistema segundo o ponto de vista de informação do RM-ODP.

Funcionalidade POS SGPOM Objeto atrelado à sua

persistência

SIM NÃO

Objeto CORBA SIM NÃO (tanto faz)

Operações de E/S connect(), disconnect(), store(), restore() e delete()

Register(), Comm_way_Store(), Store(), Restore() e Delete()

Operações delegadas NÃO SIM

Componentes (camadas)

PO, PID, POM, PDSs, Protocol, Datastore

SGPOM_PO, SGPOM_PID, SGPOM_OMs (LEADER, TYPE, SUBTYPE, GENERIC), SGPOM_DSs,

Protocol, Comm_way e Datastore

Suporte à Multimídia NÃO (pois é geral) SIM

Suporte à Concorrência ao estado do Objeto

NÃO (delega para o Serviço de Concorrência)

SIM

Tratamento de exceções NÃO SIM

Monitoração do desempenho

NÃO SIM

Protocolo default de serialização

Externalization (OMG) Serialization (Java)

Transmissão do Objeto ORB6 Subsistema de Comunicação

Número de interfaces da especificação

257 31

Tabela 5.3: POS X SGPOM.

6

Para o Serviço de Externalização.

7

A especificação do POS traz, ao longo do seu bojo, um conjunto de interfaces opcionais (não- padronizadas), num total de 18, as quais estão relacionadas a exemplos de fábricas, protocolos e repositórios (Datastores) passíveis de serem usados na implementação do serviço.