Еволюцията е част от живота. Дефиницията на еволюцията гласи, че това е постепенен растеж на нещо. Тя може да бъде биологична или техническа. В тази статия ще разгледаме как се развива софтуерното инженерство и различните различни архитектури, които са внедрени.
1 ниво Архитектура
- Ниво на представяне: Това е компонентът (в повечето случаи UI), който потребителят използва, за да взаимодейства с приложението.
- Приложно ниво: Това е бизнес компонентът (логиката) на приложението, който решава какво да прави с входните данни, които получава от презентационния слой.
- Ниво на база данни: Това е компонентът, където се съхраняват и получават всички данни, свързани с приложението.
Забележка: Споменатите по-горе имена ще бъдат използвани за другите архитектури, които са обяснени в следващите раздели.
Първоначално, ако е необходима компания за стартиране на софтуер, тази конкретна част от софтуера се инсталира на всяка машина, която трябва да изпълнява това. В тази архитектура потребителските интерфейси, логиката за изпълнение на приложението, както и базата данни, която съхранява данните за това приложение, се съхраняват на една единствена машина.
Основното предимство на тази архитектура е, че е най-малко сложна. Но това носи голям недостатък, тъй като бизнес логиката и структурата на базата данни се съхраняват в клиентската система.
2-степенна архитектура
Програмистите смятат, че вместо да разполагат с базата данни на всяка отделна система, защо да не я поставят на отделна система, така че всяка машина, използваща приложението, да има достъп до същата база данни, което в случай също ще намали натоварването на твърдия диск.
С помощта на LAN (локална мрежа) компютрите можеха да бъдат свързани помежду си. Така че вместо да записват данни на всеки отделен компютър, те са били записани на една конкретна машина и след това всяка друга машина, която е свързана с тази машина, ще може да получи данните. Сега вместо да работи на една машина, приложението се изпълнява на множество машини. Сега компютрите, които имат приложението (клиент), ще комуникират със системата, която има базата данни (сървър).
Основното предимство на тази архитектура е, че е лесна за проектиране, но не е най-сигурната, тъй като бизнес логиката е от страна на клиента.
Забележка: Двуслойната архитектура и предстоящите архитектурни проекти са известни също като клиент сървър архитектура
3-степенна архитектура
В момента нашата система за приложения е на едно място, а логиката на базата данни е на друго място. Програмистите искаха да оптимизират още повече двустепенната система.
Така че те измислиха начин да разделят нивото на представяне (UI) и нивото на приложението (бизнес логика) поотделно, така че множество машини да могат да използват едно приложение, което се съхранява на една машина, докато имат достъп до базата данни, която е в друга машина.
Предимството на използването на тази архитектура е, че тя има по-добра свързаност на данни в сравнение с 2 нива, тъй като нивото на приложението е отделено от клиентската машина и е по-сигурно. Единственото ограничение биха били проблемите със свързаността, тъй като нивото на приложението ще действа като междинен софтуер между клиента и базата данни (сървъра).
n ниво архитектура
Това също е известно като многослойна архитектура. Тук процесите, които се използват за създаване на приложение, са разделени на множество различни части и са слабо свързани заедно. Тъй като е слабо свързан, това е предимство за системните разработчици да актуализират системите лесно и много разработчици могат да работят поотделно върху различни компоненти едновременно.
Забележка: 3-степенната архитектура също е пример за n-степенна архитектура.
Добре дошъл интернет
Гореспоменатите архитектури могат да бъдат реализирани чрез локална мрежа. Но навлизането на интернет създаде ново предизвикателство за разработчиците относно начина, по който техните системи ще бъдат достъпни. С това имаше 3 различни типа уеб сървъри, които бяха използвани за целите на разработката.
- Уеб сървър
- Уеб контейнер
- Сървър за приложения
Уеб сървър
Уеб сървърите са отговорни за съхраняването на статично съдържание в интернет. Може да съхранява статични html страници, видеоклипове, изображения и музикални файлове. Тези уеб сървъри не се занимават с никакъв вид динамични процеси. Те просто ще върнат тип файл, който е поискан от потребителите. Нека разгледаме един пример.
Когато потребител въведе URL (започващ от http:), браузърът ще отиде и ще провери локалния DNS сървър за този URL. Локалният DNS сървър ще се свърже с уеб сървъра, за да осъществи връзка. След това уеб сървърът ще види дали има исканите данни. Ако го има, той ще изпрати данните до DNS, който след това ще ги изпрати обратно към уеб браузъра. Ако данните не съществуват, ще изпрати съобщение за грешка.
Уеб контейнер
Вместо да изпращат статично съдържание обратно на потребителите, разработчиците измислиха начин динамичното съдържание също да бъде изпратено обратно. Уеб контейнерът също съдържа уеб сървър в него. За да изпрати динамично съдържание, уеб контейнерът ще работи със сървлет компонент.
Servlet ще съдържа методите за изпълнение за динамичното съдържание. Нека разгледаме един пример. Ако се направи заявка към уеб контейнера, той ще провери за съдържанието, което трябва да се върне. Ако е статичен, той ще комуникира с уеб сървъра и ще върне необходимия файл, ако е нещо динамично, ще се свърже със сървлет компонента и методите се зареждат в контейнера. Контейнерът след обработка ще го предаде с файла от уеб сървъра обратно на потребителя.
Забележка: Сървлетите нямат основен метод. Така че зареждането се извършва в уеб контейнера.
Основният недостатък на уеб контейнера е, че той може да зарежда само един тип клас, например уеб контейнер може да може да получава само методи за математическия клас.
Сървър за приложения
Уеб контейнерите не успяха да заредят различни класове едновременно. Само един тип клас. Така че, за да стартира напълно функционално корпоративно приложение, беше създаден Сървърът за приложения. Сървърът на приложения може да извършва процесите както на уеб сървъри, така и на уеб контейнери. Следната диаграма може да улесни виждането на йерархията на трите.
Сървърът на приложения може да изпълнява всички задачи, които и уеб контейнерът, и уеб сървърът могат да изпълняват.
EJB (Enterprise Java Bean) е разработен на сървъри за приложения. Тези видове приложения ще изискват тежка обработка от страна на сървъра. Така че сървърите за приложения са по-скъпи от другите два сървъра.
Забележка: EJB е технология, която е изградена върху RMI (Remote Method Invocation). Има 3 основни EJB технологии. Session bean, Event Driven Bean и Entity Bean. Щракнете тук за повече информация.
Архитектура на микросервизи
Архитектурата на микросервизите с прости думи би била слабо свързани компоненти, които ще комуникират един в друг, за да изпълняват своите процеси. Тъй като те са слабо свързани, много разработчици са в състояние да разработят самостоятелно компоненти и след това да ги внедрят заедно. Тази архитектура е добра за новите разработчици, за да се впуснат в проект и да започнат работа веднага. Основният недостатък на този архитектурен дизайн е, че той може да стане сложен за по-големи проекти и частта за изпълнение може да бъде трудна, като се има предвид голямото количество компоненти, с които се занимават по-големите проекти.
Облачно базирана архитектура
Ако говорим за еволюцията на софтуерната архитектура, определено трябва да поговорим малко за нещо, наречено облак. Облакът е тенденция в днешно време, всички, които разработват приложения, мислят главно за възможностите на облака. Облачните изчисления могат да бъдат разделени на две части.
- Преден край: Това ще бъде клиентската инфраструктура. Клиентите ще могат да взаимодействат директно с. Пример: уеб браузър, мобилни устройства.
- Back End : Това е мястото, където се осъществяват всички други части на приложението, включително базата данни, логиката на приложението и цялата вътрешна комуникация. Сигурността на системата и поддръжката се извършват в задната част.
Забележка: Облачните изчисления са голяма тема, която трябва да се обхване в тази статия. За малко повече информация относно облачните изчисления щракнете тук.
