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.
Difference between revisions of "OSEE/Developers Guide"
(New page: =Architecture= <p>Although there is quite a bit to understand about the Architecture of OSEE, the main thing to understand right away is that OSEE provides an Extensible Framework called ...) |
|||
| Line 1: | Line 1: | ||
| − | =Architecture= | + | =Client Architecture= |
<p>Although there is quite a bit to understand about the Architecture of OSEE, the main thing to understand right away | <p>Although there is quite a bit to understand about the Architecture of OSEE, the main thing to understand right away | ||
| Line 17: | Line 17: | ||
[[Image:OSEEArchitecture.gif]] | [[Image:OSEEArchitecture.gif]] | ||
| + | |||
| + | =Client/Server Architecture= | ||
| + | |||
| + | <p>In order to be a scalable system, the Open System Engineering Environment (OSEE) has been slowly migrating | ||
| + | into a distributed architecture where clients interact with an application server in-charge of managing access | ||
| + | to an OSEE data store. Additionally, in an effort to provide load balancing, failure recovery, and code compatibility, | ||
| + | clients consult an arbitration server before connecting to an application server. The arbitration server's responsibility | ||
| + | is to keep track of all the application servers interacting with a common data store and direct clients to a healthy | ||
| + | application server compatible with the client’s OSEE code version. In this arrangement, arbitration servers act as the | ||
| + | initial access points into the OSEE server cloud where a collection of application servers manage client requests to | ||
| + | access and operate on a common OSEE data store. Figure 1 shows an example of the OSEE Client/Server network.</p> | ||
| + | <br/> | ||
| + | [[Image:Client_server_view.png]] | ||
| + | <br/> | ||
| + | |||
| + | <p>In the figure above, three application servers interact with a single OSEE data store. The data store is comprised | ||
| + | of a relational database and a remote file system used to store binary data. It is not necessary for the database and | ||
| + | the binary data to exist on the same machine. The only requirement is that the application servers have access to both | ||
| + | resources. Upon start-up, each application server registers himself on the data store’s server lookup table by entering | ||
| + | its host address, port, supported code versions, and its unique id. When the arbitration server receives a request to find | ||
| + | an application server to support a client connection, the arbitration server reads the data store’s server lookup table and | ||
| + | selects the best match for the client. The client requests this information from the arbitration server upon start-up or | ||
| + | whenever it can’t communicate with an application server. It is important to note that the arbitration server does not have | ||
| + | to be a different server thanan application server. All application servers are able to act as an arbitration server. An | ||
| + | application server is referred as an arbitration server when clients interact with it in this context. Figure 2 depicts | ||
| + | the sequence of events involved in the arbitration process.</p> | ||
| + | <br/> | ||
| + | |||
| + | [[Image:Arbitration_sequence.png]] | ||
| + | |||
| + | <p>Once a client receives an application server's address and port information, the client must authenticate with the | ||
| + | application server before it can gain access to the OSEE data store. During the authentication process, a client | ||
| + | submits to the application server the current user's credential information and the authentication protocol id to use | ||
| + | during the process. The application server verifies the user via the selected protocol and grants access to the data | ||
| + | store by creating a session for the user. From this point forward, the application server will be responsible for | ||
| + | managing access to the data store by identifying the user via the session id. Whenever a client wants to interact | ||
| + | with the application server, it will need to submit its session id in order to gain access to the OSEE data store. | ||
| + | Figure 3 shows the sequence of events involved in the authentication process. | ||
| + | </p> | ||
| + | <br/> | ||
| + | |||
| + | [[Image:Authentication_sequence.png]] | ||
Revision as of 23:13, 20 April 2009
Client Architecture
Although there is quite a bit to understand about the Architecture of OSEE, the main thing to understand right away is that OSEE provides an Extensible Framework called the OSEE Application Framework and also provides some Exemplary Applications built on this framework in the form of OSEE Define (the Requirements Management application) and OSEE ATS (Action Tracking System; the Configuration Management application).
The Application Framework provides all the necessary services to allow the application(s) to persist and share data in a common-version controlled object database.
Just like Eclipse provides the ability to add a plugin to the existing Eclipse environment, so OSEE allows other applications to add plugins and share the common data storage.
And just like Eclipse RCP allows an application to be built and deployed using the Eclipse framework but not include all the Exemplary applications like JDT, OSEE allows an application to be built and deployed using the OSEE Application Framework without including such applications as OSEE Define and OSEE ATS.
Client/Server Architecture
In order to be a scalable system, the Open System Engineering Environment (OSEE) has been slowly migrating into a distributed architecture where clients interact with an application server in-charge of managing access to an OSEE data store. Additionally, in an effort to provide load balancing, failure recovery, and code compatibility, clients consult an arbitration server before connecting to an application server. The arbitration server's responsibility is to keep track of all the application servers interacting with a common data store and direct clients to a healthy application server compatible with the client’s OSEE code version. In this arrangement, arbitration servers act as the initial access points into the OSEE server cloud where a collection of application servers manage client requests to access and operate on a common OSEE data store. Figure 1 shows an example of the OSEE Client/Server network.
In the figure above, three application servers interact with a single OSEE data store. The data store is comprised of a relational database and a remote file system used to store binary data. It is not necessary for the database and the binary data to exist on the same machine. The only requirement is that the application servers have access to both resources. Upon start-up, each application server registers himself on the data store’s server lookup table by entering its host address, port, supported code versions, and its unique id. When the arbitration server receives a request to find an application server to support a client connection, the arbitration server reads the data store’s server lookup table and selects the best match for the client. The client requests this information from the arbitration server upon start-up or whenever it can’t communicate with an application server. It is important to note that the arbitration server does not have to be a different server thanan application server. All application servers are able to act as an arbitration server. An application server is referred as an arbitration server when clients interact with it in this context. Figure 2 depicts the sequence of events involved in the arbitration process.
Once a client receives an application server's address and port information, the client must authenticate with the application server before it can gain access to the OSEE data store. During the authentication process, a client submits to the application server the current user's credential information and the authentication protocol id to use during the process. The application server verifies the user via the selected protocol and grants access to the data store by creating a session for the user. From this point forward, the application server will be responsible for managing access to the data store by identifying the user via the session id. Whenever a client wants to interact with the application server, it will need to submit its session id in order to gain access to the OSEE data store. Figure 3 shows the sequence of events involved in the authentication process.
