Re: [jira] Updated: (TUSCANY-611) RMI Binding

[Jim Marino]

On Aug 10, 2006, at 10:53 PM, Venkata Krishnan wrote:
Thanks Ant and Jim.

Ant, I shall certainly work on the formatting and a couple of other  
issues
and posted an updated patch asap.

Jim, you point was something that I did vacillate about.  I was  
wondering if
the registry should be started by the binding or should it be done  
offline.

My inclination is to start the registry in a system service. One way  
to do this is to create a system POJO implementing something like  
RMIHost with an @Init method and set to eager init and you can also  
have a destroy method to do any shutdown. I'd then have the builder  
take an autowire to the system service which would pass it to the  
service. When Service.stop() is called, the service would perform an  
unbind by using RMIHost.unbind() or something similar.

My imagination of the Registry is that it is lightweight and it  
should be ok
to host several instances of it on a host, ofcourse each on a  
different
port. Hence we might actually allow the assemblies to mention which  
port
number is preferred to host the RMI Service.
I think this could be accomplished with one system service. The  
RMIHost API could have overloaded versions of register(), one that  
takes an explicit port and one that uses a default. If an explicit  
port is passed, the RMIHost would look for a cached Registry,  
creating one if needed.

If a registry for the port
already exists then we simply use that otherwise start one.  So if is
possible that a registry on a port will host more than one service.

It is also a good idea that we clearly have one registry per host and
implement it the way you have mentioned out here.  I am open to do  
this as
well.  Let me know your final thoughts on this.

One other thing is I think it is important for the business interface  
of the Reference (and probably the Service) not to have to extend  
Remote since the binding could be changed (I think you may have  
brought this up before). In this case, the binding should perform a  
mediation during the invoke.  What do you think?
Jerermy and others what are your thoughts on this?

Thanks

- Venkat



On 8/11/06, Jim Marino <[EMAIL PROTECTED]> wrote:

Thanks Venkat. Just a quick question: do you think it is best to have
one Registry per service or could we have one Registry per runtime
instance and have services register with that? If you think the
latter may be something that works better, one thing that could be
done is to create a separate system component that instantiates the
registry. This system component would be like ServletHost (RMIHost?)
and could be autowired to the builder which could then pass it to the
service implementation which would in turn perform the bind  
operation.

Jim


On Aug 10, 2006, at 12:30 PM, ant elder wrote:

> Hi Venkat, I've committed this patch now. Had some problems getting
> the
> patch to apply cleanly so  had to fiddle about a bit, could you
> check it
> looks ok to you? The code needs formatting so maybe you could  
send in
> another patch doing that? I've also not added the service and
> reference
> samples to the main samples pom.xml yet. As you've pointed out the
> testcases
> for them only work in eclipse so we'll need to figure out what to
> do about
> that.
>
> Looks great, really good to have a real binding working at last.
>
>   ...ant
>
> On 8/10/06, Venkatakrishnan (JIRA) < tuscany-dev@ws.apache.org>  
wrote:
>>
>>      [ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ]
>>
>> Venkatakrishnan updated TUSCANY-611:
>> ------------------------------------
>>
>>     Attachment: Tuscany-RMI-Binding-Aug-10-Updated.diff
>>
>> Hi... there is one addition that has been missed out in the prev.
>> patch.  My sincere apologies for that goof-up.... here is the  
updated
>> patch.  Thanks.
>>
>> > RMI Binding
>> > -----------
>> >
>> >                 Key: TUSCANY-611
>> >                 URL: http://issues.apache.org/jira/browse/
>> TUSCANY-611
>> >             Project: Tuscany
>> >          Issue Type: Bug
>> >            Reporter: Venkatakrishnan
>> >         Assigned To: ant elder
>> >         Attachments: Tuscany-RMI-Binding-Aug-10-Updated.diff ,
>> Tuscany-RMI-Binding-Aug-10.diff,
>> Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff ,
>> Tuscany-RMI-Binding-Service-Sample-Aug-10.diff
>> >
>> >
>> > SCA RMI Binding with samples for SCA Reference and SCA Service
>> using RMI
>> Binding.
>> > Here is a first cut implementation for this.  Could somebody  
please
>> review and apply?  Also I have had the following issues un-
>> resolved: -
>> > - The samples can be tested thro the Testcases in them.  These
>> testcases
>> work from eclipse as long as I have added the RMI-Binding Eclipse
>> project to
>> the classpath.  Otherwise the binding does get picked up.  The
>> same is the
>> issue when trying to execute the testcases from maven.  Could
>> somebody
>> please help in fixing this?  Thanks.
>> > Note :-
>> > --------
>> > I shall be working further with this binding to address the
>> following :
>> -
>> > - there is single attribute called 'uri' for the binding.  I
>> shall be
>> splitting this to host, port and service name with defaults to
>> each when not
>> specified.
>> > - it is now required the that SCA Service require a component to
>> implement the interface Remote.  I imagine this to be intrusive.
>> All that a
>> developer should do is pick up an existing component with a 'non
>> remote'
>> interface and simply deploy it exposing the service as RMI.  The
>> binding
>> should dynamically be able to generate a remote interface and a
>> proxy and
>> host it as a facade to this implementation.
>> > -  will be glad to take forward any other inputs from the
>> community as
>> well.
>> > Thanks
>> > - Venkat
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/
>> software/jira
>>
>>
>>
>>  
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]