Not sure this is the right Class if not I apologize
Assignment #1: Data model [10%] This assignment relates to the following Course Learning Requirements: CLR 1: Identify, explain, and use various technologies used in the Enterprise environment. CLR 3: Implement Web Server integration with enterprise applications. CLR 5: Utilize as well as defend against common security vulnerabilities found in enterprise applications and the multi-server networked environment. CLR 6: Implement and Integrate various Java based technologies used in the enterprise environment. Objective of this Assignment: Check your ability to effectively execute the planning of enterprise applications by defining a schema of a data model in terms of MVC and to choose a communication model. Pre-Assignment Instructions: 1. To prepare you for this assignment, read the modules 3, 4 and 5 content and follow the embedded learning activities. 2. You require a drawing software that allows you to draw diagrams and charts. a. The following tool is a suggestion: i. Standalone app of https://app.diagrams.net/ which can be downloaded here https://github.com/jgraph/drawio-desktop/releases/tag/v13.6.2 ii. You are welcome to use any other such as Microsoft Visio (Windows only), pen and paper (literally). 3. You also must have the following database installed on your computer. a. For simplicity: i. I used MySQL v.8+ (https://dev.mysql.com/downloads/), and provided you an example of the data model in module 5. ii. You may use any database you wish, moreover if you decide to switch your solution to NoSQL it would be considered as a bonus – NOTE: it should be correct and workable, otherwise no bonuses will be added). Assignment description: In this assignment you will start by developing a backend for a Twitter-like application. The functionality of the application should have the following: 1. At least 2 roles a. Producer; and b. Subscriber 2. The Producers role is the same as the Subscriber, but has some extra capabilities: a. The producer can produce messages, which the Subscribers get 3. User may have both roles at the same time; 4. Users having the Subscriber role, which means they can subscribe to as many Producers as they want to; 5. All messages stored in the database, can be easily searched based on the following criteria: a. User (Producer) ID – means who wrote it; b. Message content Assignment Tasks: What you should do: 1. Acquiring MVN design pattern, you need to build a data model for the application described in the Assignment Description section together with API Contracts 2. As a result, you should have the following: · ERD diagram (if you use RDBMS) as a picture of JPEG/PNG format; · Script to create the data model in the DB (SQL for RDBMS, CQL for Cassandra, etc.), which should be runnable, and creates an expected data structure; · Script to populate the database with few records (2-3 users, 5-7 messages); · A minimum of the following queries: i. Get list of users; ii. Get list of content producers; iii. Get list of content subscribers (full); iv. Get list of content subscribers, subscribed on specific producer; v. Get all messages; vi. Get all messages created by specific producer; vii. Get all messages for given subscriber (it may include messages from multiple producers). Assignment Submission 3. You need to submit an archive with name pattern {Course #}_{Section #}_{Last name}_{First name}.zip containing the following: · ERD diagram (if you use RDBMS) as a picture of JPEG/PNG format; · Script to create the data model in the DB (SQL for RDBMS, CQL for Cassandra, etc.); · Script to populate the database with few records (2-3 users, 5-7 messages); · List of queries in regular text file; · Screenshots demonstrating the result of each query execution. 1 Assignment Grading Rubric (10%) Criteria Excellent 80-100% Good 50-79% Requires Improvement <50% points assignment quality all information provided is accurate all information is clearly expressed and well explained contains original ideas, connections or applications most information provided is accurate all information clearly expressed and explained contains mainly original ideas, connections or applications some or no provided information offered information is rarely or never clear and require further explanation many non- original ideas, or unclear connections or applications /1 comments assignment knowledge and skills demonstration clear, concise synthesis of course content to demonstrate understanding of topic all ideas are clearly developed, organized logically, and connected with effective transitions explores ideas, supports points fully using a balance of evidence, uses effective reasoning to make useful distinctions all relevant course and topic links are made evidence of some synthesis of course content to demonstrate understanding of topic some unified and coherent ideas are developed with effective transitions supports most ideas with effective examples, and/or references, and details, makes key distinctions most relevant course and topic links are made lack of evidence or weakness in the synthesis of course content to demonstrate understanding of topic develops and organizes ideas that are not necessarily connected. some ideas seem illogical and/or unrelated presents ideas in general terms, most ideas are inconsistent/unsupported, and reasoning is flawed or unclear some or no relevant course and topic links are made /8 comments assignment structure formatted as per assignment details structure and format enhance delivery of the information formatted as per assignment details in most components structure and format fits well with the delivery of the information formatting has not been followed structure and format are unclear and impedes delivery of the information /1 comments total points 10 7 5 /10 module 3: application environment and integration introduction this module introduces different techniques of microservice integration into the whole ecosystem. you’ll discover two different approaches of scalability applications in order to maintain high load, the importance of service discovery and load balancers, as well as, seeing s.o.l.i.d. principles in practice. learning outcomes by the end of this module, you should be able to complete the following: 1. enumerate and apply scaling technics of enterprise applications; 2. explain the scope of each microservice and perform functional decomposition at a high level. key terms & concepts scalability: the property of a system for handling a growing amount of work by adding resources to the system. service discovery: another process which aims to perform at least one function - automatic detection of devices and services offered by these devices on a computer network to reduce the configuration efforts from users. this process helps to represent the system as a monolith with a single point of entry. load balancer: any software or hardware device that facilitates the load balancing process for most computing appliances, including computers, network connections and processors. it enables the optimization of computing resources, reduces latency, and increases output and the overall performance of a computing infrastructure. orchestration: the activity of coordinating calls to several different services, in order to process a single service request. scalability problem the load on your applications varies depending on the time of the day, the day of the month or the month of the year. take for instance, amazon.com. its loads are very high around thanksgiving, up to 20 times the normal load. however, during major sporting events, such as the super bowl or a fifa world cup, the traffic could be considerably less - because everybody is busy watching the event. it is quite possible that the infrastructure needs to handle 10x the normal load. how is it possible to serve such a number of requests per one single application? the actual problem is shown in the following figure. (c) figure 1 - hi load problem it’s not much of an issue when the number of incoming requests is low, and your application is capable of serving them. however, what will happen if the number of requests raises significantly? imagine this situation: your service starts adding incoming messages to the queue, where they continue growing to the point where some of them become not actual any more (time to live factor), or worse, the incoming queue overflows –leading you to an even bigger problem. although this is a possibility, in the microservice world, the answer is simple – it would not be considered a single application anymore. recall from the previous module, we discussed the 4 main criteria of any microservice applications this is important for you, as those criteria make it possible to scale an application horizontally: small: microservices are designed to be small. some of the estimation techniques like function points, and use cases, may be used to define the size of the microservice. however usually by “small” you have to mention the amount of the functionality each of the microservices performs, and generally one microservice should be responsible for only one independent block of functionality of the ecosystem. stateless: a stateless application handles every request with the information contained only within it. a microservice must be stateless, and it must service the request without remembering the previous communications from the external system. in(ter)dependent: microservices must service the request independently; they may collaborate with other microservices within the ecosystem. for example, a microservice that generates a unique report after interacting with other microservices is an interdependent system. in this scenario, other microservices, which only provide the necessary data to the reporting microservices, may be independent services. full-stack application: a full stack application is individually deployable. it has its own server, network & hosting environment. the business logic, data model and the service interface (api or gui) must be part of the entire system. a microservice must be a full stack application. how to scale an application horizontally? what does it mean? simply, you have to run it a second time. let’s take another look at figure 1 in greater detail. (c) figure 1 - hi load problem in figure 1, you can see only one application and five clients trying to reach it. this is a fairly common situation, considering that the application is run on your powerful server somewhere at the datacenter. in addition, you will also use vertical scalability techniques at the same time, in order to use your hardware at its full power without making it idle and waste electricity. keeping this in mind, what happens if you simply start another application? how will your client know where to go and how to reach that second application or another instance of that application? to answer the question, naturally, you can assign a different ip address and even the dns’s name to that application in the case of a web service; but, would that be convenient for a client? to help better explain the convenience of a client, let’s use the following example: one client connects to your service using a dns name like www.example.com, but at one point, it figures out that the service is not responding, therefore requiring he or she to use another address which is www1.example.com. is this a convenient approach for your customers? and how do they know which ip address or dns name they need to connect to, in order to ensure they receive first-class performance? the answer to all these questions is a load balancer. load balancers will save you in these situations. load balancing what is the load balancer? a load balancer is any software or hardware device that facilitates the load balancing process for most computing appliances, including computers, network connections and processors. it enables the optimization of computing resources, reduces latency, and increases output and the overall performance of a computing infrastructure. if this is that clear, then take a look at the figure 2: (c) figure 2 - load balancer load balancing is a method to distribute incoming socket connections to different servers. it is not distributed computing, where jobs are broken up into a series of sub-jobs, so each server does a fraction of the overall work. it is not that at all. rather, incoming socket connections are spread out to different servers. each incoming connection will communicate with the node it was delegated to, and the entire interaction will occur there. each node is not aware of the other nodes’ existence. why is load balancing required? scalability: if your application becomes busy, resources, such as bandwidth, cpu, memory, disk space, disk i/o, and more, may reach their limits. in order to remedy such a problem, you have two options: scale up, or scale out. load balancing is a scale out technique. rather than increasing server resources, you add cost effective, commodity servers, creating a “cluster” of servers that perform the same task. scalability out is more cost effective, because commodity level hardware provides the most ‘bang for the buck’. high- end super computers come at a premium, and can be avoided in many cases. redundancy: servers crash; this is the rule, not the exception. your architecture should be devised in such a way to reduce or eliminate single points of failure (spof). load balancing a cluster of servers that perform the same role, provides room for a server to be taken out manually for maintenance tasks, without taking down the system. you can also withstand a server crashing. this provides you high availability. load balancing is a tactic that assists with high availability. how to perform load balancing? there are 3 well-known ways: 1. dns based: this is also known as round robin dns. you can inject multiple a records for the same hostname. this creates a random distribution – requests for the hostname will receive the list in a random order. if you wish to weigh it (say servera can take 2x the number of requests points="" assignment="" quality="" all="" information="" provided="" is="" accurate="" all="" information="" is="" clearly="" expressed="" and="" well="" explained="" contains="" original="" ideas,="" connections="" or="" applications="" most="" information="" provided="" is="" accurate="" all="" information="" clearly="" expressed="" and="" explained="" contains="" mainly="" original="" ideas,="" connections="" or="" applications="" some="" or="" no="" provided="" information="" offered="" information="" is="" rarely="" or="" never="" clear="" and="" require="" further="" explanation="" many="" non-="" original="" ideas,="" or="" unclear="" connections="" or="" applications="" 1="" comments="" assignment="" knowledge="" and="" skills="" demonstration="" clear,="" concise="" synthesis="" of="" course="" content="" to="" demonstrate="" understanding="" of="" topic="" all="" ideas="" are="" clearly="" developed,="" organized="" logically,="" and="" connected="" with="" effective="" transitions="" explores="" ideas,="" supports="" points="" fully="" using="" a="" balance="" of="" evidence,="" uses="" effective="" reasoning="" to="" make="" useful="" distinctions="" all="" relevant="" course="" and="" topic="" links="" are="" made="" evidence="" of="" some="" synthesis="" of="" course="" content="" to="" demonstrate="" understanding="" of="" topic="" some="" unified="" and="" coherent="" ideas="" are="" developed="" with="" effective="" transitions="" supports="" most="" ideas="" with="" effective="" examples,="" and/or="" references,="" and="" details,="" makes="" key="" distinctions="" most="" relevant="" course="" and="" topic="" links="" are="" made="" lack="" of="" evidence="" or="" weakness="" in="" the="" synthesis="" of="" course="" content="" to="" demonstrate="" understanding="" of="" topic="" develops="" and="" organizes="" ideas="" that="" are="" not="" necessarily="" connected.="" some="" ideas="" seem="" illogical="" and/or="" unrelated="" presents="" ideas="" in="" general="" terms,="" most="" ideas="" are="" inconsistent/unsupported,="" and="" reasoning="" is="" flawed="" or="" unclear="" some="" or="" no="" relevant="" course="" and="" topic="" links="" are="" made="" 8="" comments="" assignment="" structure="" formatted="" as="" per="" assignment="" details="" structure="" and="" format="" enhance="" delivery="" of="" the="" information="" formatted="" as="" per="" assignment="" details="" in="" most="" components="" structure="" and="" format="" fits="" well="" with="" the="" delivery="" of="" the="" information="" formatting="" has="" not="" been="" followed="" structure="" and="" format="" are="" unclear="" and="" impedes="" delivery="" of="" the="" information="" 1="" comments="" total="" points="" 10="" 7="" 5="" 10="" module="" 3:="" application="" environment="" and="" integration="" introduction="" this="" module="" introduces="" different="" techniques="" of="" microservice="" integration="" into="" the="" whole="" ecosystem.="" you’ll="" discover="" two="" different="" approaches="" of="" scalability="" applications="" in="" order="" to="" maintain="" high="" load,="" the="" importance="" of="" service="" discovery="" and="" load="" balancers,="" as="" well="" as,="" seeing="" s.o.l.i.d.="" principles="" in="" practice.="" learning="" outcomes="" by="" the="" end="" of="" this="" module,="" you="" should="" be="" able="" to="" complete="" the="" following:="" 1.="" enumerate="" and="" apply="" scaling="" technics="" of="" enterprise="" applications;="" 2.="" explain="" the="" scope="" of="" each="" microservice="" and="" perform="" functional="" decomposition="" at="" a="" high="" level.="" key="" terms="" &="" concepts="" scalability:="" the="" property="" of="" a="" system="" for="" handling="" a="" growing="" amount="" of="" work="" by="" adding="" resources="" to="" the="" system.="" service="" discovery:="" another="" process="" which="" aims="" to="" perform="" at="" least="" one="" function="" -="" automatic="" detection="" of="" devices="" and="" services="" offered="" by="" these="" devices="" on="" a="" computer="" network="" to="" reduce="" the="" configuration="" efforts="" from="" users.="" this="" process="" helps="" to="" represent="" the="" system="" as="" a="" monolith="" with="" a="" single="" point="" of="" entry.="" load="" balancer:="" any="" software="" or="" hardware="" device="" that="" facilitates="" the="" load="" balancing="" process="" for="" most="" computing="" appliances,="" including="" computers,="" network="" connections="" and="" processors.="" it="" enables="" the="" optimization="" of="" computing="" resources,="" reduces="" latency,="" and="" increases="" output="" and="" the="" overall="" performance="" of="" a="" computing="" infrastructure.="" orchestration:="" the="" activity="" of="" coordinating="" calls="" to="" several="" different="" services,="" in="" order="" to="" process="" a="" single="" service="" request.="" scalability="" problem="" the="" load="" on="" your="" applications="" varies="" depending="" on="" the="" time="" of="" the="" day,="" the="" day="" of="" the="" month="" or="" the="" month="" of="" the="" year.="" take="" for="" instance,="" amazon.com.="" its="" loads="" are="" very="" high="" around="" thanksgiving,="" up="" to="" 20="" times="" the="" normal="" load.="" however,="" during="" major="" sporting="" events,="" such="" as="" the="" super="" bowl="" or="" a="" fifa="" world="" cup,="" the="" traffic="" could="" be="" considerably="" less="" -="" because="" everybody="" is="" busy="" watching="" the="" event.="" it="" is="" quite="" possible="" that="" the="" infrastructure="" needs="" to="" handle="" 10x="" the="" normal="" load.="" how="" is="" it="" possible="" to="" serve="" such="" a="" number="" of="" requests="" per="" one="" single="" application?="" the="" actual="" problem="" is="" shown="" in="" the="" following="" figure.="" (c)="" figure="" 1="" -="" hi="" load="" problem="" it’s="" not="" much="" of="" an="" issue="" when="" the="" number="" of="" incoming="" requests="" is="" low,="" and="" your="" application="" is="" capable="" of="" serving="" them.="" however,="" what="" will="" happen="" if="" the="" number="" of="" requests="" raises="" significantly?="" imagine="" this="" situation:="" your="" service="" starts="" adding="" incoming="" messages="" to="" the="" queue,="" where="" they="" continue="" growing="" to="" the="" point="" where="" some="" of="" them="" become="" not="" actual="" any="" more="" (time="" to="" live="" factor),="" or="" worse,="" the="" incoming="" queue="" overflows="" –leading="" you="" to="" an="" even="" bigger="" problem.="" although="" this="" is="" a="" possibility,="" in="" the="" microservice="" world,="" the="" answer="" is="" simple="" –="" it="" would="" not="" be="" considered="" a="" single="" application="" anymore.="" recall="" from="" the="" previous="" module,="" we="" discussed="" the="" 4="" main="" criteria="" of="" any="" microservice="" applications="" this="" is="" important="" for="" you,="" as="" those="" criteria="" make="" it="" possible="" to="" scale="" an="" application="" horizontally:="" small:="" microservices="" are="" designed="" to="" be="" small.="" some="" of="" the="" estimation="" techniques="" like="" function="" points,="" and="" use="" cases,="" may="" be="" used="" to="" define="" the="" size="" of="" the="" microservice.="" however="" usually="" by="" “small”="" you="" have="" to="" mention="" the="" amount="" of="" the="" functionality="" each="" of="" the="" microservices="" performs,="" and="" generally="" one="" microservice="" should="" be="" responsible="" for="" only="" one="" independent="" block="" of="" functionality="" of="" the="" ecosystem.="" stateless:="" a="" stateless="" application="" handles="" every="" request="" with="" the="" information="" contained="" only="" within="" it.="" a="" microservice="" must="" be="" stateless,="" and="" it="" must="" service="" the="" request="" without="" remembering="" the="" previous="" communications="" from="" the="" external="" system.="" in(ter)dependent:="" microservices="" must="" service="" the="" request="" independently;="" they="" may="" collaborate="" with="" other="" microservices="" within="" the="" ecosystem.="" for="" example,="" a="" microservice="" that="" generates="" a="" unique="" report="" after="" interacting="" with="" other="" microservices="" is="" an="" interdependent="" system.="" in="" this="" scenario,="" other="" microservices,="" which="" only="" provide="" the="" necessary="" data="" to="" the="" reporting="" microservices,="" may="" be="" independent="" services.="" full-stack="" application:="" a="" full="" stack="" application="" is="" individually="" deployable.="" it="" has="" its="" own="" server,="" network="" &="" hosting="" environment.="" the="" business="" logic,="" data="" model="" and="" the="" service="" interface="" (api="" or="" gui)="" must="" be="" part="" of="" the="" entire="" system.="" a="" microservice="" must="" be="" a="" full="" stack="" application.="" how="" to="" scale="" an="" application="" horizontally?="" what="" does="" it="" mean?="" simply,="" you="" have="" to="" run="" it="" a="" second="" time.="" let’s="" take="" another="" look="" at="" figure="" 1="" in="" greater="" detail.="" (c)="" figure="" 1="" -="" hi="" load="" problem="" in="" figure="" 1,="" you="" can="" see="" only="" one="" application="" and="" five="" clients="" trying="" to="" reach="" it.="" this="" is="" a="" fairly="" common="" situation,="" considering="" that="" the="" application="" is="" run="" on="" your="" powerful="" server="" somewhere="" at="" the="" datacenter.="" in="" addition,="" you="" will="" also="" use="" vertical="" scalability="" techniques="" at="" the="" same="" time,="" in="" order="" to="" use="" your="" hardware="" at="" its="" full="" power="" without="" making="" it="" idle="" and="" waste="" electricity.="" keeping="" this="" in="" mind,="" what="" happens="" if="" you="" simply="" start="" another="" application?="" how="" will="" your="" client="" know="" where="" to="" go="" and="" how="" to="" reach="" that="" second="" application="" or="" another="" instance="" of="" that="" application?="" to="" answer="" the="" question,="" naturally,="" you="" can="" assign="" a="" different="" ip="" address="" and="" even="" the="" dns’s="" name="" to="" that="" application="" in="" the="" case="" of="" a="" web="" service;="" but,="" would="" that="" be="" convenient="" for="" a="" client?="" to="" help="" better="" explain="" the="" convenience="" of="" a="" client,="" let’s="" use="" the="" following="" example:="" one="" client="" connects="" to="" your="" service="" using="" a="" dns="" name="" like="" www.example.com,="" but="" at="" one="" point,="" it="" figures="" out="" that="" the="" service="" is="" not="" responding,="" therefore="" requiring="" he="" or="" she="" to="" use="" another="" address="" which="" is="" www1.example.com.="" is="" this="" a="" convenient="" approach="" for="" your="" customers?="" and="" how="" do="" they="" know="" which="" ip="" address="" or="" dns="" name="" they="" need="" to="" connect="" to,="" in="" order="" to="" ensure="" they="" receive="" first-class="" performance?="" the="" answer="" to="" all="" these="" questions="" is="" a="" load="" balancer.="" load="" balancers="" will="" save="" you="" in="" these="" situations.="" load="" balancing="" what="" is="" the="" load="" balancer?="" a="" load="" balancer="" is="" any="" software="" or="" hardware="" device="" that="" facilitates="" the="" load="" balancing="" process="" for="" most="" computing="" appliances,="" including="" computers,="" network="" connections="" and="" processors.="" it="" enables="" the="" optimization="" of="" computing="" resources,="" reduces="" latency,="" and="" increases="" output="" and="" the="" overall="" performance="" of="" a="" computing="" infrastructure.="" if="" this="" is="" that="" clear,="" then="" take="" a="" look="" at="" the="" figure="" 2:="" (c)="" figure="" 2="" -="" load="" balancer="" load="" balancing="" is="" a="" method="" to="" distribute="" incoming="" socket="" connections="" to="" different="" servers.="" it="" is="" not="" distributed="" computing,="" where="" jobs="" are="" broken="" up="" into="" a="" series="" of="" sub-jobs,="" so="" each="" server="" does="" a="" fraction="" of="" the="" overall="" work.="" it="" is="" not="" that="" at="" all.="" rather,="" incoming="" socket="" connections="" are="" spread="" out="" to="" different="" servers.="" each="" incoming="" connection="" will="" communicate="" with="" the="" node="" it="" was="" delegated="" to,="" and="" the="" entire="" interaction="" will="" occur="" there.="" each="" node="" is="" not="" aware="" of="" the="" other="" nodes’="" existence.="" why="" is="" load="" balancing="" required?="" scalability:="" if="" your="" application="" becomes="" busy,="" resources,="" such="" as="" bandwidth,="" cpu,="" memory,="" disk="" space,="" disk="" i/o,="" and="" more,="" may="" reach="" their="" limits.="" in="" order="" to="" remedy="" such="" a="" problem,="" you="" have="" two="" options:="" scale="" up,="" or="" scale="" out.="" load="" balancing="" is="" a="" scale="" out="" technique.="" rather="" than="" increasing="" server="" resources,="" you="" add="" cost="" effective,="" commodity="" servers,="" creating="" a="" “cluster”="" of="" servers="" that="" perform="" the="" same="" task.="" scalability="" out="" is="" more="" cost="" effective,="" because="" commodity="" level="" hardware="" provides="" the="" most="" ‘bang="" for="" the="" buck’.="" high-="" end="" super="" computers="" come="" at="" a="" premium,="" and="" can="" be="" avoided="" in="" many="" cases.="" redundancy:="" servers="" crash;="" this="" is="" the="" rule,="" not="" the="" exception.="" your="" architecture="" should="" be="" devised="" in="" such="" a="" way="" to="" reduce="" or="" eliminate="" single="" points="" of="" failure="" (spof).="" load="" balancing="" a="" cluster="" of="" servers="" that="" perform="" the="" same="" role,="" provides="" room="" for="" a="" server="" to="" be="" taken="" out="" manually="" for="" maintenance="" tasks,="" without="" taking="" down="" the="" system.="" you="" can="" also="" withstand="" a="" server="" crashing.="" this="" provides="" you="" high="" availability.="" load="" balancing="" is="" a="" tactic="" that="" assists="" with="" high="" availability.="" how="" to="" perform="" load="" balancing?="" there="" are="" 3="" well-known="" ways:="" 1.="" dns="" based:="" this="" is="" also="" known="" as="" round="" robin="" dns.="" you="" can="" inject="" multiple="" a="" records="" for="" the="" same="" hostname.="" this="" creates="" a="" random="" distribution="" –="" requests="" for="" the="" hostname="" will="" receive="" the="" list="" in="" a="" random="" order.="" if="" you="" wish="" to="" weigh="" it="" (say="" servera="" can="" take="" 2x="" the="" number="" of="">