Module CSC5002—ASR6: Middleware and software architecture for distributed applications

The writing of SSE services in JAVA follows the JAX-RS (Jakarta RESTful Web Services) specifications and is achieved with the Eclipse Jersey and Eclipse Grizzly frameworks.

Read the source files in your favorite development environment. We favor using Eclipse. Before importing the project into Eclipse, build it by executing command mvn install. Then, import the Maven project using the menu File / import, select Maven / Existing Maven Projects, and use the Browse button to select directory Learn-SSE-JAX-RS.

Follow the instructions in the readme.md file in order to test the server:

• With the Junit tests.
• With JAVA clients.

When you have understood the examples (especially the one with the broadcaster), you are ready to write your own SSE client and server.

Verify first that you are able to answer the following questions:

1. You do need to start the server before starting any client. How do you start the server?
   mvn exec:java@server

   You first have to compile the code with

   mvn clean install
2. What are the endpoints? Provide the list and explain the origin of each one?
   Hint: use the WADL description.
   Open the link of the WADL description. The link is displayed in the console when executing the server (command mvn exec:java@sse-server).
   

   WADL available at http://localhost:8083/MyServer/application.wadl * Resource class HelloSseResource - resource path="/hello/eventStream" with method id="getServerSentEvents" and name="GET" * Resource class HelloSseResourceBis - resource path="/hellobis/eventStream" with method id="getServerSentEvents" and name="GET" * Resource class BroadcastSseResource - resource path="/broadcast/newmessage" with method id="broadcast" and name="POST" - resource path="/broadcast/register with method id="registerToBroadcast" and name="GET" * Resource class BroadcastSseResourceBis - resource path="/broadcastbis/newmessage" with method id="broadcast" and name="POST" - resource path="/broadcastbis/register" with method id="registerToBroadcast" and name="GET"
3. Explain why the broadcasting examples need two endpoints? And before that, explain why the other examples only use one endpoint?
   In the “one endpoint” examples, namely resource classes HelloSseResource and HelloSseResourceBis, the call the endpoint leads to both the creation of the long connection (produces media type "event-stream"), and the creation and the starting of a thread that sends events.
   In the “two endpoints” examples, namely resource classes BroadcastSseResource and BroadcastSseResourceBis, the first endpoint is for the creation of the long connection and the second endpoint is for proposing a message to be broadcast to the registered clients.
4. What is the difference between HelloSseResource and HelloSseResourceBis?
   In the second resource class, the connection is forced to be closed. This causes the client to ask for re-registration, which causes the server to create a new long connection and to start a new thread. This can be seen by several lines with “data=Hello world 0!” in the console.
5. In the broadcasting examples, how many broadcasters are created?
   There is only one SseBroadcaster object.
   Note that this object is not managed by the container: there is no injection for this object. Therefore, the lifecycle management of this object is application dependent. As a consequence, a resource class can create as many SseBroadcaster objects as needed.
6. What is the difference between BroadcastSseResource and BroadcastSseResourceBis? What is the impact?
   The difference is the injection of the Sse object: as an argument of the constructor versus as an attribute of the resource class.
   Injecting as an attribute forces to complement the constructor with the instantiation of the SseBroadcaster object after the execution of the constructor of the resource class: This is done in a method that annotated @PostConstruct.