Information on caGrid's requirements are on the caGrid Downloads page.
Java 5 (or 1.5) is the officially supported version. Not all components require it (some will work with 1.4). Java 6 will also probably work.
You can verify the version of Java you are using by running the command:
There are no explicit hardware/OS requirements. As long as your hardware/OS can meet the prerequisites (see above), then it will be fine; caGrid is cross platform. As for hardware, that depends on what you are going to do with the node, but in general, caGrid only requires modest hardware (even any modern desktop is more than sufficient).
Both caGrid versions 1.0 and 1.1 make use of the 3.1 version of the caCORE ApplicationService API. For example, the caDSR grid service uses this API to communicate with the production caCORE service to extract caDSR metadata. However, caGrid Data Services provide support for multiple versions of caCORE SDK, for the purpose of creating a Data Service to expose a data resource created by the SDK. For information on which versions of caCORE SDK are supported by each version of caGrid Data Services, please see Data Services caCORE SDK Support.
Extensively: every night, and every time code is committed to SVN, the project is built and hundreds of unit tests are run. The results are then submitted and archived on our historical quality dashboard. Additionally, numerous system/integration tests are run periodically and reported to the dashboard. These tests create, deploy, and test, many of our services.
Instructions for testing caGrid are included in every release. Check the build instructions for the release you are using. For example, View caGrid 1.2 testing instructions.
- All services running in the same Globus (the Globus container, or the wsrf web application in Tomcat) share a common classpath. This is something we inherit from Globus, and cannot easily "fix" for caGrid.
- If you are using a caCORE SDK-created system, the ApplicationService class uses some singletons which most likely will cause you problems during concurrent accesses to your services.
- If you've created multiple Introduce services in the same package, you'll likely have problems with such things as configuration (as some of the generated classes will have the same names).
- If you have multiple instances of the same service (meaning the same WSDL) running in the same container (under different service paths, e.g cagrid/MyService and cagrid2/MyService), you may also have problems with the routing of messages due to how Axis works. You should try to avoid this.
We run many of the core services in the same container with no problems, so if you can avoid the issues above, you should be fine.
Note: Since Introduce 1.2 we have supported programatic undeployment of services. For more information please see the Introduce users guide for the current version of Introduce you are using. Services built prior to Introduce 1.2 the following statements hold true for.
Unfortunately, for the same reasons (shared classpaths) running multiple services in the same container can be an issue, there is no "clean" way to automatically support undeployment. For example, we can't remove jar files for one service as they maybe used by another service.
To manually undeploy a service, you can delete your service's jar files from the container's "lib" directory, the configuration files from the "etc" directory, and the schemas from the "schema" directory.
For example, in Tomcat:
- Delete the jars known to only be used by your service from $CATALINA_HOME/webapps/wsrf/WEB-INF/lib
- Delete the directory $CATALINA_HOME/webapps/wsrf/etc/cagrid_<your service name>
- Delete the directory $CATALINA_HOME/webapps/wsrf/share/schema/<your service name>
Check the dashboard for build history. It is more likely an issue with your environment. Common problems are:
- You don't have the proper prerequisites. See information here.
- You don't have the proper Java installed, or aren't using it. See information here.
- You have old versions of caGrid jars deployed to GLOBUS_LOCATION. caGrid's build path includes GLOBUS_LOCATION/lib and if you've deployed caGrid services to the Globus container, you will have potentially conflicting jars there. You should either undeploy those services, or point your GLOBUS_LOCATION environment variable to a different Globus installation.
If you still think you have a problem, you can follow these instructions to submit a bug or get further information.
Read about Troubleshooting Index Service Registration.
Yes. See information here.
Is there a sandbox grid with core services deployed which I can use to test with before using the Production Grid?
Yes; but it is strictly a testing sandbox environment and you should not make any restricted data available on it.
caGrid 1.1 (and later) includes the capability to change the target Grid.
The services hosted can be discovered using the DiscoveryClient aimed at http://index.training.cagrid.org:8080/wsrf/services/DefaultIndexService. The (secure) services in this grid run with certificates not trusted by the production release. The list of core services can be found on the Community Training Grid.
It depends on what caGrid APIs you want to use. But there are some commonalities:
- You should always have *.jar from $GLOBUS_LOCATION/lib
- From each project you want to use, you should add:
- *.jar from the lib directory - which is where each project has its own unique libraries
- *.jar from the ext/lib directory - which is where each project has the libraries it inherits from other caGrid projects
- *.jar from the build (generally build/lib or build/jars) directory - which is where each project generates its own libraries
You can also determine the necessary libraries of each project by looking at its build file (build.xml)
If you are going to use the client API of a service you generated with Introduce, you generally need these same things (with the omission of ext/lib).
How does a grid service get 'advertised?' How do others know you are there and what you are allowing access to? Do interested parties need to have a grid service to query a grid service?
When a grid service is deployed, there is a configuration setting that determines whether you want to advertise and to which Index Service you'd like to advertise to. Then, users can discover the service by querying the Index Service. There is an API that tool developers can use to query the Index Service. The type of security that is being employed by a grid service is advertised and publicly accessible. However, the pieces of data that a user has access to is not advertised. A grid service is not required to query another grid service. There are public APIs that can be used, as well as messaging standards. Furthermore, users can construct and issue queries from the caGrid Portal.
- Download the IdentityFinder jar from http://software.cagrid.org/tools/IdentityFinder.jar
- To run the jar either:
- Double-click the jar file
- Using a terminal, go to the folder housing the jar and
- The Host Identity Tool will open, provide the service URL in the Service Address box and press "Go"
- The Grid Identity will appear in the Identity space
Can I use versions of ant, globus, tomcat or jboss other than those installed via the caGrid Installer?
Do so at your own risk, caGrid has only been tested with those versions.
There is probably a duplicate log4j file that is preventing the log file from updating properly. To solve this problem delete the duplicate log4j file.
Refer to Debug caGrid
There has been some discussion about this in the caGrid forums: https://cabig-kc.nci.nih.gov/CaGrid/forums/viewtopic.php?f=20&t=564&sid=15d20ed1bbdbb809f55b03edc17ba648
Additionally Python clients can be developed, refer to http://cagrid.org/display/knowledgebase/Develop+Python+Clients for more information.
A release date has not been specified by the NCI for caGrid 1.4 as yet.
Refer to caGrid 1.3 Grid Installation Guide