You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/10/10 00:47:38 UTC

[2.x] Changes around EndpointRegistry and EndpointReferenceBinder

Hi,

I made some changes around the how EndpointRegistry is used for a Node and 
how the EndpointReference is bound an endpoint in the registry.

> URL: http://svn.apache.org/viewvc?rev=823672&view=rev
> Log:
> Refactor the runtime build logic into EndpointReferenceBinder
> Refactor the endpoint-wrapper into domainRegistryFactory that delegates to 
> endpoint registry implementations by the scheme
> Improve/workaround the monitor so that it can be shared by multiple nodes 
> (We need a better design for this)

Basically, each Node can be configured with the following information:

domain: The URI of the domain that the Node belongs.
domainRegistryURI: The URI that can be used to connect to a domain registry, 
such vm://localhost, multicast://<address>:<port>?attr1=v1&attr=v2.

When the Node starts, it looks up the DomainRegistryFactory (replacing 
EndpointRegistryWrapper) which knows how to find an implementation of 
EndpointRegistry that support the scheme such as "vm" or "multicast". An 
instance is created for the given registry URI and domain URI and cached by 
the combined key. I removed the endpoint-wrapper module.

I also refactored the runtimebuild code from the EndpointReferenceBuilder 
into a new utility called EndpointReferenceBinder that can bind a EPR to the 
endpoint in the endpoint registry that is passed in as an argument.

When I tried to bring up the tests in domain-node, I discovered some flaws 
in our Monitor creation and usages. I'll start a different thread for that.

Thanks,
Raymond
---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action (A book on Tuscany SCA): 
http://tuscanyinaction.com/
 


Re: [2.x] Changes around EndpointRegistry and EndpointReferenceBinder

Posted by Simon Laws <si...@googlemail.com>.
On Tue, Oct 13, 2009 at 11:52 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Oct 13, 2009 at 11:46 AM, Simon Laws <si...@googlemail.com> wrote:
>> Hi Raymond
>>
>> ...snip
>>> Basically, each Node can be configured with the following information:
>>>
>>> domain: The URI of the domain that the Node belongs.
>>> domainRegistryURI: The URI that can be used to connect to a domain registry,
>>> such vm://localhost, multicast://<address>:<port>?attr1=v1&attr=v2.
>>>
>>> When the Node starts, it looks up the DomainRegistryFactory (replacing
>>> EndpointRegistryWrapper) which knows how to find an implementation of
>>> EndpointRegistry that support the scheme such as "vm" or "multicast". An
>>> instance is created for the given registry URI and domain URI and cached by
>>> the combined key. I removed the endpoint-wrapper module.
>>
>> Am very happy to see the wrapper as I didn't know what it was for ;-)
>>
>
> See the log message from when it was committed -
> http://svn.apache.org/viewvc?view=rev&revision=808871 - which did have
> the commented that it should be changed to work more like this new
> way.
>
>   ...ant
>

I missed the word "renamed";-) I recognize that it's doing the same
thing as it was before and that that's useful. Was not sure that the
name wrapper adequately described it's role to the newcomer.

Simon

Re: [2.x] Changes around EndpointRegistry and EndpointReferenceBinder

Posted by ant elder <an...@gmail.com>.
On Tue, Oct 13, 2009 at 11:46 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Raymond
>
> ...snip
>> Basically, each Node can be configured with the following information:
>>
>> domain: The URI of the domain that the Node belongs.
>> domainRegistryURI: The URI that can be used to connect to a domain registry,
>> such vm://localhost, multicast://<address>:<port>?attr1=v1&attr=v2.
>>
>> When the Node starts, it looks up the DomainRegistryFactory (replacing
>> EndpointRegistryWrapper) which knows how to find an implementation of
>> EndpointRegistry that support the scheme such as "vm" or "multicast". An
>> instance is created for the given registry URI and domain URI and cached by
>> the combined key. I removed the endpoint-wrapper module.
>
> Am very happy to see the wrapper as I didn't know what it was for ;-)
>

See the log message from when it was committed -
http://svn.apache.org/viewvc?view=rev&revision=808871 - which did have
the commented that it should be changed to work more like this new
way.

   ...ant

Re: [2.x] Changes around EndpointRegistry and EndpointReferenceBinder

Posted by Simon Laws <si...@googlemail.com>.
Hi Raymond

...snip
> Basically, each Node can be configured with the following information:
>
> domain: The URI of the domain that the Node belongs.
> domainRegistryURI: The URI that can be used to connect to a domain registry,
> such vm://localhost, multicast://<address>:<port>?attr1=v1&attr=v2.
>
> When the Node starts, it looks up the DomainRegistryFactory (replacing
> EndpointRegistryWrapper) which knows how to find an implementation of
> EndpointRegistry that support the scheme such as "vm" or "multicast". An
> instance is created for the given registry URI and domain URI and cached by
> the combined key. I removed the endpoint-wrapper module.

Am very happy to see the wrapper as I didn't know what it was for ;-)

>
> I also refactored the runtimebuild code from the EndpointReferenceBuilder
> into a new utility called EndpointReferenceBinder that can bind a EPR to the
> endpoint in the endpoint registry that is passed in as an argument.

Sounds OK but I'd still like to be able to call this binder from the
builders for those references that are resolveable locally. The
intention being to warn users of incorrect wiring where possible at
build time rather than waiting until run time. I'm not saying your
change makes this any more difficult but you removed an empty method
that was reminding me to look at it. I'll try and get round to it.

>
> When I tried to bring up the tests in domain-node, I discovered some flaws
> in our Monitor creation and usages. I'll start a different thread for that.

Ok, this is to do with having a separate instance of the domain for
each node instance now that the top level design has been changed to
share the majority of infrastructure between nodes? I'll look for the
new thread.

Simon