Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enterprise Java Microservices : creating and managing large-scale Java applications

744 views

Published on

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

Published in: Software
  • Be the first to comment

Enterprise Java Microservices : creating and managing large-scale Java applications

  1. 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. 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. 3. Here is what our app’s UI might look like.
  4. 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. 5. Address UI page flow.
  6. 6. Architecture of the Application. Let’s take a moment and ignore microservices – the architecture for our application would probably look something like:
  7. 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. 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. 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. 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. 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. 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. 13. Viewing all addresses. Now it’s time to develop the RESTFul endpoints we need for CRUD of our addresses.
  14. 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. 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. 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. 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. 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. 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. 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. 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:

×