[MOBY-guts] biomoby commit
Mark Wilkinson
mwilkinson at pub.open-bio.org
Fri Jun 6 00:45:47 UTC 2003
mwilkinson
Thu Jun 5 20:45:47 EDT 2003
Update of /home/repository/moby/moby-live/Perl/MOBY
In directory pub.open-bio.org:/tmp/cvs-serv2184
Modified Files:
Central.html Central.pm
Log Message:
updating and cleaning up pod documentation. Committing new HTML documentation. Will update website right away. Can now retrieve a WSDL file for a service which is sufficient for 'stubbing', but it doesn't contain an object definition (XSD).
moby-live/Perl/MOBY Central.html,1.1,1.2 Central.pm,1.70,1.71
===================================================================
RCS file: /home/repository/moby/moby-live/Perl/MOBY/Central.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- /home/repository/moby/moby-live/Perl/MOBY/Central.html 2003/06/05 19:08:19 1.1
+++ /home/repository/moby/moby-live/Perl/MOBY/Central.html 2003/06/06 00:45:46 1.2
@@ -22,7 +22,7 @@
<li><a href="#new">new</a></li>
<li><a href="#registerobjectclass">registerObjectClass</a></li>
- <li><a href="#deregisterobject">deregisterObject</a></li>
+ <li><a href="#deregisterobjectclass">deregisterObjectClass</a></li>
<li><a href="#registerservicetype">registerServiceType</a></li>
<li><a href="#deregisterservicetype">deregisterServiceType</a></li>
<li><a href="#registernamespace">registerNamespace</a></li>
@@ -79,19 +79,19 @@
use SOAP::Transport::HTTP;</pre>
<pre>
my $x = new SOAP::Transport::HTTP::CGI;
- $x->dispatch_to('WWW_SERVER_PATH', 'MOBY::Central', 'MOBY::Central::new');
+ # fill in your server path below...
+ $x->dispatch_to('WWW_SERVER_PATH', 'MOBY::Central');
$x->handle;</pre>
<p>---------------------------------------</p>
<p>CLIENT-SIDE</p>
<pre>
use SOAP::Lite +autodispatch =>
- proxy => '<a href="http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY-Central.pl">http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY-Central.pl</a>',
+ proxy => '<a href="http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl">http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl</a>',
on_fault => sub {
my($soap, $res) = @_;
die ref $res ? $res->faultstring : $soap->transport->status, "\n";
};</pre>
<pre>
- my $Central = MOBY::Central->new;
my $reg = $Central->registerService("
);
print "success ", $reg->success;
@@ -149,14 +149,24 @@
<p>
</p>
<h2><a name="registerobjectclass">registerObjectClass</a></h2>
-<pre>
- * used to register a new object Class into the Class ontology
- * you can envision this as simply registering a new node into the Class ontology graph, and creating the primary connections from that node.
- * MOBY, by default, supports three types of Class Relationships: ISA, HAS, and HASA (these are the relationship ontology terms)
- o foo ISA bar is a straight inheritence, where all attributes of bar are guaranteed to be present in foo.
- o foo HAS bar is a container type, where bar is an object inside of foo in one or more copies.
- o foo HASA bar is a container type, where bar is an object inside of foo in one copy only
- * 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".</pre>
+<ul>
+<li><strong><a name="item_used_to_register_a_new_object_class_into_the_class">used to register a new object Class into the Class ontology</a></strong><br />
+</li>
+<li><strong><a name="item_can_envision_this_as_simply_registering_a_new_node">can envision this as simply registering a new node into the Class ontology graph, and creating the primary connections from that node.</a></strong><br />
+</li>
+<li><strong><a name="item_hasa">MOBY, by default, supports three types of Class Relationships: ISA, HAS, and HASA (these are the relationship ontology terms)</a></strong><br />
+</li>
+<ul>
+<li><strong><a name="item_foo_isa_bar_is_a_straight_inheritence%2c_where_all">Foo ISA bar is a straight inheritence, where all attributes of bar are guaranteed to be present in foo.</a></strong><br />
+</li>
+<li><strong><a name="item_foo_has_bar_is_a_container_type%2c_where_bar_is_an">foo HAS bar is a container type, where bar is an object inside of foo in one or more copies.</a></strong><br />
+</li>
+<li><strong><a name="item_foo_hasa_bar_is_a_container_type%2c_where_bar_is_a">foo HASA bar is a container type, where bar is an object inside of foo in one copy only</a></strong><br />
+</li>
+</ul>
+<li><strong><a name="item_notice_that%2c_in_a_has_and_hasa_relationships%2c_">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''.</a></strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<registerObjectClass>
@@ -179,12 +189,19 @@
<p>...Registration Object...</p>
<p>
</p>
-<h2><a name="deregisterobject_*_used_to_remove_an_object_class_from_the_class_ontology_*_this_will_not_be_successful_until_you_respond_positively_to_an_email_sent_to_the_address_that_you_provided_when_registering_that_object._*_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.">deregisterObject
- * used to remove an Object Class from the Class ontology
- * this will not be successful until you respond positively to an email sent to the address that you provided when registering that object.
- * 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.</a></h2>
+<h2><a name="deregisterobjectclass">deregisterObjectClass</a></h2>
+<ul>
+<li><strong><a name="item_used_to_remove_an_object_class_from_the_class_onto">used to remove an Object Class from the Class ontology</a></strong><br />
+</li>
+<li><strong><a name="item_this_will_not_be_successful_until_you_respond_posi">this will not be successful until you respond positively to an email sent to the address that you provided when registering that object.</a></strong><br />
+</li>
+<li><strong><a name="item_you_may_only_deregister_classes_that_you_yourself_">you may only deregister Classes that you yourself registered!</a></strong><br />
+</li>
+<li><strong><a name="item_you_may_not_deregister_object_classes_that_are_bei">you may not deregister Object Classes that are being used as input or output by ANY service</a></strong><br />
+</li>
+<li><strong><a name="item_you_may_not_deregister_object_classes_that_are_in_">you may not deregister Object Classes that are in a ISA or HASA relationship to any other Object Class.</a></strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<deregisterObjectClass>
@@ -195,11 +212,16 @@
<p>
</p>
<h2><a name="registerservicetype">registerServiceType</a></h2>
-<pre>
- * used to register a new node in the Service Ontology
- * the ISA ontology terms must exist or this registration will fail.
- * all parameters are required.
- * email must be valid for later deregistration or updates</pre>
+<ul>
+<li><strong><a name="item_used_to_register_a_new_node_in_the_service_ontolog">used to register a new node in the Service Ontology</a></strong><br />
+</li>
+<li><strong><a name="item_the_isa_ontology_terms_must_exist_or_this_registra">the ISA ontology terms must exist or this registration will fail.</a></strong><br />
+</li>
+<li><strong><a name="item_all_parameters_are_required%2e">all parameters are required.</a></strong><br />
+</li>
+<li><strong><a name="item_email_must_be_valid_for_later_deregistration_or_up">email must be valid for later deregistration or updates</a></strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<registerServiceType>
@@ -222,10 +244,14 @@
<p>
</p>
<h2><a name="deregisterservicetype">deregisterServiceType</a></h2>
-<pre>
- * used to deregister a Service term from the Service ontology
- * will fail if any services are instances of that Service Type
- * will fail if any Service Types inherit from that Service Type.</pre>
+<ul>
+<li><strong><a name="item_used_to_deregister_a_service_term_from_the_service">used to deregister a Service term from the Service ontology</a></strong><br />
+</li>
+<li><strong><a name="item_will_fail_if_any_services_are_instances_of_that_se">will fail if any services are instances of that Service Type</a></strong><br />
+</li>
+<li><strong><a name="item_will_fail_if_any_service_types_inherit_from_that_s">will fail if any Service Types inherit from that Service Type.</a></strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<deregisterServiceType>
@@ -236,10 +262,14 @@
<p>
</p>
<h2><a name="registernamespace">registerNamespace</a></h2>
-<pre>
- * used to register a new Namespace in the Namespace controlled vocabulary
- * must provide a valid email address
- * all parameters are required.</pre>
+<ul>
+<li><strong><a name="item_used_to_register_a_new_namespace_in_the_namespace_">used to register a new Namespace in the Namespace controlled vocabulary</a></strong><br />
+</li>
+<li><strong><a name="item_must_provide_a_valid_email_address">must provide a valid email address</a></strong><br />
+</li>
+<li><strong>all parameters are required.</strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<registerNamespace>
@@ -255,10 +285,14 @@
<p>
</p>
<h2><a name="deregisternamespace">deregisterNamespace</a></h2>
-<pre>
- * used to remove a Namespace from the controlled vocabulary
- * will fail if that namespace is being used by any services
- * you will recieve an email for confirmation of the deregistration</pre>
+<ul>
+<li><strong><a name="item_used_to_remove_a_namespace_from_the_controlled_voc">used to remove a Namespace from the controlled vocabulary</a></strong><br />
+</li>
+<li><strong><a name="item_will_fail_if_that_namespace_is_being_used_by_any_s">will fail if that namespace is being used by any services</a></strong><br />
+</li>
+<li><strong><a name="item_you_will_recieve_an_email_for_confirmation_of_the_">you will recieve an email for confirmation of the deregistration</a></strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<deregisterNamespace>
@@ -269,10 +303,14 @@
<p>
</p>
<h2><a name="retrieverelationshiptypes">retrieveRelationshipTypes</a></h2>
-<pre>
- * used to remove a Namespace from the controlled vocabulary
- * will fail if that namespace is being used by any services
- * you will recieve an email for confirmation of the deregistration</pre>
+<ul>
+<li><strong>used to remove a Namespace from the controlled vocabulary</strong><br />
+</li>
+<li><strong>will fail if that namespace is being used by any services</strong><br />
+</li>
+<li><strong>you will recieve an email for confirmation of the deregistration</strong><br />
+</li>
+</ul>
<p>Input XML :</p>
<pre>
<deregisterNamespace>
@@ -283,13 +321,20 @@
<p>
</p>
<h2><a name="registerservice">registerService</a></h2>
-<pre>
- * all elements are required
- * a service must have at least one Input OR Output Object Class.
- * the contactEmail address must be valid, as it is used to authorize deregistrations and changes to the service you registered.
- * 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 anyone else were to perform the same transformation they would have to have obtained the information 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.</pre>
+<ul>
+<li><strong><a name="item_all_elements_are_required">all elements are required</a></strong><br />
+</li>
+<li><strong><a name="item_a_service_must_have_at_least_one_input_or_output_o">a service must have at least one Input OR Output Object Class.</a></strong><br />
+</li>
+<li><strong><a name="item_the_contactemail_address_must_be_valid%2c_as_it_is">the contactEmail address must be valid, as it is used to authorize deregistrations and changes to the service you registered.</a></strong><br />
+</li>
+<li><strong><a name="item_the_object_classes%2c_namespaces%2c_and_service_ty">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.</a></strong><br />
+</li>
+<li><strong><a name="item_the_%22authoritativeservice%22_tag_is_used_to_indi">the ``authoritativeService'' tag is used to indicate whether or not the registered service is ``authoritative'' for that transformation. i.e. if anyone else were to perform the same transformation they would have to have obtained the information 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.</a></strong><br />
+</li>
+<li><strong><a name="item_only_input_secondary_articles_are_defined_during_r">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.</a></strong><br />
+</li>
+</ul>
<pre>
Input XML :</pre>
<pre>
@@ -320,46 +365,63 @@
...Registration Object...</pre>
<pre>
There are two forms of Primary articles:</pre>
-<pre>
- * Simple - the article consists of a single MOBY Object
- * Collection - the article consists of a collection ("bag") of MOBY Objects (not necessarily the same object type).
- o Their number/order is not relevant, nor predictable
- o If order is important to the service provider, then a collection should not be used, rather the collection should be broken into named Simple parameters. This may impose limitations on the the types of services that can be registered in MOBY Central. If it becomes a serious problem, a new Primary article type will be added in a future revision.
- o The use of more than one Class in a collection is difficult to interpret, though it is equally difficult to envision a service that would require this. It is purposely left losely defined since any given Service Instance can tighten up this definition during the registration process.
- o A collection may contain zero or more Objects of each of the Classes defined in the XML during Service Instance registration.
- + Each distinct Object Class only needs to be included once in the XML. Additional entries of that Class within the same Collection definition must be ignored.</pre>
-<pre>
- An example of the use of each of these might be another BLAST service, where you provide the sequences that make up the Blast database as well as the sequence to Blast against it. The sequences used to construct the database might be passed as a Collection input article containing multiple Sequence Objects, while the sequence to Blast against it would be a Simple input article consisting of a single Sequence Object.</pre>
-<pre>
- There is currently only one form of Secondary article:</pre>
-<pre>
- * Secondary - the article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.
- o In the case of inputs, they are generally user-configurable immediately prior to service invocation.
- o During service invocation a Client must send all Secondary articles defined in the Service Instance, even if no value has been provided either as default, or Client-side.
- o Secondary articles that are considered "required" by the Service should be registered with a default value.
- o The Service may fail if an unacceptable value is passed for any Secondary Article.</pre>
-<pre>
- Articles are, optionally, named using the articleName attribute. This might be used if, for example, the service requires named inputs. The order of non-named articles in a single Input or Output set MUST not be meaningful.</pre>
-<pre>
- The XML structure of these articles is as follows:</pre>
-<pre>
- * Simple</pre>
+<ul>
+<li><strong><a name="item_simple_%2d_the_article_consists_of_a_single_moby_o">Simple - the article consists of a single MOBY Object</a></strong><br />
+</li>
+<li><strong><a name="item_collection">Collection - the article consists of a collection (``bag'') of MOBY Objects (not necessarily the same object type).</a></strong><br />
+</li>
+<ul>
+<li><strong><a name="item_their_number%2forder_is_not_relevant%2c_nor_predic">Their number/order is not relevant, nor predictable</a></strong><br />
+</li>
+<li><strong><a name="item_if_order_is_important_to_the_service_provider%2c_t">If order is important to the service provider, then a collection should not be used, rather the collection should be broken into named Simple parameters. This may impose limitations on the the types of services that can be registered in MOBY Central. If it becomes a serious problem, a new Primary article type will be added in a future revision.</a></strong><br />
+</li>
+<li><strong><a name="item_the_use_of_more_than_one_class_in_a_collection_is_">The use of more than one Class in a collection is difficult to interpret, though it is equally difficult to envision a service that would require this. It is purposely left losely defined since any given Service Instance can tighten up this definition during the registration process.</a></strong><br />
+</li>
+<li><strong><a name="item_a_collection_may_contain_zero_or_more_objects_of_e">A collection may contain zero or more Objects of each of the Classes defined in the XML during Service Instance registration.</a></strong><br />
+</li>
+<ul>
+<li><strong><a name="item_each_distinct_object_class_only_needs_to_be_includ">Each distinct Object Class only needs to be included once in the XML. Additional entries of that Class within the same Collection definition must be ignored.</a></strong><br />
+</li>
+</ul>
+</ul>
+</ul>
+<p>An example of the use of each of these might be another BLAST service, where you provide the sequences that make up the Blast database as well as the sequence to Blast against it. The sequences used to construct the database might be passed as a Collection input article containing multiple Sequence Objects, while the sequence to Blast against it would be a Simple input article consisting of a single Sequence Object.</p>
+<p>There is currently only one form of Secondary article:</p>
+<ul>
+<li><strong><a name="item_secondary_%2d_the_article_may_or_may_not_be_specif">Secondary - the article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.</a></strong><br />
+</li>
+<ul>
+<li><strong><a name="item_in_the_case_of_inputs%2c_they_are_generally_user%2">In the case of inputs, they are generally user-configurable immediately prior to service invocation.</a></strong><br />
+</li>
+<li><strong><a name="item_during_service_invocation_a_client_must_send_all_s">During service invocation a Client must send all Secondary articles defined in the Service Instance, even if no value has been provided either as default, or Client-side.</a></strong><br />
+</li>
+<li><strong><a name="item_secondary_articles_that_are_considered_%22required">Secondary articles that are considered ``required'' by the Service should be registered with a default value.</a></strong><br />
+</li>
+<li><strong><a name="item_the_service_may_fail_if_an_unacceptable_value_is_p">The Service may fail if an unacceptable value is passed for any Secondary Article.</a></strong><br />
+</li>
+</ul>
+</ul>
+<p>Articles are, optionally, named using the articleName attribute. This might be used if, for example, the service requires named inputs. The order of non-named articles in a single Input or Output set MUST not be meaningful.</p>
+<p>The XML structure of these articles is as follows:</p>
+<ul>
+<li><strong><a name="item_simple">Simple</a></strong><br />
+</li>
<pre>
<Simple articleName="NameOfArticle">
<objectType>ObjectOntologyTerm</objectType>
<Namespace>NamespaceTerm</Namespace>
<Namespace>...</Namespace><!-- one or more... -->
</Simple></pre>
-<pre>
- * Collection note that articleName of the contained Simple objects is not required, and is ignored.</pre>
+<li><strong><a name="item_collection_note_that_articlename_of_the_contained_">Collection note that articleName of the contained Simple objects is not required, and is ignored.</a></strong><br />
+</li>
<pre>
<Collection articleName="NameOfArticle">
<Simple>......</Simple> <!-- Simple parameter type structure -->
<Simple>......</Simple> <!-- DIFFERENT Simple parameter type (used only when multiple Object Classes appear in a collection) -->
</Collection></pre>
-<pre>
- * Secondary</pre>
+<li><strong><a name="item_secondary">Secondary</a></strong><br />
+</li>
<pre>
<Parameter articleName="NameOfArticle">
@@ -370,6 +432,7 @@
<enum>...<enum> <!-- ... -->
<enum>...<enum> <!-- ... -->
</Parameter></pre>
+</ul>
<p>
</p>
<h2><a name="registerservicewsdl">registerServiceWSDL</a></h2>
@@ -401,25 +464,38 @@
</findService></pre>
<pre>
ServiceQueryObject XML:
- To query MOBY Central, you fill out the relevant elements of a Query Ojbect. These include the input and/or output data Classes (by name from the Class ontology), the Service-type (by name from the Service-type ontology), the authority (service provider URI), or any number of keywords that must appear in the service description.</pre>
-<pre>
- * MOBY Central finds all services which match the contents of the Query Object.
- * All elements are optional, however at least one must be present.
- * All elements present are considered as increasingly limiting on the search (i.e. "AND").
- * keywords are:
- o comma-delimited
- o sentence-fragments are enclosed in double-quotes
- o wildcard "*" is allowed in combination with keyword fragments and or sentence fragments (lone "*" is meaningless and ignored)
- o multiple keywords are considered joined by "AND".</pre>
+
+To query MOBY Central, you fill out the relevant elements of a Query Ojbect. These include the input and/or output data Classes (by name from the Class ontology), the Service-type (by name from the Service-type ontology), the authority (service provider URI), or any number of keywords that must appear in the service description.</pre>
+<ul>
+<li><strong><a name="item_moby_central_finds_all_services_which_match_the_co">MOBY Central finds all services which match the contents of the Query Object.</a></strong><br />
+</li>
+<li><strong><a name="item_all_elements_are_optional%2c_however_at_least_one_">All elements are optional, however at least one must be present.</a></strong><br />
+</li>
+<li><strong><a name="item_search">All elements present are considered as increasingly limiting on the search (i.e. ``AND'').</a></strong><br />
+</li>
+<li><strong><a name="item_keywords_are%3a">keywords are:</a></strong><br />
+</li>
+<ul>
+<li><strong><a name="item_comma%2ddelimited">comma-delimited</a></strong><br />
+</li>
+<li><strong><a name="item_sentence%2dfragments_are_enclosed_in_double%2dquot">sentence-fragments are enclosed in double-quotes</a></strong><br />
+</li>
+<li><strong><a name="item_fragments">wildcard ``*'' is allowed in combination with keyword fragments and or sentence fragments (lone ``*'' is meaningless and ignored)</a></strong><br />
+</li>
+<li><strong><a name="item_multiple_keywords_are_considered_joined_by_%22and%">multiple keywords are considered joined by ``AND''.</a></strong><br />
+</li>
+</ul>
+</ul>
<p>In addition to the search parameters, there are two ``flags'' that can be set in the Query object:</p>
-<pre>
- * expandServices: this flag will cause MOBY Central to traverse the Service ontology and discover services that are child types (more specific) than the Service-type you requested</pre>
-<pre>
- e.g. you might request "alignment", and it would discover services such as "Blast", "Smith Waterman", "Needleman Wunsch"</pre>
-<pre>
- * expandObjects: this flag will cause MOBY Central to traverse the Class ontology to find services that operate not only on the Object Class you are querying, but also any parent types or sub-objects of that Object Class.</pre>
-<pre>
- e.g. if you request services that work on AnnotatedSequence Objects this flag will also return services that work on Sequence objects, since AnnotatedSequence objects inherit from Sequence objects</pre>
+<ul>
+<li><strong><a name="item_types">expandServices: this flag will cause MOBY Central to traverse the Service ontology and discover services that are child types (more specific) than the Service-type you requested</a></strong><br />
+</li>
+e.g. you might request ``alignment'', and it would discover services such as ``Blast'', ``Smith Waterman'', ``Needleman Wunsch''
+<p></p>
+<li><strong><a name="item_expandobjects%3a_this_flag_will_cause_moby_central">expandObjects: this flag will cause MOBY Central to traverse the Class ontology to find services that operate not only on the Object Class you are querying, but also any parent types or sub-objects of that Object Class.</a></strong><br />
+</li>
+e.g. if you request services that work on AnnotatedSequence Objects this flag will also return services that work on Sequence objects, since AnnotatedSequence objects inherit from Sequence objects
+<p></p></ul>
<p>The Query object structure is as follows:</p>
<pre>
<inputObjects>
@@ -451,7 +527,10 @@
Title : retrieveService
Usage : $WSDL = $MOBY->locateService($inputXML)
Function : get the WSDL descriptions for services with this service name
- Returns : XML (see below)
+ Returns : XML (see below)
+ Comment : the WSDL that you get back is invalid w.r.t. the object structure
+ It will always be so.
+ It should be used only to create stubs for the connection to the service.
inputXML :
<retrieveService>
<Service authURI="authority.uri.here" serviceName="myServ"/>
@@ -459,16 +538,7 @@
outputXML (by category):</pre>
<pre>
- moby: <Service><![CDATA[WSDL document here]]</Service>
-#
-# cgi : <Service>
-# <serviceName>NameOfService</serviceName>
-# <URL><a href="http://service.url.here</URL>">http://service.url.here</URL></a>;
-# <GETstring>sprintf_formatted_GET_string</GETstring>
-# <Description>
-# <![CDATA[human readable description here]]>
-# </Description>
-# </Service></pre>
+ moby: <Service><![CDATA[WSDL document here]]</Service></pre>
<p>
</p>
<h2><a name="retrieveserviceproviders">retrieveServiceProviders</a></h2>
===================================================================
RCS file: /home/repository/moby/moby-live/Perl/MOBY/Central.pm,v
retrieving revision 1.70
retrieving revision 1.71
diff -u -r1.70 -r1.71
--- /home/repository/moby/moby-live/Perl/MOBY/Central.pm 2003/05/26 02:01:43 1.70
+++ /home/repository/moby/moby-live/Perl/MOBY/Central.pm 2003/06/06 00:45:47 1.71
@@ -42,7 +42,8 @@
use SOAP::Transport::HTTP;
my $x = new SOAP::Transport::HTTP::CGI;
- $x->dispatch_to('WWW_SERVER_PATH', 'MOBY::Central', 'MOBY::Central::new');
+ # fill in your server path below...
+ $x->dispatch_to('WWW_SERVER_PATH', 'MOBY::Central');
$x->handle;
@@ -51,13 +52,12 @@
CLIENT-SIDE
use SOAP::Lite +autodispatch =>
- proxy => 'http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY-Central.pl',
+ proxy => 'http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl',
on_fault => sub {
my($soap, $res) = @_;
die ref $res ? $res->faultstring : $soap->transport->status, "\n";
};
- my $Central = MOBY::Central->new;
my $reg = $Central->registerService("
);
print "success ", $reg->success;
@@ -164,13 +164,27 @@
=head2 registerObjectClass
- * used to register a new object Class into the Class ontology
- * you can envision this as simply registering a new node into the Class ontology graph, and creating the primary connections from that node.
- * MOBY, by default, supports three types of Class Relationships: ISA, HAS, and HASA (these are the relationship ontology terms)
- o foo ISA bar is a straight inheritence, where all attributes of bar are guaranteed to be present in foo.
- o foo HAS bar is a container type, where bar is an object inside of foo in one or more copies.
- o foo HASA bar is a container type, where bar is an object inside of foo in one copy only
- * 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".
+=over 3
+
+=item * used to register a new object Class into the Class ontology
+
+=item * can envision this as simply registering a new node into the Class ontology graph, and creating the primary connections from that node.
+
+=item * MOBY, by default, supports three types of Class Relationships: ISA, HAS, and HASA (these are the relationship ontology terms)
+
+=over 3
+
+=item * Foo ISA bar is a straight inheritence, where all attributes of bar are guaranteed to be present in foo.
+
+=item * foo HAS bar is a container type, where bar is an object inside of foo in one or more copies.
+
+=item * foo HASA bar is a container type, where bar is an object inside of foo in one copy only
+
+=back
+
+=item * 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".
+
+=back
Input XML :
@@ -196,6 +210,7 @@
...Registration Object...
+
=cut
@@ -327,12 +342,22 @@
-=head2 deregisterObject
- * used to remove an Object Class from the Class ontology
- * this will not be successful until you respond positively to an email sent to the address that you provided when registering that object.
- * 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.
+=head2 deregisterObjectClass
+
+=over 3
+
+=item * used to remove an Object Class from the Class ontology
+
+=item * this will not be successful until you respond positively to an email sent to the address that you provided when registering that object.
+
+=item * you may only deregister Classes that you yourself registered!
+
+=item * you may not deregister Object Classes that are being used as input or output by ANY service
+
+=item * you may not deregister Object Classes that are in a ISA or HASA relationship to any other Object Class.
+
+=back
+
Input XML :
@@ -442,10 +467,19 @@
=head2 registerServiceType
- * used to register a new node in the Service Ontology
- * the ISA ontology terms must exist or this registration will fail.
- * all parameters are required.
- * email must be valid for later deregistration or updates
+=over 3
+
+
+=item * used to register a new node in the Service Ontology
+
+=item * the ISA ontology terms must exist or this registration will fail.
+
+=item * all parameters are required.
+
+=item * email must be valid for later deregistration or updates
+
+=back
+
Input XML :
@@ -591,9 +625,16 @@
=head2 deregisterServiceType
- * used to deregister a Service term from the Service ontology
- * will fail if any services are instances of that Service Type
- * will fail if any Service Types inherit from that Service Type.
+=over 3
+
+=item * used to deregister a Service term from the Service ontology
+
+=item * will fail if any services are instances of that Service Type
+
+=item * will fail if any Service Types inherit from that Service Type.
+
+=back
+
Input XML :
@@ -673,9 +714,17 @@
=head2 registerNamespace
- * used to register a new Namespace in the Namespace controlled vocabulary
- * must provide a valid email address
- * all parameters are required.
+=over 3
+
+
+=item * used to register a new Namespace in the Namespace controlled vocabulary
+
+=item * must provide a valid email address
+
+=item * all parameters are required.
+
+=back
+
Input XML :
@@ -745,9 +794,16 @@
=head2 deregisterNamespace
- * used to remove a Namespace from the controlled vocabulary
- * will fail if that namespace is being used by any services
- * you will recieve an email for confirmation of the deregistration
+=over
+
+=item * used to remove a Namespace from the controlled vocabulary
+
+=item * will fail if that namespace is being used by any services
+
+=item * you will recieve an email for confirmation of the deregistration
+
+=back
+
Input XML :
@@ -861,9 +917,16 @@
=head2 retrieveRelationshipTypes
- * used to remove a Namespace from the controlled vocabulary
- * will fail if that namespace is being used by any services
- * you will recieve an email for confirmation of the deregistration
+=over 3
+
+=item * used to remove a Namespace from the controlled vocabulary
+
+=item * will fail if that namespace is being used by any services
+
+=item * you will recieve an email for confirmation of the deregistration
+
+=back
+
Input XML :
@@ -878,12 +941,22 @@
=head2 registerService
- * all elements are required
- * a service must have at least one Input OR Output Object Class.
- * the contactEmail address must be valid, as it is used to authorize deregistrations and changes to the service you registered.
- * 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 anyone else were to perform the same transformation they would have to have obtained the information 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.
+=over 3
+
+=item * all elements are required
+
+=item * a service must have at least one Input OR Output Object Class.
+
+=item * the contactEmail address must be valid, as it is used to authorize deregistrations and changes to the service you registered.
+
+=item * 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.
+
+=item * the "authoritativeService" tag is used to indicate whether or not the registered service is "authoritative" for that transformation. i.e. if anyone else were to perform the same transformation they would have to have obtained the information 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.
+
+=item * 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.
+
+=back
+
Input XML :
@@ -915,31 +988,62 @@
There are two forms of Primary articles:
- * Simple - the article consists of a single MOBY Object
- * Collection - the article consists of a collection ("bag") of MOBY Objects (not necessarily the same object type).
- o Their number/order is not relevant, nor predictable
- o If order is important to the service provider, then a collection should not be used, rather the collection should be broken into named Simple parameters. This may impose limitations on the the types of services that can be registered in MOBY Central. If it becomes a serious problem, a new Primary article type will be added in a future revision.
- o The use of more than one Class in a collection is difficult to interpret, though it is equally difficult to envision a service that would require this. It is purposely left losely defined since any given Service Instance can tighten up this definition during the registration process.
- o A collection may contain zero or more Objects of each of the Classes defined in the XML during Service Instance registration.
- + Each distinct Object Class only needs to be included once in the XML. Additional entries of that Class within the same Collection definition must be ignored.
+=over 3
+
+=item * Simple - the article consists of a single MOBY Object
+
+=item * Collection - the article consists of a collection ("bag") of MOBY Objects (not necessarily the same object type).
+
+=over 3
+
+=item * Their number/order is not relevant, nor predictable
+
+=item * If order is important to the service provider, then a collection should not be used, rather the collection should be broken into named Simple parameters. This may impose limitations on the the types of services that can be registered in MOBY Central. If it becomes a serious problem, a new Primary article type will be added in a future revision.
+
+=item * The use of more than one Class in a collection is difficult to interpret, though it is equally difficult to envision a service that would require this. It is purposely left losely defined since any given Service Instance can tighten up this definition during the registration process.
+
+=item * A collection may contain zero or more Objects of each of the Classes defined in the XML during Service Instance registration.
+
+=over 3
+
+=item * Each distinct Object Class only needs to be included once in the XML. Additional entries of that Class within the same Collection definition must be ignored.
+
+=back
+
+=back
+
+=back
+
+An example of the use of each of these might be another BLAST service, where you provide the sequences that make up the Blast database as well as the sequence to Blast against it. The sequences used to construct the database might be passed as a Collection input article containing multiple Sequence Objects, while the sequence to Blast against it would be a Simple input article consisting of a single Sequence Object.
+
+There is currently only one form of Secondary article:
- An example of the use of each of these might be another BLAST service, where you provide the sequences that make up the Blast database as well as the sequence to Blast against it. The sequences used to construct the database might be passed as a Collection input article containing multiple Sequence Objects, while the sequence to Blast against it would be a Simple input article consisting of a single Sequence Object.
+=over 3
- There is currently only one form of Secondary article:
+=item * Secondary - the article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.
- * Secondary - the article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.
- o In the case of inputs, they are generally user-configurable immediately prior to service invocation.
- o During service invocation a Client must send all Secondary articles defined in the Service Instance, even if no value has been provided either as default, or Client-side.
- o Secondary articles that are considered "required" by the Service should be registered with a default value.
- o The Service may fail if an unacceptable value is passed for any Secondary Article.
+=over 3
+=item * In the case of inputs, they are generally user-configurable immediately prior to service invocation.
+=item * During service invocation a Client must send all Secondary articles defined in the Service Instance, even if no value has been provided either as default, or Client-side.
- Articles are, optionally, named using the articleName attribute. This might be used if, for example, the service requires named inputs. The order of non-named articles in a single Input or Output set MUST not be meaningful.
+=item * Secondary articles that are considered "required" by the Service should be registered with a default value.
- The XML structure of these articles is as follows:
+=item * The Service may fail if an unacceptable value is passed for any Secondary Article.
- * Simple
+=back
+
+=back
+
+
+Articles are, optionally, named using the articleName attribute. This might be used if, for example, the service requires named inputs. The order of non-named articles in a single Input or Output set MUST not be meaningful.
+
+The XML structure of these articles is as follows:
+
+=over 3
+
+=item * Simple
<Simple articleName="NameOfArticle">
<objectType>ObjectOntologyTerm</objectType>
@@ -947,7 +1051,7 @@
<Namespace>...</Namespace><!-- one or more... -->
</Simple>
- * Collection note that articleName of the contained Simple objects is not required, and is ignored.
+=item * Collection note that articleName of the contained Simple objects is not required, and is ignored.
<Collection articleName="NameOfArticle">
@@ -955,7 +1059,7 @@
<Simple>......</Simple> <!-- DIFFERENT Simple parameter type (used only when multiple Object Classes appear in a collection) -->
</Collection>
- * Secondary
+=item * Secondary
<Parameter articleName="NameOfArticle">
@@ -967,6 +1071,8 @@
<enum>...<enum> <!-- ... -->
</Parameter>
+=back
+
=cut
@@ -1614,26 +1720,46 @@
</findService>
ServiceQueryObject XML:
- To query MOBY Central, you fill out the relevant elements of a Query Ojbect. These include the input and/or output data Classes (by name from the Class ontology), the Service-type (by name from the Service-type ontology), the authority (service provider URI), or any number of keywords that must appear in the service description.
+
+To query MOBY Central, you fill out the relevant elements of a Query Ojbect. These include the input and/or output data Classes (by name from the Class ontology), the Service-type (by name from the Service-type ontology), the authority (service provider URI), or any number of keywords that must appear in the service description.
+
+=over 3
+
+=item * MOBY Central finds all services which match the contents of the Query Object.
+
+=item * All elements are optional, however at least one must be present.
+
+=item * All elements present are considered as increasingly limiting on the search (i.e. "AND").
- * MOBY Central finds all services which match the contents of the Query Object.
- * All elements are optional, however at least one must be present.
- * All elements present are considered as increasingly limiting on the search (i.e. "AND").
- * keywords are:
- o comma-delimited
- o sentence-fragments are enclosed in double-quotes
- o wildcard "*" is allowed in combination with keyword fragments and or sentence fragments (lone "*" is meaningless and ignored)
- o multiple keywords are considered joined by "AND".
+=item * keywords are:
+
+=over 3
+
+=item * comma-delimited
+
+=item * sentence-fragments are enclosed in double-quotes
+
+=item * wildcard "*" is allowed in combination with keyword fragments and or sentence fragments (lone "*" is meaningless and ignored)
+
+=item * multiple keywords are considered joined by "AND".
+
+=back
+
+=back
In addition to the search parameters, there are two "flags" that can be set in the Query object:
- * expandServices: this flag will cause MOBY Central to traverse the Service ontology and discover services that are child types (more specific) than the Service-type you requested
+=over 3
+
+=item * expandServices: this flag will cause MOBY Central to traverse the Service ontology and discover services that are child types (more specific) than the Service-type you requested
+
+e.g. you might request "alignment", and it would discover services such as "Blast", "Smith Waterman", "Needleman Wunsch"
- e.g. you might request "alignment", and it would discover services such as "Blast", "Smith Waterman", "Needleman Wunsch"
+=item * expandObjects: this flag will cause MOBY Central to traverse the Class ontology to find services that operate not only on the Object Class you are querying, but also any parent types or sub-objects of that Object Class.
- * expandObjects: this flag will cause MOBY Central to traverse the Class ontology to find services that operate not only on the Object Class you are querying, but also any parent types or sub-objects of that Object Class.
+e.g. if you request services that work on AnnotatedSequence Objects this flag will also return services that work on Sequence objects, since AnnotatedSequence objects inherit from Sequence objects
- e.g. if you request services that work on AnnotatedSequence Objects this flag will also return services that work on Sequence objects, since AnnotatedSequence objects inherit from Sequence objects
+=back
The Query object structure is as follows:
@@ -2490,7 +2616,10 @@
Title : retrieveService
Usage : $WSDL = $MOBY->locateService($inputXML)
Function : get the WSDL descriptions for services with this service name
- Returns : XML (see below)
+ Returns : XML (see below)
+ Comment : the WSDL that you get back is invalid w.r.t. the object structure
+ It will always be so.
+ It should be used only to create stubs for the connection to the service.
inputXML :
<retrieveService>
<Service authURI="authority.uri.here" serviceName="myServ"/>
@@ -2499,15 +2628,6 @@
outputXML (by category):
moby: <Service><![CDATA[WSDL document here]]</Service>
-#
-# cgi : <Service>
-# <serviceName>NameOfService</serviceName>
-# <URL>http://service.url.here</URL>
-# <GETstring>sprintf_formatted_GET_string</GETstring>
-# <Description>
-# <![CDATA[human readable description here]]>
-# </Description>
-# </Service>
=cut
@@ -2529,21 +2649,6 @@
#$debug && &_LOG("WSDL_________________$wsdls\n____________________");
return $wsdls;
}
- #elsif ($category eq 'cgi'){
- # my $serviceString = &_getCGIService($dbh, $sth_hash, $id, $serviceName, $AuthURI, $URL, $desc, $category);
- # my $service = "<Service>
- # <CGIService>
- # <serviceName>$serviceName</serviceName>
- # <URL>$URL</URL>
- # $serviceString
- # <Description><![CDATA[$desc]]></Description>
- # </CGIService>
- # </Service>\n";
- # $debug && &_LOG( "got $service description\n");
- # return $service;
- #
- #}
-
}
More information about the MOBY-guts
mailing list