[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] [Discovery] Double Network Address and Remote Services
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Mon, 27 Sep 2010 09:14:14 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20100915 Thunderbird/3.1.4
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
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
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:
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)
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
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