Hi Wim,
On 9/27/2010 9:29 AM, Wim Jongman wrote:
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?
Yes, absolutely...thanks much. Did you intend it to be a wiki
manual for remote services (or all of ECF)? Either is great with
me...and I will attempt to dedicate some time to both form (i.e.
consistency across authors/contributors) as well as content (reusing
existing content as well as creating new stuff on general remote
services/distributed systems topics, as well as how ECF deals with
the general topics).
But for everyone reading/listening to this thread...all
contributions of documentation...examples, use cases, topics,
issues/questions, answers from committers/contributors/community
members, etc will be welcomed.
Scott
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
|
