[MOBY-guts] biomoby commit
Martin Senger
senger at pub.open-bio.org
Sat Aug 27 20:20:48 UTC 2005
senger
Sat Aug 27 16:20:48 EDT 2005
Update of /home/repository/moby/moby-live/Java/docs
In directory pub.open-bio.org:/tmp/cvs-serv26668
Modified Files:
Moses.html
Log Message:
moby-live/Java/docs Moses.html,1.1,1.2
===================================================================
RCS file: /home/repository/moby/moby-live/Java/docs/Moses.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- /home/repository/moby/moby-live/Java/docs/Moses.html 2005/08/26 06:40:52 1.1
+++ /home/repository/moby/moby-live/Java/docs/Moses.html 2005/08/27 20:20:48 1.2
@@ -10,21 +10,268 @@
<h1>MoSeS - Moby Services Support</h1>
</center>
-Documentation in progress... <p>
+The MoSeS project hopes to give a full support for those who are
+writing Biomoby services. And because the Biomoby data exchange format
+is symmetric (data from and to services have the same structure) the
+support (such as a general XML parser for Biomoby data) can be used
+also for clients. <p>
-Expected before end of August 2005! <p>
+The current Moses is for Java services - but not much is missing and
+Moses can produce also code in Perl (if you think that it would be
+useful let me know). <p>
+<a name="overview"></a>
+<h2>Overview</h2>
+The basic idea is not new - it was already implemented in other
+languages for Biomoby: take descriptions of Biomoby data types from a
+registry and generate Java classes for all these data types, keeping
+in place their hierarchy. Once we have Java representation of all data
+types, we can generate also code for a Biomoby service that will be
+using strongly-typed access to all incoming and out-coming data. An
+implementation of such service will inherit from a generated
+<em>service skeleton</em> in such way that all processing of Biomoby
+XML is hidden. <p>
+
+This is an example of a <b>full implementation</b> of a service called
+<tt>HelloBiomobyWorld</tt> that does not expect any input and produce
+a String data type (with a predictable contents) (the code is
+available in jMoby): <p>
+
+<pre class=code>
+package org.jmoby.tutorial.service;
+
+import net.jmoby.samples.HelloBiomobyWorldSkel;
+import org.biomoby.shared.MobyException;
+import org.biomoby.shared.parser.MobyPackage;
+import org.biomoby.shared.parser.MobyJob;
+import org.biomoby.shared.datatypes.*;
+
+public class HelloBiomobyWorldImpl
+ extends HelloBiomobyWorldSkel {
+
+ public void processIt (MobyJob request,
+ MobyJob response,
+ MobyPackage outputContext)
+ throws MobyException {
+ set_<b>greeting</b> (response, new MobyString ("Hello, World!"));
+ }
+}
+</pre>
+<p>
+
+The service was registered in a Biomoby registry as follows: <p>
+
+<pre class=code>
+<Services>
+ <Service authURI='samples.jmoby.net'
+ serviceName='HelloBiomobyWorld'
+ lsid='urn:lsid:biomoby.org:serviceinstance:samples.jmoby.net,HelloBiomobyWorld'>
+ <serviceType>Retrieval</serviceType>
+ <authoritative>1</authoritative>
+ <Category>moby</Category>
+ <Description>
+This is a cult service, known to an exclusive group of persons sharing an esoteric
+interest. One of their believes is that a word started on January, 1 1970.
+ </Description>
+ <contactEmail>martin.senger at gmail.com</contactEmail>
+ <signatureURL></signatureURL>
+ <URL>http://localhost:8080/axis/services/</URL>
+ <Input>
+ </Input>
+ <Output>
+ <Simple articleName='<b>greeting</b>'>
+ <objectType>String</objectType>
+ </Simple>
+ </Output>
+ <secondaryArticles>
+ </secondaryArticles>
+ </Service>
+</Services>
+</pre>
+
+I have highlighted in both pictures a word <tt>greeting</tt>. It is an
+article name in a Biomoby registry, and it became a method name in a
+service implementation. <p>
+
+The same happens also with data types name, as shown in the second
+example (here it shows only part of the implementation class but its
+full version is in jMoby): <p>
+
+<pre class=code>
+ /**************************************************************************
+ * This is a mandatory method to be implemented.
+ *************************************************************************/
+ public void processIt (MobyJob request,
+ MobyJob response,
+ MobyPackage outputContext)
+ throws MobyException {
+ <b>Regex</b> input = get_<b>language</b> (request);
+ if (input == null) return;
+
+ <b>simple_key_value_pair</b>[] output = doBusiness (input);
+ set_<b>hello</b>Set (response, output) ;
+ }
+
+ /**************************************************************************
+ * Here is where the bussines logic is done
+ *************************************************************************/
+ protected <b>simple_key_value_pair</b>[] doBusiness (<b>Regex</b> regex)
+ throws MobyException {
+
+ String regExpression = regex.get_<b>regex</b>();
+ if (isEmpty (regExpression))
+ return new <b>simple_key_value_pair</b>[] {};
+ ...
+</pre>
+<p>
+
+The <tt>Regex</tt> and <tt>simple_key_value_pair</tt> are Biomoby data
+types - and you see that you can manipulate them as any Java
+object. The other highlighted words are parts of methods - they came
+either from the article names or from data types names (where article
+names were missing). The suffix <tt>Set</tt> in one method indicates
+that the object will be a Biomoby collection. <p>
+
+
+<a name="quick"></a>
+<h2>Quick start</h2>
+
+Details and explanation follow in the next sections. The examples of
+typing assumes that you have a CVS copy of jMoby and you have already
+compiled all classes (which is easy to do just by typing
+<tt>./build.sh</tt>. <p>
+
+
+<ol>
+
+ <li class=count> <b>Register your service</b> (for example, a
+service named <tt>TheService</tt>). Select what data types it will
+consume and what data types it will produce. Register the unless they
+are already registered. (<em>There is no support in Moses for this
+step - there are already several ways how to do it by other
+tools.</em>) <p>
+
+ <li class=count> <b>Generate Java classes for all data types</b>,
+compile them, packed them into a jar file and let javadoc generate
+their API documentation (note that you must have Internet connection
+because it explores Biomoby registry):
+
+ <pre>
+ ./build-dev.sh moses-datatypes
+ </pre>
+
+ <li class=count> <b>Generate skeleton for your service</b>, compile
+it, generate its API:
+
+ <pre>
+ ./build-dev.sh -Dmoses.service=TheService moses-services
+ </pre>
+
+ <li class=count> <b>Write your own implementation</b>, for example a
+class <tt>TheServiceImpl</tt>, that extends skeleton
+<tt>TheServiveSkel</tt>, and that contains the business logic you want
+to have. Compile it, test it (you can test it using the
+<tt>BaseCmdLineClient</tt> even before you deploy it to your
+Tomcat). If you place your source code into <tt>src/samples</tt> - use
+whatever package you like - you can compile it using jMoby Ant:
+
+ <pre>
+ ./build-dev.sh
+ </pre>
+
+ <li class=count> Start your Tomcat and <b>deploy your
+implementation</b> to your Tomcat (<em>sorry, this is not yet fully
+implemented</em>):
+
+ <pre>
+ ./build-dev.sh -Dservice.name=TheService deploy-services
+ </pre>
+
+</ol>
+
+<p>
+
+
+<a name="features"></a>
+<h2>Main features</h2>
+
+The services implemented on top of generated skeletons have implicitly
+(i.e. without any need to program) the following features: <p>
+
+<ul>
+ <li> They parse data input in Biomoby XML and they produce data in
+Biomoby XML format.
+
+ <li> They accept and deal with any number of Biomoby <em>jobs</em>
+in one request (a <em>job</em> is what Biomoby API calls a
+<em>query</em>, and what is expressed inside one <tt>mobyData</tt>
+Biomoby XML).
+
+ <li> They can accept XML data as <tt>string</tt> or as a byte array
+- as required by the Biomoby API.
+
+ <li> They are prepared to accept more specialized data types that
+they were registered for. This data type can be either an existing
+data type in time where the service skeleton was generated, but it can
+be also a new data type that was added to Biomoby data types long
+after the code for the service was generated.
+
+ <li> The source code of service skeletons contains information about
+the service (taken from the registry), including graphs of service
+neighbourhood (other services that can be connected with this
+one). Here is an example extract from service API: <p>
+
+<a href="images/service-api-example.png"><img src="images/service-api-example-small.png" border=0></a>
+
+ <li> It has built-in access to the deployment parameters (the
+parameters that can give service necessary configuration properties,
+such as JDBC user name and password).
+
+</ul>
+
+<p>
+
+Some other features are either planned to be added, or to be discussed
+how useful they would be, some of them can be done by few lines of
+code: <p>
+
+<ul>
+
+ <li class=tiny> Providing own testing data.
+ <li class=tiny> Providing additional, Biomoby non-compliant methods,
+such as <em>ping</em>.
+ <li class=tiny> Connecting automatically to a monitoring service,
+such as <a href="http://www.bionanny.org" target="_top">Bionanny</a>.
+ <li class=tiny> Supporting automatic data compression (without
+breaking clients that do no support it).
+
+</ul>
+<p>
+
+
+<a name="components"></a>
+<h2>MoSeS Components</h2>
+
+
+
+
+<p>
+
+Documentation in progress... <img src="images/arbeiter.gif" border=0/> (as long as I can keep my eyes open): <p>
+
+<img src="images/linuxinsidenotebook-smaller.jpg" border=0 align=center/> <p>
+
+Will be (almost) finished before the end of August 2005...
+
+<p>
<hr>
<div align=right class="address">
<address><A HREF="mailto:martin.senger at gmail.com">Martin Senger</A><BR></address>
<!-- hhmts start -->
-Last modified: Fri Aug 26 00:56:35 2005
+Last modified: Sun Aug 28 05:14:21 2005
<!-- hhmts end -->
</div>
</body> </html>
-
-
-
More information about the MOBY-guts
mailing list