For each of the following tasks the client and the server side of the system have to be modified.
Furthermore, there is a shared part where modifications might be necessary. Import the provided
assignment template which consist of a multi-project Gradle build. There is a root project con-
taining sub-projects for the client, the server, and a shared one. You can import the root project
idstrsys into your IDE as existing gradle project. In Eclipse, all the sub-projects are imported as
own projects. An overview of these projects and what to do where is given in the following:
client: This project contains the Swing-GUI of the existing system. Additional “backend
implementations” (at least one for UDP and one for AMQP) must implement the interface
TicketManagementBackend and be registered. Check the JavaDoc documentation of the
class Main for more details.
server: This project contains a very basic server backend implementation, which currently
offers no remote access possibilities. Implement the Interface RemoteAccess and register
your implementation as described in class Main of the server project.
shared: Contains all classes which are used on the server and the client side (i.e., the Ticket
representations). You can also add additional classes, e.g., for UDP message formats if you
idistrsys: This project is the root project. For this assignment you might do configuration
changes in it, but in general there are no changes necessary here.
Part 1: UDP communication
Basic level: Create the possibility to send a newly created ticket to the server by imple-
menting the method createNewTicket(...) of the interface TicketManagementBackend
and by providing a basic implementation of the RemoteAccess interface on the server side.
A one way communication is sufficient here - so the createNewTicket(...) can return null,
or an empty Ticket.
Advanced Level: Of course, the basic solution is not really feature complete, so: Create
a basic communication protocol in order to fully implement the TicketManagementBackend
by adding the ability to update Tickets and to retrieve a list of existing Tickets from the
server. Ensure that the server can handle multiple simultaneous requests from different
Even more advanced: As especially the ticket lists might be too large for a single UDP
packet, it might be necessary to split the message into smaller chunks which are sent in
multiple packets. Extend the basic communication protocol to split the packets at the
sender side and to reassemble them on the receiver side. Be aware that the order of packets
is not guaranteed by the UDP protocol.
Part 2: AMQP communication
Basic Level: Implement a basic one-way communication protocol between the clients and
the backend system. Ensure that messages are delivered to at least one Queue. Messages
from the clients to the backend should be stored persistently in a Queue during forwarding.
Advanced level: Improve the protocol to be able to receive replies from the backend server.
As the number of clients is unknown, it is not possible to create the queues for the replies
upfront. Therefore “temporary queues” have to be created during the runtime by the clients.
Even more advanced: Create an additional Exchange, which forwards new messages to
all registered clients when a new ticket is created or has been updated. The clients and the
server must asynchronously receive messages by implementing a Push-API.
Optional Part 3: Server Backend system
The existing prototypic implementation is not threadsafe, which might cause trouble if more
and more clients are added to the system. Create another, threadsafe backend implementation
implementing the TicketStore interface!
Remarks and Constraints:
Use the provided template which contains already preconfigured gradle projects.
Read the javadoc documentation for the existing GUI and the prototypic backend server
carefully! These comments describe how to adapt and extend the existing source code.
The backend system should be able to handle tickets via UDP sockets and AMQP in parallel!
Moreover: It might be possible that more than one client submits tickets concurrently. How-
ever, the client should either send messages using AMQP or UDP - switching the protocol
during runtime is not needed.
Some additional remarks for the “even more advanced” UDP level:
– There should be no limitations regarding the length of all fields of the newly created
Tickets. I.e., it should be possible to use the full length of String and the other types.
– If Tickets are splitted into multiple UDP packets, your solution should be able to deal
with incorrect ordering. However, it is not needed that lost messages are resent.
– Similarly the detection and resending of completely lost Tickets is not required... but
if you have way too much time... ;-)
Some additional remarks for AMQP in general:
– All needed components within RabbitMQ must be declared by the server and/or by
the clients using the Java Client Library. Make a reasonable decision for each level!
– You can use a Pull-API to receive messages in your implementation for the basic and
the advanced level. However, using a Push-API is recommended.
As this is “Introduction to Distributed Systems” it should be possible (but not mandatory)
to distribute the clients, the backend server and the AMQP broker on different machines.
Of course this should be possible without recompiling your solutions. Pass host names and
other information as arguments to the main classes. Document the correct usage of
Do not close or refresh the page, until you have got a SMS with OTP
You will get a SMS within 60 seconds on below number