Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OSEE/Design/OseeApplicationServer/Architecture"

(Reasons For refactor)
(Migration)
 
(6 intermediate revisions by the same user not shown)
Line 37: Line 37:
  
 
= Architecture Goal =
 
= Architecture Goal =
 +
 +
= Communication =
  
 
= Blocks =
 
= Blocks =
Line 43: Line 45:
  
 
# Need a controller to dispatch all operations - sends  
 
# Need a controller to dispatch all operations - sends  
 +
 +
* Services:
 +
** Status Service - who is running what - multi app server / internal - potential progress monitoring
 +
** Negotiation Service - synchronization of operations
 +
** Executor Service - manages thread pools/jobs -
 +
***only one allowed to create threads.
 +
***only one allowed to run the operation.
 +
 +
** All other services send/receive messages (dispatchers)
 +
** Operations send/receive messages
 +
 +
* Bundle:
 +
** Versioning Bundle
 +
*** Commit
 +
*** Create Branch
 +
*** Change Report
 +
***
 +
*** Branch Exchange
 +
 +
 +
 +
== Migration ==
 +
 +
*Commit -
 +
*Change Report -
 +
*Transaction Manager -
 +
*Branch Archiving -
 +
*Status Service -
 +
*Conflict -
 +
*Executor Service -
  
 
[[Category:OSEE]]
 
[[Category:OSEE]]

Latest revision as of 17:57, 9 November 2009

OSEE Application Server Architecture

Currently, the OSEE application server is divided into the following services:

  • Branch Management
  • Authentication
  • Session Management
  • Resource Management
  • Searching/Tagging Engine
  • Server Lookup / Arbitration
  • Task Service
  • Admin Operations

Communication between Client/Server is handled via servlets:

  • Session Management Servlet - interats with session manager and authentication
  • Resource Management Servlet - interacts with resource management service to store, acquire, and delete resource data
  • Branch Management Servlet - interacts with the Branch Management Service
  • Search Engine Servlet - interacts with search and tagging services
  • Server Lookup Servlet - performs server lookup / arbitration
  • Add ons (These are servlets that provide none-core functionality) :
  • Artifact Servlet - serves artifact's binary data (only supports whole word document artifact types)
  • Client Info Servlet - provides application server installation locations through a web pagee

Design Limitations

  • Progress Information is not sent to clients
  • Unable to easily cancel operations once they are in progress
  • Unable to determine what is running on the server (communication between service)
  • Code duplication between admin ops and client requested ops
  • Database code is spread out among services

Reasons For refactor

  1. Address design limitations
  2. Change from servlet communication to using Osee Messaging Service (Gateway)
  3. Easily migrate skynet core functionality to the server
  4. Be able to synchronize operations for data integrity
  5. Multiple application servers - distributed

Architecture Goal

Communication

Blocks

New Service Structure

  1. Need a controller to dispatch all operations - sends
  • Services:
    • Status Service - who is running what - multi app server / internal - potential progress monitoring
    • Negotiation Service - synchronization of operations
    • Executor Service - manages thread pools/jobs -
      • only one allowed to create threads.
      • only one allowed to run the operation.
    • All other services send/receive messages (dispatchers)
    • Operations send/receive messages
  • Bundle:
    • Versioning Bundle
      • Commit
      • Create Branch
      • Change Report
      • Branch Exchange


Migration

  • Commit -
  • Change Report -
  • Transaction Manager -
  • Branch Archiving -
  • Status Service -
  • Conflict -
  • Executor Service -

Back to the top