RMI през IIOP

Какво е RMI през IIOP?

RMI over IIOP (RMI-IIOP оттук нататък), разработена съвместно от IBM и Sun, е нова версия на RMI (Remote Method Invocation) за IIOP (Internet Inter-ORB Protocol), която съчетава лесните функции за програмиране на RMI с оперативната съвместимост на CORBA. Тази нова версия на RMI е официално пусната през юни и е достъпна свободно от уебсайта на Sun (вижте раздела Ресурси по-долу за информация къде можете да го изтеглите). Референтната реализация на Sun работи на Windows 9x / NT и Solaris. Това е стандартно разширение, което поддържа както JDK 1.1.6, така и платформата Java 2.

RMI и CORBA са се разработили независимо като модели за програмиране на разпределени обекти. RMI, основа на технологиите EJB и Jini, беше въведена като Java-базиран, лесен за използване програмен модел за разпределени обекти. CORBA (Common Object Request Broker Architecture), дефинирана от OMG (Object Management Group), е добре познат модел на програмиран разпределен обект, който поддържа редица езици. Протоколът IIOP свързва продуктите на CORBA от различни доставчици, осигурявайки оперативна съвместимост между тях. RMI-IIOP е в известен смисъл брак на RMI и CORBA.

За целите на тази статия предполагаме, че вече сте запознати с основите на CORBA. Ако имате нужда от допълнителна помощ за ускоряване, има полезна връзка в раздела Ресурси по-долу.

Преди RMI-IIOP

Вижте Фигура 1 по-долу. Пространството над централната хоризонтална линия представлява оригиналния домейн на RMI; долният регион представлява света на CORBA и IIOP. Тези два отделни свята, след като са се развили независимо, в исторически план не са били способни да общуват помежду си. Например родният протокол на RMI, JRMP (Java Remote Method Protocol), не може да се свърже с други протоколи.

Ако единственият език за програмиране, който ви е необходим в нов проект, е Java, използването на RMI и JRMP - комбинация, наричана RMI (JRMP) за останалата част от тази статия - традиционно е най-добрият избор. За разлика от CORBA, която изисква използването на доста сложния език за дефиниране на интерфейса (IDL), RMI (JRMP) предлага лесно програмиране за любителите на Java. CORBA, от друга страна, позволява програмиране на разпределени обекти на различни платформи и различни езици за програмиране. Разработчиците се нуждаят от програмиране на разпределени обекти не само за нови проекти, но и за използване на наследени софтуерни ресурси. Разбира се, наследеният софтуер в повечето случаи е програмиран на езици, различни от Java; в такива ситуации разработчиците се нуждаят от CORBA, а не от RMI (JRMP).

По този начин имаме нашата централна дилема: RMI (JRMP) има предимството от лесното програмиране, докато CORBA осигурява оперативна съвместимост между множество езици за програмиране на различни платформи. За съжаление обаче традиционно не е имало начин да се използват и двете тези отлични технологии. Това е показано от диаграмата на фигура 2, в която кръг означава ситуация, в която клиентът може да извика сървър, а X означава случай, в който това не е възможно

Най-доброто от двата свята

По-рано беше трудно да се избере между RMI (JRMP) и CORBA при стартиране на нов проект. Ако сте избрали RMI (JRMP), получавате лесно програмиране, но губите оперативна съвместимост на множество езици. Ако сте избрали CORBA, сте получили оперативна съвместимост, но сте се сблъскали с по-страшна задача за програмиране. Потребителите на RMI (JRMP) и CORBA, уморени от вземането на това решение, казаха с един глас: "Моля, свържете двете."

На фигура 3 по-долу горната секция представлява модела RMI (JRMP), средната секция - моделът RMI-IIOP, а долната секция - моделът CORBA. Стрелката представлява ситуация, при която клиентът може да извика сървър. RMI-IIOP принадлежи към света на IIOP под хоризонталната линия. Това, което може да изглежда странно, са диагоналните стрелки, които пресичат границата между света на JRMP и света на IIOP, което предполага, че клиентът на RMI (JRMP) може да извика сървър на RMI-IIOP и обратно. Естествено е читателите да мислят, че тези диагонални стрелки са погрешни - в края на краищата различните протоколи никога не могат да говорят помежду си, нали? Тези стрелки обаче всъщност са на правилното място. RMI-IIOP поддържа както протоколи JRMP, така и IIOP.

Двоичен файл на сървър (т.е. файл с клас), създаден с помощта на API на RMI-IIOP, може да бъде експортиран като JRMP или IIOP. Не е нужно да пренаписвате изходния му код на Java или да го компилирате при преминаване от JRMP към IIOP или обратно. Трябва само да промените параметри като свойствата на Java системата, когато го изпълнявате. Като алтернатива можете да определите използвания протокол, като го посочите в изходния код на Java. Същата гъвкавост се отнася и за клиентския код на RMI-IIOP.

Двоен износ

Има още един важен факт, който трябва да имате предвид, когато решавате между протоколите JRMP и IIOP. Когато експортирате RMI-IIOP обект на вашия сървър, не е задължително да избирате между JRMP и IIOP. Ако имате нужда от един обект на сървър, който да поддържа както JRMP, така и IIOP клиенти, можете да експортирате своя RMI-IIOP обект едновременно в JRMP и IIOP. В терминологията RMI-IIOP това се нарича двоен износ.

Диагоналните стрелки на фигура 3 са възможни, тъй като API на RMI-IIOP поддържат протоколи JRMP и IIOP. Това означава, че без пренаписване на изходния код на RMI (JRMP) обект, той може да бъде извикан от нов RMI-IIOP клиент. По същия начин, без да пренаписвате изходния код на RMI (JRMP) клиент, можете да замените RMI (JRMP) сървърния обект с нов RMI-IIOP обект, който CORBA клиент също може да извика. По този начин RMI-IIOP запазва съществуващите инвестиции в двоични файлове на RMI (JRMP), тъй като RMI-IIOP може да комуникира с тях без промени в изходния код или рекомпилация.

Тази оперативна съвместимост с RMI (JRMP) беше един от принципите на проектиране на RMI-IIOP. Дизайнерите на RMI-IIOP са избегнали изкушението да изместят CORBA и RMI с трети програмен модел, тъй като това само би объркало програмистите с разпределени обекти и би направило миграцията от RMI (JRMP) още по-трудна.

Оперативна съвместимост с CORBA

Погледнете отново фигура 3. Разделът под хоризонталната линия е светът на IIOP, където клиентът RMI-IIOP извиква CORBA сървър, а клиентът CORBA извиква RMI-IIOP сървър. Под клиент на RMI-IIOP имаме предвид клиентска програма, написана от програмист на RMI, който не знае нищо за CORBA или IDL. По същия начин клиент на CORBAе клиентска програма, написана от програмист на CORBA, непознаващ RMI. Разделянето на интерфейса от внедряването е добре установена техника за позволяване на програмистите да имат достъп до различни ресурси, без да е необходимо да знаят как тези ресурси се прилагат; ако се спазва тази техника, потребителите както на RMI-IIOP, така и на CORBA могат да използват услугите на другия протокол, ако могат да получат достъп до неговия интерфейс. Интерфейсният файл на RMI Java е интерфейсът към потребителите на RMI-IIOP, докато IDL е интерфейсът към потребителите на CORBA; оперативна съвместимост между RMI-IIOP и CORBA на фигура 3 се постига чрез предоставяне на всеки потребител с очаквания интерфейс, като същевременно запазва действителното изпълнение скрито.

Последната подробност, която трябва да бъде обяснена на фигура 3, е пунктираната стрелка, показваща RMI-IIOP клиент, извикващ CORBA сървър. Защо само тази стрелка е осеяна? Клиентът RMI-IIOP не може непременно да има достъп до всички съществуващи обекти на CORBA. Семантиката на CORBA обектите, дефинирани в IDL, е супермножество от тези на RMI-IIOP обекти, поради което IDL на съществуващ CORBA обект не винаги може да бъде картографиран в RMI-IIOP Java интерфейс. Едва когато семантиката на конкретен CORBA обект съвпада с тези на RMI-IIOP, клиентът на RMI-IIOP може да извика CORBA обект. Пунктираната стрелка показва връзка, която понякога - но не винаги - е възможна.

Несъвместимостта тук обаче не бива да се преувеличава. Ограниченията, посочени от пунктираната стрелка, се прилагат само при работа със съществуващи обекти на CORBA. Да предположим, че проектирате чисто нов разпределен обект с RMI-IIOP Java интерфейс. В този случай можете автоматично да генерирате съответния IDL сrmicинструмент. От този IDL файл можете да го внедрите като обект CORBA - например в C ++. Този C ++ обект е чист CORBA обект, който може да бъде извикан от CORBA клиент и може да бъде извикан от RMI-IIOP клиент без никакви ограничения. За клиента RMI-IIOP този C ++ CORBA обект се появява като чист RMI-IIOP обект, тъй като е дефиниран от RMI-IIOP Java интерфейс. Накратко, разликата между обект CORBA и обект RMI-IIOP е само въпрос на изпълнение. По същия начин, ако обект е реализиран в RMI-IIOP, обектът се появява като CORBA обект на CORBA клиент, защото CORBA клиент го осъществява чрез своя IDL.

Фигура 4 по-долу показва матрицата, която обобщава стрелките на Фигура 3. Пунктираният кръг означава същото като пунктираната стрелка на Фигура 3. Фигура 4 показва, че ако внедрите вашия сървър в RMI-IIOP, имате най-широкия избор клиенти. По същия начин, ако внедрите вашия клиент в RMI-IIOP, можете да говорите с най-големия набор от сървъри, въпреки че има някои ограничения в случай на съществуващи обекти на CORBA, както е посочено от пунктирания кръг.

Политика за проектиране на RMI-IIOP

Имаше две основни предпоставки, които оформиха дизайна на протокола RMI-IIOP: семантиката на RMI трябваше да бъде оставена възможно най-непокътната, а CORBA трябваше да бъде подобрена, така че семантиката на RMI да може да бъде приложена с помощта на инфраструктурата на CORBA. Това беше по-лесно да се каже, отколкото да се направи. Ако се въведе трети модел за програмиране, това само ще обърка програмистите. За да се постигне щастлив брак на RMI и CORBA, беше необходимо да се постигне компромис между различните среди на тези брачни партньори - ако и двамата партньори отхвърлят някакъв компромис, бракът няма да стигне до никъде. За щастие общността на CORBA призна това и прие определени промени, така че RMI-IIOP да може да се превърне в реалност.

Двете основни промени, които CORBA прие, бяха обектите по стойност и спецификациите на Java-to-IDL Mapping . Първият, който вече е достъпен за потребителите на RMI под формата на сериализация на обекти на Java, е спецификация на CORBA, предназначена да накара други езици да реализират подобна способност. Последното е картографирането, използвано за преобразуване на интерфейсите на RMI Java в дефиниции на CORBA IDL и не трябва да се бърка с картографирането на IDL към Java, вече дефинирано в CORBA 2.2. (Вижте Ресурси за връзки към тези две нови спецификации на CORBA.)

OMG вече официално прие и двете спецификации за CORBA 2.3, но внедряванията на CORBA ще трябва да настигнат тази нова версия, преди новият брак на CORBA и RMI, описан тук, да стане широко разпространена реалност. Например компилатор IDL към Java, който съответства на CORBA 2.3, е достъпен от Sun за използване заедно с RMI-IIOP ORB (посредник на заявки за обекти), но в момента е версия за ранен достъп, подходяща само за проучване на оперативната съвместимост на CORBA и RMI-IIOP, а не за производствена употреба. Освен това компилаторът IDL към Java, разпространен от Sun за използване с Java IDL ORB в Java 1.2, не отговаря на CORBA 2.3, така че не може да се използва за тестване на оперативна съвместимост с RMI-IIOP. Тази ситуация ще бъде разрешена през следващите няколко месеца, тъй като доставчиците на CORBA представят нови версии на своите продукти, които поддържат CORBA 2.3.Например, следващото издание на платформата Java 2, стандартно издание, ще включва както RMI-IIOP, така и IDL-to-Java компилатор с качествено производство, който поддържа CORBA 2.3.

Процедура за разработване

Фигура 5 по-долу показва процедурите за разработка както на RMI-IIOP сървъри, така и на клиенти. Ще забележите, че те са почти същите като тези на RMI (JRMP). Точно както в RMI (JRMP), дефиницията на разпределен обект е неговият интерфейс RMI Java ( MyObject.javaна фигура 5). Разликата е -iiopпараметърът на rmicкомпилатора. Тази опция се използва за rmicгенериране на заглушки и вратовръзка, които поддържат протокола IIOP. Без тази -iiopопция rmicгенерира мъниче и скелет за протокола JRMP. Въпреки че процедурата за разработване на RMI-IIOP е близка до тази за RMI (JRMP), средата на изпълнение е различна, тъй като комуникацията се осъществява чрез ORB, съвместима с CORBA 2.3, като се използва IIOP за комуникация между сървъри и клиенти.

Ако обмисляте да конвертирате RMI (JRMP) код в RMI-IIOP, трябва да знаете, че има някои разлики в изпълнението при изпълнение на IIOP. Разпределеното събиране на боклук не се поддържа от CORBA, която използва изрично унищожаване и постоянни препратки към обекти с прозрачна пасивация и активиране. Регистърът на RMI се заменя с JNDI с CosNamingдоставчика на услуги или LDAP, а активирането на RMI се заменя от преносимия обектен адаптер. Препратките към отдалечени обекти трябва да бъдат свалени надолу, като се използва програмен narrow()метод, вместо директно предаване на език на Java. Други семантики на RMI, като сериализация на обекти, се поддържат изцяло през IIOP.

Процедура за оперативна съвместимост на CORBA

Фигура 6 показва как да се постигне оперативна съвместимост между RMI-IIOP и CORBA. За да улесним нашата дискусия, нека разгледаме два аспекта на такава оперативна съвместимост: клиент на CORBA, използващ обект RMI-IIOP, изобразен в най-левия раздел на фигура 6, и клиент на RMI-IIOP, използващ обект CORBA, изобразен в най-десния раздел. В центъра на фигурата са тези споделени процеси, които позволяват да работят и двете форми на оперативна съвместимост.