[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] [Discovery] Double Network Address and Remote Services
- From: Wim Jongman <wim.jongman@xxxxxxxxx>
- Date: Mon, 27 Sep 2010 18:29:19 +0200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IysRPBublIWk289AQqUSVscBPETWx1kx8El4ykjDdVWHH2BqZk223sSEiWBAxVu7Wn 6qBisKWnISi2MLbMDMMaOt/D1vLTPcWiU7rV7uq02DCm3QXNKnc9Yvm1Z9kZe2fmPX44 IGZY39d5tkUGa9IQ0PfqjMIKAvgzrpdQk/6ac=
Thanks again. I promised a while ago to make a start with the wiki manual.. I did not forget. Can I use the existing docs in the CVS to get us started?
On Mon, Sep 27, 2010 at 6:14 PM, Scott Lewis <slewis@xxxxxxxxxxxxx>
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.
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.
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:
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.
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.
I was wrongfully thinking this was calculated on the fly.
Ok. Please let me know what I can do to help further.
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.
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 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.