figura 6 - Estrutura de um Cliente
Existe uma variedade de implementações de ORBs possíveis com a "Common ORB Architecture" (CORBA). Nesta seção será apresentada algumas destas diferentes opções. Note que uma ORB pode suportar múltiplas opções e protocolos de comunicação.
Se temos um mecanismo de comunicação adequado, a ORB pode ser implementada com rotinas residentes no cliente e implementações. O stub cliente usa o mecanismo IPC (local e transparente) ou acesso direto à localização do serviço para estabelecer comunicação com as implementações. Códigos ligados à implementação são responsáveis por colocar no ar o banco de dados usado pelo cliente.
Para centralizar o controle da ORB, todos os clientes e implementações podem comunicar com um ou mais servidores cujo trabalho é direcionar as requisições dos clientes para as implementações. A ORB pode ser um programa normal no sistema operacional disponível, e o IPC poder ser usado para fazer a comunicação com a ORB.
Para realçar a segurança, a robustez e a performance, a ORB pode estar provida dos serviços básicos de um sistema operacional. Referências de objeto podem ser feitas de forma a não serem falsificada, reduzindo assim o custo de autenticidade de cada requisição. Como o Sistema Operacional pode saber a localização e a estrutura de clientes e implementações, isto será possível à uma variedade de optimização de implementação.
Para objetos leves e que a implementação pode ser dividida, a implementação será feita em bibliotecas. Neste caso, o stub pode ser podem ser os métodos atuais. Isto assume que é possível para o programa cliente acessar os dados do objeto e que esta implementação garante que o cliente não modificará os dados.
O cliente de um objeto tem uma referência de objeto que se refere à este objeto. Uma referência de objeto é um sinal que pode ser invocado ou passado como parâmetro para uma invocação em objetos diferentes. Invocação à um objeto envolve a especificação do objeto a ser invocado, a operação a ser realizada e os parâmetros que devem ser fornecidos à operação ou os parâmetros devolvidos pela operação.
A ORB administra a transferência de controles e dados para a implementação de objetos e sua volta ao cliente. Quando em um evento, a ORB não pode completar a chamada, é gerado uma excessão como resposta. Geralmente, o cliente chama uma rotina em seu programa que faz a chamada e retorna quando a operação é completada.
O cliente acessa um stub específico para um objeto como se estivesse acessando uma rotina de biblioteca no seu programa (ver figura 6). O programa cliente vê então as rotinas sendo chamadas normalmente na sua linguagem de programação. Todas as implementações irão prover o uso de uma linguagem específica de dados para referenciar os objetos, geralmente um ponteiro. O cliente depois passa a referência de objeto para as rotinas de stub para estas iniciarem a invocação. Os stubs tem acesso as representações de referência de objetos e interagem com a ORB para realizar a invocação.
figura 6 - Estrutura de um Cliente
Existe uma série de códigos de biblioteca que realizam as invocações à objeto, por exemplo, quando o objeto não foi definido à tempo de compilação. Neste caso, o programa cliente prove informações adicionais para obter o tipo de objeto e o método a ser invocado, e realiza uma sequência de chamadas que irão especificar os parâmetros e iniciar a invocação.
Clientes geralmente obtém as referências de objeto através de outras invocações a outro objeto que se tem referência e que fornece como saída a referência de objeto desejada. Quando o cliente também é uma implementação é uma implementação, ele recebe referência de objeto como parâmetro de entrada para a invocação de objeto que ele implementa. Uma referência de objeto pode também ser convertida em strings que podem ser guardadas em arquivos, ou reservada, ou transmitida de várias maneiras e depois recolocada como referência de objeto pela ORB que produz a string.
A implementação de objeto prove o estado atual e o comportamento com o objeto. Pode ser feita de várias maneiras. Além da definição de métodos para suas próprias operações, uma implementação usualmente definirá procedimentos para ativar e desativar objetos, e usará outros objetos ou estruturas não-objeto para fazer o estado do objeto persistente para controle de acesso à objeto.
A implementação de objeto (ver figura 7) interage com a ORB de diversas maneiras para estabilizar suas identidades, para criar novos objetos e para obter serviços dependentes da ORB. Primeiro ela faz acesso ao adaptador de objeto, que prove uma interfacepara o servico ORB conveniente para um estilo particular de implementação de objeto.
figura 7 - Estrutura de um Implementação de Objeto
Devido a grande variedade de implementação de objeto, fica difícil definir uma como padrão.
Quando acontece uma invocação, a "ORB Core", o adaptador de objeto e o esqueleto arranjam a chamada para o método apropriado de implementação. O parâmetro para este método especifica o objeto a ser invocado, o que o método pode usar para localizar os dados para o objeto. Parâmetros adicionais são suportados de acordo com a definição do esqueleto. Quando o método é terminado, ele retorna parâmetro ou excessões ao cliente.
Quando um novo objeto é criado, a ORB tem que ser avisado para saber onde achar a implementação para este objeto. Usualmente, a implementação se auto-registra como implementação de objeto de uma interface particular, e especifica como inicializar a implementação se esta não estiver rodando.
A maioria das implementações possuem este comportamento, usando recursos adicionais à ORB ou adaptadores de objeto.
O adaptador de objeto (figura 8) é o primeiro modo para a implementação de objeto acessar serviços ORB tal como referência de objetos. O adaptador de objeto exporta a interface pública para a implementação de objeto, e a interface privada para o esqueleto. Isto é construído em uma interface ORB privada.
Adaptadores de objeto são responsáveis pelas seguintes funções:
Estas funções são feitas através da "ORB Core" e qualquer componente adicional necessário. Frequentemente o adaptador de objeto irá manter o seu estado para realizar estas tarifas. Isto pode ser possível para um adaptador de objeto particular que delegue uma ou mais responsabilidades sobre a ORB, à qual ele foi construído.
Como mostrado na figura 8, o adaptador de objeto é implicitamente envolvido na invocação dos métodos, embora a interface direta seja através dos esqueletos. Por exemplo, o adaptador de objeto pode ser envolvido na ativação da implementação ou na autenticação do pedido.
figura 8 - Estrutura de um Adaptador de Objeto
O adaptador de objeto define vários serviços da ORB que a implementação de objeto pode depender. Diferentes ORB irão fornecer diferentes níveis de serviços e diferentes ambientes de operação que terão algumas propriedades implícitas e necessitarão que outras sejam adicionadas pelo adaptador de objeto. Por exemplo, é comum para a implementação de objeto querer guardar certos valores em referência de objetos, para se ter uma fácil identificação do objeto invocado. Se o adaptador de objeto permite em uma implementação especificar certos valores quando um novo objeto é criado, ele pode ser capaz de guarda-las em uma referência de objeto para a ORB que permita isto. Se a "ORB Core" não permite esta funcionalidade, o adaptador de objeto gravará este valor no seu próprio repositório e o fornecerá a implementação quando da invocação. Com adaptador de objeto, é possível par uma implementação de objeto ter acesso a um serviço que pode ser ou não implementado na "ORB Core"- se a "ORB Core" permite isto, o adaptador simplesmente prove uma interface para ele; se não, o adaptador o implementa no topo da "ORB Core". Todo adaptador tem que prover a mesma interface e serviço para toda ORB que é implementada nele.
Não é necessário todos os adaptadores de objetos proverem a mesma interface e funcionalidade. Algumas implementação de objetos tem necessidade especiais, por exemplo, uma base de dados orientda a objeto pode querer registrar implicitamente vários objetos sem fazer chamadas individuais ao adaptador de objeto. Neste caso, será impraticável e desnecessário para o adaptador de objeto manter qualquer objeto por estado. Usando uma interface de adaptadore de objeto calibrado pela implementação de objeto, é possível tomara vantagem de detalhes particulares da "ORB Core" para prover o acesso mais eficiente à ORB.
Existem vários tipos de adaptadores de objeto. A maioria dos adaptadores de objetos são desenhados para atender uma variedade de implementação de objeto, assim, somente quando a implementação requisitar diferentes serviços ou interfaces os novos adaptadores de objetos serão considerados. Nesta seção serão descritos 3 tipos de adaptadores de objetos.
Esta especificação define adaptadores de objetos que podem ser usados pela maioria dos objetos ORB, com implementação convencional. Para estes adaptadores de objetos, implementações são geralmente programas separados. Ele permite à existência de um programa inicializado pelo método e um programa separado para cada objeto, ou um programa compartilhado por todos os tipos de objeto. Prove uma pequena quantidade de armazenamento para cada objeto o que pode ser usado como nome ou identificador para outro armazenamento, para acesso à lista de controle, ou outras propriedades de objeto. Se a implementação não esta ativa quando a invocação é feita, a BOA irá inicializar uma.
Este adaptador de objeto é usado por objetos que possuem implementações de biblioteca. Ele acessa arquivos, e não suporta ativação e autenticação, desde que os objetos estejam no programa cliente.
Este adaptador faz conexão com uma base de dados orientada à objeto para ter acesso aos objetos armazenados no banco. Desde que a OODB prove métodos e armazenamento persistente, objetos podem ser registrados implicitamente e não são necessários estados no adaptadores de objeto.