----
h1. Portal 2.0.2 Design
----

{cagridtable}
{table-row}
{th:class=confluenceTh|colspan=3}*Development Team*{th}
{table-row}
{table-row}
{th:class=confluenceTh}Development{th}
{th:class=confluenceTh}Programmer's Guide{th}
{th:class=confluenceTh}Program Managment{th}
{table-row}
{table-row}
{cagridtablecell-width}Joshua Phillips{cagridtablecell-width}
{cagridtablecell-width}Joshua Phillips{cagridtablecell-width}
{cagridtablecell-width}Arumani Manisundaram{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width} {cagridtablecell-width}
{cagridtablecell-width} {cagridtablecell-width}
{cagridtablecell-width}Avinash Shanbhag{cagridtablecell-width}
{table-row}
{table-row}
{cagridtable}


{cagridtable}
{table-row}
{th:class=confluenceTh|colspan=2}*Contacts and Support*{th}
{table-row}
{table-row}
{cagridtablecell-width}Enter training contact{cagridtablecell-width}
{cagridtablecell-width}Joshua Phillips (joshua.phillips@semanticbits.com){cagridtablecell-width}
{table-row}
{cagridtable}

{cagridroundpanel}
{pre:class=cagridheaderfont}Table of Contents{pre}
{toc:outline=true|exclude=Portal 2.0.2 Design|style=none}
{cagridroundpanel}


h1. Introduction
----
The caGrid Portal is a workspace for discovering and interacting with caGrid services. Service status and metadata are aggregated from one or more index services providing a near real-time view of the grid. Services may be discovered using a sophisticated search interface or browsed through a directory-style interface. A map view provides a geographically-oriented entry point into all of the information that is associated with caGrid services. Individual portlets serve as tools for interacting with or discovering services. Related tools are assembled onto a portal page. Portal users can personalize pages to suit their needs.

h1. Overview
----
This section describes system requirements, technology dependencies and provides a high-level view of the portal architecture. A more details description of the portal design is provide in the Design and Architecture section.

h2. System Requirements
----
The caGrid Portal consists of a set of components written in the Java language. The following components are required by the portal and are not distributed with it.

{cagridtable}
{table-row}
{th:class=confluenceTh}Component{th}
{th:class=confluenceTh}Version{th}
{table-row}
{table-row}
{cagridtablecell-width}Sun Java JRE{cagridtablecell-width}
{cagridtablecell-width}1.5+{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Apache Tomcat{cagridtablecell-width}
{cagridtablecell-width}4.0.23 and 5.5.23{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Apache Jetspeed 2{cagridtablecell-width}
{cagridtablecell-width}2.1{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Globus Toolkit{cagridtablecell-width}
{cagridtablecell-width}4.0.3{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}MySQL Database{cagridtablecell-width}
{cagridtablecell-width}5+{cagridtablecell-width}
{table-row}
{cagridtable}


h2. Technology Dependencies
----
Following is a partial list of the technologies that caGrid Portal depends on which are not part of the caGrid project. For a complete list, see caGrid/projects/portal2/lib/README.txt

{cagridtable}
{table-row}
{th:class=confluenceTh|width=20%}Technology{th}
{th:class=confluenceTh|width=20%}Version{th}
{th:class=confluenceTh|width=30%}Description{th}
{table-row}
{table-row}
{cagridtablecell-width}Spring{cagridtablecell-width}
{cagridtablecell-width}2.0.5{cagridtablecell-width}
{cagridtablecell-width}Spring is used in various layers of caGrid Portal. In all layers, Spring provides dependency injection and object lifecycle management. In the presentation layer, both Spring MVC, and Spring Portlet MVC are used. In the service and DAO layers, Spring provides declarative transaction demarcation.{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Hibernate Core{cagridtablecell-width}
{cagridtablecell-width}3.2.2{cagridtablecell-width}
{cagridtablecell-width}Provides persistence strategy{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Hibernate Annotations{cagridtablecell-width}
{cagridtablecell-width}3.3.0{cagridtablecell-width}
{cagridtablecell-width}Provides ORM configuration{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Velocity{cagridtablecell-width}
{cagridtablecell-width}1.4{cagridtablecell-width}
{cagridtablecell-width}Rendering of portal layouts and decorations{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}JSP{cagridtablecell-width}
{cagridtablecell-width}2.0{cagridtablecell-width}
{cagridtablecell-width}Rendering of portal views{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}Scriptaculous{cagridtablecell-width}
{cagridtablecell-width}1.6.5{cagridtablecell-width}
{cagridtablecell-width}DHTML effects{cagridtablecell-width}
{table-row}
{table-row}
{cagridtablecell-width}DWR{cagridtablecell-width}
{cagridtablecell-width}?{cagridtablecell-width}
{cagridtablecell-width}AJAX{cagridtablecell-width}
{table-row}
{cagridtable}

h2. Architecture

h1. Portal Requirements
----
The caGrid Monitoring and Discovery Portal must meet the following functional requirements:

* Main display response times should be consistent with standard web page interactions, generally between 1.0-1.5 seconds.
* Search page response times should be on par with other search pages and are expected to be slower than displaying static content, but generally between 1.0-1.5 seconds.
* Portal will be able to take information from one or more caGrid 1.0 index services.
* Main display requirements:
** Portal needs to display grid centers on a geographic map. Points on the map are referred to as "nodes" in this document. Locations that house a service or multiple services are referred to as "centers".
** Portal needs to be accessible to all users and enable reasonable navigation by adhering to Section 508c of the Rehabilitation Act of 1978.
** Portal should display well at resolutions of 800x600px or greater.
** Portal will expose the Grid center URL as defined in the common service metadata.
** Portal will display center RSS URL in the center display (as defined in the common service metadata).
** Portal will have top level navigation in the header for each page.
* Visualization interaction:
** Node selection:
*** When a user selects a node from the map, the portal will display a synopsis of the data for the Center drawing on the common service metadata which includes:
Name
Description
*** The portal should also display a summary of service availability or availabilities within a time period set in the portal configuration.
** Node information "drill down":
*** There should be a way to invoke a detailed display. When invoked, the geographical map and information display are replaced with an enumeration of services running at the center with accompanying service availability over a configurable time period.
*** Center level RSS is displayed.
*** The following center data from the common service metadata is displayed:
Name
Homepage URL
RSS News
Address
Contact information
Photo/image
Point of contact
Description
** Center service "drill down":
*** Selecting a service from the center display will display a service availability graph for the selected service over a configurable time period.
*** The portal will display data drawn from the common service metadata including:
Service name
Contact information
RSS News URL
*** Portal will display service functions with return types.
*** When documentation is provided for operations defined in a service WSDL, it will be displayed in the function enumeration.
* caGrid 1.0 Common Service Metadata:
** The portal will depend upon elements of the common service metadata for caGrid 1.0 as well as information accessible from the caGrid 1.0 index service. The portal will use:
*** Research Center metadata:
Name
Short name - shortened title for display on a map
Homepage URL
RSS News URL - allows for promulgation of Center wide news and announcements.
Address - a complex element type consisting of all the elements necessary to make an international address (street 1, street 2, locality, state/province, postal code, country)
Contact information
Photo/image URL
Point of contact
Description
*** Service metadata:
Name
Contact information
RSS News URL - allows promulgation of service specific news (upgrades, scheduled downtimes, etc.)
*** The portal will also require information about the freshness of data from the index server (time of update, and time to live).
* Search option:
** A "basic" search box will appear on the main page. This search box will search a subset of the fields of the caGrid 1.0 common service metadata.
*** Alphabetic search strings will constrain the search to these fields:
Research center name
Research center short name
Research center point of contact
Research center description
Service name
Service operations as defined in its WSDL
Service technical point of contact
Service functional point of contact
*** Numeric search strings will constrain the search to these fields:
Research contact numbers


h1. Design and Architecture
----
h2. Portlets
----
The main functionality of the caGrid Portal is provided by individual, JSR-168 compliant portlets. While Jetspeed is used as the portal platform, the caGrid Portal portlets do not have any dependencies on Jetspeed. The portlets that are part of the 1.1 release include:
* ServiceDiscoveryPortlet
* ServiceSelectionPortlet
* ServiceDetailsPortlet
* DataServiceQueryPortlet
* ServiceAnnotationPortlet
* MapViewPortlet
* ParticipantSearchPortlet
* ParticipantSelectionPortlet
* ParticipantDetailsPortlet

In general, the portlets are design in such a way that they can interact with one or more other portlets. Users can configure how this communication happens, effectively wiring together portlets.

The approach to inter-portlet communication (IPC) that we have chosen to use for the 1.1 release requires that they be deployed in the same web application. For the 2.0 release, we may consider a more flexible approach to IPC. The IPC mechanism is described later in this document.

h3. ServiceDiscoveryPortle
ServiceDiscoveryPortlet allows the user to enter one or more criteria which are used to discover services. The criteria that are supported are:
* Service Metadata Categories:
** service metadata keyword: will match against the textual representation of any service metadata or domain model attribute value.
** research center
** point of contact
** service name
** operation name
** operation input: UML classname of input parameter type
** operation output: UML classname of operation output
** permissible value
** domain model name: name of domain model as registered in caDSR
** classname: name of any UML class in the domain model
* Semantic Metadata Categories
** A semantic metadata search involves first querying EVS to retrieve concept codes that are associated with the given keywords. Then the concept codes are used to search against service metadata. This approach effectively enriches the search by providing concept codes that represent sub concepts that match the given keywords. The subsequent search against service metadata can be constrained to the following categories:
*** service: match against concept codes associated with the service itself
*** operation:
*** data: inputs/outputs
*** model: classes in the domain model

The results of the search are published to the user-configured session attribute.

h3. ServiceSelectionPortlet

ServiceSelectionPortlet allows the user to browse through a set of services, view status, and select a particular service upon which to perform further operations (via another portlet). For example, if the DataServiceQueryPortlet is wired to listen to the ServiceSelectionPortlet, then when the user clicks on a service in the service list of the ServiceSelectionPortlet, that service's URL will be displayed in the DataServiceQueryPortlet as the target service. (And in version 2.0, the service's data model will be displayed in the CQLQueryBuilderPortlet.)

h3. ServiceDetailsPortlet

ServiceDetailsPortlet allows the user to view and navigate through all status and metadata associated with a service. It also allows the user to select an arbitrary metadata component with which to associate/view user-provided annotations. Service metadata is rendered as an expanding/collapsing DHTML tree. Each node of the tree can have any number of user-supplied annotations. Clicking on a node will publish (via AJAX) its unique identifier to another user-configured portlet to allow addition/modification of annotations.

h3. ServiceAnnotationPortlet

ServiceAnnocationPortlet allows the user to associate additional content with any service metadata object or attribute. A service metadata object or attributes that has an associated MetadataAnnotation is represented as MetadataAnnotationTarget object.

h3. MapViewPortlet

MapViewPortlet will display any selected set of objects that have geocoordinates on a map. Those objects include services, caBIG participants, and caBIG organizations. For example, if an instance of MapViewPortlet is wired to listen to the messages that are published by ServiceDiscoveryPortlet, then all services that are returned by a search will be displayed on the map.

h3. Participant*Portlet

The Participant* portlets allow the user to search for, select, view, and (if in the appropriate role) edit information about caBIG participants. These portlets work together in manner that is similar to the way the Service* portlets interact. Participants include people and organizations.

h2. Inter-portlet Communication (IPC)
----
Portlets communicate with one another by sending/receive messages to/from logical topics. The input and output messages of a portlet are declared as portlet preferences in portlet.xml. Each input message is mapped to a "source" topic. Each output message is mapped to one or more "publish" topics. Defining messages and topics as portlet preferences enables the user to wire together portlets to suit his needs.

Three portlet preferences are required to map an input or output message to a queue. The mapping is achieved through a simple naming convention. An example will illustrate:
{code}
...
<preference>
<name>MsgInput1Name</name>
<value>sgsId</value>
</preference>
<preference>
<name>MsgInput1SourceName</name>
<value>selectedGridService</value>
</preference>
<preference>
<name>MsgInput1SourceNamespace</name>
<value>gs</value>
</preference>
...
{code}

In this case, the local message name "sgsId" is mapped to the queue "gs:selectedGridService".

If a portlet needed to publish this message to multiple other portlets, the following declaration would be used:
{code}
\\
...
<preference>
<name>MsgOutput1Name</name>
<value>sgsId</value>
</preference>
<preference>
<name>MsgOutput1PublishName1</name>
<value>selectedGridServiceId</value>
</preference>
<preference>
<name>MsgOutput1PublishNamespace1</name>
<value>gs</value>
</preference>
<preference>
<name>MsgOutput2Name</name>
<value>sgsId</value>
</preference>
<preference>
<name>MsgOutput1PublishName1</name>
<value>theGridServiceId</value>
</preference>
<preference>
<name>MsgOutput1PublishNamespace1</name>
<value>xs</value>
</preference>
...
{code}
The implementation that we are currently using maintains topics in the PortletSession (see [here|http://www.doc.ic.ac.uk/~mo197/portlets/portlet_messaging/] for more information). However, to enable IPC via AJAX or to enable IPC among portlets that are deployed in different web applications, we may switch to an implementation that maintains topics in a database.

h2. Security
----
h3. Authentication

Most of the functionality provided by the caGrid Portal portlets does not require that the user be authenticated. The default configuration of the main portal pages will enable portlets to interact in a way that makes sense. However, in order for a user to be able to customize a portal page, by adding/removing/wiring portlets, she must authenticate, so that the state of portlets and portal pages may be associated with some persistent identity.

In order to interact with secure services, the user must provide grid credentials. So, the portal must be able to accommodate two types of users: local and grid. These two type of users are represented by the PortalUser and GridPortalUser classes in the portal domain model, respectively.

Typically, authentication is the responsibility the enterprise portal. Jetspeed's security model is based on JAAS and supports authentication through LDAP or an RDBMS. However, in order to avoid dependency on a particular portal platform and to accommodate caGrid/PKI-based authentication, caGrid Portal does not utilize Jetspeed's built-in authentication mechanisms. Instead, caGrid Portal authentication is delegated to a separate web application, using a SSO-style interaction.

caGrid Portal authentication is achieved through the interaction of three components: the "GridSecurityValve" custom Jetspeed valve, the "authn" web application, and the "WebAuthnSvc" grid service. The GridServiceValve valve intercepts portal requests and, if necessary, redirects the user agent to the authn web application. The authn web application provides a GUI to the WebAuthnSvc service and is responsible for maintaining browser-based, SSO sessions. The WebAuthnSvc service manages persistence of local user accounts and interacts with with caGrid identity providers (IdPs).

The GridSecurityValve can be configured to require all users to be authenticated before viewing any portal page. This is called "forceLogin" mode. Or, it can be configured to force authentication only when requested. The latter configuration is the default.

Following is a description of the authentication process for a grid user.

The GridServiceValve is not in forceLogin mode. The user clicks the login link on a portal page. This link includes the forceLogin request parameter which indicates that the user should be authenticated. The GridSecurityValve attempts to retrieve the JAAS subject from the session. If subject is present, it will also try to retrieve the user's grid credentials from the session. If the subject and grid credentials are present, but the grid credentials are not valid (e.g. they are expired), the user is redirected to the authn web application. If the subject and grid credentials are present, and the credentials are valid, request processing continues.

If the subject is not present in the session, then the user has either not yet authenticated or is being redirected back to the portal from the authn web application. In the former case, if the GridServiceValve is in forceLogin mode, then the user agent will be redirected to the authn web application. Otherwise, request processing will continue. In the latter case, then there will be a login key parameter in the request which indicates that the user is being redirected from the authn web application. The use of the login key is explained later in this section.

In this scenario, the subject is not present and the request includes the forceLogin parameter, so the user is redirected to the authn web application. The authn web application. The LoginController of the authn web application first checks to see if the user has already established a SSO session by attempting to retrieve a PortalUser object from the session. If the PortalUser object is found, then a login key is generated (more about that later). If the request also includes the targetUrl parameter (which is the URL of the portal), then the user is redirected back to the portal, and the login key is included in the request. If the targetUrl parameter is not present, then a login success page is displayed to the user. If the PortalUser object is not found in the session, then the user is given the option to login as a local user, login as a grid user, or register for an account.

The user chooses to login as a grid user, and a page is displayed in which the user specifies his username, password, and selects the IdP that should be used to authenticate him. When the user clicks submit, the GridLoginController calls the createLoginKeyForGridUser operation of the WebAuthnSvc grid service. This operation takes the URL of the selected IdP and a BasicCredential object, which includes the username and password.

The WebAuthnSvc calls out to the specified IdP to retrieve a SAML assertion of the user's identity. If successful, the WebAuthnSvc will create a UserInfoType object that will include the user's username, roles, and the SAML assertion. The user's username will be the email address found in the SAML assertion, not the username that the user provided. If a local account for the user already exists, then the roles associated with that account are used. Otherwise, a new local account is created and the default roles are applied. WebAuthSvc generates a random number and associates the UserInfoType object with that number. The random number is returned to the callers as the loginKey. This loginKey can be used only once to retrieve the corresponding UserInfoType object.

Once the call to WebAuthnSvc has returned successfully, GridLoginController creates the GridPortalUser object and puts it in the session. It then forwards to LoginController. LoginController find the user object in the session and also a targetUrl, so it redirects the user's browser back to the portal.

Now the request to the portal includes a loginKey. GridSecurityValve detects that there is no JAAS subject in the session, but there is a loginKey. So, it calls the getUserInfo operation of WebAuthnSvc to retrieve the UserInfoType object associated with the loginKey. It then uses the SAML found in that UserInfoType object to retrieve grid credentials from Dorian. Once the grid credentials are validated, the user is considered authenticated.

The grid credentials are stored in the session where they are available to portlets that need to interact with secure services. The username and roles found in the UserInfoType object are used to populate the JAAS subject and store it in the session.

h3. Authorization

CaGrid Portal uses JAAS authorization, which is the default authorization mechanism supported by Jetspeed. A description of this model can be found [here|http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/atz-jaas.html]

h2. Tasks
----
CaGrid Portal uses various background processes. These processes are referred to here as tasks.

Tasks are managed by Spring. They are created in the singleton scope of a Spring application context that is deployed as part of the cagridportlets web application. Therefore, the tasks are running whenever the cagridportlets web application is in a deployed state.

h3. IndexServiceMonitor

The IndexServiceMonitor monitors a configured set of index services, and the grid services that are registered to those index services. It is responsible for determining a) when new services appear, b) when the metadata associated with a service changes, and c) when the state (i.e. up or down) of a service changes. When any of these events occurs, the IndedServiceListener publishes a corresponding event to the Spring application context.

h3. RegisteredServiceListener

The RegisteredServiceListener task listens for RegisteredServiceEvent events. It is responsible for interacting with the DAO layer to persist the initial state of a newly registered service.

h3. ServiceStateChangeListener

The ServiceStateChangeListener task listens for ServiceStateChangeEvent events. It is responsible for interacting with the DAO layer to update the statistics associated with a service over time.

h3. ServiceMetadataChangeListener

The ServiceMetadataChangeListener task listens for ServiceMetadataChangeEvents. It is responsible for updating the persisted service metadata.

h3. TrustSynchronizer

The TrustSynchronizer task is responsible for periodically synchronizing the local trust store with the trust fabric.

h2. Service
----
The service layer defines a high-level API for managing the portal domain model. Method calls to objects in the service layer are wrapped in database transactions.

h2. Persistence
----
Data access objects (DAOs) are defined in the persistence layer. They provide a thin abstraction over the persistence strategy. Each major entity defined in the portal domain model has a corresponding DAO. DAOs are not transactional. Transactions are scoped to service-level operations. The Spring @Transactional annotation is used to declare service objects as transactional.

Hibernate is used as the persistence strategy. EJB3/JPA Annotations are used to configure the object-relational mappings. In order enable lazy-loading of associated objects while rendering views in the presentation layer, the Spring OpenSessionInView interceptor is used. This interceptor is included in the list of interceptors that are defined in the HandlerMapping bean definitions for each portlet.

Hibernate Search is used to provide integration with Lucene to enable indexed searches.

h1. References
----
h2. caGrid References
----
# Monitoring and Discovery Portal Enterprise Architect Project [GForge SCM Link|http://gforge.nci.nih.gov/plugins/scmcvs/cvsweb.php/cagrid-1-0/caGrid/projects/portal/docs/project/Portal.EAP?cvsroot=cagrid-1-0;f=h;ln=1]
# caGrid 1.0 Gforge website [http://gforge.nci.nih.gov/projects/cagrid-1-0/]
# caGrid Homepage [https://cabig.nci.nih.gov/workspaces/Architecture/caGrid/]

h2. Technical Manuals/Articles
----
# Java Timer Tasks [http://java.sun.com/j2se/1.3/docs/api/java/util/TimerTask.html]
# Spring framework [http://www.springframework.org/]
# Java Bean Specification: [http://java.sun.com/products/javabeans/docs/spec.html]
# Foundations of Object-Relational Mapping: [http://www.chimu.com/publications/objectRelational/]
# Object-Relational Mapping articles and products: [http://www.service-architecture.com/object-relational-mapping/]
# Hibernate Reference Documentation: [http://www.hibernate.org/hib_docs/reference/en/html]
# Basic O/R Mapping: [http://www.hibernate.org/hib_docs/reference/en/html/mapping.html]
# Java Programming: [http://java.sun.com/learning/new2java/index.html]
# Javadoc tool: [http://java.sun.com/j2se/javadoc/]
# JUnit: [http://junit.sourceforge.net/]
# Extensible Markup Language: [http://www.w3.org/TR/REC-xml/]

h2. caBIG Material
----
# *caBIG:* [http://cabig.nci.nih.gov/]
# *caBIG Compatibility Guidelines*: [http://cabig.nci.nih.gov/guidelines_documentation]

h2. caCORE Material
----
# *caCORE:* [http://ncicb.nci.nih.gov/core]
# *caBIO:* [http://ncicb.nci.nih.gov/core/caBIO]
# *caDSR:* [http://ncicb.nci.nih.gov/core/caDSR]
# *EVS:* [http://ncicb.nci.nih.gov/core/EVS]
# *CSM:* [http://ncicb.nci.nih.gov/core/CSM]

h1.Glossary
----
||Term||Definition||
|API|Application Programming Interface|
|caArray|cancer Array Informatics|
|caBIG|cancer Biomedical Informatics Grid|
|caBIO|Cancer Bioinformatics Infrastructure Objects|
|caCORE|cancer Common Ontologic Representation Environment|
|caDSR|Cancer Data Standards Repository|
|caMOD|Cancer Models Database |
|cardinality|Cardinality describes the minimum and maximum number of associated objects within a set|
|CDE|Common Data Element|
|CGAP|Cancer Genome Anatomy Project|
|CMAP|Cancer Molecular Analysis Project|
|CN|Common Name |
|CS|Classification Scheme|
|CSI|Classification Scheme Item|
|CSM|Common Security Module|
|CTEP|Cancer Therapy Evaluation Program|
|CUI|Concept Unique Identifier|
|CVS|Concurrent Versions System|
|DAML|DARPA Agent Markup Language|
|DAO|Data Access Objects|
|DARPA|Defense Advanced Research Projects Agency|
|DAS|Distributed Annotation System|
|DL|Description Logic|
|EA|Enterprise Architect|
|EBI|European Bioinformatics Institute|
|EVS|Enterprise Vocabulary Services|
|GAI|CGAP Genetic Annotation Initiative|
|GEDP|Gene Expression Data Portal|
|GIS|Geographical Information System|
|HIPPA|Health Insurance Portability and Accountability Act|
|HLGT|High Level Group Term|
|HLT|High Level Term|
|HTTP|Hypertext Transfer Protocol|
|ISO|International Organization for Standardization|
|JAAS|Java Authentication and Authorization Service|
|JAR|Java Archive|
|Javadoc|Tool for generating API documentation in HTML format from doc comments in source code ([http://java.sun.com/j2se/javadoc/])|
|JDBC|Java Database Connectivity|
|JET|Java Emitter Templates|
|JMI|Java Metadata Interface|
|JSP|JavaServer Pages|
|JUnit|A simple framework to write repeatable tests [http://junit.sourceforge.net/]|
|JSF|Java Server Faces|
|LDAP|Lightweight Directory Access Protocol |
|LLT|Lowest Level Term|
|LOINC|Logical Observation Identifier Names and Codes|
|MAGE|MicroArray and Gene Expression|
|MAGE-OM|MicroArray Gene Expression - Object Model|
|MedDRA|Medical Dictionary for Regulatory Activities|
|metadata|Definitional data that provides information about or documentation of other data.|
|MGED|Microarray Gene Expression Data|
|MMHCC|Mouse Models of Human Cancers Consortium|
|MO|MGED Ontology|
|multiplicity|Multiplicity of an association end indicates the number of objects of the class on that end may be associated with a single object of the class on the other end|
|NCI|National Cancer Institute|
|NCICB|National Cancer Institute Center for Bioinformatics|
|OIL|Ontology Inference Layer|
|OilEd|Ontology editor allowing you to build ontologies using DAML+OIL|
|OLLT|Obsolete Lower Level Terms|
|OMG|Object Management Group|
|ORM|Object Relational Mapping|
|PT|Preferred Term|
|RDBMS|Relational Database Management System|
|SDK|Software Development Kit|
|Semantic connector|A development kit to link model elements to NCICB EVS concepts.|
|SOC|System Organ Class|
|SPORE|Specialized Programs of Research |
|SQL|Structured Query Language|
|SSC|Special Search Categories|
|UI|User Interface|
|UID|User Identification|
|UML|Unified Modeling Language|
|UMLS|Unified Medical Language System|
|UPT|User Provisioning Tool|
|URL|Uniform Resource Locators|
|VD|Value Domain|
|WAR|Web Application Archive|
|WSDL|Web Services Description Language|
|XML|Extensible Markup Language ([http://www.w3.org/TR/REC-xml/]) - XML is a subset of Standard Generalized Markup Language (SGML). Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML|