Page History

...

• Application Service Layer - accepts incoming requests from all public interfaces and translates them, as required, to Java calls in terms of the native LexEVS API. Non-SDK queries are invoked against the Distributed LexEVS API, which handles client authentication and acts as proxy to invoke the equivalent function against the LexEVS core Java API. The caGrid and SDK-generated services are optionally run in an application server separate from the Distributed LexEVS API.
  
  The LexEVS caCORE SDK services work directly against the database, via Hibernate bindings, to resolve stored objects without intermediate translation of calls in terms of the LexEVS API. However, the LexEVS SDK services do still require access to metadata and security information stored by the Distributed and Core LexEVS API environment to resolve the specific database location for requested objects and to verify access to protected resources, respectively.
  From the client prospective, the LexEVS services will function as "ports" accessible through the caGrid service architectural model. LexEVS services will follow the caGrid architecture for analytical and data services. See the caGrid documentation for architectural details.
  
  
• Core API Layer - underpins all LexEVS API requests. Search of pre-populated Lucene index files is used to evaluate query results before incurring cost of database access. Access to the LexGrid database is performed as required to populate returned objects using pooled connections.
  
  
• Data Source Layer - is responsible for storage and access to all data required to represent the objects returned through API invocation.

...

The following figure shows the caGrid Hosting Environment. The Hosting Environment comprises the LexBIG Service which comprises the Service metadata, Query Service, Service Manager, and Extensions. A Service Discovery points to the Service Metadata component.

The LexBIG architecture provides the underpinnings LexBIG services to be made accessible through the caGRID environment in the future, where LexBIG services might optionally be deployed in a caGRID Globus container. caGrid provides a Globus service for service registration and discovery. LexBIG services deployed to the grid would be registered in the NCICB registry and be searchable through the NCICB index service.

Additional specifications related to the registration and discovery of LexBIG services in the caGRID environment will be included later phases of work in accordance with caGRID 1.0.

Service Management Subsystem

...

In addition, each LexBIGService provides a centralized metadata index that allows registration and query of code system metadata without requiring resolution of individual CodingSchemes. This metadata index is optionally populated, typically during the vocabulary load process. The metadata index allows for the metadata of multiple code systems to be cross-indexed and searched as part of the query subsystem.Finally, the LexBIG architecture provides the underpinnings for LexBIG services to be made accessible through the caGRID environment in the future, where vocabulary services might be deployed and discovered within a caGRID Globus container. However, this portion of the API is preliminary and awaits recommendations on future design priorities.

Query Subsystem

The following figure shows the Query Subsystem.

...