Lab 5.pdf | bartleby

Electrical, Computer and Biomedical Engineering Page 1 of 15 Software Design and Architecture (COE692) Lab 5 Duration 2 weeks Group work and Group submission 1 Objectives The main objectives of this lab are as follows: • Implementing Asynchronous messaging between microservices using Kubernetes Queues • Implementing Synchronous messaging between microservice in a cloud environment • Pull the microservices of your project as docker containers in docker hub • Set up communications between containers using Kubernetes • Deploy all microservice on the Google Cloud • Expose the final project on a public api, such that everyone can test and see the work! Problem description The first part of the lab asks you to complete asynchronous messaging between microservices based on kubemq technology. The second part of the lab asks you to complete synchronise communication between microservices, and between each microservice and its own database (Because a database will be deployed in a container). The third part of the lab asks you to create docker containers for all microservices and their databases and push them to Docker Hub. The fourth part of the lab asks you to deploy your project using Kubernetes pods and services over Google Cloud. Requirements ● Installing all required tools based on the document “Pre-requirements of lab 5”. ● A very comprehensive review of Week 10 for theories and Week 11 for technical aspects of the project. Part 1: Implementing Asynchronous messaging In this part, you must recognize micro-services that need asynchronous messaging, their databases and 1 All files needed to be deployed on a Google Cloud Account. Just one Google Cloud account is enough for each team. If two team-members are in different sections (should be handled by the same TA), the group deadline is the latest deadline in the team (e.g., in a group of two members with deadlines of Tuesday and Thursday, the group deadline will be on Thursday).

Page 2 of 15 affected tables and then implement publishing a message and receiving messages. In the following I will comprehensively describe how I implemented this technique in my own Library Management System (LMS) project. You must complete this part for your own project 2 . • Dependent microservices description : In LMS project, there are two microservices hold_book and borrow_book that need to communicate asynchronously. Borrow_book can borrow a book to a user only if it is not on hold by another user. Hence borrow_book needs to know which books are on hold by whom. Whenever a new hold created by the hold_book microservice, a new message must be published to interested consumers. The borrow_book microservice is subscribed to the Hold Book Channel, when it can see and act upon receiving new messages. • Database Description : hold_book microservice has the hold_LBS database. This database has the BOOK_Hold table, which has id, isbn, userid, startdate columns (see the following schema): When a request for holding a book is performed, a new row will be added to the BOOK_Hold table. Also a message will be published in a channel named “hold_book_channel” with the following format: HOLD:$BOOKISBN:$USERNAME:$ExpireDate, when $BOOKISBN is the isbn of the book is on hold, :$USERNAME is the username who hold a book, :$ExpireDate is when hold is no longer valid in this format “yyyy-MM-dd”. The borrow_book microservice has the borrow_LBS database with following tables: USER_BOOK_Borrow is a table related to borrowing books. BOOK_Hold is table that keeps information about books that are on hold received from hold_book micro service. 2 Please note that your project may need to have multiple asynchronous messaging to perform well. But for the purpose of this lab, describing and implementing just one is enough.

Page 3 of 15 Coding: In order to implement messaging, I added a new class to the HoldBook project, business package. This class is named Messaging and has the following structure: Figure 1 Messaging class has a sendmessage method that sends a message to the “hold_book_channel”. ClientID could be anything here, I chose “hold-booksubscriber”. The important part is line #23, when the address for sending this message must be assigned. I do not know the exact address on the cluster, so I assume there will be an environment variable which will be set at run time. This environment variable is named “kubeMQAddress”. Lines #25, and #26 creates a channel and set it to be stored (Please refer to the lecture to find out more about different channel types). In line #30, message will be converted to an appropriate format. Finally line #33 sends the message. You can use the exact same method in your codes by some customizations (Example: changing the channel name). 3 3 All codes of this project will be available on your D2L in a zip file named Lab5codes.zip

Page 4 of 15 In the BorrowBook project, in the • Sending message Code: In HOLDBOOK project, in the HoldBusiness class, I changed the hold method to send the appropriate message using the Messaging class as follow: Figure 2 In the BorrowBook project, I created a Messaging class in the business package as follows:

Page 5 of 15 Figure 3 You must modify lines #16 to #39 for implementing your own logic (Please refer to lecture Week 11 for more details.). Finally Figure 4 is where the receiving messages will be run (See lecturer notes for more details)

Page 6 of 15 Figure 4 More explanations: Two important thigs you must not forget: 1. Editing web.xml of the microservice that has MyAppServletContextListener and add the following: Where the package and the class name must be modified based on your own project. 2. Add the following dependencies to the project that uses kubemq

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help