Re: Re: POA Progress

Sasa Bojanic wrote:

>Hi Dave,
>
>CORBA layer in shark is just a wrapper for POJO interface. It does not have almost any logic (except the one for collecting CORBA
>object to release them after disconnect action or doneWith method call, starting threads for deadline and limit check, requesting
>authorization for all admin interfaces, ...), holds only references to POJO classes, and just propagates user's request to them.
>Shark has several layer structure, because even the POJO classes objects that are referenced by CORBA wrapper objects are only
>proxys to the real shark kernel objects, and thus shark is never giving it's own kernel(working) memory to the client.
>So, shark's CORBA object is generally only proxy of the POJO proxy, and if  i.e. two CORBA client application ask for some
>WfActivity, they will get different CORBA proxy objects that are both having reference to different POJO proxy WfActivity, and POJO
>proxy WfActivity is only holding Ids necessary to access real kernel WfActivity object.
>
>I'm not sure what you think by:
>
>"... This can be utilized to properly activate the POA objects.   In fact, there probably should be hierarchy of POA adapters for
>the variety of complex objects in Shark..."
>  
>
I understand that aspect of the structure of Shark.  What I'm referring 
to is the generation of these proxy objects and the
concern that has occurred over proper memory management of the CORBA 
"containers".  The POA is designed to deal
with this in an efficient manner.  I'm not suggesting in the slightest 
any penetration from CORBA into the kernel or POJO wrappers.
I'm just suggesting that we look at ways of making the CORBA layer more 
efficient.  For example, I've noticed running the
corba client that every time I go to the instantiation panel, it calls 
the corba server to create a new object. ProcessIteratorExpressionBuilder.
Basically, what I seen in the CORBA layer is a layered set of factories 
creating CORBA objects, with it not being clear when
these CORBA objects are being released.  The POA approach can provide 
mechanisms of managing these CORBA references.  For example,
POA enables the separation of the CORBA reference from the servant 
underlying the reference.  In a sense your kernel or POJO layers are
providing the underlying servants through the CORBA references.   I'm 
not suggesting anything specific here, just some thinking through the 
implications
of this capability of CORBA in making your life a little easier for 
CORBA clients.  There is great value in the CORBA service in many cases
because of the ability of various clients using the same service.   This 
can also occur through the webservice interface, but the CORBA service
should be as robust as possible, in my opinion. 

I have things working ok except for the sending of objects from the 
client to the server, which I'm working on at the moment. 

Dave

>but we certainly don't want to include anything from CORBA into the kernel or POJO wrappers. This must stay clean, and idea is only
>to make CORBA, EJB, RMI, WEB Service, ... wrappers over shark POJO interface if we want shark to be deployed in any of these
>environments.
>
>I hope this helps.
>
>Thanks so much for your effort,
>Sasa.
>
>----- Original Message -----
>From: "David Forslund" <[email protected]>
>To: <[email protected]>
>Sent: Wednesday, June 22, 2005 10:27 PM
>Subject: [shark] Re: POA Progress
>
>
>  
>
>>I've made some progress on the POA implementation (replacing the BOA) in
>>Shark.  However, the right way to do this may require rethinking
>>some aspects of what is in the CORBA interface for Shark.   The POA
>>provides lifecycle management capabilities which probably should be used
>>to replace
>>the code snippets used in the current implementation to control memory
>>utilization.  It seems to me that the Shark CORBA layer is just a window
>>into the objects
>>that are created underneath in the Shark Kernel.   This can be utilized
>>to properly activate the POA objects.   In fact, there probably should
>>be hierarchy of POA adapters for the variety of complex objects in
>>Shark.  I will make some stab at getting this done in my POA
>>implementation, but I don't know if I know enough about the workings of
>>Shark to get it all right.   Any suggestions in this area would be
>>greatly appreciated.    The javaworld articles on the "new" CORBA POA
>>capabilities (2002) are helpful in this regard.
>>
>>Thanks,
>>
>>Dave
>>
>>
>>
>>    
>>
>
>
>-
>

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws