Package Structure for OmniGene
$Date: 2002/11/26 21:25:07 $
$Revision: 1.2 $
The package structure for medical and population genetics department will be changes to the following structure as of October 15, 2002:
Top Level Directory
The src directory will contain the following subdirectories to accommodate different languages;
The /java directory shall consist of the following structure:
The will be three sub packages under omnigene:
The framework package contains code that is modified in order to build services for a particular organization. In our case we are building webservices for the Whitehead Institute. These services shall import framework code to provide specific functionality specified by the OmniGene team’s customers: Lab heads, lab staff, or scientific counterparts.
The framework module shall consist of the following generic packages:
Description of each package:
The request package consists of classes that handle server side requests to the OmniGene middleware system. They are responsible for routing requests to the appropriate EJB for query.
This package consists of modules that contain the response of the middleware after user query. They are passed to the web service to inspect and produce SOAP responses.
The DBSieve package consists of modules to query a mutli-star schema. This module reads the ‘fat table” of a relational database (currently Oracle) and then produced SQL to query the attributed of this table dynamically.
The omnidas package contains generic code to call a DAS 1.0 server. Some of these objects are used to form an OmniGeneResponse. These are typically segment objects.
The jaxb package contains application code that build objects from DTD’s that are being considered for standardization in the bioinformatics community. They are no longer used in the middleware application architecture but, are used in the client side for presentation and transformation.
The webservice module consists of abstract classes that all other omnigene webservices extend from. They provide convenience methods to generate SOAP messages and attachments.
The bio package contains objects that represent biological objects that are easily serializable into XML. In the short term this package represents objects needed by the medical and population genetics department at the Whitehead Institute. Eventually, these objects will be represented in DAML+OIL and instantiated from these documents to produce biological objects.
This is a framework that allow java to execute any analysis program written in any language. It utilizes a relational database (postgresql) as a queuing system for jobs that are sent to it. These jobs are managed through an Enterprise Java Bean layer and supporting classes.
The analysis service can be broken down into further sub packages such as;
The service package contains code that extends the framework package to build applications specific to your organization. The service structure is shown below:
Each service must follow the template package structure as defined below:
Service specific requests shall reside in the request directory. Typically a developer extends from the request objects found in framework to produce these objects.
Service specific responses (XML, cursors etc) will reside in the response package of its parent. These classes typically extend from the response framework package.
Ejb’s associated with this service must be placed in the ejb package.
Webservice specific code will be contained in the webservice directory of the service and will extend the webservice classes found in the framework code listed above.
The analysis package is based off of the analysis framework to execute common bioinformatics tools such as:
Others as needed
This service contains information about projects, groups within a project, membership to a project, and entities (objects) that may be used in a project (SNP lists, gene lists etc.)
The SNP Service is a webservice which provides information about public and private polymorphism data. This includes attributes such as: allele frequency, population information, chromosomal position, coding/non-coding changes etc.
SSO stands for single sign on and allows users to authenticate against all web services that are installed in you institution a single time only. This service acts as a faćade over the webservices that are registered with it.
The util package contains code that is not specific to any module but can be used by all. It is shared code and will be very closely monitored so as to not allow it to become a dust bin.
Perl modules will reflect the same structure as the java package structure which will allow developers to have a consistent naming structure across modules. Developers will adhere to the following module naming scheme: