[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Some ECF remote services tooling goodies coming out of 3.12.0
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Fri, 4 Dec 2015 11:13:31 -0800
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
Argh. My apologies about the ascii art munging. Steps 5.6.7 should
be underneath the Remote Service Consumer and all should be aligned with
4 on the right.
On 12/4/2015 10:53 AM, Scott Lewis wrote:
With ECF 3.12.0 now released, I wanted to update everyone on the state
of the ECF tooling for Remote Service/RSA .
As described in the 3.12.0 new and noteworthy , 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
Remote Service Host Remote Service Consumer
1. Register Remote Service
2. Export Service
3. Publish endpoint (opt)------------------------(network protocol
[e.g. zookeeper] of EDEF)--------------> 4. Discover Endpoint
5. Import Endpoint
6. Remote Service Proxy created and registered
(triggering app injection via DS, or ServiceTracker, etc)
Impl of remote service <
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
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 .
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 . Of
course, this does this through a IRemoteServiceAdminManagerAsync
remote service! . 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)
4) OSGi Applications
5) ECF Identity, Namespace, Containers
6) Extension Registry
These remote mgmt services  will be used to access the remote model
contents for the above.
Enough for now. Please ask any questions or provide comments.
ecf-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit