Using REST services synchronizer, we implement the following:

All participants that are interested in accessing the common resource have to initially register with the synchronizer.

Each time a participant P wants to access the resource, it sends a reserve request to the synchronizer. The request includes the service ID and duration of use. The synchronizer checks whether the resource is available.

• If the resource is available, it replies to P with a ticket (i.e., password) that grants access to P; the synchronizer marks the resource as busy.
• If the resource is unavailable, it executes an internal algorithm to estimate the waiting time for P. Then it replies to P with the estimated waiting time.
• P has to send a follow-up message stating whether it agrees to wait or not along with the service ID.
  • If P does not agree to wait, the synchronizer discards Ps request and replies with a discarded message.
  • If P agrees to wait, the synchronizer puts P in a local waiting list and replies with acknowledgement message back to P;

Whenever a participant is done using the resource, it sends a release message to the synchronizer. The synchronizer uses an internal policy to select the next service (e.g., FIFO) and sends an access ticket (i.e., password) to the selected participant.

(Assume that there is no fault/failure in the system.)

1. Give the REST API of Synchronizer. For each API, provide the following:
   1. The protocol used (GET or POST).
   2. The URL (you do not need to give actual URL.
   3. A short text description (one or two sentences) of what the API does.
   4. The XML structure of the input message (sent to the API as request) and output message (result sent back by the API).
   5. Who invokes the API (e.g., participant, coordinator, etc.)
2. Give the REST API of each participant. For each API, provide the following:
   1. The protocol used (GET or POST).
   2. The URL (you do not need to give actual URL.
   3. A short text description (one or two sentences) of what the API does.
   4. The XML structure of the input message (sent to the API as request) and output message (result sent back by the API).
   5. Who invokes the API (e.g., participant, coordinator, etc.)
3. Give a UML sequence diagram showing the execution of the system for 3 participants. Assume the requests to access the resources are received in this order: 1, 2, 3. Also, assume that access to the resource is granted in this order: 1, 3, 2.