HAI Use Case: Limit response size for non-authenticated users: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary
No edit summary
Line 12: Line 12:


== Actors ==
== Actors ==
<font size="-2" color="green">''List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary actor and briefly describe role.''</font>
* User
* Hyrax


== Preconditions ==
== Preconditions ==
<font size="-2" color="green">''Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about other systems can also be stated here, for example, weather conditions. List all preconditions.''</font>
A user wants to access data held at a running Hyrax sever.


== Triggers ==
== Triggers ==
<font size="-2" color="green">''Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.''</font>
A user attempts to access data held at a running Hyrax server.
 


== Basic Flow ==
== Basic Flow ==
<font size="-2" color="green">''Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)''</font>
# The user makes a data request of a Hyrax server.
# The server receives the request.
# The server checks to see if the user is authenticated and determines that the user is not authenticated.
# The server calculates the size of the requested data object.
# The server compares the size of the requested data object to a threshold value.
# The
 


== Alternate Flow ==
== Alternate Flow ==

Revision as of 17:08, 16 November 2010

Point Of Contact: Nathan Potter

Description

Limit data response sizes.

Goal

Reduce server loading by limiting response sizes for non-authenticated users. This limitation may be extended to authenticated users in certain roles in the future.

Summary

When a user makes a data request the server check to see if they are authenticated. If they are not then a quick calculation is made to determine the size of the response and if the requested data object is larger than a configurable threshold then the server will return a response object with an error and instructions on how to limit the response size.

Actors

  • User
  • Hyrax

Preconditions

A user wants to access data held at a running Hyrax sever.

Triggers

A user attempts to access data held at a running Hyrax server.


Basic Flow

  1. The user makes a data request of a Hyrax server.
  2. The server receives the request.
  3. The server checks to see if the user is authenticated and determines that the user is not authenticated.
  4. The server calculates the size of the requested data object.
  5. The server compares the size of the requested data object to a threshold value.
  6. The


Alternate Flow

Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.

Post Conditions

Here we give any conditions that will be true of the state of the system after the use case has been completed.

Activity Diagram

Here a diagram is given to show the flow of events that surrounds the use case.

Notes

There is always some piece of information that is required that has no other place to go. This is the place for that information.

Resources

In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include data and services, and the systems that offer them. This section will call out examples of these resources.


Resource Owner Description Availability Source System
name Organization that owns/ manages resource Short description of the resource How often the resource is available Name of system which provides resource