NCBO-OOR Architecture - Revision history

Benjamindai: /* Consolidating the Bioportal back-end */

2009-02-19T19:28:25Z

Consolidating the Bioportal back-end

Benjamindai: /* Consolidating the Bioportal back-end */

2009-02-19T19:27:33Z

Consolidating the Bioportal back-end

Benjamindai: /* Consolidating the Bioportal back-end */

2009-02-19T19:25:53Z

Consolidating the Bioportal back-end

Benjamindai at 00:35, 10 February 2009

2009-02-10T00:35:58Z

Benjamindai at 22:47, 9 February 2009

2009-02-09T22:47:20Z

Benjamindai at 22:37, 9 February 2009

2009-02-09T22:37:34Z

Benjamindai at 22:36, 9 February 2009

2009-02-09T22:36:29Z

Benjamindai at 22:35, 9 February 2009

2009-02-09T22:35:48Z

Benjamindai at 22:28, 9 February 2009

2009-02-09T22:28:39Z

Benjamindai at 22:27, 9 February 2009

2009-02-09T22:27:21Z

← Older revision		Revision as of 19:28, 19 February 2009
Line 14:		Line 14:
	While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.		While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.

−	With this in mind, adding, removing, and changing back-ends to the BioPortal is entirely customizable and adjustable by design. The server-side architecture leverages the principles of aspect-oriented programming. Thus, the majority of server-side component in the BioPortal can be more easily modified to meet the needs of OOR.	+	With this in mind, adding, removing, and changing back-ends to the BioPortal is entirely customizable and adjustable by design. The server-side architecture leverages the principles of aspect-oriented programming. Thus, the majority of server-side component in the BioPortal can be more easily modified to meet the needs of OOR. Please see the [[NCBO-OOR Server-Side Customization]] page for descriptions and examples how this customization can be done.

← Older revision		Revision as of 19:27, 19 February 2009
Line 14:		Line 14:
	While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.		While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.

−	With this in mind, adding, removing, and changing back-ends to the BioPortal is ~~modular~~ by design. The server-side architecture ~~implicitly is based on~~ the ~~principle~~ of aspect-oriented programming. Thus, the majority of server-side component in the BioPortal can be modified to meet the needs of OOR.	+	With this in mind, adding, removing, and changing back-ends to the BioPortal is entirely customizable and adjustable by design. The server-side architecture leverages the principles of aspect-oriented programming. Thus, the majority of server-side component in the BioPortal can be more easily modified to meet the needs of OOR.

← Older revision		Revision as of 19:25, 19 February 2009
Line 13:		Line 13:
	=Consolidating the Bioportal back-end=		=Consolidating the Bioportal back-end=
	While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.		While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.
		+
		+	With this in mind, adding, removing, and changing back-ends to the BioPortal is modular by design. The server-side architecture implicitly is based on the principle of aspect-oriented programming. Thus, the majority of server-side component in the BioPortal can be modified to meet the needs of OOR.

← Older revision		Revision as of 00:35, 10 February 2009
Line 12:		Line 12:

	=Consolidating the Bioportal back-end=		=Consolidating the Bioportal back-end=
−	While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized and native OWL/RDF ~~stores~~ in collaboration between Stanford University and Mayo Clinic.	+	While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized store and native OWL/RDF triple store in collaboration between Stanford University and Mayo Clinic.

← Older revision		Revision as of 22:47, 9 February 2009
Line 7:		Line 7:
	The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries). Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services. In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes. For example, one could implement a completely different UI than that currently exposed by the BioPortal. Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all. Please see [[NCBO_REST_services \| NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.		The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries). Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services. In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes. For example, one could implement a completely different UI than that currently exposed by the BioPortal. Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all. Please see [[NCBO_REST_services \| NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.

−	The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced. [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur. ~~At this~~ time, all OWL and ~~Protege~~ ontologies ~~are delegated~~ to ~~Protege~~ for ~~storage, parsing~~, and ~~exploration~~. All ~~other ontologies and controlled vocabularies~~ (e.g., ~~OBO~~ and RRF~~) are delegated~~ to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized and native OWL/RDF stores in collaboration between Stanford University and Mayo Clinic.	+	The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced. [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur.
		+
		+	The ''Persistence Tier'' uses the Hibernate technology as a basic object-relational mapping to the back-end relational database. Hibernate is used for storing administrative (e.g., user information) and external ontology data (e.g., ontology attributes specified at upload time). All ontology content is stored in Protege and LexGrid as shown in the ''Business Logic'' layer.
		+
		+	=Consolidating the Bioportal back-end=
		+	While architecturally it is preferable to have a single ontology/terminology back-end repository to reduce complexity, no single repository meets all NCBO requirements. The NCBO must support the OWL language and RDF/XML, OBO, RDF and RRF formats. As shown in the diagram, Protégé 3.x has been incorporated into the business-logic layer to enable full support of OWL ontologies and the capability to store ontology based meta-data, mappings, and marginal notes. LexGrid continues to support the diverse terminology formats required by NCBO (e.g., the RRF format used for UMLS is particularly critical). As shown in the above diagram, the combination of LexGrid and Protégé jointly provide sufficient support for the diverse standards and formats. All OWL ontology requests (e.g., get concept, find concept, and upload) will be routed to Protégé. All other ontology/terminology requests such as RRF and OBO will be routed to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized and native OWL/RDF stores in collaboration between Stanford University and Mayo Clinic.

← Older revision		Revision as of 22:37, 9 February 2009
Line 1:		Line 1:
−	The NCBO-OOR architecture (essentially the NCBO BioPortal architecture) uses a classic architecture layered approach, which decouples the logic and domain object models between each layer. This approach decouples the versioning and changes in one layer from another. Thus, as software modules evolve (which they always do), the impact on the rest of the software sub-systems is significantly reduced. Furthermore, the BioPortal enforces de-coupling through web services (e.g., REST and SOAP) and the enterprise pattern of “Dependency Injection.” Note that Protégé 3.x has been incorporated into business logic layer (in addition to pre-existing LexGrid) to enable full support of OWL ontologies and the capability to store ontology based meta data, mappings, and marginal notes. The following diagram presents a simple overview of the ~~four~~ layers in the BioPortal architecture followed by a description of each ~~layer~~.	+	The NCBO-OOR architecture (essentially the NCBO BioPortal architecture) uses a classic architecture layered approach, which decouples the logic and domain object models between each layer. This approach decouples the versioning and changes in one layer from another. Thus, as software modules evolve (which they always do), the impact on the rest of the software sub-systems is significantly reduced. Furthermore, the BioPortal enforces de-coupling through web services (e.g., REST and SOAP) and the enterprise pattern of “Dependency Injection.” Note that Protégé 3.x has been incorporated into business logic layer (in addition to pre-existing LexGrid) to enable full support of OWL ontologies and the capability to store ontology based meta data, mappings, and marginal notes. The following diagram presents a simple overview of the layers in the BioPortal architecture followed by a description of each.

	[[Image:BP Simple Layered Diagram.jpg\|frame\|center\|200x\|\|\|]]		[[Image:BP Simple Layered Diagram.jpg\|frame\|center\|200x\|\|\|]]

← Older revision		Revision as of 22:36, 9 February 2009
Line 7:		Line 7:
	The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries). Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services. In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes. For example, one could implement a completely different UI than that currently exposed by the BioPortal. Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all. Please see [[NCBO_REST_services \| NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.		The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries). Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services. In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes. For example, one could implement a completely different UI than that currently exposed by the BioPortal. Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all. Please see [[NCBO_REST_services \| NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.

−	The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced. [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur. At this time, all OWL and Protege ontologies are delegated to Protege for storage, parsing, and exploration. All other ontologies and controlled vocabularies (e.g., OBO and RRF) are delegated to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both ~~Normalized~~ and ~~Native~~ OWL/RDF stores in collaboration between Stanford University and Mayo Clinic.	+	The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced. [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur. At this time, all OWL and Protege ontologies are delegated to Protege for storage, parsing, and exploration. All other ontologies and controlled vocabularies (e.g., OBO and RRF) are delegated to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both normalized and native OWL/RDF stores in collaboration between Stanford University and Mayo Clinic.

← Older revision		Revision as of 22:35, 9 February 2009
Line 7:		Line 7:
	The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries). Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services. In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes. For example, one could implement a completely different UI than that currently exposed by the BioPortal. Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all. Please see [[NCBO_REST_services \| NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.		The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc). The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries). Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services. In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes. For example, one could implement a completely different UI than that currently exposed by the BioPortal. Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all. Please see [[NCBO_REST_services \| NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.

−	The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced. [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur	+	The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces. This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework. For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software. This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration. The need to do a major BioPortal software release to support a customized implementation is significantly reduced. [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur. At this time, all OWL and Protege ontologies are delegated to Protege for storage, parsing, and exploration. All other ontologies and controlled vocabularies (e.g., OBO and RRF) are delegated to LexGrid. Long-term, the NCBO plans to rearchitect the BioPortal to leverage both Normalized and Native OWL/RDF stores in collaboration between Stanford University and Mayo Clinic.

@@ Line 5: / Line 5: @@
 The ''Presentation Tier'' delivers the BioPortal user-interface which currently uses the Ruby on Rails technology.  Ruby on Rails is a leading mature UI framework supported by large software development communities.  It enables rapid prototyping as well as solid integration with web services.
-The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc).  The Presentation Tier will be solely driven by the REST services (currently implemented with RESTlet libraries and possible migration to NetKernel).  Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services.  In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes.  For example, one could implement a completely different UI than that currently exposed by the BioPortal.  Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all.  Please see [[NCBO_REST_services | NCBO REST Services]] documentation to learn about consuming the BioPortal services.
+The ''Interface Tier'' consists of both REST and SOAP web services that present all BioPortal capabilities to the upper tiers (e.g., upload ontology, download ontology, display concept, administrative functions, etc).  The Presentation Tier is primarly driven by the REST services (currently implemented with RESTlet libraries).  Thus, the BioPortal Presentation Tier is just one vanilla consumer of the BioPortal REST services.  In the principle of Service-Oriented Architecture, any number of partner developers could consume the set of existing REST services for any number of purposes.  For example, one could implement a completely different UI than that currently exposed by the BioPortal.  Or, one could simply want to consume a single REST services for integrating into a back-end workflow with no UI at all.  Please see [[NCBO_REST_services | NCBO REST Services]] documentation to learn about consuming the BioPortal REST services.
 The ''Business Logic Tier'' uses the Spring technology which enables a partner to insert any software implementation that abides to the NCBO-defined interfaces.  This is achieved through the “Dependency Injection” enterprise pattern which is core to the Spring framework.  For example, if NCI requires use of a different flavor of LexGrid, a module could be easily implemented by NCI using the NCBO interfaces and deployed without having to modify the core BioPortal software.  This architectural approach enables incorporation of new capability into the BioPortal through packaging and configuration.  The need to do a major BioPortal software release to support a customized implementation is significantly reduced.  [[NCBO-OOR Server-Side Customization]] provides further details how such a customization can occur

@@ Line 1: / Line 1: @@
-The NCBO-OOR architecture (essentially the NCBO BioPortal architecture) uses a classic architecture layered approach, which decouples the logic and domain object models between each layer.  This approach decouples the versioning and changes in one layer from another.  Thus, as software modules evolve (which they always do), the impact on the rest of the software sub-systems is significantly reduced.  Furthermore, the BioPortal enforces de-coupling through web services (e.g., REST and SOAP) and the enterprise pattern of “Dependency Injection.”  Note that Protégé 3.x has been incorporated into business logic layer (in addition to pre-existing LexGrid) to enable full support of OWL ontologies and the capability to store ontology based meta data, mappings, and marginal notes.
+The NCBO-OOR architecture (essentially the NCBO BioPortal architecture) uses a classic architecture layered approach, which decouples the logic and domain object models between each layer.  This approach decouples the versioning and changes in one layer from another.  Thus, as software modules evolve (which they always do), the impact on the rest of the software sub-systems is significantly reduced.  Furthermore, the BioPortal enforces de-coupling through web services (e.g., REST and SOAP) and the enterprise pattern of “Dependency Injection.”  Note that Protégé 3.x has been incorporated into business logic layer (in addition to pre-existing LexGrid) to enable full support of OWL ontologies and the capability to store ontology based meta data, mappings, and marginal notes.  The following diagram presents a simple overview of the four layers in the BioPortal architecture followed by a description of each layer.
 [[Image:BP Simple Layered Diagram.jpg|frame|center|200x|||]]
 The ''Presentation Tier'' delivers the BioPortal user-interface which currently uses the Ruby on Rails technology.  Ruby on Rails is a leading mature UI framework supported by large software development communities.  It enables rapid prototyping as well as solid integration with web services.