Re: [ecf-dev] [Discovery] Double Network Address and Remote Services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

 Hi Wim,

On 9/27/2010 8:19 AM, Wim Jongman wrote:
> Ah, I understand. so the ip is already in the ID which is created by 
> the user. 

Although the ID is often created/supplied by the user...it doesn't have 
to be.  It can/could be created programmatically as well...and this does 
give greater control over the ID creation.

But for most providers (e.g. ecf generic, r-osgi, jms, etc., etc) the ID 
for the host container does contain the IP (or more frequently the 
hostname).

Note this isn't required in general...that is, it is possible for a 
provider to use whatever it wants (i.e. not the IP/hostname) in the 
ID...as long as the provider code is able to use this information from 
the ID to ultimately reach the target service.  So for example I could 
make up my own namespace (call it slewis), and create a provider that 
has an address like this:

slewis://tilly.lewis/someservice

In this case, however, the 'slewis' provider has to be able to interpret 
'tilly.lewis', and understand what that means in terms of addressing 
'someservice'.  It could correspond to a host/IP...e.g. through some 
lookup service...or it could just be 'known'.

In any event, my point is that the existing providers (r-osgi, ecf 
generic, jms, etc) happen to use the hostname/IP in the ID...but that is 
not required by ECF at all.  The namespace/ID part of ECF allows the 
creation/addition of arbitrary namespaces...with whatever syntax is 
necessary for addressing and communicating with remote systems using 
whatever communication medium desired.  Of course most of the existing 
one use IP addressing/dns, etc...but they don't have to.

> I was wrongfully thinking this was calculated on the fly.

Well, with the ECF APIs it is quite easy to have it calculated on the 
fly if desired/necessary...but since the remote services spec (chap 13) 
alone doesn't provide any API at all (it's just specified service 
properties)...there's no means to support calculating it on the fly 
within just that spec.  As I mentioned, there is indeed a way to 
calculate it on the fly via the 
IHostContainerFinder/DefaultContainerFinder...and it's also possible to 
have it calculated on the fly via the IDFactory service.



> Still puzzling because I am already communicating.
>
> provider publishes a service (remoted)
> service is picked up by zookeeper
> Zookeeper delivers at client
> Client proxies the service
> Client tries to communicate but fails
>
> I will debug more tonight.

Ok.  Please let me know what I can do to help further.

I need to also say...I hope that I and the entire ECF 'crowdsource' will 
be make progress on the ECF book in the coming year...as there are many 
good topics/chapters coming out of these various discussions around 
remote services...for example:

1) discovery (there's of course a lot to say here)
2) addressing (namespaces, IDs, etc)
3) reliability
4) synchronous and asynchronous interaction with a remote service
5) point to point and pub/sub patterns of communication
6) data replication and sync vs. data centralization
7) lots of other things :)
8) ...please feel free to add to this list if you want...it's a 
community list

IMHO these are subtle, difficult, and complex issues with distributed 
systems...and although I would love to have something completed to make 
available for everyone wishing to create/use remote services, such a set 
of documents doesn't exist yet.  Hopefully with community help it 
can/will soon.

Scott