Hi Ram,
On 11/21/2016 2:53 PM, Ramachandran K. Narayanan wrote:
Hello ICE-Dev, Scott,
I had pulled in the changes and looked at the video and
wanted to clarify my understanding here:
1) The second instance of the Core, spawned from Core
OSGi.launch is not visible since it needs endpoint discovery.
This is supported through various ways:
-
EDEF: File format with information on how the
consumer can find the host. Can import automatically or
manually (for modifying certain properties).
-
Network discovery: Through zookeeper, zeroconf, etc.
Is EDEF preferred over Network discovery in specific
cases?
Yes, EDEF is preferable over network discovery for some cases. For
example, if the service is accessed over a WAN, doing network
discovery can be very complicated (e.g. firewalls, etc). In such
cases EDEF can be much easier. Security constraints can also
change discovery requirements for individual use cases.
I would think that EDEF doesn't rely on the existence of
Network discovery protocols and so can be independent of
that. However, Network discovery can publish the existence
of a host, similar to a name server and thus does not need
an explicit file to describe the endpoint.
That's right on all counts. The reason for all the options WRT
discovery is that there are many possible use cases.
2) Who would typically write the EDEF file, i.e. it looks
like the Host is best placed to generate the endpoint
information since it runs on the endpoint?
Yes the host actually creates an EndpointDescription when a service
is exported on the host. All that's necessary is to take the
EndpointDescription and write it out as xml. ECF has a class
specifically for this called EnpdointDescriptionWriter. This is
actually what's done via the DebugRemoteServiceAdminListener (it
writes the xml out to System.out when a remote service is exported.
If the Host machine was to change frequently (say the
consumer could connect to any machine in a cluster, each time
it connected), would the EDEF file need to be updated each
time? Would a network discovery approach be better here?
Yes a network discovery could be better/easier in this case. OTOH,
it would still be possible to use EDEF...e.g. to have a single EDEF
template and simply update the properties that determine which host
is consulted for importing the remote services. Also, it's quite
possible to call
RemoteServiceAdmin.importService(EndpointDescription)
programmatically if more control over the import is needed/desired.
Hope I have described my doubts clearly. If you need any
clarifications, please let me know.
You might be interested in the architectural overview for Remote
Service Admin (the standardized management agent for remote
services...called RemoteServiceAdmin). It's here [1].
Also, we have a number of examples that are part of tutorials [2].
Many of these use/show different approaches to discovery.
Or just feel free to ask for more/other explanation and/or specific
examples.
Scott
[1] http://wiki.eclipse.org/EIG:Remote_Services_Admin
[2]
http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#Tutorials
Regards,
Ram
Hello Jay, Scott,
Thanks a lot for tackling various
issues with regard to the OSGi services here. I got a
chance to catch up on the conversation just about now.
I will pull in the changes, focus on the EDEF file and will
go through the uploaded video (thank you Jay) to
understand what we have so far.
Regards,
Ram
--
Ramachandran K. Narayanan
(Ram)
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248
|