[
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