Ръководство за начинаещи за Enterprise JavaBeans

Предприятието JavaBeans (EJB) предизвика голямо вълнение от обявяването на версията 1.0 на спецификацията Enterprise JavaBeans от март 1998 г. Компании като Oracle, Borland, Tandem, Symantec, Sybase и Visigenic, наред с много други, са обявили и / или доставили продукти, които отговарят на спецификацията EJB. Този месец ще разгледаме на високо ниво какво точно представлява Enterprise JavaBeans. Ще разгледаме как EJB се различава от оригиналния компонентния модел на JavaBeans и ще обсъдим защо EJB е генерирал толкова огромен интерес.

Но първо, съвет: няма да разглеждаме изходния код или темите с инструкции този месец. Тази статия не е урок; по-скоро това е архитектурен преглед. EJB обхваща голяма част от територията и без първо да се разберат основните концепции, кодови фрагменти и трикове за програмиране са безсмислени. Ако има интерес от страна на читателите на JavaWorld , бъдещите статии може да обхванат спецификата на използването на Enterprise JavaBeans API за създаване на собствени Enterprise JavaBeans.

За да разберем защо EJB е толкова привлекателен за разработчиците, се нуждаем от историческа справка. Първо ще разгледаме историята на клиент / сървърните системи и текущото състояние на нещата. След това ще обсъдим различните части на EJB система: EJB компоненти - които живеят в EJB контейнер, работещ в EJB сървър - и EJB обекти, които клиентът използва като вид „дистанционно управление“ на EJB компоненти . Тук ще разгледаме двата типа EJBs: сесия и автономните обекти. Ще прочетете и за дома и дистанционнотоинтерфейси, които създават екземпляри на EJB и осигуряват достъп до бизнес методите на EJB, съответно. В края на статията ще имате представа как могат да бъдат изградени разширяеми сървъри с помощта на Enterprise JavaBeans. Но първо, поглед назад във времето.

История на клиент / сървър

Древна история

В началото имаше основният компютър. И беше добре. (Или както и да е добър, така или иначе.) Състоянието на техниката в обработката на информация през 60-те години се състои предимно от големи, скъпи машини, използвани от големи организации за подпомагане на ежедневните им бизнес операции. Миникомпютрите и споделянето на времето през 70-те години увеличиха достъпността на изчислителната мощ, но информацията и обработката все още бяха централизирани на отделни машини. Първите персонални компютри през 80-те години бързо затрупаха корпоративния пейзаж с хиляди миниатюрни острови с информация, като всички неуморно изхвърляха доклади с променливо качество, губеха важни данни при срив и бързо ставаха несъвместими помежду си.

Клиент / сървър на помощ

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

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

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

Сървърите на бази данни обаче имат някои задължения. Често SQL за определена бизнес функция (например добавяне на елемент към поръчка) е идентичен, с изключение на данните, които се актуализират или вмъкват, от обаждане до повикване. Сървърът на базата данни в крайна сметка анализира и преработва почти идентичен SQL за всяка бизнес функция. Например всички SQL изрази за добавяне на елемент към поръчка вероятно ще бъдат много сходни, както и SQL изразите за намиране на клиент в базата данни. Времето, което отнема този анализ, ще бъде по-добре изразходвано в действителност за обработка на данни. (Има проблеми с този проблем, включително кеш за синтактичен анализ и съхранени процедури на SQL.) Друг проблем, който възниква, е версирането на клиентите и базата данни едновременно: всички машини трябва да бъдат изключени за надстройки,и клиентите или сървърите, които изостават в своята софтуерна версия, обикновено не са използваеми, докато не бъдат надстроени.

Сървъри на приложения

Един сървър за приложения архитектура (виж следващата снимка) е популярна алтернатива на сървъра на базата данни архитектура, защото тя решава някои от проблемите сървъри на бази данни имат.

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

Системите за бази данни и приложения могат да бъдат подобрени чрез добавяне на допълнителни нива към архитектурата. Така наречените тристепенни системи поставят междинен компонент между клиента и сървъра. Цяла индустрия - мидълуер - се появи, за да отговори на задълженията на двустепенните системи. A транзакция за обработка на монитор,един вид междинен софтуер, получава потоци от заявки от много клиенти и може да балансира натоварването между множество сървъри, да осигури отказоустойчивост при отказ на сървър и да управлява транзакции от името на клиента. Други видове междинен софтуер осигуряват превод на комуникационен протокол, консолидират заявки и отговори между клиенти и множество хетерогенни сървъри (това е особено популярно при работа със стари системи при реинженеринг на бизнес процеси) и / или предоставят измерване на услуги и информация за мрежовия трафик.

Множество нива осигуряват гъвкавост и оперативна съвместимост, което е довело до системи с повече от тези три нива на услуга. Например, n-степенните системи са обобщения на тристепенни системи, като всеки слой софтуер предоставя различно ниво на обслужване на слоевете над и под него. Перспективата от n-ниво разглежда мрежата като пул от разпределени услуги, а не просто като средство за достъп на клиент до един сървър.

Тъй като обектно-ориентираните езици и техники са на мода, така и системите клиент / сървър все повече се насочват към обектно-ориентирана. CORBA (Common Object Request Broker Architecture) е архитектура, която позволява на обекти в приложения - дори обекти, написани на различни езици - да се изпълняват на отделни машини, в зависимост от нуждите на дадено приложение. Приложенията, написани преди години, могат да бъдат пакетирани като услуги на CORBA и да си взаимодействат с нови системи. Предприятието JavaBeans, което е проектирано да бъде съвместимо с CORBA, е още едно влизане в обектно-ориентирания пръстен сървър на приложения.

Целта на тази статия не е да предостави урок за клиент / сървърни системи, но беше необходимо да се предостави някаква предистория, за да се дефинира контекстът. Сега нека разгледаме какво предлага EJB.

Предприятия JavaBeans и разширяеми сървъри за приложения

След като разгледахме малко история и разбрахме какво представляват сървърите на приложения, нека разгледаме Enterprise JavaBeans и да видим какво предлага в този контекст.

Основната идея зад Enterprise JavaBeans е да се осигури рамка за компоненти, които могат да бъдат "включени" към сървър, като по този начин се разширява функционалността на този сървър. Enterprise JavaBeans е подобен на оригиналния JavaBeans само по това, че използва някои подобни концепции. Технологията EJB се управлява не от спецификацията на компонентите JavaBeans, а от напълно различната (и масивна) спецификация за корпоративни JavaBeans. (Вж. Ресурси за подробности относно тази спецификация.) EJB Spec извиква различните играчи в системата клиент / сървър на EJB, описва как EJB взаимодейства с клиента и със съществуващите системи, описва съвместимостта на EJB с CORBA и определя отговорностите за различните компоненти в системата.

Enterprise JavaBeans цели

В EJB Spec се опитва да отговори на няколко цели едновременно:

  • EJB е създаден, за да улесни разработчиците при създаването на приложения, освобождавайки ги от системни детайли на ниско ниво за управление на транзакции, нишки, балансиране на натоварването и т.н. Разработчиците на приложения могат да се концентрират върху бизнес логиката и да оставят подробностите за управлението на обработката на данни на рамката. За специализирани приложения обаче винаги е възможно да влезете „под капака“ и да персонализирате тези услуги от по-ниско ниво.

  • Спецификацията на EJB определя основните структури на рамката на EJB и след това конкретно определя договорите между тях. Отговорностите на клиента, сървъра и отделните компоненти са ясно посочени. (Ще разгледаме какви са тези структури след малко.) Разработчик, създаващ Enterprise JavaBean компонент, има много различна роля от този, който създава EJB-съвместим сървър и спецификацията описва отговорностите на всеки от тях.

  • EJB се стреми да бъде стандартният начин за клиент / сървърни приложения да бъдат изградени на езика Java. Точно както оригиналните JavaBeans (или компоненти на Delphi или каквото и да било) от различни доставчици могат да бъдат комбинирани, за да се създаде потребителски клиент, компонентите на EJB сървъра от различни доставчици могат да се комбинират, за да се създаде потребителски сървър. EJB компонентите, като Java класове, разбира се ще работят във всеки EJB-съвместим сървър без рекомпилация. Това е предимство, което решенията, специфични за платформата, не могат да се надяват да предложат.

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

Как работи системата EJB клиент / сървър

За да разберем как функционира системата EJB клиент / сървър, трябва да разберем основните части на системата EJB: компонентът EJB, контейнерът EJB и обектът EJB.

Компонентът Enterprise JavaBeans

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

EJB компонентът е типът EJB клас, който най-вероятно ще се счита за „Enterprise JavaBean“. Това е клас на Java, написан от разработчик на EJB, който прилага бизнес логика. Всички останали класове в системата EJB или поддържат клиентски достъп до класове компоненти на EJB или предоставят услуги (като постоянство и т.н.).

Контейнерът Enterprise JavaBeans

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

Обектът EJB и отдалеченият интерфейс

Клиентските програми изпълняват методи на отдалечени EJB чрез обект EJB. Обектът EJB реализира "отдалечения интерфейс" на компонента EJB на сървъра. Отдалеченият интерфейс представлява "бизнес" методите на компонента EJB. Отдалеченият интерфейс извършва действителната, полезна работа на EJB обект, като например създаване на формуляр за поръчка или пренасочване на пациент към специалист. Ще обсъдим по-подробно отдалечения интерфейс по-долу.