Real Microservices with Java EE @elderjava
Elder Moraes, Cloud Evangelist, Oracle, @elderjava
What about Java EE? Is it possible to build the Microservice, a real Microservice, with Java EE? Think about JPA and database and so on. We have here an entity that is a player, and we have also another entity that is our player rank. Another entity that's related to our player, we have here the relation with the player. This will be important when we are breaking down into microservice. And we also have our Beans that will make the manipulation of the data with player, as with them also with JPA. we can save player, remove player, find by ID, find all. And we have the same for rank.
We have here another stateless beans that we also save, remove, find by ID and find all. And here we build some service. Some 90-point service, rest endpoint service for actually, find by ID, add, new, save, remove. The same stuff that we've done with the stateless service. Alright? And here we have, for our player rank, okay? , what I've done here for our monolith, is I've wrote several J unit, that's here we can try if those stuff are working. , we can try it right now. It will use, basically, the same stuff that we've done before in this service with JPA, where we've created a test for running our JPA access through database, and try all those methods used for JPA.
Okay, it's built. running system successfully, this is our monolith doing with Java EE. , how do we now can take those monoliths and break it down? Choose microservice because you have here the player and the player rank. Let's split this monolith in two process, in two projects, in two artifacts.
we can have microservice here. first of all, we have just split it in two projects. Basically have the same files I keep, here on this project on the microservice player. And we have in the specific case of the player, we didn't have any change at all, except for there is no rank in the project. if we have here, the Bean is always the same Bean, and if we have here the service, the endpoint is also the same. It didn't change at all. The project for player didn't change much. For the rank, we have some changes, because as I said before, there was a relation between the rank and the player. , what I've done here, as we don't have a player anymore inside the project, and when we are doing microservice we usually, and this is the best practice, that each service has it's own database. , in this case, we are changing the player relationship for just player ID. we have changed it here for a long standard, specifically player object. We are just storing the player ID in the database for rank, and then it will opt to the application to the other relationship, or if you have some reports to take after that, it will be up to the reports to do that relationship. Their logical relationship, because each data, each microservice has to hold its own database. that's why we change it here. And that's what, basically, the most changes, when you have the endpoint service, didn't change that much. Well, just splitting the project into two pieces isn't enough. That's not enough to have the real microservice. One approach that we use here is called API Gateway. , we just built a gateway to deal with those both microservice. we have here a player gateway that will hold the communication between your client, it can be a mobile client, a web client, a desktop client, whatever client you have. The gateway will be inside, the middle of communication, between your microservice and your client. Here we have another endpoint that we'll build a client, a web client, web target. And just point them to your microservice player and here communicate with the same endpoints that we have on the microservice player. The endpoint for there. , find by ID, find all, player service for, save and for removing. Here we have the possibility to have all the reception dealing, all the specific activity or management that you need to have for the microservice, you can do on this gateway. And we have, also, an endpoint gateway for your rank. The same way we done on the player. , we have here building a client, and here doing the communication with your endpoint that is in the microservice. The good part from the gateway is that you can use it, for example, if you do your microservice change, the place, the address, or change technology, to change parts, to change anything that the contract between the APIs. You can keep your gateways two and touch it for your client's perspective, but your microservice perspective, you can change a lot and without breaking any relationship with your clients. You can also even, change your technology. If you are using Java, and you're going to use Bidal, or you're going to use anything, you can use the gateway to decrease the break that could cause you to lose clients. , it's very good. It's one approach, but it's what we use here.
https://developer.oracle.com/ https://cloud.oracle.com/en_US/tryit
Sur cette page du site, vous pouvez voir la vidéo en ligne Real Microservices with Java EE @elderjava durée heure minute seconde en bonne qualité , qui a été Téléchargé par l'utilisateur Oracle Developers 15 avril 2018, Partagez le lien avec vos amis et connaissances, sur youtube cette vidéo a déjà été regardée 4,905 fois et il a aimé 56 téléspectateurs. Bon visionnage!
