[oil-users] Narrow e proxies

[Renato Maia]

Oi Maciel.

On 6 May 2008, at 17:59, Leonardo S. A. Maciel wrote:
> Eu esperava que o obj tivesse alguns campos de um proxy genérico, como
> "_narrow".

Se o 'obj' fosse um proxy (depois eu explico porque ele não é), tu  
verias apenas uns campos de uso interno do OiL e nenhum método. Isso  
acontece porque os métodos do proxy são todos obtidos através do  
'__index' da metatable e por isso não vão aparecer numa iteração  
'pairs' ou algo do gênero.

> Mas aparentemente você já faz o narrow implicitamente. É isto
> mesmo?

Não.

> Usei o código abaixo para chamar o método "m" do servant definido  
> acima,
> passando como parametro um proxy qualquer (para facilitar o  
> exemplo, estou
> passando o próprio proxy como parâmetro, mas não precisa ser assim):

O problema é exatamente teres usado o próprio proxy como o parâmetro.  
Vou explicar porque. O OiL implementa um recurso chamado "local  
reference resolution" que faz com que sempre que uma referência local  
seja recebida, ao invés de criar um proxy para o objeto local, ele  
substitui pela implementação do objeto. Portanto, o teu parâmetro  
'obj' é o mesmo 'self' neste teu exemplo. Por isso ele apresenta o  
campo 'm'.

Por enquanto, a única forma que sei de desabilitar a "local reference  
resolution" é adicionando o código seguinte, após o 'require "oil"'.  
Na verdade, o que é feito é a desconexão de componentes internos do  
OiL. Dessa forma, o componente de marshaling (ValueEncoder) não será  
capaz de analisar os profiles IOR para detectar quando uma referência  
é local ou não. Consequentemente, ele vai tratar todas como  
referências remotas, criando proxies para todas as referências. É  
feio, mas deve funcionar. Só lembre que essas chamadas locais vão ter  
todo o overhead de marshaling/unmarshaling de uma chamada remota.

-- get IOR profilers connected to the multiple receptacle
local connections = {}
for conn_id in oil.ValueEncoder.profiler:__all() do
	connections[#connections+1] = conn_id
end
-- remove the connections so local references are not recognized
for _, conn_id in ipairs(connections) do
	oil.ValueEncoder.profiler:__unbind(conn_id)
end


> Achei esquisito não conseguir identificar se uma tabela é uma mera  
> tabela,
> ou um CORBA Object.

Hoje não tem uma maneira limpa de fazer isso. Mas tu querias isso  
exatamente para que? Talvez tenha outra maneira de conseguir o que  
queres.

> Não posso fazer um _is_a ou um narrow para outra interface mais  
> genérica?


Na verdade não, porque o 'obj' não é um proxy e portanto não oferece  
nenhum recurso que não tenhas implementado nele, inclusive as  
operações CORBA que o OiL implementa nos proxies. Esse é o grande  
problema da "local reference resolution". Esse mecanismo é ótimo para  
exportar para CORBA aplicações Lua que não sabem nada de CORBA. Por  
outro lado, é totalmente problemático para aplicações que fazem uso  
dos recursos de CORBA, pois os objetos locais não oferecem nenhum  
recurso de CORBA, o que acaba com a transparência.

No OiL 0.3, os servants (objeto retornado pelo 'newservant')  
ofereciam as operações de CORBA da mesma forma que os proxies para  
objetos remotos. Mas como o "local reference resolution" convertia as  
referências recebidas para as implementações, o problema permanecia.

Pensando agora, acho que uma solução seria definir um campo nos  
objetos como  '__resolveto="proxy"|"servant"|"impl"'. Esse campo  
seria usado para identificar como as referências para esse objeto  
seriam convertidas localmente. Dessa forma, os servants do OiL  
poderiam voltar a apresentar as mesmas operações dos proxies e serem  
usados no lugar de proxies para objetos locais, oferecendo as mesmas  
operações de CORBA.

Enfim, existem muitas possibilidades e é difícil dizer qual a melhor  
para resolver todos os casos. Acho que é preciso entender melhor as  
necessidades dessas aplicações. Nas aplicações que tenho trabalhado,  
o "local reference resolve" funciona bem, pois me prendo mais ao  
modelo de Lua do que ao de CORBA, que é menos flexível. Por exemplo,  
ao invés de usar '_is_a' para confirmar se um objeto implementa uma  
dada interface que oferece um método específico, eu simplesmente faço  
a chamada e deixo o erro aparecer (usando o duck typing de Lua ;-) ou  
ainda testo se 'obj.method ~= nil' antes de fazer a chamada. Mas isso  
não deve funcionar para todas as aplicações. Nessa tua aplicação, tu  
precisas de recursos de CORBA dos teus objetos locais? Quais e porque?

Um abraço.


--
Renato Maia
PhD student at PUC-Rio
__________________________
http://www.inf.puc-rio.br/~maia/