Over time, enterprise-grade Java applications can become giant hulking beasts of intertwined code, bloated with third-party libraries, and vulnerable to total collapse when a single part fails. It doesn't have to be that way! This example-rich tutorial shows how to design and manage large-scale Java applications as a collection of microservices. Save 42% off Enterprise Java Microservices with code slfinnigan at: https://goo.gl/ZEYhVL

1. Creating RESTFul endpoints
with JAX-RS for a simple
microservice.
By Ken Finnigan
Save 42% off Enterprise Java Microservices
with code slfinnigan at manning.com

2. A simple microservice.
Let’s pretend that we’re developing a simple application and that the
application will utilize JAX-RS for the RESTFul microservice, with a UI
built with ReactJS.
The application includes a UI as a way to utilize the microservice in an
easier manner. Without a UI it would require issuing curl commands
to interact with it, and UIs are nicer to look at than commands in a
terminal!
So what are we developing? A simple application for managing
addresses.

3. Here is what our app’s UI might look like.

4. Application Use Cases.
We’re focusing on address management, so we don’t need to cover a
large range of use cases. Our address microservice only needs to focus
on the CRUD operations that a data object requires to create, read,
update, and delete instances of.
The UI will call the CRUD operations on the microservice for
maintaining addresses. The microservice RESTFul endpoints could be
called from any client, but we will show them operating with our UI.

5. Address UI page flow.

6. Architecture of the Application.
Let’s take a moment and ignore microservices – the architecture for our
application would probably look something like:

7. Architecture of the Application.
At the Presentation Layer we use ReactJS for the UI. The API Layer
contains the RESTFul endpoints utilizing JAX-RS for employee and
address. CDI services for employee and address represent our Business
Layer, which is called by the API Layer. Finally there are JPA entities of
employee and address in our Data Layer that interact with the physical
database. The Business Layer is responsible for interacting with the
Data Layer to persist record updates.
Whether the API Layer and Business Layer would be separate or not
depends on preference, as they could be handled within a single layer.
Typically all these layers would be packaged within a single WAR for
deployment to an application server.

8. Architecture of the Application.
How does the architecture change when we shift to constructing a
microservice?
Our server side layers are encompassed in a single Microservice. Our UI
then sits in its own WAR, to package and deploy the UI to a separate
runtime.

9. As we’ve split our UI and services into separate runtimes, we need to
add support for cross origin resource sharing (CORS). If we don’t, the
browser will prevent the UI from making an HTTP request to the
microservice. To do this our microservice needs a filter:

10. Creating RESTFul endpoints with JAX-RS.
To keep the microservice simple we will focus on the RESTFul endpoint
--the API Layer-- and ignore the development of the additional layers.
Any Enterprise Java developer would then be able to take the
microservice and extend it to utilize CDI and JPA if they wanted.

11. Developing the AddressController.
Our AddressController will focus on making the CRUD style
operations for address data available from RESTFul endpoints. It
specifies that the RESTFul @Path for the controller is /address. We
then define a counter as a unique identifier, and a Map to store the
addresses in memory. Last, we populate an internal Map called
addresses with some initial data during construction of the instance.
As we’re storing data for addresses in our controller, we need to make
the class a singleton within JAX-RS. By default, all JAX-RS resource
instances are only active on a per-request basis. If we don’t change
that, then every request will see the same initial data state every time,
and the UI would never show different data no matter how many new
addresses were added or updated.

12. Developing the AddressController.
We need to define a JAX-RS
application that can indicate
to the implementation which
RESTFul endpoints we want to
be singletons:

13. Viewing all addresses.
Now it’s time to develop the RESTFul endpoints we need for CRUD of
our addresses.

14. Deleting an address.
Once we have an address, we need the ability to delete an old one that
isn’t used. For that we need to add a RESTFul endpoint for deleting an
address from the database.

15. Adding an address.
Here we have a RESTFul
endpoint to add a new
address into our database
and provide it with a
unique identifier.

16. Running the microservice.
Although we’ve indicated that our RESTFul endpoint is an Address
microservice, there’s actually nothing in the code we’ve developed that
prevents it from being built as a WAR and deployed to an application
server. As we’re only dealing with a UI communicating with a single
microservice, there isn’t any difference between that and existing
Enterprise Java development with WARs. The upside to the similarity is
that it makes it easier to migrate existing Enterprise Java code into a
Microservice if no code changes are required for a microservice
producer.
To give more of a microservice feel for our example, we will package it
as an uber jar with WildFly Swarm.

17. Running the microservice.
WildFly Swarm offers an alternative approach to packaging your
applications utilizing WildFly instead of a full Java EE Application Server.
It allows us to choose the parts we need from WildFly and package
them into an uber jar that can be run from the command line.
To do that we need to add the following plugin to our pom.xml:
Latest version of WildFly Swarm.
Specify a port offset of 1 so
our microservice will start on
port 8081.

18. Running the microservice.
That’s all we need to do to provide a way to run the microservice from
the directory, as well as package it as an uber jar.
So how and what do we run?
There are two pieces that need to be run, one for the UI and one for
the microservice. If you wanted to execute some tests against the
RESTFul endpoints directly, without using the UI, then you only need to
start the microservice.
Let’s see what we need to do to start our microservice:

19. Running the microservice.
Open a terminal, or command window, and navigate to the /chapter2/jaxrs
directory of the book example code (https://github.com/kenfinnigan/ejm-
samples). From that directory run:
This will start the microservice containing our RESTFul endpoints for
address crud. Once the log shows that the microservice is deployed you
can go to a browser and open it to:
Your browser will load the initial address
data and display it in JSON format. Now
we know the microservice is running,
let’s run the UI.

20. Running the microservice.
Now let’s start the UI.
Open a terminal and navigate to the /chapter2/ui directory of the book
example code. From that directory run:
This will start a web server with the UI code only. Once the log shows
that it’s deployed you can go to a browser and open it to:
Your browser will load the UI containing some sample address data.

21. Voila! That’s all for now.
We hope you found this presentation informative. Don’t forget to
save 42% off Enterprise Java Microservices with code slfinnigan at
manning.com.
Also see: