Metodologjitë për Zhvillimin e Shërbimeve Ueb – Zhvillimi i Aplikacioneve Mobile, Shërbimeve Ueb, Arkitektura SOA - Teknologji
Kalo te përmbajtja

Metodologjitë për Zhvillimin e Shërbimeve Ueb – Zhvillimi i Aplikacioneve Mobile, Shërbimeve Ueb, Arkitektura SOA

Reklamat

Coulouris i përkufizoi sistemet e shpërndara si "sisteme në të cilat komponentët e harduerit dhe/ose softuerit që ekzistojnë në një rrjet kompjuterik komunikojnë dhe koordinojnë veprimet e tyre duke shkëmbyer mesazhe".

Ky koncept është bërë popullor vitet e fundit për shkak të disa faktorëve. Faktori i parë që nxiti zhvillimin e sistemeve të shpërndara ishte shfaqja e rrjeteve lokale me shpejtësi të lartë. Një faktor tjetër i rëndësishëm ishin përparimet teknologjike në performancën e kompjuterëve personalë dhe zhvillimi i softuerit për të mbështetur aplikacionet e shpërndara. Sistemet e shpërndara janë të lidhura me konceptin e Uebit dhe Internetit. Me evolucionin e Uebit dhe shfaqjen e zonave, ndërveprimeve, nevojave dhe aplikacioneve të reja, shfaqet koncepti i Web 2.0. Ky term u krijua nga Tim O'Reilly në 2004 për t'iu referuar një brezi të dytë në historinë e Uebit të bazuar në komunitetet e përdoruesve dhe një gamë të veçantë shërbimesh, të tilla si rrjetet sociale, bloget, wikis ose folksonomies, që inkurajojnë bashkëpunimin dhe shkathtësinë. shkëmbimi i informacionit ndërmjet përdoruesve.

Arkitekturat e para që mund të konsiderohen të orientuara nga shërbimi (SOA) u bazuan në CORBA (Arkitektura e Ndërmjetësimit të Kërkesës së Objekteve të Përbashkëta), e cila veproi si një shtresë abstraksioni për të ndërlidhur elementët e ndryshëm të arkitekturës dhe për të ndërtuar shërbime. Teknologji të tjera të hershme ishin DCOM (Distributed Component Object Model) ose RPC (Remote Procedure Protocol). Me nevojën për të dizajnuar dhe zbatuar sisteme të shpërndara në Web në mënyrë efikase, lindin disa sfida, disa të përqendruara në vetë zhvillimin (performanca, përvoja e përdoruesit, etj.) dhe të tjera plotësuese, bazuar në ripërdorimin dhe përputhshmërinë e shërbimeve. Nga këto nevoja lindin Web Services, të cilat ofrojnë mekanizma të standardizuar për të ndërlidhur përdorues të ndryshëm me serverët e informacionit.

ARKITEKTURA TË ORIENTUARA NË SHËRBIM

Sipas SOA (Service Oriented Architecture) ato janë arkitektura softuerike që përcaktojnë përdorimin e shërbimeve për të mbështetur kërkesat e biznesit, objektivi i të cilave është arritja e lidhjes minimale të mundshme midis agjentëve softuerikë. Një shërbim është një njësi e punës e kryer nga një ofrues shërbimi për të arritur një rezultat përfundimtar të dëshiruar nga një konsumator shërbimi. Si ofruesi i shërbimit ashtu edhe konsumatori i shërbimit janë role të luajtura nga agjentët e softuerit, jo nga pronarët e tyre. Në një kuptim të përgjithshëm, një arkitekturë e orientuar nga shërbimi është një zgjidhje softuerike që synon të lejojë një kompani të organizojë dhe të përdorë procese të ndryshme. Me SOA, aplikacionet softuerike nuk janë më blloqe të mëdha funksionesh dhe procesesh. Në vend të kësaj, këto aplikacione përbëhen nga shërbime modulare të montuara. Mos harroni se një shërbim është një funksion i thjeshtë softueri (si anulimi i riprodhimit në një CD). Mund të ekzekutohet sipas kërkesës nga çdo sistem, pavarësisht nga sistemi operativ, platforma, gjuha e programimit ose vendndodhja gjeografike.

Ajo që është revolucionare në lidhje me SOA nuk është vetë koncepti, i cili ka ekzistuar për një kohë të gjatë, por fakti që ai mund të zbatohet përmes WWW (World Wide Web). Ashtu si faqet e internetit ngarkohen në çdo platformë, shërbimet e uebit funksionojnë në mënyrë të ngjashme, pavarësisht nga platforma që janë ndërtuar duke përdorur
standardet universale.

FotografiIdeja e SOA buron drejtpërdrejt nga programimi i orientuar nga objekti, i cili sugjeron një marrëdhënie midis të dhënave dhe përpunimit të tyre. Kështu, ato përcaktojnë zyrtarisht shërbimet përmes ndërfaqeve që janë të pavarura nga platforma themelore dhe gjuha e programimit. Këto ndërfaqe fshehin veçoritë e zbatimit të tyre, gjë që i bën ato të pavarura nga zhvilluesi dhe gjuha e programimit. Nëpërmjet këtyre arkitekturave, është e mundur të projektohen dhe zbatohen sisteme shumë të shkallëzuara që pasqyrojnë logjikën e biznesit dhe në të njëjtën kohë lehtësojnë ndërveprimin midis sistemeve të ndryshme të pronarit ose të palëve të treta. Arsyeja pse duam që dikush të bëjë punën për ne është sepse ata janë ekspertë. Përdorimi i një shërbimi është përgjithësisht më i lirë dhe më efektiv sesa ta bësh vetë. Pra, shumica prej nesh e kuptojnë se nuk mund të jemi ekspertë në gjithçka. I njëjti rregull mund të zbatohet për ndërtimin e sistemeve softuerike.

Ndërfaqet janë jashtëzakonisht të rëndësishme, nëse ato nuk janë të përcaktuara mirë ose nuk funksionojnë, sistemi nuk funksionon. Integrimi i më shumë ndërfaqeve është i shtrenjtë dhe gjithashtu rrit mundësinë e gabimeve në aplikacionet e shpërndara. Ndërfaqet në distancë janë pjesa më e ngadaltë e aplikacioneve më të shpërndara. Me gjithë këtë, në vend që të ndërtohen ndërfaqe të reja për çdo aplikacion, ka më shumë kuptim të ripërdoren ndërfaqet gjenerike për të gjitha aplikacionet.

Pra, meqenëse kemi vetëm disa ndërfaqe gjenerike të disponueshme, duhet të përfshijmë semantikën specifike të aplikacionit në mesazhe. Ne mund të dërgojmë çdo lloj mesazhi përmes ndërfaqeve tona, por ka disa rregulla që duhen ndjekur për të thënë se një arkitekturë është e orientuar drejt shërbimit.

– Së pari, mesazhet duhet të jenë përshkruese, jo udhëzuese, pasi ofruesi i shërbimit është përgjegjës për zgjidhjen e problemit. Për shembull, do të ishte e ngjashme me situatën kur shkoni në një restorant dhe i tregoni kamarierit se çfarë do të dëshironit të pini dhe preferencat tuaja, por nuk duhet t'i shpjegojmë kuzhinierit se si t'i përgatisni gatimet tuaja, hap pas hapi.

‐ Së dyti, ofruesit e shërbimeve nuk do të jenë në gjendje ta kuptojnë kërkesën tuaj nëse mesazhet e tyre nuk janë të shkruara në një format, strukturë dhe fjalor të kuptueshëm për të gjithë të përfshirë. Kështu, kufizimi i fjalorit dhe strukturës së mesazheve është a
të nevojshme për komunikim efektiv. Sa më i kufizuar të jetë mesazhi, aq më lehtë është për t'u kuptuar.

‐ Së treti, mundësia e zgjatjeve është e një rëndësie jetike. Bota është një vend që ndryshon vazhdimisht, dhe po kështu është edhe mjedisi në të cilin jeton softveri. Këto ndryshime kërkojnë ndryshime përkatëse në softuerin e sistemit, konsumatorët të shërbimeve, ofruesve dhe mesazheve që ata shkëmbejnë. Nëse mesazhet nuk janë të zgjerueshme, konsumatorët dhe ofruesit do të kyçen në një version specifik të shërbimit. Kufizimi dhe shtrirja janë thellësisht të lidhura, ju keni nevojë për të dyja, dhe rritja e njërës do të thotë të zvogëloni tjetrën. Idealja është të arrihet një ekuilibër i duhur.

– Së katërti, një SOA duhet të ketë një mekanizëm që lejon konsumatorin të zbulojë një ofrues shërbimi në kontekstin e një shërbimi të kërkuar nga konsumatori. Mekanizmi duhet të jetë fleksibël dhe nuk duhet të jetë një regjistër i centralizuar.

‐ Së pesti, shërbimi pa shtetësi: Çdo mesazh që një konsumator i dërgon një ofruesi duhet të përmbajë të gjithë informacionin e nevojshëm që ofruesi ta përpunojë atë. Ky kufizim e bën një ofrues shërbimi më të shkallëzueshëm sepse ofruesi nuk ka nevojë të ruajë informacionin e gjendjes midis kërkesave. Ky mund të quhet "shërbim prodhimi masiv" pasi çdo kërkesë mund të trajtohet në mënyrë gjenerike. Ky kufizim siguron gjithashtu më shumë dukshmëri, pasi çdo softuer monitorues mund të inspektojë një kërkesë të pavarur dhe të nxjerrë qëllimin e saj. Kjo gjithashtu lejon rikuperimin e lehtë nga dështimet e pjesshme pasi nuk ka gjendje të ndërmjetme, duke e bërë shërbimin më të besueshëm.

‐ Së gjashti, kërkesat idempotente (të cilat nuk bëjnë ndryshime): kërkesat e kopjuara të marra nga një agjent softuerik kanë të njëjtin efekt si një kërkesë e vetme. Kjo kërkesë u lejon ofruesve dhe konsumatorëve të rrisin besueshmërinë e përgjithshme të shërbimi, thjesht duke përsëritur kërkesën nëse ka ndodhur një dështim.

Pra, mund të themi se SOA nuk është një mjet, por një grup standardesh për ndërtimin e aplikacioneve të reja, më dinamike dhe më pak të varura. SOA lehtëson aksesin në logjikën e biznesit dhe informacionin midis shërbimeve të ndryshme në një mënyrë sistematike, dhe gjithashtu mund të orkestrojë disa shërbime në distancë për të formuar një të vetme. Shumica e Përkufizimet identifikojnë përdorimin e Web Services, të cilin do ta shohim në kapitullin vijues, në zbatimin e një arkitekture të orientuar drejt shërbimit. Megjithatë, ai mund të zbatohet duke përdorur çdo teknologji tjetër të bazuar në shërbime.