Assessment Plan

Individual Project Details

Due: 18 April 2027

Grading rubric

• Details
  • An assay of at least 200 words on a topic selected from the EssayTopics list shared by the lecturer at the start of the semester.
  • A simple RESTful web service, A client and a core that will implement the CRUD operations.
• Expected outcome:
  • The source code should be hosted in your individual assignment repository on GitHub.
  • At least the following requirements should be met:
    • The server should be able to receive HTTP requests from clients using the RESTful API.
    • The server should be able to respond to client requests with the appropriate HTTP status codes (e.g. 200 OK, 404 Not Found, etc.) and a response body in JSON format.
    • The server should have a database or other data storage mechanism to persist data sent by clients.
    • The server should implement CRUD operations (create, read, update, delete) for the data stored in the database.
    • The server should handle concurrent requests from multiple clients.
    • The server should validate incoming requests to ensure that they conform to the expected format and that the data being sent is valid.
    • The client should implement the full CRUD operations.
    • The client should be able to receive responses from the server in JSON format.
    • The client should display the data received from the server in a user-friendly way.

Team Project Details

Due: 23 May 2027

Grading rubric

• Details
  • A team of two students, to tackle a bigger project.
• Expected outcome:
  • The source code should be hosted in the team assignment repository on GitHub.
  • At least the following requirements should be met:
    • The project should use web services technology (e.g. SOAP/REST) to allow clients to access the server's functionality.
    • The client should have a user-friendly interface that allows users to interact with the server's functionality, and implement at least the CRUD operations.
    • The MOM framework used should support load balancing to distribute incoming requests across multiple servers (at least two nodes should be used) to ensure that no single server becomes overloaded.
    • The MOM framework used should support failover to ensure that if one server fails, requests are automatically redirected to another available server to ensure continuous service.
    • The MOM framework used should provide message persistence to ensure that messages are not lost in the event of a server failure.
    • The MOM framework used should provide reliable message delivery to ensure that messages are delivered to their intended recipients, even in the event of a network failure or other disruption.
    • The MOM framework used should support message queuing to enable asynchronous communication between clients and servers.
    • The MOM framework used should be fully administered by the messages sent between the client and the message queue.
    • The project should be designed to scale horizontally to handle increasing numbers of clients and data volume.
    • The MOM framework used should provide security features to ensure the confidentiality, integrity, and availability of messages.
    • The project should be designed to work with existing MOM frameworks, such as Apache ActiveMQ, RabbitMQ, or KafkaMQ.

Assignments & Grading Rubrics

Every assignment is described and graded here. Read the rubric before you start, not after you submit. Click an assignment to expand it.

Essay & Presentation 3 criteria, weighteddraft, subject to change

What to do

• Choose a topic from the essay topics list shared by the lecturer and book a presentation slot in seminars 2 to 5.
• Write an essay of at least 200 words on the topic and present it during the booked seminar.

How to submit

Commit the essay as essay.md in your individual assignment repository on GitHub before your presentation seminar.

How it is graded

1. Content and accuracy 40%

   Excellent 4 points The topic is explained correctly and in depth, with concrete examples and at least two cited sources.

   Good 3 points The topic is explained correctly but stays at a general level, or has a single source.

   Fair 2 points The explanation has gaps or minor technical inaccuracies.

   Poor 0 points Off topic, under 200 words, or contains major errors.

2. Structure and writing 20%

   Excellent 4 points Clear introduction, body, and conclusion. Easy to follow, no copy-pasted passages.

   Good 3 points Structured but with some repetition or unclear paragraphs.

   Fair 2 points Weak structure; the argument is hard to follow.

   Poor 0 points No structure, or large parts are not the author's own words.

3. Presentation 40%

   Excellent 4 points Presented in the booked seminar, within time, with supporting slides or a demo, and answers questions confidently.

   Good 3 points Presented in the booked seminar but over time, or unable to answer some questions.

   Fair 2 points Presented in a different seminar than booked, or read verbatim from the essay.

   Poor 0 points Not presented.

Individual Project - RESTful Web Service 5 criteria, weighteddraft, subject to change

What to do

• A simple RESTful web service, a client, and a core that implement the CRUD operations.
• The server receives HTTP requests through a REST API and answers with proper status codes and JSON bodies.
• Data is persisted in a database or another storage mechanism. Incoming requests are validated and concurrent clients are handled.
• The client implements the full CRUD flow, reads JSON responses, and shows the data in a user-friendly way.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

1. REST API design and HTTP semantics 20%

   Excellent 4 points Resource-oriented URLs, correct verbs, and correct status codes (200, 201, 204, 400, 404, 409) for every operation. JSON in and out.

   Good 3 points Correct verbs and JSON, but some status codes are wrong or generic.

   Fair 2 points Works, but the API is RPC-style or returns 200 for everything.

   Poor 0 points The API is not reachable or does not follow HTTP semantics.

2. Persistence and CRUD on the server 20%

   Excellent 4 points All four operations persist correctly in a database. Ids are server-generated. Data survives a restart.

   Good 3 points All four operations work, but one has a defect (e.g. update replaces instead of merging, delete leaves orphans).

   Fair 2 points Only some operations persist, or data is kept in memory only.

   Poor 0 points No persistence.

3. Validation, error handling, and concurrency 20%

   Excellent 4 points Requests are validated with clear error bodies. Concurrent requests are handled safely, demonstrated in the presentation.

   Good 3 points Validation exists but error messages are generic or leak framework internals.

   Fair 2 points Partial validation; concurrent access can corrupt data.

   Poor 0 points No validation; the server crashes on bad input.

4. Client 20%

   Excellent 4 points Full CRUD from the client, JSON parsed, data displayed in a clear UI, server errors shown to the user.

   Good 3 points Full CRUD but errors are not surfaced, or the UI is rough.

   Fair 2 points Only some operations are wired to the server.

   Poor 0 points No working client.

5. GitHub 20%

   Excellent 4 points The code is in the assignment repository. Only the sources were added, no build directory.

   Good 3 points The code is in the repository but build output or generated files were committed as well.

   Fair 2 points The code was presented but not yet pushed to the assignment repository.

   Poor 0 points The code was not pushed to GitHub.

Team Project - Message-Oriented Middleware 5 criteria, weighteddraft, subject to change

What to do

• A team of two students builds a bigger project on top of an existing MOM framework such as Apache ActiveMQ, RabbitMQ, or Kafka.
• Clients access the server through web services (SOAP or REST) and a user-friendly interface implementing at least the CRUD operations.
• The MOM setup demonstrates load balancing across at least two nodes, failover, message persistence, reliable delivery, queuing for asynchronous communication, and security.
• The system is administered through messages between the client and the queue, and is designed to scale horizontally.

How to submit

Push the source code, deployment scripts, and a README with the architecture and run instructions to the team assignment repository on GitHub before the deadline. The last push before the deadline is graded.

How it is graded

1. Web service and client 20%

   Excellent 4 points SOAP or REST service with full CRUD and a usable client; the service and client are decoupled through the MOM.

   Good 3 points Full CRUD, but the client talks to the server directly for some operations.

   Fair 2 points Partial CRUD or an unusable client.

   Poor 0 points No working service or client.

2. Load balancing and failover 20%

   Excellent 4 points Requests are distributed across at least two nodes; killing a node during the demo causes no lost requests.

   Good 3 points Two nodes run, but failover requires a manual restart or loses in-flight requests.

   Fair 2 points A second node exists but receives no traffic.

   Poor 0 points Single node only.

3. Persistence, reliable delivery, and queuing 20%

   Excellent 4 points Messages survive a broker restart, acknowledgements and redelivery are configured, and producers and consumers work asynchronously.

   Good 3 points Persistence and queuing work, but redelivery or acknowledgements are left at defaults without justification.

   Fair 2 points Messages are queued but lost on restart.

   Poor 0 points No queuing; the system is synchronous.

4. Security and administration 20%

   Excellent 4 points Authenticated and authorized access to queues, transport encryption, and administration performed through messages as required.

   Good 3 points Authentication configured, but transport is unencrypted or administration uses the broker console.

   Fair 2 points Default credentials or open queues.

   Poor 0 points No security.

5. Architecture, scalability, and documentation 20%

   Excellent 4 points The README explains the architecture with a diagram, how to run everything, and how the system scales horizontally. Deployment is scripted.

   Good 3 points Documented and runnable, but the scaling story is only described, not shown.

   Fair 2 points Runs only with undocumented manual steps.

   Poor 0 points No documentation.

Final Grade

• You will receive a final grade only if you successfully submitted the details for both the individual and the team project.
• Final Grade = IndividualGrade * 0.4 + TeamGrade * 0.6
• If the above deadlines are not met for one of the projects in order to receive a grade you will need to attend the session exam.
  In this case the Final Grade = IndividualGrade * 0.4 + TeamGrade * 0.4 + Exam Grade * 0.2