Мидълуер
Мидълуер – Междинен интеграционен софтуер (на английски: Middleware) представлява междинен слой между софтуерните приложения и операционната система, който осигурява по-лесното разработване на сложни софтуерни системи (разпределени, компонентно-базирани и др.) като освобождава (абстрахира) тези приложения от конкретните специфики и особеностите на използваната операционна система, хардуерните компоненти и комуникационните протоколи. Основната цел на мидълуер е да се справи с хетерогенността, присъща за този тип системи (по отношение на използвания програмен език, спецификата на използваните операционни системи – пр. как са представят данните в нея и др.). Ако трябва да бъдем по-конкретни по отношение на разположението на middleware-а, то той е позициониран в OSI модела върху сесийния и представителния слой, като използва транспортния слой за осъществяване на комуникацията между отделните хостове (чрез TCP/UDP протоколите) и в същото време обслужва на едно по-високо ниво софтуерните приложения (приложния слой). Поради тази причина той често се разбира двояко:
- Мидълуер като програмна абстракция – Изразява се в разбирането на middleware като множество от архитектурни и програмни решения (абстракции) свързани с разработване и интегриране на сложни софтуерни системи (каквито са разпределените системи, компонентно-базираните системи и др.). Пример за такова решение е използването на RPC – програмна абстракция, която позволява процедурни извиквания между приложения изпълнявани на отдалечени хостове като в същото време скрива подробностите и детайлите по самата комуникация. Множеството от подобни програмни абстракции оформят програмния модел нa конкретния middleware-а, който от своя страна определя неговите характеристики и областите му на приложение;
- Мидълуер като инфраструктура – Изразява се в разбирането на middleware като среда, която предоставя готови софтуерни решения (реализации) и инструменти, които могат директно да бъдат използвани с цел изграждането на сложни софтуерни системи или тяхното интегриране. Пример за такива готови софтуерни решения и инструменти са IDL (Interface Definition Language), интерфейсен компилатор, библиотеки за трансформиране на данни (обслужващи процес на marshaling/unmarshaling) и др. Те в своята съвкупност образуват сложна софтуерна инфраструктура, която по същество реализира програмния модел заложен в конкретния middleware и определя неговите нефункционални параметри (като производителност, надеждност, ефективност при управлението на ресурси и т.н.);
Функции[редактиране | редактиране на кода]
Тъй като основната цел на middleware е да обслужва комуникацията между приложения изпълнявани от отдалечени хостове, то нейните функции са свързани с различни аспекти от тази комуникация, а именно:
- Да осигури мрежовата комуникация между отделните приложения – Включва осъществяването на мрежовата връзка, предаването на данни (включва процесите по marshaling/unmarshaling), затварянето на мрежовата връзка и т.н. между два или повече отдалечени хоста;
- Да координира комуникацията между отделните приложения – Включва осъществяването и прекратяването на комуникацията (активиране/деактивиране и свързаните с тях политики) и стратегиите за нейното осъществяване (синхронно, еднопосочно, отложено синхронно, асинхронно, групово и т.н.);
- Да осигури надеждност на осъществяваната комуникация (пр. използването на атомарни транзакции) и система за прихващане на грешки;
- Да осигури прозрачност и разширяемост;
- Да осигури хетерогенност – по отношение на използваните програмни езици, хардуерните платформи, операционните системи, използван Мидълуер и т.н.
Класификация[редактиране | редактиране на кода]
Мидълуер се класифицира в три основни групи в зависимост от целите, които преследват и съответно начина, по който ги реализират:
- Mидълуер ориентиран към транзакции – Създаден е с цел да осигури преноса на разпределени транзакции между отдалечени разпредели бази от данни. Следователно при този тип middleware хостовете представляват приложения работещи с бази от данни, а комуникацията между тях се осигурява чрез стандарти протоколи и механизмите, които описват разпределените транзакции;
- Mидълуер ориентиран към съобщения – Създаден е с цел да осигури ефективна и надеждна асинхронна комуникация между отделните компоненти на разпределената система чрез обмена на съобщения. Процеса на работа включва изпращането на съобщение (обикновено представлява структурирано множество от данни, характеризиращо се с тип и параметри, представляващи двойки от име и стойност) от страна на клиента, който изисква изпълнението на определена услуга. Последния когато е готов изпраща обратно съобщение с резултата от услугата. Всичко това се извършва асинхронно и е изключително подходящо при изграждането на системи използващи събития и publish/subscribe механизми. Освен това той предоставя възможността за едновременното изпращането на съобщения до много получатели и осигурява по-голяма надеждност (чрез използването на опашки от съобщения). Същото така е възможно използването на т.нар. брокери на съобщения (който могат да реализират специална логика за рутиране на съобщенията или тяхната трансформация);
- Обектно ориентиран мидълуер – Създаден е с цел да осигури ефективна комуникация между отдалечени приложения като ги представи като разпределени обекти, които имат пряк достъп до определени, предварително дефинирани свои операции, атрибути или вътрешни обекти. Този мидълуер е базиран на обектно ориентирания подход и основната идея при него е възприемането на отдалеченото приложение като обект в текущото приложение.
Обектно ориентиран мидълуер[редактиране | редактиране на кода]
Основните понятия свързани с обектно ориентираните мидълуер са:
- RPC (Remote Procedure Call) – Обектно ориентирания middleware надгражда системите използващи RPC (викането на отдалечени процедури с локални аргументи и получаването на резултат), като въвежда по-добри механизми за прихващане и обработка на грешки, позволява наследяване и още мн. други подобрения;
- Дефиниция на интерфейс и IDL (Interface Definition Language) – Чрез този интерфейс се дефинират операциите, които са позволени за отдалечен достъп. Те се описват чрез използването на специални IDL езици (които се използва за да опише целия обектен модел) като така се осигурява независимост спрямо избора на конкретен програмен език за реализация;
- Клиент/сървър стъб/скелетон – Реализират конкретни интерфейси от страна на клиента (стъб) и сървъра (стъб/скелетон) и осигуряват протичането на прозрачна комуникация между тях. Те се грижат за процесите на marshaling/unmarshaling и почти всеки middleware предоставя компилатор, позволяващ автоматичното им генериране с помощта на IDL;
- Разпределени обекти – Най-общо казано това са обекти, които отделните приложения в обектно ориентирания middleware „споделят“;
- Регистриране на обекти – За да бъде един обект разпределен и съответно достъпен през middleware-а е необходимо той да бъде регистриран. За целта се използват т.нар. implementation repository, което се реализира различно в отделните обектно ориентирани middleware (пр. в CORBA се използват т.нар. обектни адаптери). Той служи освен за регистрирането и „откриването“ на обекта, но и за неговото активиране/ деактивиране;
Създаването на разпределени обекти включва следните етапи: дизайн на обектите, дефиниция на интерфейса, генериране на стъбовете, имплементация на клиентския стъб, имплементация на сървърния стъб и регистриране на сървърния обект;
Сред най-често използваните обектно ориентиран мидълуер са:
- CORBA (Common Object Request Broker Architecture) – Всеки обект има идентификатор, достъп до отдалечени обекти се осъществява с помощта на указатели (references), статични типове, дефиниране на сложни типове, поддръжка на модули, позволено е дефинирането на атрибути и операции (с in/out/inout параметри), поддържа наследяване и полиморфизъм. Архитектурата му включва следните компоненти: ORB (Object request broker), което е ядрото на мидълуера (получава заявките от клиента, намира сървърния обект чрез подадения указател, предава му параметрите и след това връща отговора на клиента); Client stub/Implementation skeleton, които осъществяват marshaling/unmarshaling; Dynamic invocation, чрез които се използват за динамичното дефиниране на заявки по време на изпълнение; Object adapter; ORB Interface, който се използва за инициализация и дефиниране на обектите;
- COM/DCOM – Прави се разлика между интерфейс (дефиниращ протокол за комуникация и задължително притежаващ ID), имплементация (клас, който реализира интерфейс) и клас (конкретна имплементация, която може да бъде използвана за типизиране и също притежаващ уникално ID)
- Java/RMI (Remote Method Invocation)