CaGrid:FAQ
From caGridWiki
This page contains frequently asked questions (and hopefully answers), related to caGrid.
Wiki Questions
How do I edit or add content to the wiki?
You should email the user's list (cagrid_users-l@list.nih.gov) to request an account. An administrator will need to create it for you. Then just jump right in and edit the appropriate page. This is meant to be a community resource, so your input is greatly appreciated. However, before making any large changes or significant additions, please ask a wiki administrator. If you are not familiar with wiki syntax, you can learn more on the wiki media help page.
How can I get a question added to this list?
Just as above, you can edit this page and post your question or provide an answer or additional details to an existing question.
Non-technical Project Questions
How do I submit a bug?
The preferred approach is to first search the user's email archives for your problem, then email your question to the list. Often problems you encounter are not actually bugs, and have been previously addressed on the mailing list. If you come across an actual bug, a developer will enter a bug report for you, or ask you to do so.
Bug reports are maintained on the caGrid Gforge Project Page, and you can search for your issue there, or enter a new report if your problem is not found.
In all bug submissions, please describe in detail what steps you've taken to produce the problem, attach any detailed logs and full exceptions, and please attach the output of running the following command:
ant -diagnostics
How do I submit a feature request?
You should first verify that the feature doest not yet exist. You can do so by viewing the current scope, user, and programmer documents; these can be found on the caGrid Gforge documents page. Once you are sure the feature does not exist in the current release, you should see whether there is a currently pending feature request on the caGrid Gforge feature tracker. If it does not exist, you should post a new request detailing your desired feature. Please be as specific as possible in describing your request. You may also want to check the user's email archives for relevbant disucssions, and feel free to email the list for discussion.
How can I get support?
As mentioned above, you should first check the user's list archives, and then email the list (cagrid_users-l@list.nih.gov).
You may also contact NCICB Application Support and they will assign you a ticket and appropriately route your problem.
- E-mail: ncicb@pop.nci.nih.gov
- Local: 301.451.4384
- Toll-Free: 888.478.4423
- Web: http://ncicb.nci.nih.gov/support
How can I join the project?
Joining the gforge project is generally not necessary; you will be able to see everything, and get checkouts from CVS without doing so. Project membership is used solely for assigning write access to the repository. If you actually want to contribute to the project's code, please email your intentions to the user's list (cagrid_users-l@list.nih.gov).
Is there a user community for caGrid?
Yes. Please visit the caGrid Knowledge Center, a centralized community resource.
When does the user community meet?
- Event: caGrid User's Call (Monthly)
- When: Third Thursday of every month from 11:00 am – Noon ET
- Telecon #: 1-800-619-0279
- Passcode: 91671
- Centra URL: http://ncicb.centra.com
- Centra ID: GRID_USER
Technical Questions
What other software does caGrid require?
Information on caGrid's requirements are on the caGrid Software page.
What version of Java does caGrid require?
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:
java -version
What hardware and/or Operating Systems does caGrid work with?
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).
Where can I find additional technical documentation?
Links to documentation can be found on the technical resources page. Much less organized information can also be found directly in the relevant directory of our CVS. This location includes all of the component design documents.
caGrid doesn't seem to compile, is it broken?
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.
Is caGrid tested?
Extensively: every night, and every time code is committed to CVS, 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.
How can I test caGrid locally?
Where are the caGrid javadocs?
The javadocs for the 1.2 release are available online here, and are available as a zip file as part of the release on gforge.
I just received a grid proxy credential from Dorian, but secure grid services are rejecting it. Why?
There are a number of potential problems to investigate. However, one basic problem may be that time is out of sync between machines on the grid. This can be either between two machines running grid services (when two grid services communicate) or between your machine (as the client) and a server running the grid service you are contacting. The proxy certificate you receive after logging in expires after a maximum of 12 hours. If time is of out of sync, the service may be telling you your proxy certificate is expired.
Additionally, certain services (such as the index service) require that clients requesting advertisement have a valid time range. If the requested time range is off significantly from the index service's system clock, this can be a reason for the index service to reject the advertisement request. For more information on troubleshooting the index service, refer to the question on this page: I'm having problems with advertisement/registration, what should I do?
Make sure that all relevant machines have their clocks set accurately. There are a number of ways to do this (dependent on your typical configuration), but one common way to ensure accurate time is to use the Network Time Procol (ntp) server. NTP configuration is OS-dependent, so check your operating system's administration guide for details.
I'm having problems with serialization, what should I do?
Take a look at the information page, and the how to on configuring castor. You may also find Chapter 5 of the metadata design document helpful on a more conceptual level.
What does "forward references are not supported" or "org.exolab.castor.mapping.MappingException: No class descriptor found for extended class ..." mean?
If you see this error you most likely are using Castor to serialize, and you have a model with inheritance. There is a limitation in Castor where inherited classes must be in a certain order. See information on this here, in the closed caGrid bug. If you are using the caCORE SDK, this is not handled properly, and you will need to correct your mapping file. See the caCORE bug here. Follow the instructions here on how to configure custom Castor mappings.
Can I deploy several services to the same container?
Yes, but...
- 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, it uses some singletons in the ApplicationService 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.
Josh suggested some "work arounds" to this on the caGrid User's List.
How do I undeploy a service?
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>
I'm having problems with advertisement/registration, what should I do?
Take a look at the how to on trouble shooting the Index Service.
My service (or the Index Service) thinks its running on the wrong protocol or port?
There is a bug in Globus when using tomcat, when services "activate on startup," wherein the ServiceHost API returns the wrong information. caGrid services "activate on startup" and use the ServiceHost API to determine their service URL. This information is passed to the Index Service for registration.
The caGrid installer already applies the work around (#4 below), but if you didn't run the installer, you can use one of the work arounds below:
1) Use the Globus container.
2) Use tomcat on port 8443 with https.
3) Call a method on your service when you start the container.
4) Set parameters "defaultPort" and "defaultProtocol" in web.xml in tomcat, to how you
are running tomcat (e.g. 8080 and http).
edit: $CATALINA_HOME/webapps/wsrf/WEB-INF/web.xml
<servlet>
<servlet-name>WSRFServlet</servlet-name>
<display-name>WSRF Container Servlet</display-name>
<servlet-class>
org.globus.wsrf.container.AxisServlet
</servlet-class>
<init-param>
<param-name>defaultProtocol</param-name>
<param-value>http</param-value>
</init-param>
<init-param>
<param-name>defaultPort</param-name>
<param-value>8080</param-value>
</init-param>
<load-on-startup>true</load-on-startup>
</servlet>
NOTE: If you are running behind a port redirecting proxy or firewall, you also may also have to add a "proxyPort" and/or "proxyName" attribute(s) to your server.xml. This will ensure that registration code gets told the specified port/host when it asks Tomcat for that information. See the tomcat documentation for more information. For example, this page has some nice information on running Tomcat on port 80 as a non-root user.
What does this error mean? "Missing default constructor? Error was: java.lang.InstantiationException."
Globus is trying to deserialize into a Class that can't be constructed. Check your serialization settings and see below if you are using abstract schema types.
Can I use abstract types in my service interface?
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) makes it easy to switch between using the training grid and the production 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 here.
I'm developing an application that depends on caGrid, what do I need in my classpath?
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).
When I connect to a service, I get a connection timeout. What is the problem?
There are numerous potential causes, but basically the error is telling you the client can't connect to the server.
Here are some common causes:
- The service URL is not correct. Double check it (protocol, port, etc).
- The service is not running. Verify you can hit the service URL with your web browser.
- The service may be behind a firewall, or your client machine may have firewall restrictions.
- If you are behind a firewall and require a proxy to access the internet, you will need to configure proxy settings on the client.
- You can find information on how to do this on Axis's web site.
- Those properties can be passed as -D options on the commandline, or in code using System.setProperty()
- You can find information on how to do this on Axis's web site.
When I connect to a secure service, I see this exception containing this message: "[Caused by: Failure unspecified at GSS-API level [Caused by: Unknown CA]], what is that from?
This means that there is a trust issue between you and the service. Either you don't trust the CA which signed the credentials the service is using, or the service doesn't trust your credentials, if you are using them. You can run "ant syncWithTrustFabric" from the caGrid directory to synchronize the trust fabric, but make sure you are configured to use the same grid environment as the service you are communicating with.
As of caGrid 1.1, you can also run "ant generateTrustReport" from the gridca project (caGrid/projects/gridca). This will prompt you for a file location in which it will write a text file, and print to the screen, all of the details of the CA which you trust (and detail any potential problems).
When I connect to a service I've deployed with my client, the client can't connect and the server outputs the following message: java.io.IOException: Token length 1347375956 > 33554432. What is the problem?
The detailed stacktrace on the server side is the following:
2007-03-08 15:07:54,190 ERROR container.GSIServiceThread [ServiceThread-6,process:145] Error processing request
java.io.IOException: Token length 1347375956 > 33554432
at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readToken(GSIGssInputStream.java:93)
at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readHandshakeToken(GSIGssInputStream.java:54)
at org.globus.gsi.gssapi.net.impl.GSIGssSocket.readToken(GSIGssSocket.java:60)
at org.globus.gsi.gssapi.net.GssSocket.authenticateServer(GssSocket.java:122)
at org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:142)
at org.globus.gsi.gssapi.net.GssSocket.getOutputStream(GssSocket.java:161)
at org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:102)
at org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:302)
The problem is that the service is running in a secure globus container (using https protocol), but the client is trying to connect to the service using an insecure (http) protocol. Change your client to connect to the service using a secure protocol (modify the service URL to https instead of http).
When I connect to a service I've deployed with my client to either secure Tomcat or JBoss, I get a stacktrace error which starts with something like:
GSI Transport (encryption only) authentication required for
"{http://catissuecore.wustl.edu/CaTissueCore}query" operation.
Firstly, make sure that you have configured a Secure Globus deployment into Tomcat (by hand or with the installer) or JBoss. Meaning, that you ran the "deploySecureTomcat" or "deploySecureJBoss" target when deploying Globus. You could also check the $CATALINA_HOME/webapps/wsrf/WEB-INF/etc/globus_wsrf_core/server-config.wsdd to make sure it has the following entry.
<handler type="java:org.globus.wsrf.impl.security.authentication.
transport.TomcatTransportSecurityHandler"/>
If you have eliminated the above as not to be the problem, then the other problem could be that when you deployed and were editing the server.xml file of the Tomcat server, standalone or in tomcat, that you forgot to put the "Valve" into the engine. Please make sure that you put the correct "Valve" into this file after the "Engine" element and this error should go away. See http://www.globus.org/toolkit/docs/4.0/common/javawscore/admin-index.html#javawscore-admin-tomcat-deploying for details.
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.
What versions of caCORE APIs and SDK-generated systems does caGrid support?
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 support page.
The DiscoveryClient gives me an exception with org.xml.sax.SAXException:SimpleDeserializer, what is that from?
As with most Globus clients, a properly configured client-config.wsdd file must be accessible by the underlying Axis engine. The simplest way to do this is to either run with your $GLOBUS_LOCATION as the "working directory", add $GLOBUS_LOCATION to your classpath, or copy $GLOBUS_LOCATION/client-config.wsdd to your working directory or classpath.
If you don't do this, you will most likely see an exception similar to that shown below:
gov.nih.nci.cagrid.metadata.exceptions.RemoteResourcePropertyRetrievalException: org.xml.sax.SAXException:SimpleDeserializer encountered a child element, which is NOT expected, in something it was trying to deserialize.
My service client fails with an exception saying "The arguments do not match the signature.; nested exception is: java.lang.IllegalArgumentException: object is not an instance of declaring class" in the stack trace. Why does this happen?
Globus WSRF keeps all libraries for deployed services in a single lib directory in the container. This has the side affect that deploying multiple services to the same container can occasionally class version conflicts, especially when a container which has older services deployed is used to deploy newer services. For example, a container to which a caGrid 1.0 data service was deployed cannot be used for deploying a caGrid 1.1 data service because the jar names have changed, and the classloader may pick up the 1.0 jars when attepmting to run the 1.1 service. Often, this manifests itself at runtime with a stack trace like the following:
[java] Running the Grid Service Client
[java] AxisFault
[java] faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
[java] faultSubcode:
[java] faultString: Tried to invoke method public gov.nih.nci.cagrid.data.stubs.QueryResponse gov.nih.nci.cagrid.data.service.globus.DataServiceProviderImpl.query(gov.nih.nci
.cagrid.data.stubs.QueryRequest) throws java.rmi.RemoteException,gov.nih.nci.cagrid.data.faults.QueryProcessingExceptionType,gov.nih.nci.cagrid.data.faults.MalformedQueryExceptionT
ype with arguments gov.nih.nci.cagrid.data.stubs.QueryRequest. The arguments do not match the signature.; nested exception is:
[java] java.lang.IllegalArgumentException: object is not an instance of declaring class
[java] faultActor:
[java] faultNode:
[java] faultDetail:
[java] {http://xml.apache.org/axis/}hostname:localhost
[java] Tried to invoke method public gov.nih.nci.cagrid.data.stubs.QueryResponse gov.nih.nci.cagrid.data.service.globus.DataServiceProviderImpl.query(gov.nih.nci.cagrid.data.s
tubs.QueryRequest) throws java.rmi.RemoteException,gov.nih.nci.cagrid.data.faults.QueryProcessingExceptionType,gov.nih.nci.cagrid.data.faults.MalformedQueryExceptionType with argum
ents gov.nih.nci.cagrid.data.stubs.QueryRequest. The arguments do not match the signature.; nested exception is:
[java] java.lang.IllegalArgumentException: object is not an instance of declaring class
[java] at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:221)
[java] at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:128)
[java] at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
[java] at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
[java] at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
[java] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
[java] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
[java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[java] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[java] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
[java] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
[java] at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
[java] at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
[java] at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:645)
[java] at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
[java] at org.apache.axis.message.addressing.handler.AddressingHandler.processClientResponse(AddressingHandler.java:305)
[java] at org.apache.axis.message.addressing.handler.AddressingHandler.invoke(AddressingHandler.java:110)
[java] at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
[java] at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
[java] at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
[java] at org.apache.axis.client.AxisClient.invoke(AxisClient.java:190)
[java] at org.apache.axis.client.Call.invokeEngine(Call.java:2727)
[java] at org.apache.axis.client.Call.invoke(Call.java:2710)
[java] at org.apache.axis.client.Call.invoke(Call.java:2386)
[java] at org.apache.axis.client.Call.invoke(Call.java:2309)
[java] at org.apache.axis.client.Call.invoke(Call.java:1766)
[java] at foo.bar.my.stubs.bindings.MyServicePortTypeSOAPBindingStub.query(MyServicePortTypeSOAPBindingStub.java:1199)
[java] at foo.bar.my.client.MyServiceClient.query(MyServiceClient.java:154)
[java] at foo.bar.my.client.MyServiceClient.main(MyServiceClient.java:122)
This issue can usually be resolved by deploying the service to a completely clean container to which no services have ever been deployed and running again.
Domain objects returned from my caCORE SDK-backed data service throw an exception when calling getter methods on associations
When querying a caGrid Data Service backed by the caCORE SDK, the domain objects returned throw an exception when a getter to an associated object is called, similar to the following:
[main] ERROR applicationservice.ApplicationServiceProvider - Fatal Error in Initailizing Either Client or Server Implementation of Application Service
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at CAGWASClient.testAllMethods(CAGWASClient.java:185)
at CAGWASClient.run(CAGWASClient.java:159)
at CAGWASClient.main(CAGWASClient.java:110)
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [remoteService.xml];
nested exception is java.io.FileNotFoundException: class path resource [remoteService.xml] cannot be opened because it does not exist
The CQL specification requires that the target object of a query (and only the target) be returned, and that associations are intentionally left unpopulated. When the XML results of a CQL query are deserialized, only the attributes of the target data object are populated, and associations are left as null values. Beans generated by the caCORE SDK versions 3.1 and 3.2/3.2.1 are configured to detect this null condition, and attempt to use the application service API to populate the associated objects on calls to the getter methods. Since the grid client is disconnected from the actual application service backend, this fails with the above exception.
Why do I see tons of output when I connect to a service deployed to a secure JBoss container?
There is a jar file that is processing every encrypted message that comes into the service and it's logger is set to be on by default unless you turn it off. To turn it off you can simply add the snippet below to the JBOSS_HOME/server/default/conf/log4j.xml file in the area where you see other categories being listed. This will disable this debugging output and stop the chattering log files.
<category name=COM.claymoresystems.ptls.SSLDebug">
<priority value="OFF" />
</category>
Calling an insecure method on a service (http), "(411)Length Required" error is returned"
$ /app_data1/ws-core-4.0.3/bin/wsrf-get-property -a -z none -s http://caarraygrid.c2b2.columbia.edu/ws ... CaArraySvc {gme://caGrid.caBIG/1.0/gov.nih.nci.cagrid.metadata.dataservice}DomainModel
Error: (411)Length Required
$ /app_data1/ws-core-4.0.3/bin/wsrf-get-property -a -z none -s http://caarraygrid.c2b2.columbia.edu/ws ... CaArraySvc {gme://cagrid.caBIG/1.0/gov.nih.nci.cagrid.metadata} ServiceMetadata
Error: (411)Length Required
This issue is caused by mismatch of HTTP version. All Globus services and clients require HTTP 1.1 version. This manifests if Apache server is used as proxy and is a version older than 2.2 (which only supports HTTP 1.0). The issue can be fixed by upgrading the servers to use HTTP 1.1 version. This problem can occur if an older HTTP proxy re-directs to the container for your service, and doesn't support HTTP 1.1.
I can't import the caGrid 1.2 CDS DelegatedCredentialTypes.xsd into my analytical service? It prints out a stracktrace complaining about imported types
If you import types from File system in Introduce 1.2, and import the projects/cds/schema/CredentialDelegationService/DelegatedCredentialTypes.xsd file, you will see an error from Introduce and a stacktrace on the console:
ParseException: src-resolve.4.2: Error resolving component 'wsa:EndpointReference'. It was detected that 'wsa:EndpointReference' is in namespace 'http://schemas.xmlsoap.org/ws/2004/03/addressing', but components from this namespace are not referenceable from schema document '/caGrid/projects/cds/schema/CredentialDele gationService/DelegatedCredentialTypes.xsd'. If this is the incorrect namespace, perhaps the prefix of 'wsa:EndpointReference' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to '/caGrid/projects/cds/schema/CredentialDele gationService/DelegatedCredentialTypes.xsd'
The work-around is to modify the schema in the cds project build file: projects/cds/build/schema/CredentialDelegationService with the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://cds.gaards.cagrid.org/CredentialDelegationService/DelegatedCredential/types"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:tns="http://cds.gaards.cagrid.org/CredentialDelegationService/DelegatedCredential/types" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:wsrbf="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://schemas.xmlsoap.org/ws/2004/03/addressing" schemaLocation="../ws/addressing/WS-Addressing.xsd"> </import>
<import namespace="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd" schemaLocation="../wsrf/faults/WS-BaseFaults.xsd"> </import>
<element name="DelegatedCredentialReference">
<complexType>
<sequence >
<element ref="wsa:EndpointReference"></element>
</sequence>
</complexType>
</element>
</schema>
Then go to Introduce and import the schema (from the build directory specifically). You will see 4 new namespaces on the left-hand side:
- http://www.w3.org/XML/1998/namespace <---- Remove this
- http://schemas.xmlsoap.org/ws/2004/03/addressing <---- Remove this
- http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd <---- Remove this
- http://cds.gaards.cagrid.org/CredentialDelegationService/DelegatedCredential/types <--- Keep this
Remove the indicated namespaces above by clicking on the namespace and clicking "Remove" on the right-hand pane.
Keep the CredentialDelegationService namespace, however.
I upgraded a service with Introduce 1.2, but now my service doesn't publish service metadata. What is wrong?
You need to patch Introduce 1.2 before performing the upgrade. There is a bug in the Introduce 1.2 release that causes this problem. It has since been fixed. Read more about how to update Introduce here: Introduce:1.2:UserGuide#Software_Updates
I can't connect to my MySQL database
Check to make sure that your database is on the port you think it is and that you have configured the database with networking enabled. This paragraph from the MySQL documentation has more details:
Make sure that the server has not been configured to ignore network connections or (if you are attempting to connect remotely) that it has not been configured to listen only locally on its network interfaces. If the server was started with --skip-networking, it will not accept TCP/IP connections at all. If the server was started with --bind-address=127.0.0.1, it will listen for TCP/IP connections only locally on the loopback interface and will not accept remote connections.
To fix this problem, follow these instructions:
Note that on some Linux distributions MySQL is configured so that it will not lis- ten on the network for connections. This is done for security reasons, but it prevents Java from being able to connect to MySQL via the JDBC driver. To fix this, search for your my.cnf file (it is probably in /etc or /etc/sysconfig). There are two ways in which this may be disabled. If you find a directive called skip-networking, comment it by putting a hash mark (#) in front of it. If you find a directive called bind-address and it is configured to bind only to localhost (127.0.0.1), comment it out by putting a hash mark (#) in front of it. Save the file and then restart MySQL.
If you're database in on another machine (not "localhost"), then check that there is no firewall blocking your database connection:
Check to make sure that there is no firewall blocking access to MySQL. Your firewall may be configured on the basis of the application being executed, or the port number used by MySQL for communication (3306 by default). Under Linux or Unix, check your IP tables (or similar) configuration to ensure that the port has not been blocked. Under Windows, applications such as ZoneAlarm or the Windows XP personal firewall may need to be configured not to block the MySQL port.
More information can be found in the MySQL troubleshooting documentation.
When contacting a Grid service, I receive the following error: Authentication failed [Caused by: Failure unspecified at GSS-API level [Caused by: Bad certificate ... what is the problem?
Please see the helpful CCTS wiki page for more information: CCTS Troubleshooting
caBIG-related Questions
What is caBIG?
There is a nice overview here, and you can find out more on the caBIG website
What caBIG tools are caGrid compatible?
A growing list of tools is maintained on the caBIG website, here https://cabig.nci.nih.gov/tools
When trying to create or access service metadata, or information from the caDSR grid service, I get an error like "is not a valid XML character", what is the problem?
You might see something like:
java.lang.IllegalArgumentException: The char '0x19' in 'java.io.IOException: java.lang.IllegalArgumentException: The char '0x19' in 'A human being who may be assigned to a study.
The study specifies how the subject↓s illness will be treated and/or monitored overtime.' is not a valid XML character.' is not a valid XML character.
[java] org.apache.axis.components.encoding.AbstractXMLEncoder.encode(AbstractXMLEncoder.java:110)
[java] org.apache.axis.utils.XMLUtils.xmlEncodeString(XMLUtils.java:131)
[java] org.apache.axis.AxisFault.dumpToString(AxisFault.java:366)
[java] org.apache.axis.AxisFault.printStackTrace(AxisFault.java:796)
[java] org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:50)
[java] org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:333)
[java] org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:295)
[java] org.apache.log4j.WriterAppender.append(WriterAppender.java:150)
[java] org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
[java] org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
[java] org.apache.log4j.Category.callAppenders(Category.java:187)
[java] org.apache.log4j.Category.forcedLog(Category.java:372)
[java] org.apache.log4j.Category.log(Category.java:864)
[java] org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:192)
[java] org.apache.axis.Message.writeTo(Message.java:525)
[java] org.apache.axis.transport.http.AxisServlet.sendResponse(AxisServlet.java:895)
[java] org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:767)
[java] javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
[java] org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
[java] javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
[java] at org.apache.axis.components.encoding.AbstractXMLEncoder.encode(AbstractXMLEncoder.java:110)
[java] at org.apache.axis.utils.XMLUtils.xmlEncodeString(XMLUtils.java:131)
[java] at org.apache.axis.utils.DOM2Writer.normalize(DOM2Writer.java:344)
[java] at org.apache.axis.utils.DOM2Writer.print(DOM2Writer.java:246)
[java] at org.apache.axis.utils.DOM2Writer.print(DOM2Writer.java:208)
[java] at org.apache.axis.utils.DOM2Writer.serializeAsXML(DOM2Writer.java:77)
[java] at org.apache.axis.utils.DOM2Writer.serializeAsXML(DOM2Writer.java:60)
[java] at org.apache.axis.utils.DOM2Writer.nodeToString(DOM2Writer.java:49)
[java] at org.apache.axis.utils.XMLUtils.privateElementToString(XMLUtils.java:426)
[java] at org.apache.axis.utils.XMLUtils.ElementToString(XMLUtils.java:435)
[java] at org.apache.axis.utils.XMLUtils.getInnerXMLString(XMLUtils.java:535)
[java] at org.apache.axis.AxisFault.dumpToString(AxisFault.java:384)
[java] at org.apache.axis.AxisFault.printStackTrace(AxisFault.java:785)
[java] at java.lang.Throwable.printStackTrace(Throwable.java:451)
[java] at gov.nih.nci.cagrid.cadsr.portal.discovery.CaDSRTypeDiscoveryComponent$1.run(CaDSRTypeDiscoveryComponent.java:199)
This is caused by characters in information stored in caDSR, that are not valid (in the WS-I profile required encodings) to be passed as XML on the grid. Most often the problematic characters are "smart quotes" introduce by MS Word when editing descriptions. The easiest solution is to identify and remove the characters in caDSR. Below is a program created by Satish Patel that can help identify them. The caDSR team is putting checks in place to identify these characters before they are introduced.
import gov.nih.nci.cadsr.umlproject.domain.Project;
import gov.nih.nci.cadsr.umlproject.domain.UMLAttributeMetadata;
import gov.nih.nci.cadsr.umlproject.domain.UMLClassMetadata;
import gov.nih.nci.system.applicationservice.ApplicationService;
import java.util.Collection;
import java.util.Iterator;
/**
*
* @author Satish Patel
*
*/
public class ModelProblems {
public static void main(String[] args) {
try
{
//Project name as specified in the caDSR
String projectName = "<<project_name>>";
//Project version as specified in caDSR
String projectVersion = "<<project_version>>";
//Buffer to hold the problems
StringBuilder sb = new StringBuilder();
ApplicationService appService = ApplicationService
.getRemoteInstance("http://cabio.nci.nih.gov/cacore31/http/remoteService");
Project searcghProject = new Project();
searcghProject.setVersion(projectVersion);
searcghProject.setShortName(projectName);
System.out.println("Creating domain model for project: "
+ searcghProject.getShortName() + " (version:"+ searcghProject.getVersion() + ")");
Collection projectCollection = appService.search(Project.class, searcghProject);
//Proceed if only one Project is found in caDSR
if(projectCollection.size()!=1)
{
if(projectCollection.size()>1)
System.out.println("Number of projects found in caDSR: "+projectCollection.size());
else
System.out.println("Could not obtain the correct project from caDSR");
System.exit(-1);
}
Project project = (Project)projectCollection.iterator().next();
System.out.println("Got domain model for project: "
+ project.getShortName() + " (version:"+project.getVersion() + ")");
Collection umlClassCollection = project.getUMLClassMetadataCollection();
System.out.println("Number of classes: " + umlClassCollection.size());
for(Iterator iter=umlClassCollection.iterator();iter.hasNext();)
{
UMLClassMetadata classMetadata = (UMLClassMetadata)iter.next();
String classDesc = classMetadata.getDescription();
//Process description of the class
if (!isUnicodeCompliant(classDesc))
sb.append(classMetadata.getName()+ " class description: " + classDesc+ "\n");
//Process attributes of the class
Collection attrMetadataCollection = classMetadata.getUMLAttributeMetadataCollection();
for(Iterator attrIterator=attrMetadataCollection.iterator();attrIterator.hasNext();)
{
UMLAttributeMetadata attrMetadata = (UMLAttributeMetadata)attrIterator.next();
String desc = attrMetadata.getDescription();
if (!isUnicodeCompliant(desc))
sb.append(" "+ attrMetadata.getName()+ " attribute description in "+ classMetadata.getName()+" class: "+desc+"\n");
}
}
//Print result
if(sb.length()>0)
{
System.out.println("---------------------------------");
System.out.println("Bad characters found in following");
System.out.println("---------------------------------");
System.out.println(sb.toString());
}
else
{
System.out.println("------------------------------");
System.out.println("No Bad characters in the model");
System.out.println("------------------------------");
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
private static boolean isUnicodeCompliant(String str)
{
if (str != null)
for (int k = 0; k < str.length(); k++)
if(Character.isIdentifierIgnorable(str.charAt(k)))
return false;
return true;
}
}
Alternatively, the caGrid cadsr project contains a graphical tool which can locate such errors and generate reports which can be saved as text files. From the top level directory of caGrid, navigate to projects/cadsr, and execute the command 'ant runCadsrModelProblemFinder'.
Does the backend of a data service have to be a database? Can it be Excel or SAS files?
There is no requirement for backend databases. However, there is alot of tooling that is provided by NCICB and caGrid for taking standard relational databases and gridifying them. Excel or SAS files could be used, but you would have to create the programming logic to query them based upon the object-oriented query language that the grid supports.
What is the minimum API requirements with regard to the backend?
There is no API requirements for the backend database. However, if you are using the provided tooling (caCORE SDK, Introduce), then the backend database should be a relational database (e.g. MySQL or Oracle) with a traditional relational model.
At the Annual caBIG meeting there was discussion of silver compliance-accrediting. Does a grid service have to be accredited? Can we make it, following the rules of silver compliance, but not submitting to review?
There is no requirement that a grid service be silver compatible to be used. However, the production Index Service housed at the NCICB will only allow gold-compatible services to advertise. To accommodate others, there will be a sandbox Index Service that will allow any grid service to advertise.
What NCICB/caBIG resources can be leveraged to assist in the creation of the grid service?
The caCORE SDK provides tooling to take a UML model (defined by XMI), create a database (if one doesn't already exist), generate Java objects, and generate Java APIs. The caCORE SDK is command-line based. The caGrid Introduce toolkit then can be used to create a grid service from the caCORE SDK based system. Introduce is a graphical interface that provides wizard-like functionality for building, configuring, and deploying the service. Details on version compatibility for data services can be found here.
When a user searches across the grid to discover information in the caDSR, what is the query actually looking for; concept codes, public IDs, key words, administered items?
There are currently a number of different implications to what you suggest.
- Service advertisement
Services register their models in the caDSR. These models are then exposed by grid services through their service-level metadata. This is published to a central Index Service such that people can discover those services. The domain model is a subset of the information in the caDSR, but includes much of the information, such as CUI, class, property, value domain, etc.
Service discovery
All services on the grid that choose so may advertise their metadata (e.g. CDEs, API, etc.). Then, clients (users) can search that metadata to find services to invoke (query). For example, a client can search for all services that expose a particular CDE or portion of a CDE.
Data service querying
Once discovered, clients can query data services based. The query is structured based upon class name, property name, and associations. Value domain is not taken into account.
Federated querying
There is a component in caGrid that performs queries across data services, performing “joins” and aggregating data. CDE equivalence is not taken into account by this service, but tools that invoke the federated query processor can be written to leverage CDE equivalence.
caDSR Service
There is a grid service that allows you to query the caDSR, which is aptly named the caDSR Service. This allows you to extract pretty much all the information from the caDSR. It is based upon the Java client for the caDSR, and exposes more information than is possible to acquire through the service level metadata (a.k.a. discovery).
What is the relationship of the caDSR, EVS, and caGrid metadata and how can I use them?
This is discussed at a high level on the overview page. Additionally, relevant discussion occured on the caGrid user's mailing list, and is reproduced below:
From: caGrid Users discussion Forum [mailto:CAGRID_USERS-L@LIST.NIH.GOV] On Behalf Of Shanbhag, Krishnakant (NIH/NCI) [E] Sent: Friday, January 11, 2008 10:18 AM To: CAGRID_USERS-L@LIST.NIH.GOV Subject: Re: The coorinated use of caDSR and EVS
Here’s a potential <<example>> where the use of information provided by caGrid Metadata, caDSR and EVS can be utilized to coordinate a data workflow in a grid environment. There are many more flavors of using it; but this may give you some ideas..
Use Case:
A typical <<use case>> enabled by caGrid infrastructure, could involve a bioinfromatician wanting to get all information about Gene “Brca1” that is provided by grid enabled data services published by service providers on caGrid infrastructure.
In order to implement the above use case, here’s a <<one>> potential way that the user may use to get this information programmatically.
Step 1: In order to do any search for <<genes>>, it is important that the user use computable semantics and not depend on textual search. This is where EVS Grid service would help. The user would use the EVS Grid service to get the <<concept code>> corresponding to search term “Gene”, see below for code:
EVSGridServiceClient evsClient = new EVSGridServiceClient(“http://cagrid-service.nci.nih.gov:8080/wsrf/services/cagrid/EVSGridService”);
EVSDescLogicConceptSearchParams dlSearchParams = new EVSDescLogicConceptSearchParams();
dlSearchParams.setVocabularyName("NCI_Thesaurus");
dlSearchParams.setSearchTerm(searchTerm);
dlSearchParams.setLimit(1);
gov.nih.nci.evs.domain.DescLogicConcept[] dlConcept = evsClient.searchDescLogicConcept(dlSearchParams);
Step 2: Once a set of concept codes are obtained from Step 1, the user could use the caGrid metadata service APIs in caGrid to obtain the list of data services that contain the selected concept code
DiscoveryClient client = new DiscoveryClient(); EndpointReferenceType[] dsEPRs = client.discoverDataServicesByModelConceptCode(conceptCode);
Step 3: The user may now want to determine the specific <<object class>> that is potentially interesting to the user from the list of selected data services. This will involve calling the caGrid Metadata APIs that internally uses the caDSR Grid service. At the end of this step, the user would like to get a list of specific object classes from the various data services that can be further queried for actual data related to genes. This is where primarily the caDSR Grid service becomes useful. The combination of caGrid Metadata APIs and caDSR Grid service allows users to determine the specific attributes that may be common between different <<object classes>> in different data services that are serving the same concept code. This is important because, this knowledge would essentially allow users to develop what we call <<joins>> among multiple data services.
For example, the <GridPIR> service and <caBIO> grid service have both <Gene> class. The user may be interested in doing a query for the <Gene> class in GridPIR that have the same Genes that are available in <<caBIO>> grid service and then constrain it to be of type “Brca1”. To do this, DCQL (Distributed caBIG Query) needs to be written with the appropriate join attributes between the two services. The appropriate join attributes are determined computationally by “Common Data Element (CDE)” value (i.e. public ID and Version Number) which can be accessed from the caDSR Grid Service. In the above example, the join attributes for the <<Gene>> class for the two services turns out to be on the attribute “name” and “symbol” respectively. As you see, the attributes have different <<names>>; still they are computationally joinable because they have the same CDE.
The actual code to enable the <above> is a little more elaborate than can be written in a few lines. But, you may want to check the following APIS.
DomainModelExposedUMLClassCollection umlClassCollection = domainModel.getExposedUMLClassCollection(); UMLClass. getUmlAttributeCollection() …
Step 4: The user now has information about specific data services, object classes and join Keys. Now, the user can use the Federated query processor service to aggregate data from the selected data objects (e.g. Genes in GridPIR and caBIO) or do a distributed object join base on the selected join keys.
Foll. is an example of DCQL XML that can be generated <<dynamically>> from step 3 using the information in the caGrid Metadata API and caDSR Grid Service to do distributed querying.
<?xml version="1.0" encoding="UTF-8"?>
<DCQLQuery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://caGrid.caBIG/1.0/gov.nih.nci.cagrid.dcql Distributed_CQL_schema_2.0.xsd"
xmlns:cql="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQLQuery"
xmlns="http://caGrid.caBIG/1.0/gov.nih.nci.cagrid.dcql">
<TargetObject name="edu.georgetown.pir.domain.Gene">
<Group logicRelation="AND">
<ForeignAssociation targetServiceURL="http://cabio-gridservice.nci.nih.gov:80/wsrf-cabio/services/cagrid/CaBIOSvc">
<JoinCondition localAttributeName="name" foreignAttributeName="symbol" predicate="EQUAL_TO"/>
<ForeignObject name="gov.nih.nci.cabio.domain.Gene">
<Attribute name="symbol" value="BRC%" predicate="LIKE"/>
</ForeignObject>
</ForeignAssociation>
<Attribute name="name" value="BRC%" predicate="LIKE"/>
</Group>
</TargetObject>
<targetServiceURL>http://141.161.25.20:8080/wsrf/services/cagrid/GridPIR</targetServiceURL>
</DCQLQuery>
The user can send the above DCQL to the Federated query processor service and get instance data related to Genes “Brca1”.
Are grid queries accessing the metadata in the caDSR as part of their query function, or are they accessing metadata that is from the caDSR that is actually stored in applications/data sets?
Advertisement and Discovery accesses metadata that is extracted from the caDSR at service creation time. It is essentially static once the service is created (though service developers can change it). Queries to the actual services are based upon this metadata.
Is the data type a data element considered when querying across the grid or is it just the object and property (Class/attribute) portion used in the query?
Datatype can be used during discovery, but not querying the actual service for data.
Are queries accessing public ids of CDEs, CUIs in data element concepts? Object Classes? Properties?
CUI, object class, and property all accessible through discovery. Queries for the actual data of the data service are created using the class, property, and associations.
Are queries using keyword searches of terms in CDE names or DEC names?
Discovery generally uses full match of the names. However, there are ways to full text search. Queries to the data service use the full name.
Is it possible for us to establish equivalency of Person/Patient/Participant by the use of alternate names for standard CDEs?
Alternate name is not included in the metadata for the service. However, this information is exposed by the caDSR service, so potentially you could query the caDSR service the actual name and then perform discovery. The caGrid team is investigating whether to expose alternate name in the service-level metadata.
Is a user able to query the grid by a CDE alternate name type (ex. Alternate Name "DICOM Tag" has a value of 0008,0008) and get back all CDEs that have this tag associated with the CDE?
See answer above.
How can I get to Gold compatibility starting from scratch (or from existing system)?
There are basically two aspects to that question. The first is just how to use the tools. The second is meeting the compatibility requirements to actually be classified as “Gold.” The tools provided by caGrid can help one create systems which should meet Gold level compatibility, but not every system created by caGrid tools is automatically Gold compatible.
In the simplest case, to just use Introduce you really just need XML schemas which describe your data types, and then you can add operations to the service which use those types. Then you can implement the “stubbed” methods Introduce creates for you (you should find sufficient information on this on the wiki and in the release documents for caGrid). However, that’s far from a “Gold” service; you basically just have a grid service. Much of the guidelines around Gold compatibility are oriented around both semantic and syntactic interoperability of grid services, and to meet those requirements one must do additional steps to ensure that they just don’t have a “grid service” but that that grid service is interoperable with the rest of caBIG, and that clients of caBIG can appropriately leverage it. That is one of the key aspects which differentiates caBIG/caGrid from other grid efforts. We are currently working on version 3 of the compatibility guidelines, which will provide much more clarity and detail around the Gold level. Some of the details are aimed around leveraging harmonized and curated data types, semantically describing your data types, and publishing/registering appropriate metadata. Here’s the existing information: https://cabig.nci.nih.gov/guidelines_documentation/ We hope to have version 3 out in the near term.
How does the caDSR relate to XML Schemas used by a service?
The caDSR stores the model and its semantics, but doesn't describe how the data moves over the grid as XML. That's what the XML Schemas are for, and why they are registered in the GME. XML Schemas define datatypes in a particular namespace (to avoid naming collisions of elements/types). The particular namespace used by the schema doesn't really matter as long as it’s a valid URI, and is unique (so as to not be confused with other models). The caDSR team is currently working on registering information in caDSR which identifies the relevant namespaces and XML types a given item (Project, Class, etc) is represented as on the grid, but that is not yet available. Therefore, we currently use a naming convention for namespaces (based on things you the caDSR Project name and Context) which allows us to locate the appropriate schemas for a given Project. If you follow that convention, things like the caDSR types browser in Introduce can automatically locate and extract the necessary schemas for Projects you want to use. If you don't follow the convention, that is fine, but you must manually associate the schemas with the models you are using (until such information is programmatically available from the caDSR).
There is an effort going on the identify a minimal set of caDSR datatypes which should be used to construct all domain models, and make sure those datatypes have a formal mapping to a representation in XML Schema. The programming language choices for mapping to and from the XML are then completely irrelevant and can vary from developer to developer. For example, the same grid service may be invoked by multiple clients from multiple programming languages; certainly a Perl client won’t actually be using java.lang.Integer. What is important is the registration of the logical structure and semantics, and a formal and consistent mapping to XML Schema.
Is caGrid 0.5 still supported?
Now that the caGrid 1.1 infrastructure has become fully operational, one of the most important thrusts in caGrid 1.1 has been to implement the first set of policies and procedures created by the caBIG™ Security Working Group. One of the security requirements of caGrid is to have both user and host service credentials to be adhering to the initial Levels of Assurance (LOA1).
For instructions on obtaining caGrid grid accounts, see links below:
Additionally, the caGrid security infrastructure enables institutional credential providers to participate in the caGrid trust fabric. Please contact the caBIG™ Security Working Group for guidance on becoming part of the caGrid trust fabric.
caGrid 0.5 De-support: De-support of the caGrid 0.5 “Test bed” infrastructure was announced on October 1, 2007, and completed on January 1, 2008.
caGrid 0.5 User Accounts: Due to LOA1 requirements, it was not practical to migrate caGrid 0.5 user credentials to caGrid 1.1; users must register for a new account on the caGrid 1.1 Dorian Identity Provider.
If you have any questions or problems obtaining these credentials, please do not hesitate to ask for support.
Calling a method on a secure service throws the error "No client transport named 'https' found!"
When a call is made to a secure grid service (using https transport), the following error message might be seen:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: No client transport named 'https' found!
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:No client transport named 'https' found!
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:170)
at org.apache.axis.client.Call.invokeEngine(Call.java:2727)
at org.apache.axis.client.Call.invoke(Call.java:2710)
at org.apache.axis.client.Call.invoke(Call.java:2386)
at org.apache.axis.client.Call.invoke(Call.java:2309)
at org.apache.axis.client.Call.invoke(Call.java:1766)
at gov.nih.nci.cagrid.data.stubs.bindings.DataServicePortTypeSOAPBindingStub.getServiceSecurityMetadata(DataServicePortTypeSOAPBindingStub.java:1028)
at gov.nih.nci.cagrid.data.client.DataServiceClient.getServiceSecurityMetadata(DataServiceClient.java:129)
at gov.nih.nci.cagrid.introduce.security.client.ServiceSecurityClient.configureStubSecurity(ServiceSecurityClient.java:177)
at gov.nih.nci.cagrid.data.client.DataServiceClient.query(DataServiceClient.java:116)
at org.cagrid.sdk4.example.tutorial.QueryRunner.performQuery(QueryRunner.java:28)
at org.cagrid.sdk4.example.tutorial.QueryRunner.main(QueryRunner.java:50)
The Axis Engine underlying the client API does not have the https transport registered. This can be resolved by adding $GLOBUS_LOCATION to the client's classpath.
caGrid Portal Questions
Why doesn't my service appear in the Portal?
Firstly, depending on server load, network traffic etc, it can take anywhere from 15 minutes to 2 hours for any new service to appear in the caGrid Portal. Its usually on the low end of this time scale, but its not instantaneous.
This question is very frequenty asked on the caGrid users list and its usually a few common reasons on why a service is not in the caGrid Portal.We've listed them here with pointers on how to debug/correct these problems. If the debugging steps are confusing or you would like more help, please feel free to contact the contact the CBIIT Application Support team.
Here are the typical problems
- Service in not in the caGrid Index Service.
- Service is in the index, but the registration is invalid.
For both of these problems, please see this How-To document to debug these issue
- Index and/or Portal have their system clocks significantly out of sync.
- Your service has been banned by the Portal
For both of these issues, please contact the CBIIT Application Support team.
My service is in the Portal, but is Inactive
The Portal marks a service as Active if it meets all of these criteria:
- Registered in the Index Service
- Metadata is fully aggregated
- Service URL can be reached from the Internet (i.e., putting the service URL in a web browser returns a page with "Hi there, this is an AXIS service!"). That is, a HTTP GET on the service URL completes.
If your service is Inactive, please follow this how-to guide all the way through.
My service is in the portal and ACTIVE, but there is a status warning indicating the "Service will not be visible in the portal"
The only reason for the service to be ACTIVE and also for the message "Service will not be visible in the Portal" to appear in the diagnostics, is due to the metadata (in the Portal) being invalid/null.
Usually, this will correct itself once the Portal renews the metadata. If the Portal does not see any change in the metadata (it maintains a checksum of the metadata and re-loads metadata when it changes), then there are two possible fixes:
- Make a slight change to the metadata. For example, add a service description to the service metadata. Then re-deploy the service and re-start the service container.
- Contact NCICB application support and ask them to force the production portal to renew the metadata. (Alternatively, for the Training Grid portal contact the user's mailing list).
My service is in the Portal, but is not on the map
If you have successfully created and deployed a caGrid service and you can see the service in the Portal , but your service does not appear on the US Map that appears on the Portal homepage, this is most likely because you have not entered appropriate metadata for you caGrid service. The portal needs the hosting research center's street address to generate the correct geocoding information for the service to be displayed on the map.
You can do one of three things:
- Edit your service metadata in Introduce, using the provided editor, and then redeploy it anyway you like. NOTE: these edits will be "permanent," in that they are made to the service itself and will be used each time the service is deployed.
- Redeploy the service using the caGrid Installer (selecting "My Introduce Service" as the service to deploy), which will prompt you for the needed information. The metadata will only be edited in the temporary copy of the service which is used for deploying; it won't change the permanent metadata of your service.
- Manually modify the metadata in your deployed service to add the appropriate metadata. The metadata contents are stored in an XML file ending in "serviceMetadata.xml". For example, if your service is named "HelloWorld" and is deployed to Tomcat, you would edit the file
$CATALINA_HOME/webapps/wsrf/WEB-INF/etc/cagrid_HelloWorld/HelloWorld_serviceMetadata.xml
and add appropriate information in the <ns1:hostingResearchCenter> section of the file (sample below):
<ResearchCenter displayName="Center for Biomedical Informatics and Information Technology " shortName="CBIIT" xmlns="gme://caGrid.caBIG/1.0/gov.nih.nci.cagrid.metadata.common"> <Address country="US" locality="Rockville" postalCode="20852" stateProvince="MD" street1="2115 Executive Blvd" street2="Suite 5000"/> <pointOfContactCollection> <PointOfContact affiliation="NCI-CBIIT" email="doejohn@email.com" firstName="John" lastName="Doe" phoneNumber="(123) 456-7890" role="Grid Administrator"/> </pointOfContactCollection> </ResearchCenter>
Note: Please don't use the above XML snippet to cut and paste your serviceMetadata.xml file. We highly recommend that if you plan to edit the metadata manually, you use a utility like XML Spy (or similar) as any formatting or typographical errors can potentially cause schema validation errors.
Note: If your service does not show up in the portal at all, then please see this FAQ
Why is my old service still in the Portal?
This question is frequently asked by service developers that created a service and registered it in the caGrid Index service. But subsequently they have stopped the service advertisement or moved the service advertisement to a different index. The portal follows its own caching strategy and does not always reflect the contents of the caGrid Index Service.
See the this FAQ for details on the Service registration lifecycle within the Portal
If you would like to permanently and immediately remove a service from the portal, then you should contact the CBIIT Application Support team, and request them to ban the service. A service which is placed in the banned state is invisible in the portal, even if the service is active and advertising to the index service.
How does the Portal assign Status to a Service?
Service registration in the Portal has the following life cycle:
- A new grid service shows up in caGrid Index.
- Service URL is cached in the portal database.
- Portal periodically pings the service to see if it is active or inactive.
Prolonged periods of inactivity (more that four days) will result in the service being marked as dormant. In the dormant state, the service is no longer discoverable through the portal. However, should the service become active again, the service will automatically become discoverable (visible) in the portal once again.
Why is there a difference between the services registered in the Index service and the Portal?
See the previous FAQ. Portal follows its own caching and aggregation mechanism and will not always reflect the contents of the caGrid Index Service.
Who can I contact for help with the Portal?
If you are a service developer that is having issues getting your service in the caGrid Portal, please contact contact the CBIIT Application Support team. In your request, please tell provide the following details
- Grid Service URL
- Which index service you are registering to
- How long your service has been online and registering in the index?
If you are a user with general question on the caGrid Portal, feel free to join the caGrid Users List (cagrid_users-l@list.nih.gov) and post questions to the list.

