Състоянието на средния софтуер за приложения на Java, част 1

Клиентът / сървърът е мъртъв. Това е шумът сега, когато по-новите интернет базирани технологии процъфтяват. Но тези нови технологии са просто естествената еволюция на по-ранните подходи, приложени с по-нови, по-отворени протоколи и предназначени да осигурят по-голяма мащабируемост, управляемост и разнообразие.

Мащабът на тази еволюция е поразителен. Повечето от големите доставчици на клиенти / сървъри са модернизирали своите продукти и сега насочват своите маркетингови долари към тристепенни технологии. В повечето случаи по-новите продукти са ориентирани към Java и Интернет-протокол. Например, при последно броене идентифицирах най-малко 46 продукта на Java среден софтуер. Преди две години щеше да е трудно да се избере половината от този брой.

Това е първата от поредица от две части статии, посветени на обяснението на средния софтуер за Java с общо предназначение в настоящите му форми. В тази първа статия ще разгледам характеристиките на текущите продукти и ще обясня защо тези характеристики са важни. Във втората част Anil Hemrajani ще проучи Enterprise JavaBeans (EJB) и ще покаже как текущото поколение Java продукти за мидълуер е свързано и поддържа този важен компонент стандарт.

Заден план

На първо място, нека дефинираме Java средния софтуер.Терминът обхваща сървъри за приложения като BEA WebLogic, продукти за съобщения като ActiveWorks на Active Software и SpiritWAVE на Push Technologies, както и хибридни продукти, които се базират на наследство на СУБД и добавят базирани на сървъра функции за изпълнение на обект Java. Бих могъл да се съсредоточа върху по-тесен сегмент, като сървъри за приложения, но това би било несправедливо по отношение на многото продукти, които не отговарят точно на тази категория, но въпреки това трябва да се вземат предвид при многостепенни приложения. Освен това, дори сред сървърите за приложения има доста спектър, включително тези, които са предимно сървлетни сървъри, както и тези, които са базирани на ORB или OODB. Поставянето на граница между всички тези продукти се оказва все по-трудно. Обединяващата функция обачее, че всички те се опитват да разрешат проблема с внедряването на мултитиър приложения, използвайки Java и интернет технологии.

Бизнес аргументът за използване на Java в мидълуер е убедителен; сред предимствата, предлагани от Java средния софтуер, са следните:

  • Способността на Интернет да свързва икономически офиси и организации

  • Необходимостта организациите да си сътрудничат чрез споделяне на данни и бизнес процеси

  • Желанието да се консолидират генеричните услуги и управлението на тези услуги

  • Желанието да се осигури централизирано управление на приложенията, включително стартиране, изключване, поддръжка, възстановяване, балансиране на натоварването и мониторинг

  • Желанието да се използват отворени услуги и протоколи

  • Желанието да се преразпредели бизнес логиката по желание и неограничено от инфраструктурата; това налага използването на отворени API и протоколи, които се поддържат широко в повечето инфраструктурни продукти

  • Необходимостта да се подкрепят сътрудничещите приложения със смесена архитектура

  • Желанието да се преместят решенията за мрежова и сервизна инфраструктура извън пространството на приложенията, така че системните мениджъри да могат да вземат решения за инфраструктура, без да бъдат възпрепятствани от приложения, които зависят от патентовани протоколи или функции

  • Желанието да се намали разнообразието и нивото на необходимите умения на персонала на програмистите и да се сведе до минимум необходимостта от усъвършенстван опит в изграждането на инструменти в рамките на проекти

  • Желанието да се използва обектно-ориентиран опит, като се разшири в сферата на сървърите - следователно по-нови обектно-ориентирани сървърни продукти и обект-към-релационни мостове

Целта на междинния софтуер е да централизира софтуерната инфраструктура и нейното внедряване. Клиент / сървър произхожда от ерата на интеграция в рамките на един отдел. Понастоящем организациите често се опитват да се интегрират през отделните граници - дори от една организация в друга. Интернет - който примамва бизнеса със способността му да служи като глобална мрежа, която позволява на отделите и партньорите да се свързват ефективно и бързо - генерира търсенето на тази интеграция.

Java предоставя lingua franca за лесно свързване на данни и приложения през организационни граници: В разпределена глобална среда, в която нямате контрол върху това какъв избор на технология могат да направят вашите партньори, интелигентните компании избират отворени и неутрални за платформата стандарти. Компаниите не могат да предвидят кой ще стане техен клиент, партньор или дъщерно дружество след две години, така че не винаги е възможно да се планира обща инфраструктура с партньорите. В тази несигурна ситуация най-доброто решение може да бъде използването на възможно най-универсалните и адаптивни технологии.

Java ви позволява да намалите броя на програмните езици и платформи, които вашият персонал трябва да разбира. Защо? Тъй като Java вече е внедрена в толкова разнообразен контекст, колкото интернет браузърите, съхранените процедури в базите данни, бизнес обектите в продуктите на мидълуер и приложенията от страна на клиента.

На тригодишна възраст обаче технологията Java все още е малко незряла и това важи за продуктите, обсъдени в тази статия. От друга страна, сега може да сме в ера, когато продуктите никога никога не достигат зрялост, защото основните технологии, на които се основават, се променят толкова бързо. Всъщност открих значителни проблеми на практика с всеки продукт на мидълуер, който съм използвал, включително уж зрели продукти, които са на пазара от няколко години и наскоро излязоха със значителни нови функции. Въпросът е, че когато продавачът успее да отстрани проблеми, са добавени нови функции. Цикълът за добавяне на нови функции сега е много по-кратък от всякога и затова продуктите нямат достатъчно време, за да станат стабилни, преди да включат следващия основен набор от функции.Това може да е нещо, с което трябва да свикнем и изучаването на силните и слабите страни на продуктите, които избираме, е важна част от всеки цикъл на проектиране на приложения и прототип.

Цели за мидълуер

Стандартът за компоненти на EJB за междинен софтуер е разработен със следните цели:

  • За осигуряване на оперативна съвместимост на компонентите. Предприятията, разработени с различни инструменти, ще работят заедно. Също така, зърната, разработени с различни инструменти, ще работят във всяка EJB среда.

  • Да осигури лесен за използване модел на програмиране, като същевременно поддържа достъп до API на ниско ниво.

  • За справяне с проблеми на жизнения цикъл, включително разработка, внедряване и време на изпълнение.

  • Да се ​​осигури съвместимост със съществуващите платформи, което позволява да се разширят съществуващите продукти, за да се осигури поддръжка за EJB.

  • За поддържане на съвместимост с други API на Java.

  • За осигуряване на оперативна съвместимост между EJB и приложения, които не са Java.

  • За да бъде съвместим с CORBA.

Следователно фокусът на стандарта EJB е върху създаването на стандарт за оперативна съвместимост на Java средния софтуер, предпазващ програмистите от необходимостта да се справят с много от трудните проблеми, които възникват при разработването на разпределени приложения. Това позволява на разработчиците на софтуер да се концентрират върху бизнес логиката, вместо да пишат сложна домашна инфраструктура и инструменти. В резултат на това предприятията могат да вложат по-голямата част от своите образователни ресурси в обучение на персонал по бизнес процеси, което обикновено е това, което осигурява най-голяма печалба.

Към горния списък добавям следните допълнителни цели за Java среден софтуер от корпоративен клас. Тези характеристики на продукта са необходими в дългосрочен план, за да може успешно да се поддържа и поддържа среда, базирана на мидълуер:

  • Той трябва да побере взаимовръзката на множество бизнес единици, компании и клиенти в разпределена инфраструктура, без да се застрашава сигурността или да се въвежда хаос

  • Той трябва да позволява гъвкави, но надеждни механизми за контрол на достъпа, за да се гарантира достъпът до данните на бизнес партньорите само по предвидените начини и само от предвидените страни

  • Той трябва да позволява на системните администратори да управляват разпределена изчислителна среда, съдържаща голям брой компоненти на бизнес логиката, по еднакъв начин, без да се налага да разбират или прилагат уникални процедури към определени компоненти

  • тя трябва да позволи на системните администратори да правят избор на компоненти на инфраструктурата, без да засягат приложенията, да настройват и мащабират тези компоненти и да имат еднакви и общи средства за измерване на производителността и нуждите от ресурси на всички приложения

  • Той трябва да позволява преместване на бизнес компоненти между клиенти и сървъри, без да се засяга архитектурата на нито един от двата

  • Той трябва да осигури механизъм за сигурност, който позволява на определени потребители да добавят нови компоненти, без да се налага да дава на администратора на сървъра достъп до всички компоненти и източници на данни (това е чудесна възможност за добавена стойност, тъй като е от решаващо значение за екстранет и приложения за партньорство )

Компоненти и характеристики на платформите за мидълуер на Java

Най-бързо развиващата се категория Java среден софтуер днес вероятно е сървърите за приложения. Важно е обаче да се реализира голямото разнообразие от сървъри за приложения (и други видове продукти на междинния софтуер), които съществуват. Разграниченията между категориите продукти на Java за мидълуер днес са представени не от линия, а от огромен континуум на мидълуер. Сега ще обсъдя характеристиките на Java средния софтуер, базиран на моите собствени сравнения на работата, които обхващат всеки клас Java среден софтуер, за който знам.

Модели на обекти, компоненти и контейнери

Компонентите на приложението трябва да се придържат към някакъв модел за внедряване по време на изпълнение, който определя как компонентът комуникира със своята среда; (евентуално) как се инсталира, стартира, спира и се извиква; и как той осъществява достъп до услуги, важни за неговата среда. Популярните модели за изпълнение и контейнери със сървърни компоненти, ориентирани към Java, включват RMI, EJB, CORBA, DCOM, сървлет, JSP (Java Server Pages) и Java съхранени процедури. В допълнение, моделите на компонентите могат да бъдат изразени в различни основни езици, включително Java, IDL, C ++ и много други.

Има припокриване с различни модели компоненти. Например RMI е тривиален компонентен модел с много основни съоръжения за активиране на обект и местоположение и е предимно стандарт за отдалечено извикване, докато EJB използва RMI и определя RMI като свой основен модел за извикване на обект. EJB също поддържа CORBA. Всъщност нито един от тези модели не е изключителен и много сървъри за приложения на Java поддържат повечето или всички модели по-горе.

Много сървъри за Java среден софтуер изпълняват множество екземпляри на бизнес обекти (които в света CORBA сега нарича слуги) в рамките на една Java виртуална машина (JVM). Типовата безопасност на езика Java позволява на един JVM процес да обслужва заявки от множество клиенти и да използва програмни структури от данни и зареждащи класове, за да поддържа клиентските данни отделни. Докато служителите не използват собствени собствени методи, не е възможно един служител да свали други служители, ако се срине (освен ако не срещне грешка в самия JVM) или да получи достъп до данни, които са частни за други класове . Правилно проектираният обектен сървър ще защити своите частни обекти и ще попречи на грешните обекти да имат достъп до това, което принадлежи на други обекти.

Въпреки това, данните, декларирани като статични в клас Java, могат да се споделят между клиенти в рамките на един и същ JVM, ако клиентите използват един и същ клас за зареждане, така че правилата трябва да бъдат дефинирани, за да диктуват кога отделен JVM (или еквивалентът на отделен JVM, използващ памет техники за разделяне) или е необходим отделен зареждащ клас, за да се даде на клиента собствено пространство за статични данни. Такива правила са определени за аплети, но не и за други среди за изпълнение. Java уеб сървърът на Sun използва един JVM за всички сървлети и отделно пространство от имена на класове за сървлети с различна кодова основа. EJB заобикаля проблема, като забранява нефинални статични данни.

Ефективността може да се увеличи, ако обектите са инактивирани или пасивирани, когато не се използват, освобождавайки ресурси като връзки с база данни. Поради тази причина много сървъри пасивират и реактивират обектите, както е подходящо. По същия начин някои продукти поддържат често създавани обекти в пул или кеш в инициализирано състояние и готови за незабавна употреба. Обектният контейнер трябва да управлява пасивирането и повторното активиране, както и обединените ресурси, засегнати от пасивирането.

EJB съвместимост (версия)

Моделът EJB вече става всеобщо поддържан. Почти всеки доставчик на мидълуер е обещал да го поддържа и много вече го правят. Освен това Групата за управление на обекти (OMG) е включила картографиране към EJB като част от предложената спецификация на компонентите на CORBA. Трудно е да си представим, че дори Microsoft, самотният и непоколебим задържане, в крайна сметка няма да даде и предостави EJB контейнери за DCOM.

Въпреки че различен EJB-съвместим междинен софтуер може да внедрява и експлоатира едни и същи компоненти на приложението (стига тези компоненти да използват само стандартно необходимите функции на EJB), все още има много вариации сред EJB-съвместимите сървъри. От една страна, самата спецификация на EJB се развива. Следователно, важен въпрос при оценяването на продуктите на Java за среден софтуер е: Сървърът поддържа ли най-новата версия на EJB или поддържа само по-ранна версия? Друг ключов въпрос е: Дали продуктът е ориентиран към EJB или поддръжката на EJB е включена само в функциите с добавена стойност на продукта (и следователно не е налична, когато се използват услуги или API на EJB)? И накрая: Кои незадължителни EJB функции са включени (например обект на обекти и устойчивост, управлявана от контейнери)?