Bug #2490
closedGet ecogrid endpoints from Ecogrid registry
0%
Description
Currently, individual endpoints for SRB, metacat, GEON, and Digir ecogrid implementations are stored in the KEPLER/lib/config.xml file that ships with Kepler. Unfortunately, these endpoint may change. We need to update Kepler to retreive these from the Ecogrid registry (at startup?)so that they can change and just send new values to the registry (Otherwise, distributed versions of Kepler will break when endpoints are changed!)
Related issues
Updated by Derik Barseghian almost 17 years ago
Endpoints are now optionally retrieved at Kepler startup. One has to manually enable this by setting the boolean autoDataSourcesUpdate variable in lib/config.xml with a text editor.
Details:
with this enabled, on your first click on the Data tab in a given Kepler window this happens:
- query registry for Data Sources
- rewrite the servicesList section in config.xml file
- update the EcoGridQueryServicesController, so that when you click on the Sources button (on the data tab), you see a current list of services to choose from.
There are some things I want to improve on this including:
- it should probably only make this call on a per Kepler basis, not a per workflow window basis
- the Sources panel needs to be redone, as Kepler website requests
- I also have some ideas on changing the code to make it cleaner...
Updated by Dan Higgins almost 17 years ago
Assuming this works, we should turn it 'on' for RC1
Updated by Derik Barseghian almost 17 years ago
My first sentence in comment #1 "...optionally retrieved at startup" is wrong.
I had it occurring at startup for awhile, but no longer. As that comment goes on to explain, when this feature is turned on, checking for new endpoints occurs when the user clicks on the Data tab.
Updated by ben leinfelder almost 17 years ago
As part of the upcoming 1.0.0 release [candidate], there are some substantial changes to the SEEK ecogrid and registry services. these services will be designated as 1.0.0 (up from beta) and will have namespaces denoting that change. Also, the service names and some method/operation names will change.
These changes will require some modification on the Kepler side. Most notably is the use of the EcogridServicesController to handle all the services registerd in the reqistry. As part of this enhancement, a refresh() method will be implemented that allows users to easily query the registry for new and updated services (rather than doing it every time the data tab is selected).
Much of this coding has already been completed on my local machine, but it is not committed to cvs yet since it requires the upgrade of the seek services in order to work properly.
I'm going to assign this bug to me for the bug day, 1/23/2008
Updated by ben leinfelder almost 17 years ago
Refreshing the list of available services is working nicely locally - there's even an option to retain the existing (i.e. locally-configured) services for a client. This is nice for developers who want to point to local ecogrid services.
Waiting to commit until a formal plan for upgrading SEEK deployments is made.
Updated by ben leinfelder almost 17 years ago
Endpoints are now automatically refreshing from the registry when a user first goes to the Data search tab. This still happens once per kepler window (there is a new bug that deals with reducing this to once per Kepler launch).
Additionally, there is a "Refresh" button on the Sources dialog. This can be used to force a refresh when desired.
Registry entries are then serialized to the config file and persist there.
Note that the scope of the EcoGridServicesController has been expanded to include more service types than just the QueryService (authentication, identification, put, and authenticated query). This class should be used as the main interaction point between Kepler, the registry, and the various services.
Updated by ben leinfelder almost 17 years ago
this is part of RC1 - retargeting bug