org.biomoby.registry.Central.RegistryImpl
|
Version: 1.1.1 | |||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||
java.lang.Object
public class RegistryImpl
| Constructor Summary | |
|---|---|
RegistryImpl()
|
|
| Method Summary | |
|---|---|
String |
deregisterNamespace(String deregistrationObject)
Deregister a deprecated namespace term |
String |
deregisterObjectClass(String deregistrationObject)
Deregister a deprecated object class. |
String |
deregisterService(String deregistrationObject)
Deprecated. |
String |
deregisterServiceType(String deregistrationObject)
Deregister a deprecated service type. |
String |
registerNamespace(String registrationObject)
Register a new namespace. |
String |
registerObjectClass(String registrationObject)
Register a new object class. |
String |
registerService(String registrationObject)
Register a new service instance. |
String |
registerServiceType(String registrationObject)
Register a new service type. |
| Methods inherited from class java.lang.Object |
|---|
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Constructor Detail |
|---|
public RegistryImpl()
| Method Detail |
|---|
public String registerObjectClass(String registrationObject)
Registry
registerObjectClass in interface RegistryregistrationObject - an XML string with the following structure:
<registerObjectClass>
<objectType>NewObjectType</objectType>
<Description><![CDATA[
human readable description
of data type]]>
</Description>
<Relationship relationshipType="RelationshipOntologyTerm">
<objectType articleName="SomeName">ExistingObjectType</objectType>
...
</Relationship>
...
<authURI>Your.URI.here</authURI>
<contactEmail>You@your.address.com</contactEmail>
</registerObjectClass>
o Class names are unique within the ontology, and there is only one
canonical MOBY Class ontology.
o You can envision this as simply registering a new node into the
class ontology graph, and creating the primary connections from
that node.
o MOBY, by default, supports three types of class relationships: ISA,
HAS, and HASA (these are the relationship ontology terms)
* foo ISA bar is a straight inheritence, where all attributes of
bar are guaranteed to be present in foo.
* foo HAS bar is a container type, where bar is an object inside
of foo in one or more copies.
* foo HASA bar is a container type, where bar is an object inside
of foo in one copy only
o Notice that, in a HAS and HASA relationships, it is necessary to
indicate an article name for each contained object type. Thus,
for example, you could have a sequence object that contained a
String object with name "nucleotideSequence" and an
Integer object with the name "sequenceLength".
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String deregisterObjectClass(String deregistrationObject)
Registry
deregisterObjectClass in interface RegistryderegistrationObject - a string of XML, with the following structure:
<deregisterObjectClass>
<objectType>ObjectOntologyTermToRemove</objectType>
</deregisterObjectClass>
Notes:
* You may only deregister classes that you yourself registered!
* You may not deregister object classes that are being used as input or output by any service
* You may not deregister object classes that are in a ISA or HASA relationship to any other object class.
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
<RDF><![CDATA[ the RDF of your service instance here (if applicable) ]]></RDF>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String registerServiceType(String registrationObject)
Registry
registerServiceType in interface RegistryregistrationObject - an XML string with the following structure:
<registerServiceType>
<serviceType>NewServiceType</serviceType>
<contactEmail>your_name@contact.address.com</contactEmail>
<authURI>Your.URI.here</authURI>
<Description>
<![CDATA[ human description of service type here]]>
</Description>
<Relationship relationshipType="RelationshipOntologyTerm">
<serviceType>ExistingServiceType</serviceType>
<serviceType>ExistingServiceType</serviceType>
</Relationship>
</registerServiceType>
* serviceTypes are unique within the service ontology, and there
is only one canonical MOBY service ontology.
* The only relationship ontology type currently supported by
MOBY is the "ISA" relationship.
* Services described to be in ISA relationship with the
new service type must exist or this registration will fail.
* All parameters are required.
* Email must be a valid address.
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String deregisterServiceType(String deregistrationObject)
Registry
deregisterServiceType in interface RegistryderegistrationObject - a string of XML with the following structure:
<deregisterServiceType>
<serviceType>ServiceOntologyTermToRemove</serviceType>
</deregisterServiceType>
* Will fail if any current services are instances of that service type
* Will fail if any other service types inherit from that service type.
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String registerNamespace(String registrationObject)
Registry
registerNamespace in interface RegistryregistrationObject - a string of XML with the following structure:
<registerNamespace>
<namespaceType>NewNamespaceHere</namespaceType>
<contactEmail>your_name@contact.address.com</contactEmail>
<authURI>Your.URI.here</authURI>
<Description>
<![CDATA[human readable description]]>
</Description>
</registerNamespace>
* All fields are required.
* Namespaces are unique within the namespace vocabulary and there is only one canonical MOBY namespace controlled vocabulary.
* contactEmail must be a valid email address.
* authURI must be a valid URI
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String deregisterNamespace(String deregistrationObject)
Registry
deregisterNamespace in interface RegistryderegistrationObject - a string of XML with the following structure:
<deregisterNamespace>
<namespaceType>MyNamespaceToRemove</namespaceType>
</deregisterNamespace>
* Will fail if that namespace is being used by any services
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String registerService(String registrationObject)
Registry
registerService in interface RegistryregistrationObject - a string of XML with the following structure:
<registerService>
<Category>moby</Category> <!-- one of 'moby', 'cgi', 'soap' -->
<serviceName>YourServiceNameHere</serviceName>
<serviceType>TypeOntologyTerm</serviceType>
<authURI>your.URI.here</authURI>
<signatureURL> http://some.URL.org/path/to/RDF/file </signatureURL>
<URL>http://URL.to.your/Service.script</URL>;
<contactEmail>your_name@contact.address.com</contactEmail>
<authoritativeService>1 | 0 </authoritativeService>
<Description><![CDATA[
human readable COMPREHENSIVE description of your service]]>
</Description>
<Input>
<!-- zero or more Primary (Simple and/or Collection) articles -->
<!-- each of these articles will appear EXACTLY ONCE in the input to the service -->
</Input>
<secondaryArticles>
<!-- zero or more INPUT Secondary (Parameter) articles -->
<!-- each of these articles will appear EXACTLY ONCE in the output from the service -->
</secondaryArticles>
<Output>
<!-- zero or more Primary (Simple and/or Collection) articles -->
</Output>
</registerService>
* All elements are required
* A service must have at least one Input OR Output Object Class.
* serviceName must comply with rules for method names of a web
service. i.e. must be include only characters [A-Za-z0-9_] and
begin with a letter.
* The object classes, namespaces, and service types must all exist
for the registration to be successful, so make sure you register
these first, or ensure that they already exist in their respective
ontologies.
* The authoritativeService tag is used to indicate whether or not the
registered service is "authoritative" for that transformation. i.e.
if you are "authoritative" anyone else performing the same transformation
would have to have obtained the information/code to do so from you. This
is similar to, but not necessarily identical to, mirroring someone elses
data, since the data in question may not exist prior to service
invocation.
* Only input secondary articles are defined during registration;
output secondary objects are entirely optional and may or may not
be interpreted client-side using their articleName tags.
* When registering a service, the registration object that you are returned
contains an extra XML element with the RDF tag. Inside of this element is
the RDF document corresponding to your service signature. MOBY Central
will expect to be able to recover that RDF document when it calls a GET
on the URL that you provide in the signatureURL element of the
registerService XML below. An agent will call this document on a
regular basis, and update your registered service with whatever
it finds there. If you wish to de-register your service, just remove
that document (or the portion of that document corresponding to your
service).
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
<RDF><![CDATA[ the RDF of your service instance here ]]></RDF>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
public String deregisterService(String deregistrationObject)
Registry
deregisterService in interface RegistryderegistrationObject - a string of XML, for example,
<deregisterService>
<authURI>service.provider.uri</authURI>
<serviceName>serviceName</serviceName>
</deregisterService>
<MOBYRegistration>
<success> <!-- 1 | 0 | -1 --> </success>
<id> <!-- some id number for your registration --> </id>
<message> <![CDATA[message here]]> </message>
<RDF><![CDATA[ the RDF of your service instance here ]]></RDF>
</MOBYRegistration>
* The content of message will contain any extra information, for example, the reason for failure, etc.
* success is 0 (failure), 1 (success) or -1 (pending)
* id, not used anymore, but could potentially be a place for an lsid (unofficial)
Registry.deregisterService(java.lang.String)
|
Version: 1.1.1 | |||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||||