Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] [Discovery] Double Network Address and Remote Services

Hi,

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?

Regards,

Wim   

On Mon, Sep 27, 2010 at 6:14 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
 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




_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top