| Re: [ice-dev] AbstractExecutor not found by ECF |
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:
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 DebugRemoteServiceAdminListene r (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
On Mon, Nov 21, 2016 at 9:50 AM Ramachandran K. Narayanan <knarayanan@xxxxxxxxxxxxx> wrote:
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 EngineerRNET Technologies Inc.240 W.Elmwood Drive, Suite 2010Dayton, OH 45459-4248
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev