2 # BioPerl module for Bio::SimpleAnalysisI
4 # Please direct questions and support issues to <bioperl-l@bioperl.org>
6 # Cared for by Martin Senger <martin.senger@gmail.com>
7 # For copyright and disclaimer see below.
10 # POD documentation - main docs before the code
14 Bio::SimpleAnalysisI - A simple interface to any (local or remote) analysis tool
18 This is an interface module - you do not instantiate it.
19 Use other modules instead (those that implement this interface).
23 This interface contains public methods for accessing and controlling
24 local and remote analysis tools. It is meant to be used on the client
25 side. The interface consists only of a necessary set of methods for
26 synchronous invocation of analysis tools. For more complex set,
27 including an asynchronous access, see interface C<Bio::AnalysisI>
28 (which inherits from this one, by the way).
34 User feedback is an integral part of the evolution of this and other
35 Bioperl modules. Send your comments and suggestions preferably to
36 the Bioperl mailing list. Your participation is much appreciated.
38 bioperl-l@bioperl.org - General discussion
39 http://bioperl.org/wiki/Mailing_lists - About the mailing lists
43 Please direct usage questions or support issues to the mailing list:
45 I<bioperl-l@bioperl.org>
47 rather than to the module maintainer directly. Many experienced and
48 reponsive experts will be able look at the problem and quickly
49 address it. Please include a thorough description of the problem
50 with code and data examples if at all possible.
54 Report bugs to the Bioperl bug tracking system to help us keep track
55 of the bugs and their resolution. Bug reports can be submitted via the
58 https://redmine.open-bio.org/projects/bioperl/
62 Martin Senger (martin.senger@gmail.com)
66 Copyright (c) 2003, Martin Senger and EMBL-EBI.
69 This module is free software; you can redistribute it and/or modify
70 it under the same terms as Perl itself.
74 This software is provided "as is" without warranty of any kind.
82 http://www.ebi.ac.uk/Tools/webservices/soaplab/guide
88 This is actually the main documentation...
90 If you try to call any of these methods directly on this
91 C<Bio::SimpleAnalysisI> object you will get a I<not implemented> error
97 # Let the code begin...
99 package Bio
::SimpleAnalysisI
;
102 use base
qw(Bio::Root::RootI);
104 # -----------------------------------------------------------------------------
108 Usage : $tool->analysis_name;
109 Returns : a name of this analysis
114 sub analysis_name
{ shift->throw_not_implemented(); }
116 # -----------------------------------------------------------------------------
120 Usage : $tool->analysis_spec;
121 Returns : a hash reference describing this analysis
124 The returned hash reference uses the following keys (not all of them always
125 present, perhaps others present as well): C<name>, C<type>, C<version>,
126 C<supplier>, C<installation>, C<description>.
130 sub analysis_spec
{ shift->throw_not_implemented(); }
132 # -----------------------------------------------------------------------------
136 Usage : $tool->input_spec;
137 Returns : an array reference with hashes as elements
140 The analysis input data are named, and can be also associated with a
141 default value, with allowed values and with few other attributes. The
142 names are important for feeding the analysis with the input data (the
143 inputs are given to methods C<run> and C<wait_for> as name/value
148 sub input_spec
{ shift->throw_not_implemented(); }
150 # -----------------------------------------------------------------------------
154 Usage : $tool->result_spec;
155 Returns : a hash reference with result names as keys
156 and result types as values
159 An analysis can produce several results, or the same result in several
160 different formats. All such results are named and can be retrieved
161 using their names by metod C<result>.
163 Here is an example of the result specification:
166 'outseq' => 'String',
167 'report' => 'String',
168 'detailed_status' => 'String'
173 sub result_spec
{ shift->throw_not_implemented(); }
175 # -----------------------------------------------------------------------------
179 Usage : $tool->run ( ['sequence=@my.seq', 'osformat=embl'] )
181 Args : data and parameters for this execution
184 Create a job, start it, and wait for its completion. The method is
185 identical to the method C<wait_for>. Why there are two methods doing
186 the same? Because it is expected that the sub-classes may implement
187 them differently (an example is an interface C<Bio::AnalysisI> which
188 uses method C<run> for an asynchronous execution and method
189 C<wait_for> for a synchronous one.
191 Usually, after this call, you ask for results of the finished job:
193 $analysis->run (...)->result;
195 The input data and prameters for this execution can be specified in
200 =item array reference
202 The array has scalar elements of the form
206 where C<name> is the name of an input data or input parameter (see
207 method C<input_spec> for finding what names are recognized by this
208 analysis) and C<value> is a value for this data/parameter. If C<value>
209 is missing a 1 is assumed (which is convenient for the boolean
210 options). If C<value> starts with C<@> it is treated as a local
211 filename, and its contents is used as the data/parameter value.
215 The same as with the array reference but now there is no need to use
216 an equal sign. The hash keys are input names and hash values their
217 data. The values can again start with a C<@> sign indicating a local
224 sub run
{ shift->throw_not_implemented(); }
226 # -----------------------------------------------------------------------------
230 Usage : $tool->wait_for ( { 'sequence' => '@my,file' } )
232 Args : the same as for method 'run'
234 Create a job, start it and wait for its completion. The method is
235 identical to the method C<run>. See details in the C<run> method.
239 sub wait_for
{ shift->throw_not_implemented(); }
241 # -----------------------------------------------------------------------------
245 Usage : $tool->status
246 Returns : string describing a status of the execution
249 It returns one of the following strings (and perhaps more if a server
250 implementation extended possible job states):
252 CREATED (not run yet)
253 COMPLETED (run and finished normally)
254 TERMINATED_BY_ERROR (run and finished with an error or a signal)
258 sub status
{ shift->throw_not_implemented(); }
260 # -----------------------------------------------------------------------------
264 Usage : $job->result (...)
265 Returns : a result created by running an analysis
266 Args : none (but an implementation may choose
267 to add arguments for instructions how to process
270 The method returns a scalar representing a result of an executed
271 job. If the job was terminated by an error the result may contain an
272 error message instead of the real data (or both, depending on the
277 sub result
{ shift->throw_not_implemented(); }
279 # -----------------------------------------------------------------------------