Full transcript of “IPT1 Topic III Middleware and Message Brokers Part 1”. Click a timestamp to open the video at that moment. Need another video? Use the YouTube transcript generator.
0:00 Good day to everyone. So our lesson for today is all about the middleware and message broker. So from the previous topic so pinag-aralan natin yung sa integration architecture and their patterns. Tapos ngayon is focus na tayo for the middleware and message. So next week is yung focus naman natin yung sa API. Kumbaga guys is idi-deep lang natin yung learning about the middleware and broker and API and API gateway. So I think mas magiging smooth na lang yung ating discussion because of um na-discuss ko na yung ibang mga part. Okay? Pero hindi naman
0:47 natin siya lalaktawan. Kumbaga mas nagkakaroon lang kayo ng idea when it comes to the uh discussion kapagka ay nag ah napupuntahan natin yung portion na yun. Okay. So balikan natin what is a middle. So dito muna is ano muna natin establish muna natin yung pinaka ah basic idea ng middleware before tayo pumasok sa broker ah message broker because baka ang iba sa atin ay hindi pa alam kung ano talaga ang middleware. Okay. So, middlew guys is a software layer na nasa pagitan ng dalawang application
1:34 system or service. Pag sinabi nating application, ito na yung ah mga processes. Pag sinabi nating system, system system to system, pwede rin siya or pwede rin siya for the services. So sana alam natin iyung ganon kasi baka mamaya nalilimitahan tayo for the middle w application only. No, it is focuses on the uh not focuses on the application. Pwede rin siya for the system to system, service to service. Sana ano tayo doun no? Okay. Kaya nga sinabing middle word is a layer. So what is the purpose behind? So ang purpose nito ay tulungan silang makipag-communicate.
2:21 Okay? Hindi lang kailangan na alam ni application A, ni system A or ni service A kung paano internally ginagawa or pinapatakbo si application P. Okay. So sa diagram guys kung makikita natin ay meron tayong mga application A, middleware and application B. So halimbawa si application A so meron siyang front end. Okay. Web front end. At si application B naman is meron siyang isang payment service. So instead na si application A mismo siya ang gumawa ng lahat ng logic para maintindihan kung paano kausapin
3:07 ang payment service. So maaaring si midderware ang humawak ng common integration responsibility gaya ng messenging, routing and security. Okay. So this is the important because midleware can provide a common communication layer between the other wise difference system. So in a simple way terms na pwede nating uh pwede nating i-elaborate number one is think of a middleware as a ah software na nasa gitna. Okay. Hindi siya ano ah 'yung main application na
3:53 ginagamit ng mga user at hindi rin siya necessary for 'yung final system na may data or services. So ang work niya is tulungan lang itong dalawa. Okay. Ah dalawang system na magkaintindihan at makipag-communicate sa isa't isa. 'Yun lang naman ang purpose ni uh Middlewar. Okay. So hindi kinakailangan na parehang technology ng dalawang yan. Kaya nga sabi ko sa mga previous topic eh hindi mo na kailangan magre-develop for that. Um para lang [nililinis ang lalamunan] mag-communicate yang dalawang yan. Okay. So for example, um application A,
4:40 sabihin natin na PHP siya tapos naka-wind server. Tapos ang ginagamit niya na um ah AP ano na connection is RES, API and Jason. Pagdating naman kay application B, nandiyan na yung language niya na Java tapos ang OS niya is Linux. Tapos ibang communication protocol yung gamit niya. Samantalang dito is naka-rest. Okay? Siguro dito naka-soft yung SOAP. Okay. So middle square can help hide and handle those differences. So which is exactly what the statement at the button ' ba doon sa part ng ating discussion
5:28 kasi nga very important siya guys ba um nale-lessen na natin yung mga ganung um decision part as a ba even if you are a developer naano na natin nale-lessen na natin okay so paano ba nagwo-work okay So, so sa itong um left side ko atsaka right side which is the application A and application B. So si application A initiate communication okay based don sa diagram. So nakikita niyo naman yung arrow 'di ba? Okay so may kailangan ah kailangan itong ah data or service mula kay application P. Okay. So ang second
6:16 natin diyan is request uh goes through the middleware. So dito maaaring mangyari ang additional processing tulad ng ah messenging handling, ano pa? routing, security checking, protocol or data transformation. Pagdating kay middleware, so middleware forward the request to a application P. So ang gagawin naman ni application B is magfe-perform depende dun sa kanyang responsibility. Okay? Kung may respond so maaari itong dumaan pabalik sa middleware bago makarating kay application A. So what is the important? So important um linawin natin na hindi
7:04 ibig sabihin na ginagawa ni Middlew ang trabaho ni application B. it facilitate and manage the communication. So ang syempre dito si application B is meron siyang sariling service. Okay? Like for example dito sa slide payment service. Hindi ginagawa ni Middle William. Ang ginagawa niya lang guys is properly communic properly process to communicate the request and response per each application. Okay. Sana clear tayo do kasi based doon sa mga ano eh sa mga let's say sa naging presentation um parang nami-miss ah mi-misconception natin si
7:50 middleware. Okay? Nagiging iba yung dating eh or yung pagkakaintindi ninyo regarding doon sa middleware. So ibibahin natin siya no. So let's say dito sa diagram. Okay. So dito is iimaginin niyo yung application A na sinasabi dito is website. Okay? Yung website na 'to is ang sample natin may process dito for magbabayad siya ng ah magbabayad siya ng payment. Hindi na kinakailangan ni application A i-direct doon kay payment service. Kaya kasi nga sabi ko nga kanina they are different types of the services and system.
8:37 Okay? So ang properly communication natin is the middle for that. Okay? Si payment application B naman ang nagpa-process once na okay na yung communication between the A and B. Okay. So bigyan pa natin ng mas ano mas ah example. Okay. So iyung genetic login, are you familiar in genetic ah generic plugin? So sa interface system integration kasi sabihin natin no suppose na may company na may integration ah sabihin nating ano
9:22 inventory system tapos inventory system to and then ito is middleware and then shipping system Okay. So kapag may item na na ready na i-deliver, so kailangan na ipasa kay inventory system ang information sa shipping system. So ano ang problema doon? So magkaibang developer ang gumawa ng system. Maaaring magkaiba ang programming language. Ano pa? Maaring magkaiba ang expected data format like XML and ah Jason. May sariling security requirements ang shipping system. So instead na ilagay lahat ah lahat ng
10:08 integration logic sa inventory system. So bakit hindi ka gumawa ng isang middleware na magha-handle ng communication between the inventory and shipping system? Okay? So for example sa inventory system send nakaano to naka XML. So magse-send siya ng um uh ano niya request niya. Okay. So order niya naka-ready na. Tapos um pero sa J pero sa Jason sabihin natin sa shipping Jason siya. Okay. So possible role ni Middlewear anoung last time napag-aralan natin kung face
10:55 to face lang 'to is magtatanong ako eh. Okay. So una niyan syempre ire-receive as XML kasi naka XML 'to 'di ba? And then validate, transform into Jason and then route kung saan siya is-send. So mapupunta na siya kay shipping system. Okay. So dito mapapakita natin ' ba ng middleware is hindi lang basta abstract na software in middle. May actual integration responsibility itong ginagawa. Okay? Not just is ganyang ano lang diagram no. Okay. So ina-emphasize natin ang responsibility for each part. So si Axend
11:43 papunta kay papunta kay B pero hindi agad niya mare-receive kasi dadaan mo na siya kay middlewar. Kailangan mo ng i-validate, kailangan mo ng i-transform, kailangan mo ng intindihin. Kailangan siyang i-route. Tignan ng security. Tignan ng security ni B kung papasok ba talaga, kung maa-acquired niya. Okay. So ganun siya. And then si application B, ang responsible niya is yung sinend na request. Let's say sinend na request is order and then siya magpa-process for the shipping. So yun is system to system ba. So bakit nagma-matter ito? So ba sabi nga natin without middleware
12:30 kailangan intindihin directly ang implementation requirements ni application B. So very complicated pagdating sa development. Okay. Kapag nagbago si application B point to point possible na kailangan ding baguhin si application A. So with middle, okay, application A then middleware, application B. So mas nle-lessen und directly dependency. Yun kasing iniiwasan natin eh dependency ng application sa isa't isa. Okay? So kaya very important guys yung concept na pwede pwedeng ano natin ikwan natin dito i-emphasize natin. Okay. So later on
13:17 makikita natin yan yung interoperability abstraction reusability, loose coupling. Guys, misconception lang. Okay. Ah sa nangyayari kasi middleware is not equal to uh message broker kasi nga ang topic natin is message broker. Okay? So this is the important guys na middlew is not a equal or let's say parehas sila ni mid message broker. Si si midle excuse me ha pas na kayo doun sa mga manok talagang ganyan no middle is broad category so maaring klase ah classification maing function ang
14:03 middlewar samantalang si message broker naman ay isang more specific middleware technology so saan po ako si same ah broker so later on mababanggit yan pero ipakapiaw ko na ngayon receiving routing ano pa delivering message between the system or between the system tama okay so from now guys um iano muna natin establish muna natin so middle word is a broader concept while message broker is a specific messing oriented um middleware. Okay. So ito yung pinakamagandang ano part no sa ano sa
14:49 middle wear. Okay? Para ma-differentiate natin yung dalawa. Okay, remember guys no before we proceed to the next slide um middleware can provide a communication layer okay layer between the system so they can work together without needing to know all of each other internal implementation details. Yun kasi ang work niya e. Okay. Actually si middleware talaga is more on focuses focusing on the communication proper. Okay. 'Yun ang ano niya. 'Yun ang pinaka portion niya. Pero kasi syempre pag sinabi nating middle, marami siyang ginagawa eh. Marami siyang kino-consider or sine-set aside.
15:36 And the main topic for that is that ano um anong tawag doun yung message broker. Okay so tingnan natin sa next slide tayo. Okay y middle wear sabi diyan why middle wear matter in integration. Okay. So kanina so na-establish natin ang middle ver. Sabi natin uh middleware is a layer ' ba na pagitan ng application or system or services to ah parang to communicate to properly communicate between the two system two application or two services. Ngayon the
16:25 question is bakit kailangan pa natin ng middleware? Bakit hindi na lang natin ah i-direct na mag-connect yung dalawang application? Something like that. Ah syempre dito pumapasok yung apat na reason. Ito yun. Bakit nagma-matter? Okay? Decouffling, interoperability, reusability and scalability. So dito muna tayo kayopling. Okay. Sabi diyan, "System depend on the shared contract, not on each other code or time." Kasi si decopling guys nagbabawas ng direct dependency.
17:10 Okay? Dependency ng isang system sa ibang system. Kaya nga kanina nakita niyo ' ba dito dito sa portion na to. Okay. If you are going to di ito walang dependency na nangyari kasi kung wala yan dependency ang nangyayari diyan. Okay? Bakit kamo? Kailangan natin nagre-rely directly dun sa application because of the middle word nale-lessen natin yun. So don' pumapasa si decoping. Okay. So binabawasan niya 'yung direct dependency ng isang system sa ibang system. So kung tilly connected ang dalawa, hindi siya loose coupling. Okay? So maaaring nakadepende si application A
17:56 sa specific implementation, availability or behavior ni application B. Okay. With the middleware, mas nakikipag-communicate ang system through the agreed contract or message format rather than uh let's say being highly dependent on the other uh internal code. Okay. Let's say for example without a middle inventory system okay direct call for the shipping system ung kaninang sample natin. So kapag unavailable si shipping system maaring maapektuhan agad ang process ni ng inventory system kasi direct siya eh. Okay? With the middleware or messenging so inventory
18:44 system tapos middleware then shipping. So sa asynchronous messenging setup natin for example ganun siya. Okay? Maaring tanggapin muna ni middleware ang message na magpa-process. Okay. Ito para doon sa shipping system kapag available na to. Okay. So guys, important clarification. So yung statement natin for that is um tawag doun um dun sa may ito important um clarification. Sabi diyan, not on each other um others code
19:30 or at time. So 'yung statement na 'yan guys is particular 'yan for the applicable kapag gumagamit tayo ng asynchronous messenging. So lahat ng middleware automatically remove the need for the receiving system to be online. Okay. So, ito rin ang nagiging important connection um for the ano for the message broker. Okay. So later on i da-down ay ano natin yan discuss. So remember guys decoupling means is reducing
20:16 direct dependency between the system. Okay. Next interoperability. Ito na-mention na 'to lakaran eh 'di ba? So 'yung 'yung problem natin na what if the system use different technology. So dito pumapasok si interoperability 'yung parang PHP tapos MySQL and then Windows. So possible na meron tayong application for PHP application tapos meron tayong Java application or even the system. for example um legacy system tapos middleware then modern cloud service. So dito pumapasok si interoperability ng middleware. So
21:01 magkak maaari silang ah different programming language, operating system, protocol, ano pa? Data format. Pero si middleware can provide a mechanism so that allow this system to communicate or properly communicate. Okay. So sabi nating ah kanina so XML 'di ba 'yun 'yung format and then middleware tas Jason. So instead na parehang application ang gumagawa ng transformation logic so maing i-centralize or i-handle by the by an integration middleware. Okay? So guys, interoperability different technology but they can still
21:47 work together. Okay? Ulitin ko lang ha. Si decoupling ang pinag-uusapan natin dito means reducing direct dependency between the system while si interoperability different technologies but can but they can still work together. Okay. So next tayo is for the reosability. So ito naman is for the architectural benefits. Okay? Sa architecture design mo. So dito nagbe-benefits ang reusability. So mas madaling ma-miss itong part na to. Okay? Yung architecture benefits. So ano bang meron doon? So
22:33 imagine no meron tayong maraming application. So ang application natin is apat. Sabihin niyo lang no. Mayon tayong kunwari itong mga card na 'to. Meron tayong inventory system. Mayon tayong shipping system. Excuse me. Meron tayong customer portal. Meron tayong warehouse system. Kung bawat application gumagawa ng sarili nitong authentication, security, checking logging monitoring transaction handling. So maraming duplicated functionality. So middleware can provide a certain common services that multiple application can use. For example,
23:19 application ABC. So si middle weer pupunta sa logging services. So meaning instead na tatlong magkakaibang logging implementation so na maaaring magkaroon lang ng common mechanism. Parang ganito lang kasimple intindihin. Parang instead na mag-develop ka ng different login interface, iisa na lang. Okay. So bakit nagma-matter ito? Kasi because of without ba without reusable same functionality implemented repeatedly harder to maintain. Bakit sinabi nating implemented repeatedly? Imagine tatlong
24:05 apat na application to may sari-sariling login. Hindi ba nagre-repe ang implementation natin for the for each features? Maintain to harder. What if nabago akong may bagong authentication um protocol or policy? Nagdag ako ng kunyari ang nila-login natin dito is username pero later on gumamit na tayo ng contact number or email pwede lang iapat yan. So harder to maintain baung functionality ba without the reusability. Next with reusability middleware service. Common functionality,
24:50 centralized or shared, more consistent implementation. Male-less pa natin yung harder to maintain. So important guys lahat ng business logic dapat ilagay sa ah middleware. Hindi hindi ibig sabihin ganun no? Um kasi baka yun ang nasa ano niyo eh nasa isip niyo ngayon. Hindi ibig sabihin na lahat ng business logic eh dapat nasa middleware. Common integration concern ang magandang ano dito atake for the candidate for the usability not a business logic kasi yun ang concern niya eh. Pagdating
25:36 sa development maybe lagay mo lahat ang business requirements. Pero the business logic hindi lahat ilalagay mo sa ano sa middle. Okay? Kasi ang concern lang naman natin is for ano eh ah for ano eh for the reusability when it comes to the integration. Number four, middlewear. Um, scalability. So ano ba yung scalability? So ito is ano naman to ah siguro mas magandang i-connect natin siya sa message broker. Ah sample suppose meron tayong normal
26:21 load ng isang system. kumbaga um 'yung um sample 'yung gumagamit ng system meron siyang 100 ah message per minute. Okay? So sa kunyari sa isang company 200 ang nagwo-work diyan. Okay? 500 ang nagwo-work. Okay? And then ang message lagi diyan is 100 ah 100 per minute. Iba-iba 'yan. Iba-ibang request. iba-ibang services ang kailangan. So then biglang naging naging 10,000 per minute. Kung direct communication ah application A to application B
27:07 without a middleware na may possibility na hindi kayanin ni application B lahat ng request. Okay. Balik tayo kanina. Ito payment service. Normally ang load lang niyan is nasa 100. Kayang-kaya niya yan without. Okay. What if nga kanina sa sample natin is nag 10,000? The question is kaya niya bang i-handle? So hindi. Hindi niya kayang i-handle 'yun. So sa messenging app architecture natin so maaaring magkaroon tayo ng tinatawag na que or message broker.
27:52 So let's say dito i-emphasize ko muna. Kunyari itong producer natin, okay, itong message broker natin or que tapos consumer. Okay. So instead na ah kailangan sabay-sabay process lahat ng message can be buppered in in a queue and the processing according to the customer consumer ah capacity. So pwede rin magkaroon ng multiple consumer like for example is producer tapos meron siyang tatlong consumer. So yung pangalawang consumer doon is naka-Que. So pwede ring ganon ang mangyayari. So habang tumataas ang workload so depende sa depende sa
28:40 architecture we can add processing capacity. Okay? Agag ang pinag-uusapan natin is scalability. So important clarification guys, middleware itself does not automatically make an application scalable. No, hindi nangyayari yun. rather certain uh middlewear capabilities especially for the queue, asynchronous messenging, load distribution and message broken. So sabihin natin can help us design system that can be handle increasingly workload more efficient or let's say effectively. Okay.
29:26 Tandaan niyo guys, pagka sinabi nating decouffling, hindi kinakailangan ng tilly dependent ang system sa isa't isa. Okay? Ah, interoperability. Kahit magkakaibang technology yan, okay, maaari silang makipag-communicate through the middleware, reusability, common integration, services don't need to be revealed repeatedly. Okay, hindi ka na kailangan gumawa pa. Scalability, we can better manage increasing the communication and workload. Okay yan yung mga nagma-matter bakit ginagamit natin si middleware. Okay?
30:11 So middleware is not a simply software na nasa gitna no? Okay. Architecturally ginagamit natin ito. because it helped solve real integration problem that appear when system become larger more device or more interconnected. Okay? Pakitandaan 'yun guys kasi it very important. Okay, next tayo. I think may hinanda ako ditong ano eh. Ah mamaya naend to sa ano sa common ano tayo common types of middle world pero syempre ang focus ito yung mga common also na ano na natin
30:58 na-discuss na natin pero ito may mga separated pa tayo diyan so ang focus nga natin ngayon is yung message oriented kasi nasa message broker tayo so dito tayo magfo-focus pero itong mga to eh na-discuss na 'yan last week or last last week so ang ginawa lang natin is ano lang natin uh binigyan lang natin sila ng kwan ng uh definition 'di ba? Pero ngayon si si ma si ma'am um okay yan yung ating focus for today. Okay so sige punta tayo sa message oriented ah middleware or mom. Okay.
31:43 So sa previous ah slide natin kanina sinabi natin na yung meron siyang major benefits ang middleware which is the coupling 'di ba? Ngayon i-ano lang natin iwan lang natin ah si decoupling ' ba application A is direct call for the application B. So pupwedeng gumamit ng message oriented um middleware which is sending um message middleware and receiver. Okay. So ano ito? Umm yung major difference. So major difference
32:30 um sa part ni ano ng ano na to ng kwan ng decopling is wherein application communicate by exchanging message rather than directly calling to each other. So pasok natin si message oriented middleware. So ano bang meron sa kanya? So guys this is a form of middlew designed especially for messagebased communication between application or services. So ang isang application ay maaaring maging sender o yung tinatawag natin na producer.
33:16 gumawa ng ipadala yon sa middle ver. Then the middle ver receive and hold the message until na mai itong kunin or i-process ah ng intended receiver or consumer. Okay, ulitin ko lang ha. Ang sender or frustrood usucer iisa lang 'yon. Okay. So sila yung gumagawa ng it sila yung gumagawa ng umage. Okay? Sila yung nagpapadala sa middleware. Okay. So the middlew receive and hold the message until na maaari niya ng kunin or i-process
34:03 ng intended receiver or consumer. Okay? Pakitandaan yan. the reserver the sender and receiver don't necessarily have to communicate at the same time. So hindi siya ganon no. Ah ito ay sabihin nating tinatawag nating asynchronous communication. Okay? Kaya nga kanina ah asynchronous messenging ang ano natin diyan. Okay. Ang focus natin um ano ba yung bigyan muna natin ng emphasize yung asynchronous and synchronus? So ito pagkaasynchronous guys is formal direct request. Okay? For example,
34:51 application A ito. Then application B. Okay? Magse-send ng request from application B. Magre-respond muna 'yan. Okay. Magre-respond. So kapag nag-request ka, ito pag nagresponse ito, hindi ito agad-agad magre-respond. So meron pang nangyayari na ano diyan na nagwe-wait muna 'yan. Paano siya nagwe-wait? Paano siya nag-aantay? Paano siya magre-respond kapagka okay na yung ah process? Okay? Kunyari nag-request si application A, naghihintay siya ng response bago magpatuloy sa dependent part ng process.
35:37 So halimbawa may request na tumagal ng 5 seconds kung kailangan munang ang result maghihintay ang color or ang sender. Okay? Kasi magre-respond siya e ba kung ano man yung request. So sa asynchronus sa asynchronous is um sa sender message t's middleware send continue wait lang um uulitin ko pagkaynchronos direct, okay? Direct na nagre-respond at
36:24 nagre-request pero pag asynchronous guys, meron pa siyang process. Okay? Meron pa siyang process na nangyayari. So kapag successfully accepted na ang middleware ang message, hindi na necessarily kailangan hintayin ng sender na matapos agad ni receiver ang actual process. Okay. So ito yung key idea ng asynchronous exchange. Okay. So yun yung pinakaimportant kay ano kay asynchronus. So [nililinis ang lalamunan] ayan sa sender and message. So suppose meron tayong magbigay tayo ng sample diyan. Ah suppose meron tayong
37:10 information ah student information system. So ang kinakailangan niya is mag-send ng thousand of email notification after uh the grade are released. So ibig sabihin yun ang parang process na mangyayari niyan no. Ulitin ko lang. student information system magse-send siya ng 1,000 ay000 of email notification kasi nga ah ire-release na ang grade. So instead ng mangyari muna na ' ba parang ang ano natin parang ang mangyayari is let's say student information system direct for
37:57 the email. Ah server yung email service na to no. Okay, ito yung information student information system and then wait um wait tapos and then sent ah sent hindi yun d sent next mail. Okay. So ang application gumagawa ng um
38:43 yung application ang gagawa ng message dito. Yun. Okay. Kunyari ang ise-send niya diyan is student ID 2026 1025 tapos email student at sabihin natin atsu.ededu.ph. Tapos yung type niya is yung grade notification. Okay. Then ipapadala niya sa um messenging middleware. So meron na siyang messenging middleware diyan para doon kay email ah service. Tapos punta kay student. Tapos ang mangyayari diyan ito yung middleware natin. So mag pagka nagre request siya so magre-respon naman
39:28 yan. Babalik 'yung middleware tapos siya magse-send ng notification. Okay? Ganyan na ang mangyayari niyan. Student information system. So since may middleware na tayo, ang mangyayari is punta muna kay middleware, pa-process niya. Route etera, etcera. And after that, sa email service natin, ang mangyayari diyan magre-response siya. So magse-send siya ng magse-send siya ng ano niya ng process niya. Okay? Ire-respond na ire-respond niya na yung process. So punta kay middle or ira-route. And then kay
40:17 student information system. So kay student information system may process din siyang gagawin. Natural 'yung format nng email kanino ise-send 'yun na 'yun. Okay? Siya na 'yun ang bahala don. And then tsaka magse-send doon sa ah kung kanino man email 'yun student email. Mare-receive niya na sa UI yun. Okay. So, middle middle where hold the message. So, nasan na 'yun? Ito after the message the middle word can store queue until can be processed. So, student um student information system send a message. So sa middleware nakapila yan message one, message 2 hanggang 10,000
41:03 kung thousand off. So hindi na kinakailangan i-process ng email service lahat ng uh part na yon. The message can wait in the middle where according to the message system configuration and delivery guarantee. Then the receiver when uh so sa receiver read when ready. So then ah sabihin natin si email notification service magpa-process na ng message. Okay. So ang mangyayari sa kanya si ah from middleware to email toification service. Ang mangyayari diyan is message one process send ganun na siya. Message to
41:51 send email. Okay. So magkakaiba ng responsibility no'no. So si sender, I need this work to be done. Si middleware I will manage deliver the message. And then the receiver I will process the message. Okay? Or yung kaninang sinample ko nababalik muna siya dito tsaka niya ise-send. Kasi yung iba 'yung iba kasing type ng email service direct na kumbaga direct ng ise-send. dahil nga sinama mo na dun sa protocol yung format kaya automatically hindi na babalik. Yung iba naman kasi ang ginagawa ano ah babalik muna para dun sa um maybe dun sa template or what basta
42:37 ganun. And then yung iba naman is direct. Okay? Direct na magse-send doon sa mga student. So what if the receiver is temporarily offline? Ayan na. Ito na yung pinakamagandang part kasi si message oriented middleware let's say student student system tapos meron tayong messenging middleware and then email service. Sabi natin at 10 a.m. nag-send ng message ang student. Ay nag-send ng message ang student system. Pero temporarily down yung email service with appropriate configure.
43:24 So configure yung durable persistent messenging. So the message can uh remain available in the middle at 10 a.m. So ang tendency si receiver or email service offline ' ba. So kapag naging available na ulit siya so doun niya doun niya na ipa-process. Saan na yun? Doun niya na ipa-process yun. Okay. So wala wala bang magiging problema? Oo. Nakay middleware lang 'yun. Hindi lang magse-send pa kahit na even na si si student information system
44:09 nag-send siya ng ano. Hihintayin lang yun. Pero ano to ah makaka-receive ng ano to na notification na offline siya as of the moment. So pwede ka na lang magkaroon ng ganong function. Ah magha-handle nung ano nung ah exemption ni ano ni service may mga gan. So, so hindi na kilaka-kailangan na ano sabay na online si sender, student information, kay email service at the exact moment na mag-message ito na mag-produce ' ba. So sasabihin niyan the system can be offline at different times basta gaganon na lang siya. Okay? So
44:55 the important for that is uh this this depend on the middle word. persistence, durability acknowledgement or or end delivery configuration. Hindi lahat kasi ng message ay automatically guaranteed ' ba. So asan na tayo? Ito this give a loose cffling in time, in location, in data per month. So in loose kasi merong three ways na sinasabi ito time, location and data format ' ba. So doon tayo sa time. Bakit ah this give lose copling in time?
45:41 Kasi hindi na kinakailangan sabay na active ang sender at receiver. Okay? Yun yang sinample ko kanina ' ba. sender send now a receiver process later this is ito y tinatawag na temporal um decouling ba next loose coupling in location so hindi na kinakailangan direct na malaman ni sender kung nasaan ang physical network wise ang exact receiver instance hindi na no need the messenging infrastructure can help route the message toward the appropriate destination or consumer. Okay. Wala pakialam si ano doun. Walang pakialam si sender doun. Basta magse-send siya, bahala na si Mendelware
46:28 maghanap doun. Okay? Yun ang loose coupling in location. Next, loose coupling in data format. Ito paulit-ulit na lang. Okay. Messenging middleware may support standardized message format or transformation mechanism reducing direct format dependency between the system. Okay. Um hindi ibig sabihin guys na magically naintindihan na ni ah message oriented message ang kahit anong format no. Hindi siya ganon. Okay. Kinakailangan pa rin ng agreed message contract or schema or configuration for the transformation. Okay. Let's say XML t's Jason. Ico-configure mo pa yun
47:16 dito. Hindi siya basta na magic na ano lang ha na middlew ikaw pa rin nagagawa niyan. Okay. Siya ganun siya ganun. Magic parang kasing 'yung ano niya eh sa logic niya no kino-configure pa rin 'yan based sa agreed message contract or schema. Okay? So misconception natin asynchronus is is a equal daw sa ano sa instant or parang instant faster daw siya. Yung pag ganito siyang argument. Kapag sinabi nating asynchronous ah hindi ibig sabihin na mas mabilis na automatically. Okay? Ibig sabihin guys the sender does
48:01 not have to wait for the receiver to finish the process before continuing with unrelated work. Okay? Possible ng may possible na may message na nasa que for several um second or minute depending on workload. But the advantage of the coupling or workload management not guaranteed for the faster execution. Okay. So next ito may hinanda ako dito eh yung ano ayan sa Mam. So kunyari ang message natin or event type is order created. So ito yung key and then ano natin is
48:47 success ah successful. So pag nag-send yan guys ayan the receiver received the message and processing complete successfully. So pero pagka sa amulate failure natin ang nangyayari diyan guys is processing complete. The receiver um ano yun the receive receiver receive the message processing the complete but ang nangyari sa atin ay meron tayong failure eh ko siya nilagay. Widlever receiver can hold the message while the receiver is unavailable. Okay. So ganun yung process niya no. Yung iyang pinapadala dito guys is
49:36 syempre madami pa yan. Let's say ang services natin na naka ah ano kay riser is 10. So ira-roote niya yun. Okay? Then aalamin niyo yung mga ah ito yung type of message format or data format. So ganun ganun siya nag-ano ganun siya nag exis. Okay. So next tayo. So dito naman guys kanina is dinefine sa atin yung message oriented middleware. So sender meron siyang sender, meron siyang middleware, meron siyang receiver. Pero dito guys, what is the important part? Question
50:22 muna tayo. Kapag nag-send ako ng isang message, sino ba dapat makakatanggap nito? Isang receiver lang or maraming receiver? So dito pumapasok yung dalawang common messenging model natin. Okay. So, pinakaimportant dito guys na distinction is how message are distribute to consumer. Ito 'yung consumer natin. Okay. So, dito muna tayo sa point to point. Ang sabi diyan, okay, point to point, one message is consumed by exactly one receiver. work is shared among consumer si ang ang producer natin ito yung P
51:08 yung sender. Okay? Nagpapadala ng message sa isang que at ang isang message ay pina-process ng one consumer only. Kaya nga point to point siya. Okay. So important nating tandaan guys, one message is equal to process by one consumer. Okay? Pero guys, hindi ibig sabihin na isa lang ang consumer na pupwedeng naka-connect sa queue eh pwedeng maraming consumer para magshe-share sila ng workload. Okay. Let's say producer natin is tapos
51:55 meron tayong worker na A, B and C. Tapos si C lang ang naka. So meron tayong message. Sabihin nating meron tayong message 1 2 3 Iapadala. Ang pepwedeng maging conceptual natin don. Sandali iano natin kunwari no. Asan na yung ano natin kanina? Ayan ah yung diagram. Let's say may producer tayo and then meron tayong worker. Tatlong worker
52:40 A B and C. Okay. So technically ang que natin dito lang kay C ' ba yung kanina. Okay. Tapos dito pepwede pa rin tayo through the middleware. Yan AC. Pero ang que natin dito lang. Okay. So let's say meron tatlong message. Si producer meron daw tatlong message. Okay. Message 1, message 2, message 3. Okay. Ang conceptual na pwedeng mangyari diyan si message one kay worker A,
53:27 message 2 kay worker B. Si message 3 kay worker C. Pwede yan. Pwedeng maging ganyan pero hindi pwede na si message one. Hindi pwede yan kay point to point message one tapos worker A, worker B and worker C. So mali yan. Hindi yan. Ito point to point pwede yan. Kung tatlo yung message mo, iba-ibang ano yun. Iba-ibang worker ang kwan non. Okay. Iba-ibang worker or iba-ibang consumer.
54:12 Okay. Pero kung isang message from different ano sila from different worker hindi siya pwede. So ayusin natin. Sabihin natin ang ano ba yung message? Let's say Jason Jason type Jason. Okay. Naka curly braces yan ba kunyari name tapos age tapos yung value ' ba yan yung message. Ngayon ito daw message na to ise-send kada isang um consumer.
54:57 Isang service, isang application, isang system. Hindi daw siya pwedeng mangyari na isang message magse-send from different ah work, different consumer, different application, different system, different services. Mali daw yun kay point to point. Hindi daw yun ang idea niya. Ang idea niya is point to point 1 to1. Okay. So kapag uh balik tayo don sa slide. Kapag kailangan nating i-broadcast ang same message sa lahat, ito itong ginawa natin dito. So ibig sabihin ibang model ang
55:43 gagamitin natin. Okay kita niyo 'yan guys ha. So ito sample um kanina dito suppose meron tayong application na magge-generate ng PDF report tapos ang nagre-request 500 na user. So paano yun? So application. Okay. Ah report ang report job niya tapos pupunta sa que tapos doun na sa ah sa worker yung gagawa. Okay. Instead ng pa-process agad ng report sa main application. So ilalagay muna natin sa job kasi ang dami
56:32 noun 'di ba? Okay. Para hindi masyadong mahirapan. Ito si workload C natin. Okay. Then available worker can process them 'di ba? Report A. Okay. and worker then meron tayong let's say ano no um okayin natin [nililinis ang lalamunan] kunwari application ba magge-generate siya ng um report report job tapos ilalagay sa que tapos Tapos
57:18 um yung report report worker yung gagawa. Okay. So let's say sabihin natin 500 yung process yung request ng user from application maggenerate ng 500. Okay. So meron tayong process diyan na report one 'di ba? Yung report one and then sabihin nating report one ah report number one. Report number two, report number 3. Okay. Report number four. And then hanggang 500.
58:03 Hanggang 500 yan. So ibig sabihin kada kada request isang generate ng report daw is isang worker ang gumagawa. Isang worker two, isang worker 3. Naka-queq kasi siya. Naka-Q dahil meron tayong hanggang 500. At the same time point to point siya. Isa lang ang gumagawa. Okay? Hindi pwedeng sa isang report lahat sila gumagawa. Okay? So hindi na kinakailangan ng lahat ng worker na gumana para dun sa isang report. Let's say
58:50 report one. Ang worker mo kunyari apat. Apat yung worker mo. So ibig sabihin kayaung yung ano mo process mo kayang magha-handle ng apat na worker. Kaya niyang mag-handle ng apat na um apat na pag-generate ng report na sabay-sabay kasi apat yung worker. Okay? Kaya magandang gamitin yung point of fight para sa mga task. Ayan, background job, ordering process, image or video processing, email job. Yun yung mga magagandang gamitin. So next tayo. Pagdating naman kay publish or subscribe.
59:39 Okay. So ito is ibang behavior naman no. Um sa publish or subscribe commonly called is pub sub parang ganun yung ano niya yung pub sub and sub so sabi diyan one message is deliver to every subscriber broadcast to many yung kanina so itong model gagamitin mo. Okay. So, publisher, topic and subscriber. So, ang producer dito is commonly called is publisher and then the receiver is called is subscriber. So kapag nag-publish ng event or message
1:00:25 sa topic, so multiple interests um subscriber can independently receive it. So ang conceptual niyan is ito from publisher punta sa topic tapos kay subscriber B kunwari lang. Okay. So, one published event can be delivered to multiple subscriber. Okay. Um, sa ano natin sample natin system ano natin sample natin is all about the um system event. Let's say meron tayong student enroll.
1:01:12 Okay. So, several independent service may care about the same event sa enrollment ba once na na-enroll na yung estudyante. So una unang ano natin ah subscriber natin which is email notification service. And then dito is topic ah topic and then student portal service. And then um dito naman is sa analytics service. Okay. So isang event lang ang nagpa-publish like student enroll tapos sinong in-enroll T's anong program niya? BS IT.
1:02:00 So lahat sila is nakaka-receive. ng Jason format na yon. Then after that, iano lang yun, ide-display na lang sa UI. Pinag-uusapan natin is yung sa backend part. Okay. Pero iba't ibang subscriber ang may sariling gagawin. Kunyari si email service, once na na-receive niyo yung Jason ah format natin na event student enroll tapos student ID 2026 10 25 tapos ang program niya BSIT. So ibig sabihin ang gagawin niya doon email service magse-send siya ng confirmation tapos sa student portal mag-a-update yung related information or workload ng
1:02:46 isang estudyante. Tapos sa analytics service syempre mag-a-update yung ating statistic regarding sa enrollment. So hindi sila nag-aagawan ng message. Okay. Each subscriber is interest in the same event but perform a different responsibility. Okay. Sa point to point guys and subscriber ang pinagkaiba nila kapag ang pinag ah sa pagka point to point guys pagka pinag-uusapan natin is work is distributed. So ano pa? One message is handled by one consumer lang and then multiple
1:03:32 um consumer can complete um for work. Tapos syempre siya good for task and job pagka kay point to point. Pero kapag ka kay ano naman pagka-use naman for the topic. So information event are broadcast tapos one event can be reach in multiple um subscriber pagdating kay publish and subscriber and then subscriber independently react. Ito naman is good for event and notification. So magkaiba sila ng ano na ng task. Ulitin ko lang kapagka kay Q guys is ano tayo ah task
1:04:21 or job. Pero kapagka kay topic guys is event or notification. Okay. So may ano sila no kumbaga mayroon silang mga simple decision pagdating sa ano sa kunyari ikaw as IT meron kang um sari-sariling mga um decision part. Okay. Kunyari um kung may trabaho kong gustong kung one worker ang gumawa so Q ang gagamitin ko pero may mga nangyayaring event at gusto ko multiple system ang nakakaalam anong gagamitin mo? Publish or subscribe
1:05:06 or yung topic. Ito misconception natin sa ano no sa sa part ni publish and subscribe sabi daw kapag marami daw ano kasi yung argument na yan kapagka maraming consumer ano na daw ah gamit na daw tayo ng publish and subscribe pwede kasing ano ah hindi hindi siya ganon okay pwede rin naman kasing marami ito eh Okay. Marami yan diyan. Okay. Walang problema diyan kung marami yan. Okay. Pwedeng maraming consumer ang isang queue pero those consumers generally
1:05:53 complete um for message or work. sa sa topic publish and subscribe mayon tayong topic and then subscribe one receive event receive event receive event so this is not a simply how many application are connected okay the important question guys is does one consumer hander the work or should multiple subscriber independently receive react on the event. So ano bang mas appropriate na gamitin? Parang ganun siya guys. Okay.
1:06:43 Next tayo. Okay. [nililinis ang lalamunan] Sa message broker. So sa previous slide nakita natin yung anong part yun yung model na dapat nating gamitin if point to point or publish 'di ba? So ngayon so si ang ang question natin ngayon is sino ang magma-manage ng queue or else ng topic? Sino ang tumatanggap at nagde-deliver ng mga message? So dito pumapasok si ah message broker. So message broker is a middleware component server na nasa gitna ng procer
1:07:31 at consumer. Let's say meron tayong producer and then um is um sabihin nating store and route tapos deliver a message. Parang dito sa may diagram na ito part na 'to. Okay. Sabihin natin diyan 'yung P1 and P2 is 'yung producer. So sila 'yung nag ah se-send ng message. So sa message broker siya naman yung nagma-manage ng message. Okay na message exchange. Okay? And then yung C1 and C2 is which is yung consumer
1:08:16 sila naman na tumatanggap at nagpa-process ng message. to what is the important point of this diagram. So the producer normally communicate with the broker not directly with the specific consumer instances. At sabihin natin um ganun din sa kabilang ito sa kabila. Okay. A consumer connect to the broker to receive the message intended for the queue topic they consume or subscribe through. So paano ba nagwo-work yan? So let's say um meron tayong video processing system. Okay. Ah
1:09:05 gamitin natin ito. Gamitin natin yung video processing um system para malinaw yung role ni ano ni message broker. Suppose meron tayong application kung saan nag-a-upload ang user ng video. Okay? At kailangan nitong i-convert into different resolution. Okay? Yun yung ano natin. Yun yung role. 'Yun 'yung work na gagawin. Si producer magke-create ng message. So anong ike-create niya? So kapag nag-create ay kapag nag-upload ah ang user ng video, okay mag-upload siya ng video um ah service. So
1:09:51 let's say sabihin natin dun sa may nag-upload siya. And then ang possible message niyan is let's say naka-Jason video ID. Syempre gagawan niyan ' ba? Gagawan ng ano yan eh ng details and then yung message ipapadala. So video ID sabihin natin doon is 10 15 parang 1015. And then 'yung file type niya is sabihin natin lecture.mp4. 'Yung task niya is yung transcode yun. And then so yung ang videos video upload service ang producer.
1:10:39 Okay siya yun. Tapos may possible message which is yung sinabi ko kanina. And then ang step two parang ganito siya. Parang ganito yung mangyayari niyan. So step one mangyayari doon is ah producer
1:11:24 ang gagawin niya ay ang role niya is video upload service. Tapos yung possible message niya. So ito siya. Ah naka-Jason yun eh. Okay na Jason yung format niya. Let's say sabi ko kanina video ID and then video ID. file ano pa tas
1:12:10 ayan tapos let's see yung value niya ayan natin para makita niyo ang value niya ay yung video id yung 10 25 tapos yung file type niya is lecture. before tapos ang tas ang tas ay
1:12:59 transcode. Okay? Yan yung yan yung message na ipapadala. Okay. So ulitin ko, ang producer diyan is ang role niya, video upload service. Okay. Ang message niya na ipapadal niya ito. Okay. And then step two, ang mangyayari diyan ay ito na yung ano, broker broker. receive receive the message. Ano yung mare-receive niyong message? Ito. Okay. So instead na direct tawagin ng
1:13:45 upload service ang isang particular video processing server which is ito. Okay. Dadaan muna siya kay broker message. Okay. Broker message broker. And then the broker received the message sa step two. Ito ah broker ah receive receive the message. Yan ang rule niya. And then after that, step three, ang mangyayari um broker store
1:14:31 or que yung queing natin yung queue the message kunwari sabihin natin no ah let's So busc pa yung consumer. So sa message broker naka-transcoding siya. Kunyari busy yung ano eh que so meron tayong video ba video id 1027 okay and so on. So siya yung maghahandle
1:15:16 muna ng Q. Okay. And then after that um the message can wait until process capacity become available subject to the broker configure persistence and retention behavior nung ano natin nung um ano kasing tawag doun itong uh consumer Okay. Then after that sa step four broker routes and deliver the message.
1:16:03 So ano ng mangyayari diyan? So kapag available na. Okay. So if available na ah available if available the worker para may condition siya if not available. So ah broker store yan store the message baka nakapila muna. Okay. So ang priority natin is si 1025. If available na yung worker, okay mare-receive na ni ah worker or consumer yun. Okay. So ang mangyayari
1:16:50 doon kapag available na um broker tapos video worker one. Pero kapagka maraming kunyari if multiple worker ang ginawa mo. So may possibility na ang mangyayari doon is ah itong transcoding que natin. Ito if multiple transcoding and then
1:17:35 ang mangyayari diyan mayon tayong worker one tapos worker two, worker 3. Okay. So the broker help distribute the work accordingly um to the messenging excuse me model or brower configuration. Kunyari lang ang entrada mo marami kang worker. So transcoding queue. So pag natapos na si um ibibigay yung video 10 25 kay worker 1 and then 26
1:18:24 and then 27 and then after that maghihintay. Kungari kung meron pa 'tong 28 waiting pa ong si 28. So sabi niya if not available nasa nasa ano pa siya nasa um queing pa siya pero if available na kunyari natapos na si 25 natapos na siya kay worker yung 1028 ibibigay niya kay worker one kasi tapos na then after noun sa sa step 5 natin doun na mari dun na ano wala na step 5 pala kumbaga yun na yun yung kay world one gagawin niyo na yung gagawin niya na 'yung uh pag-convert
1:19:10 nung video na in-upload. Okay. So ano ba talaga yung worth ni broker doon? So una siya yung nagre-receive, siya yung nagi-store, nagra-route nagde-deliver. Okay? Yun yung work niya. So pag nag-receive, tumatanggap ng message mula kay producer. Um pag nag-store maybe sa kanya muna ah maybe sa que muna or persisted until it be ano ba deliver or process. Then the route natural siya yung nagra-route. Kung kung nakita niyo kanina um kanino niya ba ira-route kay worker one, worker two or worker 3 siya yung gumagawa ng
1:19:57 pat. Okay? Customer pat na tinatawag. And then number ano ba yung sinabay ko pa kulang receiver store route eh also yung deliver siya yung nagpapadala kasi pag after niyang ma-rout hahanapin niya kung saan kunyari ito available na 'to. So hanapin ko na ay nahanap niya na. So ide-deliver niya na yung 1028 na available. Okay. So may mga modern broker tayo may also um provide features such as acknowledgement, retrice persistence ano pa ba? Ah deadlter handling, security and monitoring.
1:20:43 Okay. So hindi muna natin iisa-isahin kasi masyadong ano yan ah yung munang foundation ang kailangan natin. Okay. So why producer and consumers don't need to know each other? Kita niyo naman sa sample natin eh. Kahit ko na nga sagutin ito. Alam na alam natin bakit hindi na kailangan magkaalaman pa yang dalawang yan if ano ba yung pinaka essence ay yung pinaka-workload nila. Kasi producer and consumer only know the broker. Ito yun ' ba. So each ah never each other ang ano nila ang portion nila. Basta
1:21:28 alam nila kung ano yung broker, ano yung mga process co-contract for each. So without a broker direct ba pero kapagka um si application A may direct dependency sa iba't ibang service. So meron tayong for example producer wine and then meron tayong tatlong ah consumer ganun. Then si broker na ang bahala doon. Okay. Application A publisher send according to the QP routing key or destination depending on the technology. So hindi niya kinakailangan pumili ng
1:22:14 specific running consumer instance. Okay. So ano pa? So next tayo. So core core broker ah vocabulary. Ito medyo emphasize lang natin to kasi maraming mang 'di ba? Um kanina um message broker nasa gitna yung communication ta's gumagamit tayo ng words na procedure PR procedure ay producer sorry producer then meron
1:23:01 tayong message broker t's consumer 'di ba pero habang ba pinag-aaralan natin for the actual operation ng brok So paulit-ulit natin na-encounter yung mga term na to. Producer, consumer, que topic exchange, acknowledgement, dead letter Q. Ano ba yung mga yan? So ano yung role ng bawat is niyan agag nagta-travel? Okay? At ah paano pina-process yan? Parang meron ako niyan. Anoan part na yan? Ayan sa queue. Sa queue guys. Yan yung nangyayari. Ah simulate natin for the point to point. Pag point to point tayo is
1:23:46 one at the time lang. Okay? One at the time pag point to point. Okay. The worker a to the next job for the processing. Ah it parang ung katulad ng kanina pero sa publish ang ginagawa natin is equivalent. Ano siya distributed yun lang ang essence non even the failure wala pa ng wala man nangyari kay failure dito yun kay ano ah request's kay broker guys yung sa ano processing tayo ayan consumer one received the message
1:24:33 processing to complete successfully okay 'yun 'yung entrada niya. So si si message broker diyan is portion wherein 'di ba the producer talk to the broker not directly to the comm uh consumer instances the broker can receive the message store the unit if it if needed so route it deliver it for from the producer to the consumer so depende. So pag nagkaroon ng failure, let's say nagkaroon ng tuloy failure dito. So consumer processing field broker policy may try to or dead letter the message. So yun yung pag-aaralan natin yan yung mga terminology na yan. Okay.
1:25:23 So isa-isahin natin. Okay. Producer. Producer is an application or service that create and send message to the messeng system. Ah yun yung essence ni ano ni producer. Okay. Sample is order service tapos message them broker. Tapos sabihin natin yung possible na message niya is order ID and then event order created. So ang order service is yung producer. Okay. Siya yung ano doon. Siya yung ah sa-sample natin siya ang
1:26:09 producer. sample is yung ano natin yung process order service tapos yung message natin and then to to broker. Okay? Let's say ano ang magke-create siya ng order. Okay. Ngayon ang message na ipapasa niya, let's say ito. Kunwari lang ito. Okay. Kunwari ang nandito is order ID. Ko na ipo-format then event. Yan ang
1:26:55 laman yan. T's pupunta siya kay broker. So yung order service natin dito siya si producer. Okay? Siya yan yung order service. Siya si producer. And then producer doesn't necessarily process the word. it announce an event or submit work through a message. So depending on the technology, producer may publish to the topic exchange or sent to the destination such as okay next the consumer. So consumer naman ang application service na nag-receive
1:27:44 or process ng message. So the broker pupunta tayo doon meron tayo diyang broker then later mare-receive ni um consumer. So sabihin nating ah order created tapos mapupunta siya ah invent let's say inventory inventory service. So iyung possibility responsibil ah possible responsibility ni inventory service is ah ah
1:28:30 receive message. Check inventory inventory. and then reserve stock. Ayan yung possible na ah responsibility ni inventory um ano inventory service. So sa madaling salita guys si producer ang nagse-send ng gagawa ng event which is order service. Once na nakapag-create na siya, meron siyang message na dadalhin papunta
1:29:17 kay broker. Si broker naman siya na yung bahala sa queue. And then after that, si consumer siya na yung inventory um ano inventory service natin. Okay. Kaya natin ilagay sa inventory. Ayan. Okay. So yan si consumer is yung yung receiver yung orders. service yung proceed user
1:30:05 siya naman ang sender. Ang daming term no sender tos ito is receiver okay slash consumer ta's ito na sa producer slash sender. Okay. Um, receiver ah receiver or sa process. Okay. Then si Qan, yung Q is handling ah area destination kung saan maaaring maghintay ang message
1:30:50 bago sila ma-process ng consumer. Dito siya kay broker. Okay? Naka-under siya kay broker. Let's say sa broker no'no. Ah meron tayong tinatawag na Q. Ginagawa ni Qya yung nag um let's say ang bato nito ni order service is 10. Ah 10 na order order undersore created. Okay. Number niya is 00 101.
1:31:39 Yan. Kunyari ganyan. Hanggang 10. 2 3 4 5 Okay. Bago siya mapunta kay inventory bago niya gawin itong mga service na 'to. Okay? Pipilan mo na siya kay broker. So ilan ba yung let's say ilan ba yung worker ni inventory? Depende na lang yon. Pero kanina let's say tatlo yung worker niya. So ibig sabihin tatlo na yung kayang i-accommodate. Yun na yung model which is kung point to point or depende. Kasi ang entrada natin dito kung worker niya work is tatlo e point to point. Pero
1:32:28 kung 'yung tatlo na yun need dito ay yung ito toong tatlong 'to kung niya sa isang order na yan order na 'to which is three message. Kailangan niya dito kailangan niya dito. Kailangan niya dito. So anong gagamitin natin? Publish or point to point? Mas maganda kung point to point ' ba? Kasi kailangan kailangan nitong message na 'to sa lahat. Okay. So gagamitin muna ni Q. Punta muna doon. Pag natapos na ito naman. So depende na lang kung asynchronous or synchronous. Depende na naman ulit yun. Pero yon yun nga guys yun yung pinaka essence ni Q. Okay.
1:33:15 Topic of exchange. So routing point for publish and subscriber. Let's say ganito siya no. Um so yung topic or exchange is kailangan nating maging careful no dahil related sila. Okay? So but not universally identical. Pag sinabi nating topic is commonly associated with publish or subscriber. Pero pag sinabi nating exchange is more on particularly in system such as rabbit queue or routing component. So let's say si publisher um yun nga yung tatlong to okay um
1:34:01 commonly associated with the publish or subscriber. So kung multiple subscriber can receive react to the publish event so ano ang gagamitin natin topic. Okay. kung kinakailangan ito topics or tapos kung exchange naman let's say routing component uh producer exchange [sumisingasing] tapos meron tayong Q1 and Q2 tapos customer um customer natin let's say ah consumer natin let's say dalawa
1:34:47 and then pwede na natin silang sabay-sabayin itong order created one and two. Maybe ang mangyayari mag--exchange tayo maybe dito kay receive receive message one or check inventory. Pero kung ang ano natin is sa queue natin where in order created 101 kailangan siya sa lahat. So topic. Okay. So ang exchange guys is tumutulong mag-decide kung saan ira-rout yung message based on the configured routing rules. Okay. Topic exchange relate to how
1:35:34 published message are organized or route toward interest destination. kasi um meron silang similarity but different yung kanilang uh nagiging approach. Okay. Pagdating kay uh topic so commonly associated with the publish or subscribe with the multiple subscriber can receive or react to the published event while exchange is particularly in a system such as rabbit queue for the routing component. talagang literal na tumutulong lang siya to organize the routing uh
1:36:20 configuration. Next is yung acknowledgement. Sabi sa acknowledgement diyan guys is consumer confirm a message was handled. So ito yung concept guys na um wherein um binibigyan ng broker ang consumer ng message. Let's say si broker tapos na siya na um nasa que pinadalan na kay consumer. Let's say dito itong order na to pinadalan na which is kay inventory service. So para malaman ng broker kung successful ang process na iyon o diyan ginagamit yyung acknowledgement. So
1:37:07 commonly used for the shorter as 2 um ACK or acknowledgement. So ang conceptual n is from broker yung message na yung message t's broker okay papadala kay consumer which is yung order created 101 so pag nag-successful yun ang mangyayari magpapadala lang siya ng acknowledgement kay broker okay ang mangyayari diyan magpapadala siya ng acknowledgement kay broker para at least malaman ni broker na um successfully handled 'yung message. Okay. So, next
1:37:52 'yung dead letter Q naman. And then letter Q naman is hold message that could not be uh proceed. So kunwari um sabihin natin ganito um merong temporary failure supposema dun sa message. Nakaka sabihin natin dito ang value niya. naal t's t's kunwari lang ano um dito quantity tapos dito ang nakalagay yung negative 500 so consumers try to
1:38:41 process it si consumer ita-try niyang ipa-process yan yung message na ganyan but nagfi-fail siya because of yung message na pinad dala. So ayaw nating maging ah um alam mo 'yun yung parang looping paulit-ulit siya or forever na paulit-ulit na nagpa-process. Okay. After the configure failure rejection condition so the system may move or route the message into a dead letter Q or D LQ. So ang pinaka-conceptual niya guys is um from main queue natin. So consumer na-receive niya kung
1:39:28 nag-acknowledgement. Pero kapagka merong repeatedly or ah defined failure na nangyayari doon kay consumer ito or kay inventory service. So magkakaroon ng dead letter Q. So the letter Q give a developer operation um somewhere to inspect troubleshooot or potentially reprocess failed message. Okay. So an natin no um i-justify natin. So number one is producer. So si producer ang ginagawa niya guys is
1:40:14 ah publish publish or send message. Okay. Number two is topic or exchange. So ang ginagawa niya guys is nagra-route. Okay, nagra-rout yan. And then dito naman sa three after niyang ma-rout sa que, ang ginagawa niya sa queue is ang handle niya is yung deliver.
1:41:01 And then ay maliit onong producer ko. Producer. And then sa number four is yung consumer. Consumer. So ginagawa naman ni consumer guys is ayan um success fully ah process successfully process dito papasok si number five
1:41:47 which is yung ating ah AK K AC or yung tinatawag na AC uh acknowledge acknowledgement and then kapagka let's say mali kumbaga nagkaroon ng uh cannot be processed due to sabihin natin failure dito papasok si number six which is the dead uh letter Q.
1:42:34 Okay. So ganyan ang process. Okay. So remember guys, producer create the message. The broker route called it through the messenging destination. The consumer process it then the acknowledgement confirm it successfully handling or else a dead letter Q provides a place for message that cannot be successfully proceed. So ito yung mga kinakailangan nating mga word para at least kahit paano hindi tayo masyadong na nagugulat or nahihirapan na intindihin. Okay. user is publish or the message and then the topic or exchange which is to finding or
1:43:20 to or to provide a proper routing for the queing naman is yung siya natin ini-stock lahat depende dun sa request ni producer. So ide-deliver niyo ng maayos kay custom ay kay consumer. Si consumer naman is mayroon din namang um process na ginagawa. Number one, if successfully uh process, so na-acknowledgement siya. So kapag hindi naman due to the failure doun sa message or anything so may tong dead letter may pupunta din kay broker. Okay so sana clear tayo doon. So next tayo.
1:44:08 So broker um will he about the model yung ating rabbit MQ apa CF ka active QM. So meron tayo diyan tinatawag na model, best form, message, taste, strength. Kumbaga identify lang natin. Okay. Sa previous kasi pinag-usapan natin yung concept eh. producer, consumer, que topic acknowledgement dead letter que Ngayon naman is tingnan natin yung actual technology na ginagamit para ma-implement ang messenging architecture na yon. Okay? There were the three common names na na-encounter ninyo which is the rabbit que, MQ, Apache Kapka and
1:44:53 Active MQ. So ah this is the important guys na hindi sila simpleng tatlong magkakaparehas na product na na pagpipilian lang. So may mga diperensya sila sa architecture at sa problem na ah sino-solve. Okay. Dito muna tayo kay Rabbit MQ. Kay Rabbit MQ guys is a traditional message broker also known for Q or N. flexible message routing. So typically ang nangyayari diyan. So producer, exchange queue and customer and consumer. So mapapansin ninyo yung familiarity ng lahat ng terms na ginamit
1:45:39 natin. Producer, exchange, que consumer. Okay. So ah kay Rabbit is yung exchange kay Rabbit MQ yung exchange. So instead na produc producer direct choosing a consumer ah sa rabbit MQ ang nangyayari is producer exchange okay exchange and then que tapos pupunta sa consumer okay so the exchange use routing roots to determine which queue ors should receive a message. So appropriate natin
1:46:25 diyan is iyung task routing. Okay. Suppose meron tayong document process application. So PDFQ tapos PDF worker. Okay. So mag-a-upload kunyari nag-a-upload ako. Nag-upload ang um producer. So sa exchange ah image queing tapos image worker tapos may video queing or video worker. Okay parang ganun siya. Okay, depending on the message routing configuration, the work the broker can direct work to the appropriate queue. Okay? Kaya sabihin natin ano eh ang strong use case ni
1:47:13 Rabbit MQ yung background job, task, work distribution and flexible routing. Sa simplified queue model message normally remain available until they are successfully handed acknowledgement subject to configuration such as um durability TTL ano pa ba expiration and que policy. So so ito rin yung ano uh connection sa acknowledgement na pinag-aralan natin kanina. Okay. So yun yung mga typically
…
