Project

General

Profile

Bug #2490

Get ecogrid endpoints from Ecogrid registry

Added by Dan Higgins about 13 years ago. Updated over 11 years ago.

Status:
Resolved
Priority:
Normal
Category:
data access
Target version:
Start date:
07/17/2006
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2490

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

Blocked by Kepler - Bug #3124: Automatically refresh ecogrid sources (endpoints) once per KeplerResolved02/01/2008

History

#1 Updated by Derik Barseghian over 11 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...

#2 Updated by Dan Higgins over 11 years ago

Assuming this works, we should turn it 'on' for RC1

#3 Updated by Derik Barseghian over 11 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.

#4 Updated by ben leinfelder over 11 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

#5 Updated by ben leinfelder over 11 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.

#6 Updated by Chad Berkley over 11 years ago

retarget to 1.0

#7 Updated by ben leinfelder over 11 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.

#8 Updated by ben leinfelder over 11 years ago

this is part of RC1 - retargeting bug

#9 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 2490

Also available in: Atom PDF