[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Some ECF remote services tooling goodies coming out of 3.12.0

Hi Folks,

With ECF 3.12.0 now released, I wanted to update everyone on the state of the ECF tooling for Remote Service/RSA [1].

As described in the 3.12.0 new and noteworthy [2], there is a new RSA Manager view in addition to an enhanced Discovered Endpoints view. This RSA Manager view shows the *state* of the ECF RSA service...i.e. what services have been *exported* by hosts (Exported Services category in UI), and/or *imported* (Imported Endpoints category).

Why would these views help with remote services development?

One of the frequently difficult things about development and testing of remote services (in my own experience and via reports from others) seems to be that when a host exports a service this will typically trigger the following sequence of events:

Sorryinadvance about this ascii art. I will try to create a proper diagram when I can (or if someone can help with that, please let me know).


Remote Service Host Remote Service Consumer

1. Register Remote Service
|
V
2. Export Service
|
|
V Discovery
3. Publish endpoint (opt)------------------------(network protocol [e.g. zookeeper] of EDEF)--------------> 4. Discover Endpoint
|
V
5. Import Endpoint
|
V
6. Remote Service Proxy created and registered
(triggering app injection via DS, or ServiceTracker, etc)
|
V
Impl of remote service < -----------------------------------Distribution-------------------------------------------> 7. App Uses Remote Service Proxy (calls methods)
(JaxRS/REST, rosgi, generic, Hazelcast, JMS/ActiveMQ, etc)




In the above flow, in many cases all the 1-6 steps are effectively 'invisible' to the user and the programmer. This can make it extremely difficult to figure out what's going on when something has gone wrong (e.g. with respect to network discovery or the timing between export an attempt to import, etc). ECF's implementation of RSA supports tracing, or adding event handlers that do various things, but either of those are frequently cumbersome, require programming, and then still doesn't provide any way to explicitly invoke/control these steps in the appropriate environment: e.g. on a network that is known to support the desired network discovery protocol, or to import via EDEF without having to either create a bundle to do so, or to use RemoteServiceAdmin.importService.

With the new Tooling, on the host/export side the result of steps 1 and 2 can be seen in the RSA Manager view (appear in Exported Services). The result of 3 and 4 can be seen in the Discovered Endpoint view, and this view also allows the import of EDEF files from anywhere in the local file system.

Then with the Endpoint Discovery view context menu steps 5 and 6 can be explicitly controlled/triggered (or it can happen automatically and the results will appear in the RSA Manager Imported Endpoints view) as shown in [2].

Exports and Imports can then be unexported/unimported and the results for the host and/or consumers of the Remote Service can be observed or manipulated. I expect that this will provide greater visibility into the dynamics of what's going on for remote services designers, implementers, and testers. Note that all of the above is completely independent of Discovery implementation/protocol (e.g. whether it's Zookeeper, zeroconf, dnssd, etcd, EDEF file, or custom discovery provider). And it's independent of Distribution as well. It will all work with any Discovery and/or Distribution provider (ones created by us or others) and remote services can be tested and debugged with one Discovery and Distribution provider combination, and if desired deployed and run with another.

The content provider and model classes used in the RSA Manager and Endpoint Discovery views are now API and extensible, and so can be replaced and/or extended by other tools creators. One thing that this allows is the creation of Eclipse views that show the state (e.g.) of a *remote* RSA implementation (e.g. running on Karaf, Equinox server, another Eclipse, or some other Remote Service host). As an example of this, I've created a prototype remote RSA Manager here [3]. Of course, this does this through a IRemoteServiceAdminManagerAsync remote service! [4]. Next steps over the next few months would be to create remote views to allow the examination and some control over the following in a remote OSGi framework (not necessarily Eclipse at all):

1) OSGi Service Registry
2) RSA (as above)
3) SCR
4) OSGi Applications
5) ECF Identity, Namespace, Containers
Equinox Only
6) Extension Registry
7) P2

These remote mgmt services [5] will be used to access the remote model contents for the above.

Enough for now.   Please ask any questions or provide comments.

Thanks,

Scott

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=454609
[2] https://www.eclipse.org/ecf/NewAndNoteworthy_3.12.0.html
[3] https://github.com/ECF/OSGIRemoteManagement/tree/master/plugins/org.eclipse.ecf.mgmt.rsa.eclipse.ui
[4] https://github.com/ECF/OSGIRemoteManagement/blob/master/bundles/org.eclipse.ecf.mgmt.rsa/src/org/eclipse/ecf/mgmt/rsa/IRemoteServiceAdminManagerAsync.java
[5] https://github.com/ECF/OSGIRemoteManagement/tree/master/bundles