This page will grow for a while as architecture issues are clarified and decided. Check it regularly through week "10.5". There may be some last-minute interface and architecture changes based on what happens in the preliminary integration test in class on week 10. Any such changes will be publicized by 11:59pm on the Thursday between weeks 10 and 11. The architecture and interfaces will be frozen after that.

• Processes
• Responsibilities
• Deployment
• Java EE applications and technologies
• Processing flow for major scenarios

Back to top

Processes

A working DiNo system involves up to four types of processes. These processes are shown as packages in the diagram, with dependencies that demonstrate the uses relationship. For our purposes, there will be one instance of the directory service and multiple instances of notebook servers and clients. A more-robust implementation might include a second copy of the directory service for availability and/or load balancing, but we will not implement that in order to keep the complexity of the project under (some) control.

Back to top

Responsibilities

A summary of the responsibilities of the four types of DiNo processes is as follows:

• Directory service

  • Assign notebook IDs

  • Ensure uniqueness of notebook IDs

  • Enforce uniqueness of notebook titles

  • Maintain the association between notebooks and their primary servers

• Notebook service

  • Interact with the directory service to

    • get a notebook ID for a new notebook

    • remove a notebook from the system when it is deleted

    • get the complete list of notebooks, when requested by a client

  • Manage notes

  • Respond to clients' requests for notes

  • Participate in keeping secondary copies, if any, up-to-date

  • When necessary, forward client requests to the primary copy of a notebook

• Notebook client

  • Make notebook-level management requests (create, delete)

  • Make note-level management requests (create, update, delete)

  • Retrieve whole notebooks

  • Retrieve individual notes

  • Retrieve the complete list of notebooks

• Administrative client

  • Request creation and deletion of secondary copies of notebooks

  • Configure directory service URLs

  • If necessary, make any of the requests that can be made by the Notebook client

A "server" is an instance of a service. A computer can host multiple DiNo servers. Notebook servers host primary and secondary copies of notebooks. A notebook must always have a primary copy, which must be created first, before any secondary copies. A notebook can have zero or more secondary copies. A DiNo system can have many notebook servers. Different notebooks may have their primary copies hosted on different servers. The quality attribute table defines capacity targets such as maximum servers in the system.

The notebook client and administrative client are different in principle, but in practice, any process that can make HTTP requests can act as a notebook client or administrative client. We will use the same client programs (RESTful client, test suite, or shell scripts that use curl or wget) for all types of client requests.

In general, the directory service is responsible for anything that requires knowledge of the complete set of notebooks in the system. A notebook server only knows about the notebooks for which it hosts a primary or secondary copy. The directory server is the only server with knowledge of the complete list of notebooks in the system.

Clients interact directly with notebook servers, never with the directory service.

Back to top

Deployment

There can be many notebook servers in the system. A "notebook server" is a running instance of the notebook service.

Your software should be packaged so that all of your notebook servers can run on separate hosts, or all on the same host.

Every instance of the notebook or directory service will be deployed in Glassfish.

A host computer is part of the DiNo system if at least one instance of the notebook and/or directory service running on it.

Back to top

Java EE applications and technologies

Directory service

• enterprise application

• technologies: EJB, JNDI

Notebook service

• web application, implementing a RESTful interface for clients

• technologies: Servlets, JNDI

• You may need to expand this list when you design support for secondary copies

Clients

• any technology that can call a RESTful web service

Back to top

Processing flow for major scenarios

In the diagrams in this section, a process labeled "Client" could be either a NotebookClient or an AdminClient. The client is shown as "AdminClient" in diagrams for scenarios that are expected to be performed only by AdminClients. Currently, creation and deletion of secondary copies are the only such scenarios.

Create a notebook:

Create a secondary copy of a notebook:

There is no diagram for this scenario, because your team will be responsible for designing support for secondary copies of notebooks.

Create a note:

Replace note:

Delete note:

Delete a notebook:

Operation via some other server:

Back to top