Введення в розробку VisiBroker CORBA в середовищі JBuilder, Різне, Програмування, статті

Введення

В будь-якій організації пов’язані з бізнесом напрямки роботи розподілені між різними членами організації для більш ефективної обробки кожної частини. Таким же чином розподіляються і об’єкти в кіберпросторі організації для найбільш ефективного виконання їх бізнес-функцій. Парадоксально, але мета системи розподілених об’єктів полягає в кращій інтеграції організації. Досить осмислене і продумане розподіл об’єктів на всі бізнес-процеси організації створює велику зв’язність, додаткову ефективність і робить систему в цілому набагато більш раціональною. Однак цей розподіл має бути ідеально продумано, бо розпорошення об’єктів за вітром безсумнівно шкідливо. Щоб запобігти подібні помилки, у цій статті представлені потужні технології такі, як CORBA і Java, реалізовані в засобах розробки Borland, – VisiBroker і JBuilder. Часто виявляється, що розподілені системи становлять велику складність на всіх стадіях життєвого циклу програм – від проекту до управління. Продукти JBuilder і VisiBroker покликані удосконалити цей процес, спрощуючи створення і розгортання розподілених додатків CORBA. З появою JBuilder 3.5, інтеграція з CORBA стає “безшовній” з додаванням декількох можливостей, орієнтованих на допомогу розробникам при створенні об’єктів VisiBroker CORBA, сервлетов, серверів і клієнтів на Java.

У цій статті використано практичний підхід до представлення VisiBroker і кожна тема проілюстрована реальним додатком. Замість подання CORBA в цілому, ми будемо описувати концепції в міру того, як вони будуть нам тут зустрічатися. Цей метод допомагає краще уявити концепції CORBA за допомогою наочної ілюстрації теорії безпосереднім прикладом.

Що ж таке CORBA?

З появою Intranet і Internet, мережеві обчислення в кінцевому рахунку стають домінуючим напрямком розробки програмного забезпечення. Але як може безліч настільки різноманітних систем взаємодіяти один з одним? Щоб справитися з цією проблемою, OMG безперервно займається розробкою специфікацій CORBA. Ці специфікації стандартизують шляху мережного взаємодії програм один з одним. CORBA, однак, виходить за рамки простого взаємодії; це – гнучке, настроювана сполучна рішення для багатоланкових додатків – т.зв. middleware, або ПО проміжного рівня. Common Object Request Broker Architecture (Загальна архітектура брокера об’єктних запитів) (CORBA) – сукупність специфікацій, розроблених і стандартизованих Object Management Group (OMG).

OMG, або робоча група з розвитку стандартів об’єктного програмування, є консорціумом приблизно 800 компаній комп’ютерної промисловості. Головним напрямком діяльності OMG є визначення структури архітектури, званої Object Management Architecture (OMA), яка є структурою архітектури для розподілених обчислень. OMG не є організацією, яка розробляє стандарти. Її метою є сприяння прийняттю промисловістю специфікацій інтерфейсу для управління розподіленими об’єктами. Ще раз відзначимо, що цей некомерційний консорціум не встановлює промислові стандарти. Замість цього OMG сприяє прийняттю стандартів шляхом досягнення згоди серед його учасників. За своєю природою стандарти, які розглядаються для прийняття OMG, не є теоретичними, вони були реалізовані і випробувані на практиці. Стандарт CORBA визначає, як об’єкти представляють себе, і як вони взаємодіють в розподіленому середовищі, поряд з протоколами зв’язку для взаємодії між об’єктами.

Структура стандарту CORBA дозволяє індивідуальним постачальникам програмних продуктів, таким як Borland, розробляти програми, що відповідають рекомендаціям OMG. Кілька компонентів реалізації CORBA визначені за стандартом OMG, а проте, більшість постачальників розширює набір цих основних компонент для забезпечення закінченого рішення. Дана стаття присвячена реалізації CORBA VisiBroker і представляють його компонентів.

Що таке – розподілена об’єктна система?

Поняття “розподілений” передбачає географічно розосереджені об’єкти. Фактично розподілена об’єктна система – просте змішання двох технологій – мережевого і об’єктно-орієнтованого програмування. Мережі роблять можливими розподілені обчислення, об’єкти забезпечують інкапсуляцію, багаторазове використання і підвищену надійність в експлуатації. Однією з найбільш значних рушійних сил розподілених обчислень є Web. Будучи найбільшою у світі розподіленою системою, вона з’єднує радикально відрізняються технології, інформацію і носії. Однак не кожна розподілена система обов’язково “Об’єктно-орієнтована”. Об’єднання мережевого і об’єктного підходу веде до значного удосконалення управління розробкою і супроводом програмного забезпечення, багаторазовому використанню і масшабіруемості.

Чому розподілена?

Якщо організація знаходиться в одному місці (іншими словами має єдине місце розташування) і лише декілька комп’ютерів, подібної організації, ймовірно, немає необхідності в розподілі своїх об’єктів. Більшість організацій, однак, швидко проходять цей етап і починають розширювати свої позиції: з’являється кілька місць розташування, різноманітні напрями бізнесу і безліч комп’ютерів. Для цих організацій розподілені обчислення зможуть підвищити рівень масштабованості рішень. Крім цього, мотивація для розробки систем в розподіленому або багатоланкової виконанні може мати кілька причин. Багатоланкові розподілені додатки пропонують ряд переваг в порівнянні з традиційною розробкою клієнт / серверних додатків. Для розуміння переваг n-звенні додатків, корисно звернути увагу на недоліки інших підходів; наприклад діаметральної протилежності розподіленої системи – централізованої системи, що базується на єдиному mainframe-комп’ютері. Як відзначали прихильники клієнт / серверної архітектури, ця система має кілька недоліків. При недоступності mainframe-комп’ютера не може бути виконана жодна обробка. Крім того, всі дані повинні бути передані центральному комп’ютеру, який, по суті, є основним архівом. Аналогічно в клієнт / серверної середовищі, клієнт – це звичайно більш важка частина коду зі спеціалізованою базою даних (SQL, AS/400, і т.д.), призначена для забезпечення зберігання даних. Проблема, пов’язана з цією моделлю, полягає в тому, що більшість систем баз даних не можуть представляти і наказувати всі бізнес-правила і процеси, необхідні складної програмній системі. Через це невідповідності бізнес-логіка часто розбивається між клієнтським додатком і додатком-сервером. Такого роду практика викликає масу проблем, пов’язаних з надійністю в експлуатації, багаторазовим використанням і оновленнями, так як бізнес-логіка не належить окремій ланці програми.

На відміну від непохитного “мейнфрейм може все” або “товстих” клієнтів в клієнт / серверах, багатоланкові рішення долають багато з цих проблем, об’єднуючи бізнес-логіку в середнє (проміжне) ланка або ланки. За допомогою цього підходу здійснюється поділ об’єктів і функціональності, призначеної для роботи з базою даних. Результатом є більш проста масштабованість, обслуговування та покращене багаторазове використання програмного забезпечення.

Далі, виділення функціональних можливостей в окремі ланки значно зменшує час, необхідний для розробки нових додатків, дозволяючи, таким чином, новим системам легко взаємодіяти з поточними даними і процесами. Новий клієнт може просто використовувати існуючі об’єкти середньої ланки, посилюючи за рахунок цього віддачу вже існуючої бізнес-логіки, написаної для попередніх програм. Нарешті, збереження логіки в чітко визначеному середній ланці передбачає концентрацію більш потужних апаратних засобів для спеціалізованих об’єктних серверів. Зі збільшенням ступеня завантаження можуть бути додані нові машини, або для оптимізації продуктивності серверні процеси можуть бути перерозподілені іншим машинам, що відбувається абсолютно прозоро для клієнта.

Чому CORBA?

Рішення про використання CORBA в багатоланкової додатку зазвичай обумовлено її офіційно підтвердженої продуктивністю в промисловості, широким використанням в якості стандарту, і відкритою, крос-платформної реалізацією. Поряд зі стандартом для визначення об’єктних інтерфейсів, CORBA також визначає стандартний об’єктний протокол зв’язку (GIOP) і конкретну реалізацію GIOP, названу IIOP, яка працює поверх TCP / IP.

Здатність об’єктів CORBA обмінюватися інформацією в Web і в межах Intranet з використанням IIOP – одна з основних причин, по якій CORBA була так активно прийнята. При виборі проміжних додатків, CORBA пропонує ряд переваг в порівнянні з іншими підходами, подібними DCOM, включаючи незалежність від платформ, більший контроль над процесами передачі інформації між об’єктами і підтверджену стабільність.

Архітектура VisiBroker

Огляд ORB

Архітектура CORBA складена з декількох сервісів, керівних принципів і процесів, які дозволяють розподіленим об’єктам зв’язуватися один з одним. OMA, як описано раніше, логічно розділений на два високорівневі компоненти. Це поділ дозволяє проектувальникам систем створювати розподілені архітектури, засновані на OMA, з компонентів від численних постачальників.

Системно-орієнтований компонент: брокер об’єктних запитів (Object Request Broker)
Компонент, орієнтований на додаток: об’єкти програми CORBAfacilities.

Брокер об’єктних запитів (Object Requests Broker, ORB) – основний компонент OMA. ORB визначає і забезпечує засоби для обміну інформацією між об’єктами. ORB, або Брокер об’єктних запитів, є сполучною засобом, який забезпечує набір сервісів, що дозволяють двом об’єктам зв’язуватися по мережі. Наведемо приклади деяких сервісів, реалізованих в ORB. Це – активізація об’єкта, місце розташування і зв’язок. Ці сервіси задокументовані в архітектурі CORBA. Існує багато постачальників ORB. Деякі постачальники ORB подібно Borland також реалізують інші сервіси CORBA, такі як сервіс іменування, сервіс подій, сервіс транзакцій і сервіс баз даних. Ці додаткові послуги забезпечують базову структуру для створення масштабованих, розподілених програмних систем.

CORBAfacilities є колекціями об’єктів, визначених на мові IDL, які можуть безпосередньо використовуватися додатками. Вони складаються з горизонтальних і вертикальних компонентів, які описують правила взаємодій між об’єктами. Вони споріднені Java Bean зі світу Java.

Повна специфікація для архітектури CORBA, як вона прийнята і видана групою OMG, розділена на три основні розділи: ядро ​​CORBA, здатність до взаємодії CORBA і відображення OMG IDL на різні мови. Стандарт CORBA не задає жорстких правил реалізації архітектури. Продавці ORB вільні проектувати свій ORB так, як їм це необхідно.

Брокер об’єктних запитів (ORB) – сполучна засіб, який забезпечує набір сервісів для знаходження та використання реалізацій різних об’єктів. Брокер об’єктних запитів (ORB) є основою OMA. Він визначає інфраструктуру, що дозволяє компонентам CORBA зв’язуватися один з одним. Запам’ятайте, ORB – це те, що зазвичай згадується як CORBA. Користь від використання ORB-ов полягає в тому, що вони приховують заплутаність методу звернення, що посилається об’єкту. Коли клієнтський об’єкт викликає метод на об’єкті сервера, незалежно від його місця розташування, ORB перехоплює запит і знаходить відповідний сервер. Зручним є те, що постачальники ORB тепер записують весь комунікаційний код, коли-небудь написаний розробниками. ORB-и можуть повідомляти один одному про використання стандартних протоколів зв’язку. Це дозволяє об’єктам клієнта і сервера CORBA бути реалізованим на різних мовах програмування і в різних операційних середовищах. Після того, як серверний ORB приймає клієнтський запит, викликається метод об’єкта сервера з передачею відповідних параметрів. Як тільки об’єкт сервера закінчив обробку, серверний ORB повертає результати клієнтського об’єкту через клієнтський ORB. Клієнти можуть отримати набір параметрів результатів від єдиного запиту методу об’єкта сервера. Вхідні (in) параметри IDL і наскрізні (in / out) параметри реалізовані тільки для цієї мети. Таким чином, ORB звільняє програмістів від значного обсягу рутинної роботи. Об’єкти можуть обмінюватися інформацією незалежно від їх місця розташування, операційної системи та мови програмування.

Основна реалізація CORBA зазвичай включає Брокер об’єктних запитів (ORB), компілятор для IDL (Мова визначень інтерфейсів CORBA), і Загальні об’єктні сервіси (COS), які допомагають об’єктів в процесі взаємодії. Якщо об’єкт локальний, ORB робить локальний запит методу, якщо об’єкт знаходиться на іншій пов’язаної машині, ORB зв’язується з використанням GIOP (найбільш часто зустрічається використання IIOP поверх TCP / IP). Отже, клієнтові не обов’язково “знати” що-небудь щодо місця розташування об’єкта, операційної системи хоста, або мови, якою він був реалізований для отримання посилання на нього.

Об’єктні адаптери, BOA і POA

Адаптер об’єкта CORBA необхідний для підбору відповідності концепції реалізації об’єктів на мові програмування до концепції об’єктів CORBA. Це – возз’єднання принципу проектування адаптера. Далі наводиться те, за що відповідальні об’єктні адаптери:

Породження та інтерпретація об’єктних посилань

Стандартні об’єктні адаптери CORBA:

Розробники розуміли, що в BOA були численні недоліки. Специфікації самого BOA були неповні, що зробило написання переносимого коду сервера практично неможливим. Наведемо і деякі інші проблеми, що виникають при роботі з BOA. Це – не були задані реєстрація реалізації та обробка запитів і не визначена розкладка, або назви скелетних класів. Крім того, не існує ніяких методів для збереження та відновлення стану об’єкта. Цикли життя об’єктів CORBA і об’єктів виконання тісно пов’язані з реалізацією BOA, і технічні вимоги BOA повністю ігнорують запуски паралельних процесів в процесі сервера.

Portable Object Adapter усуває деякі з недоліків BOA. Специфікації POA призначені для надання розробникам можливості написання мобільних і масштабованих серверних додатків. При цьому POA підтримує широкий спектр можливостей, що забезпечує тонкий контроль над ресурсами, необхідними для реалізації об’єктів CORBA і направлення до них запитів. Це забезпечує інтерфейси для управління життєвим циклом реалізації об’єкта і його готовністю прийняти запити, POA може бути придатний для використання навіть для серверів з екзотичними вимогами.

Термінологія POA

POA містить власний набір концепцій, які розширюють і уточнюють модель об’єкта CORBA. У нас є об’єкт CORBA, який є “віртуальним”, абстрактним об’єктом, з можливістю звернення за його об’єктної посилання і здатністю до прийому запитів. Крім того, є сервант (servant), який є об’єктом мови програмування, які існують у межах контексту процесу сервера і реалізують об’єкт CORBA. Сервант надає фізичну форму відповідного об’єкту CORBA. Крім того, POA підтримує Об’єктний ID (ідентифікатор) – системний або визначений користувачем ідентифікатор, використовуваний для ідентифікації об’єкта в межах його POA. І, нарешті, скелет (skeleton) – об’єкт мови програмування, який підключає сервант до POA, дозволяючи POA посилати запити серванту.

Об’єкт CORBA і життєвий цикл серванта

POA забезпечує сильне розділення між термінами служби об’єктів CORBA і термінами служби серванта. Наступні терміни відносяться до циклу життя об’єкту CORBA:

Наступні терміни відносяться до циклу життя серванта:

Під час свого життя об’єкт CORBA може бути втілений більш ніж одним сервантом. У той же самий час, окремий сервант, з іншого боку, може втілювати більше одного об’єкта.

Ієрархія POA

Головна особливість архітектури POA – те, що сервер може містити вкладені в нього множинні POA. З іншого боку, вкладений POA може бути створений при використанні операції фабрикування з іншого POA. Всі сервери мають, принаймні, один кореневої POA, який може бути отриманий від ORB. Ім’я вкладеного POA унікально ідентифікує цей POA в межах контексту його батька. Назва кореневого POA – RootPOA.

Менеджери POA Кожен POA має асоційованого з ним менеджера POA, і менеджер POA управляє потоком запитів до його POA.

Менеджер POA може буферизують запити або відмовлятися від них. POA надає дуже багатий набір можливостей, які забезпечують максимальну гнучкість для розробки серверних додатків. Специфікації стандартизують розробку сервера, що дозволяє програмістам створювати додатки, що переносяться серед різних ORB-ов. Реалізація Visibroker CORBA підтримує всі особливості POA.

Огляд IDL

Однією з ключових специфікацій, які забезпечує CORBA, є Interface Definition Language (Мова визначень інтерфейсів) (IDL). IDL описує об’єкти незалежним від мови способом, так що до об’єктів безпосередньо можна звертатися за допомогою будь-якого підтримуваного мови, операційної системи або мережі. Java і C + + – це мови програмування, які дозволяють розробнику здійснювати вирішення бізнес-проблем. Що стосується IDL, то він є незалежним від інших мов, і дозволяє програмісту лише визначати інтерфейси об’єктів, але не реалізацію цих об’єктів.

CORBA забезпечує технологію розподілених об’єктів, яка дає можливість користувачам формувати інтерактивні, масштабовані додатки. Технічні вимоги IDL CORBA відокремлюють інтерфейс від його реалізації, дозволяючи реалізувати інтерфейс на мові програмування, найбільш підходящому для специфічних завдань. Відображення IDL були створені для C, C + +, Ади, і Java, також як і для інших мов. CORBA забезпечує інфраструктуру, що дозволяє різним реалізаціям об’єктів зв’язуватися один з одним. Запити об’єктів упаковуються в загальний формат, який може бути розпізнаний різними мовами і операційними системами.

Мова IDL використовується для визначення інтерфейсу об’єкта, який стає угодою або контрактом між клієнтом і сервером об’єкта. Інтерфейс описує всі операції, параметри введення і виведення, і будь-які винятки, які можуть бути згенеровані об’єктом сервера. Іншими словами, інтерфейс описує поведінку об’єкта, а не те, як це поведінка буде реалізовано. Таким чином, IDL – це ідеальний мову для визначення великих чи маленьких програмних систем, незалежно від мови реалізації. Проектувальники і архітектори систем використовують IDL, щоб описати, які ж послуги вони хочуть запропонувати потенційним клієнтам.

Крім того, IDL є чудовим способом інкапсуляції успадкованих інтерфейсів, так як він відділяє специфікацію об’єкта від його реалізації. Для взаємодії з існуючими успадкованими додатками можуть бути створені об’єкти CORBA сервера. Це забезпечує існуючі програми об’єктно-орієнтованим, доступним по мережі інтерфейсом.

IDL не містить ніякої інформації щодо того, як реалізований об’єкт. IDL тільки описує інтерфейс. Реалізація об’єкта сервера може бути представлена ​​будь-якою мовою програмування, яка підтримує CORBA. Хочеться відзначити, що IDL простий у вивченні. Він підтримує синтаксичне підмножина C + + без процедурних конструкцій типу циклів for і while. Оскільки IDL тільки описує інтерфейс до об’єкта (Наприклад: метод виклику і параметри), це зайвий раз демонструє, що він є простою мовою для вивчення. Тих, кому не подобається ідея вивчення ще однієї мови, можна порадувати – VisiBroker пропонує закінчене рішення Java, де інтерфейс визначений в інтерфейсі Java, і компілятор реконструює IDL і необхідні файли, виходячи з файлу інтерфейсу Java. Ця функція також дає можливість структурам класів Java, таким як Vector, використовуватися в якості параметрів виклику.

IDL являє собою по суті самостійна мова, хоча його конструкції схожі на C + + і Java. Кілька ресурсів є на web-сайті OMG (www.omg.org), який надає інформацію щодо початку роботи з IDL.

CORBA забезпечує прозорість місця розташування. Клієнтам не потрібно знати місце розташування реалізації об’єкта. Таким чином, забезпечується гнучкість для поєднання об’єктів на тій же самій машині, дистанційно, або можливість безперервного переміщення для об’єкта, що знаходиться в динамічному середовищі. Клієнт може використовувати Службу іменування CORBA (CORBA Naming Service), щоб знайти об’єкти сервера. Фактичне розташування об’єкта сервера прозоро для клієнта. Крім того, VisiBroker має зручний “out-of-the box” Smart Agent, який працює як Directory Service (Служба каталогів) при швидкому пошуку і визначенні місця розташування об’єктів.

CORBA IIOP

Протокол Internet CORBA Inter-ORB (IIOP) забезпечує ORB – ам незалежність від постачальників. ORB-и можуть взаємодіяти по специфікаціям IIOP. Тобто IIOP гарантує, що об’єкти CORBA, реалізовані з використанням ORB-ов одного продавця, будуть здатні спілкуватися з об’єктами CORBA, реалізованими на будь-яких інших ORB-ах.

Архітектура управління об’єктами (OMA) описує основний набір специфікацій, званих CORBAservices, які можуть бути включені в складні програмні системи. Ці сервіси дозволяють об’єктам програми зв’язуватися стандартними способами. Постачальники реалізували “CORBAservices”, що полегшує розробку великих розподілених систем.

З іншого боку – якщо розробник планує писати програми, використовуючи Enterprise Java Beans, переваги IIOP через підтримку для RMI / IIOP декларує здатність до взаємодії серед множинних мов і серед контейнерів від множинних постачальників. Контейнер EJB Inprise заснований на CORBA. Inprise Application Server передбачає CORBA-сумісність як з RMI-поверх-IIOP, так і відображення Java-на-IDL.

Створення сервера CORBA за допомогою JBuilder

Визначення об’єкта

Враховуючи ці два компоненти, визначення об’єкта як IDL і ORB як каналу зв’язку між цими об’єктами, ми можемо почати дослідження розробки програми CORBA за допомогою JBuilder. Подібно будь програмного проекту, початковими завданнями, що стоять перед реалізацією нашого застосування, будуть оцінка та дизайн. Так як CORBA – це об’єктно-орієнтована стандарт, ми повинні розбити наш бізнес-процес на логічні об’єкти, їх властивості та на операції, які ми будемо повинні виконати на цих об’єктах і з цими об’єктами. Для здійснення цих завдань, ми будемо використовувати простий сервер Attendees, який зможе витягти передбачувану відвідуваність конференції Borland / Inprise.

Для початку ми збережемо функціональні можливості простими, шляхом визначення тільки одного інтерфейсу, який ми назвемо Attendees. IDL. Інтерфейс описує, які функціональні можливості наш об’єкт пропонує клієнтам. Раніше вже згадувалося, що ми могли б використовувати Caffeine для визначення наших інтерфейсів на Java, але ми хочемо продемонструвати це на IDL.

CORBA-розробка в JBuilder

В обчислювальному світі Java швидко утвердився в якості стандартної платформи для створення Internet і Intranet аплетів і додатків. Одна з основних причин успіху Java – близька до досконалості мобільність платформи. Програми, написані на Java, можуть працювати в різноманітних операційних системах і апаратних конфігураціях. Об’єднайте ці характеристики з простотою використання Java, підтримкою обробки винятків, Потокова і складанням сміття, і ви отримаєте мова, яка є ідеальним середовищем для розробки мережевих обчислень, особливо програмування для Internet.

Java і CORBA були створені одне для одного. Java пропонує крос-платформену гнучкість, необхідну для створення і розподілу об’єктів в мережі, що складається з різноманітних комп’ютерів і операційних систем. CORBA пропонує засоби для підключення та інтегрування розподілених об’єктів, написаних на різних мовах. Давайте подивимося, як ці дві технології працюють разом.

В даний час проектувальники систем на CORBA здатні поставити розподілені програмні системи, описані на IDL і реалізовані на Java, з використанням сучасних браузерів і Web-технології.

До появи Java і CORBA віддаленим користувачам явно не вистачало вільного доступу до інформації мейнфрейма. Зв’язок з мейнфреймів є важкою справою. Доводиться турбуватися щодо нових видань платформ, комунікаційних протоколів і мов.

Для розгортання тонкого клієнта ви могли використовувати стандарт HTML на клієнті і сервлети Java (які вдвічі більше клієнтів CORBA) на web-сервері. У триланкової архітектурі, прикладна програма розбита між клієнтом, сервером і середньою ланкою. Середня ланка дозволяє спростити як клієнта, так і сервер, і робить більш простим розгортання в порівнянні з двухзвенной системою, в якій клієнт і сервер пов’язані безпосередньо.

У CORBA сервери реалізують об’єкти, і клієнти викликають методи для цих об’єктів. Опис IDL є контрактом між клієнтом і сервером і все, що потрібно клієнту – використовувати об’єкт, реалізований сервером.

Тепер, коли ми визначили, що таке CORBA і як вона реалізована, перейдемо до фактичного написання програми. Найсучасніші мови програмування підтримують розробку CORBA, включаючи C + +, Java і Object Pascal Delphi. В результаті, основні інструментальні засоби RAD підтримують в різного ступеня стандарт OMG. JBuilder був одним з перших інструментальних засобів, призначений для тісного інтеграції в IDE засобів розробки CORBA, а JBuilder3.5 додав кілька нових можливостей для створення серверів VisiBroker, клієнтів та інших сервісів CORBA. Ми будемо вивчати розробку, використовуючи Java з JBuilder.

Розробка додатків архітектури CORBA в середовищі Jbuilder

Спочатку наш сервер Attendees буде складатися з єдиного об’єкта, ConferenceManager, який буде інформувати про запити вірогідною відвідуваності конференції. Ми хочемо мати можливість запитувати AttendeesManager про очікуваний числі відвідувачів в цьому році.

В IDL ми визначаємо це таким чином: 
// Attendees.idl
module bicon2000 {
interface Attendees {
long number(in long lastYear);
};
};

Ми визначили модуль, званий bicon2000 (скорочення від Borland / Inprise Conference 2000). Модуль відображається на пакет Java, і є просто простором імен, у якому розташований інтерфейс. В межах модуля bicon2000 ми визначаємо єдиний інтерфейс на ім’я Attendees. Подібно інтерфейсам Java, цей інтерфейс, по суті, є контрактом між клієнтом і сервером, що позначає, які методи об’єкт Attendees виставляє для використання. Ми можемо тут бачити, наскільки IDL схожий з C + + і Java в своєму синтаксисі. Типи даних також подібні; ми повертаємо long (long integer) для числа наших відвідувачів, і в якості вхідного параметра беремо значення, що це було в минулому році. Аргумент “last year” ідентифікується як in, так як об’єкт сервера (визначається в цьому випадку як out) не буде змінювати це значення. Інтерфейс Attendees виставляє лише один метод “number”, маючи на увазі, що об’єкт Java, який ми використовуємо для реалізації Attendees, повинен буде тільки підтримати цей єдиний метод. Щоб створити цей файл IDL, виберіть File, New … з Top Menu. Виберіть закладку Enterprise з діалогу Objects Gallery. І потім виберіть Sample IDL.

 

Визначення закінчено, все, що необхідно зробити – це “скомпілювати” стандартні конструкції в певну мову, в нашому випадку, класи Java. Компіляція файла IDL виробляє інтерфейси Java, клієнтські стаб і скелети сервера, які реалізовані для здійснення обміну інформацією один з одним. Ці класи обробляють упаковку / розпакування даних, відому як маршаллінг (marshalling), з типів даних Java на клієнті в типи даних CORBA, і потім назад в типи даних Java на сервері. Ці класи стаб і скелетів також обробляють передачу повідомлень IIOP, яка відбувається між ними.

Клацніть правою клавішею по значку Attendees.idl і виберіть Make з з’являється спливаючого меню, яке згенерує необхідні класи.

Щоб генерувати сервер CORBA, який здійснить метод “number”, виберіть File, New … в меню панелі інструментів. Виберіть закладку Enterprise на Objects Gallery, і потім виберіть CORBA Server Application. При використанні щойно створеного файлу IDL, будуть створені залишилися файли сервера. Крім того, буде створено GUI, який може хостіровать сервер.

Створені файли:

 

Attendees. Java: Просто інтерфейс Java, який відповідає нашому інтерфейсу IDL. Об’єкт Java, який забезпечує реалізацію для нашого об’єкта Attendees, реалізує цей інтерфейс.

AttendeesHelper.java: абстрактний клас, який використовується клієнтом для прив’язки до об’єкта Server і забезпечує безліч сервісних методів для отримання ID Attendees, отримання (narrowing) CORBAServices, витягнутих з БУДЬ-ЯКИХ типів, і т.д. AttendeesHolder.java: Використаний Helper-ом, цей клас є класом підтримки, який забезпечує здатність передачі об’єкта Attendees як параметра CORBA.

AttendeesOperations.java: клас інтерфейсу, який використовується в якості альтернативи для прив’язки скелета через делегатів. Також допомагає подолати обмеження класів Java, яке виражається в нездатності успадкування від множинних інтерфейсів.

AttendeesPOA.java: Клас POA Java, від якого буде реалізований фактичний Object.

AttendeesPOATie.java: Це – делегована реалізація для інтерфейсу. Кожен екземпляр класу tie повинен бути ініціалізований екземпляром класу реалізації, який реалізує клас Operation, до якого він делегується при кожній операції.

_AttendeesStub.java: Використовується Helper-ом для делегування викликів методу для віддаленого об’єкта, це – код стаб для використання на стороні клієнта.

На стороні сервера:

 

Bicon2000ServerApp.java: Серверне додаток, який завантажить ServerFrame і виконає AttendeesImpl (реалізацію).

AttendeesImpl. Java: Фактична реалізація. Це – клас Java, який ми змінимо на реалізацію результату звернення до методу “number”. У цьому методі ми повертаємо (int) (1.2 * lastYear).

ServerFrame. Java: Клас Frame (GUI).

ServerMonitor.java: Підтримує лог-файл сервера і є контейнером для всіх сторінок Server Monitor.

ServerMonitorPage.java: Реалізує сторінку Server Monitor для відображення лічильників інтерфейсу.

ServerResources.java: Містить рядки серверного додатка для локалізації.

Щоб згенерувати клієнта, який може викликати метод number, виберіть File, New … з меню Top. Виберіть закладку Enterprise з Objects Gallery. При використанні IDL, це призведе до генерації класу ClientImpl. Щоб швидко перевірити клієнта, створіть метод main в цьому класі.

public static void main (String [] args) throws Exception {
System.out.println(new AttendeesClientImpl().number(10000));
}

Виконання програми (-ний)

Для виконання програми (-ний), спочатку запустіть SmartAgent. Виберіть Tools з меню Toolbar і виберіть VisiBroker Smart Agent. Якщо меню перевірено, ви вже маєте запущений Smart Agent. Клацніть правою клавішею миші по bicon2000ServerApp.java і виберіть Run із спливаючого меню. Щоб запустити клієнта, виберіть AttendeesClientImpl і виберіть Run із спливаючого меню. Як результат має повернутися 12000.

У вас тепер є справжнє чинне додаток CORBA. JBuilder не тільки скорочує монотонну роботу розробки програми в командному рядку EMACS, він також дозволяє генерувати швидкі прототипи та підтвердження працездатності концепції вашої програми фактично в межах декількох хвилин.

Smart Agent

Для повного розуміння коду, згенерованого Jbuilder, ми повинні вивчити деякі нові деталі реалізації VisiBroker CORBA. Перший новий пункт для обговорення – це Smart Agent, іноді званий по імені виконуваного файлу OSAGENT. Smart Agent – платформо-залежний запускається процес, який надає сервіси каталогів для клієнтів і реалізацій CORBA. Іноді він порівнюється з інформаційним оператором, з клієнтськими запитами, порівнюваними з телефонним дзвінком в інформаційну службу, де клієнт запитує іншої людини по імені, і оператор з’єднує ці дві сторони. Коли клієнт намагається з’єднатися з конкретним об’єктом, Smart Agent визначає розташування примірника цього об’єкта і повертає посилання клієнту. З іншого боку цієї моделі, коли реалізації об’єкта стануть доступними, вони реєструють себе за допомогою Smart Agent, так що клієнти можуть знаходити їх. Аналогічно, коли реалізація завершує роботу, вона разрегістрірует себе за допомогою Smart Agent. Якщо з якоїсь причини реалізація об’єкта завершується без разрегістраціі допомогою Smart Agent, агент, в кінцевому рахунку, виявить це за допомогою pingа і разрегістрірует реалізацію самостійно. Smart Agent – один з ключових процесів в моделі VisiBroker CORBA в абстрагуванні місця розташування об’єкта, він просто відшукує об’єкт, коли приходить запит. Клієнту немає необхідності знати, чи знаходиться об’єкт в межах того ж самого комп’ютера, або в глобальному масштабі, і запущений він в іншій операційній системі.

Server Side Object Implementation
public class AttendeesImpl extends bicon2000.bicon2000.AttendeesPOA {
String name = “Attendees”;


public int number(int lastYear) {
ServerMonitor.log(“(” + name + “) AttendeesImpl.java number()”);
return (int)(1.2 * lastYear);
}
}  
 
Server Side Code
/ / SmartAgent слухає порт UDP 14000. / / Це часто називається биттям серця smartagent-а.
System.getProperties().put(“ORBagentPort”, “14000”); / / Ініціалізація ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init
(args, System.getProperties()); / / Отримання RootPOA; замість ініціалізації BOA, / / Ми отримуємо посилання на / / Кореневої POA
POA poaRoot = POAHelper.narrow
(orb.resolve_initial_references(“RootPOA”)); / / Установка строкової константи, яка буде реєструвати цей / / Об’єкт
name = “Attendees”; / / Установка політики (циклу життя – lifespan) в Persistent
org.omg.CORBA.Policy[] AttendeesPolicies = {
poaRoot.create_lifespan_policy(LifespanPolicyValue.PERSISTENT)
};
/ / В BOA, об’єкт стає персистентності (збереженим), якщо отримує / / Ім’я. Деякі BOA можуть підтримувати як короткочасні, так і / / Збережені об’єкти. Однак одиночний POA може підтримувати лише або / / Збережені, або короткочасні об’єкти. Кореневий poa, отриманий / / Нами вище, підтримує лише короткочасні об’єкти. Однак нам / / Необхідний саме зберігається об’єкт. Отже, ми створимо інший / / POA з політикою життєвого циклу “persistence” (зберігається).
POA poaAttendees = poaRoot.create_POA(name + “_poa”,
poaRoot.the_POAManager(),
AttendeesPolicies);
/ / В BOA, сервант є об’єктом CORBA. Але в POA, сервант і об’єкт / / CORBA розрізняються. Замість створення об’єкта CORBA і установки / / Obj_is_ready для активації цього об’єкта, ми тепер створимо / / Сервант і активуємо його в POA за допомогою ID. Оператор new / / AttendeesImpl ()) є реалізацією серванта і активізує / / Цей сервант за допомогою ID в myPOA
poaAttendees.activate_object_with_id
(name.getBytes(), new AttendeesImpl());
/ / Активуємо менеджера POA
poaRoot.the_POAManager().activate();
/ / Почекаємо до прибуття запитів
orb.run();
Client Side Code
public class AttendeesClientImpl {
boolean bInitialized = false;
bicon2000.bicon2000.Attendees _attendees;
com.borland.cx.OrbConnect orbConnect1;
String name = “Attendees”;
public AttendeesClientImpl() {
try { jbInit();}
catch (Exception ex) { ex.printStackTrace(); }
}
private void jbInit() throws Exception {
}
public boolean init() {
if (!bInitialized) {
try {
org.omg.CORBA.ORB orb = null;
if (orbConnect1 != null) {
orb = orbConnect1.initOrb();
}
if (orb == null) {
// Initialize the ORB
orb = org.omg.CORBA.ORB.init((String[])null,
System.getProperties());
}
// Get the Server Object
_attendees = bicon2000.bicon2000.AttendeesHelper.bind(
orb, “/” + name + “_poa”, name.getBytes());
bInitialized = true;
}
catch (Exception ex) { ex.printStackTrace(); }
}
return bInitialized;
}
public int number(int lastYear) {
init();
return _attendees.number(lastYear);
}
public static void main (String [] args) throws Exception
{ System.out.println(new AttendeesClientImpl().number(10000)); }
}

Розширення нашого прикладу

Написане нами додаток Attendees було занадто спрощеним прикладом того, як може виглядати фактична Attendance System (Система відвідуваності). Щоб далі оцінити IDL і перевага CORBA, ми знову ненадовго повернімося до нашого проекту Attendees. У нашому вправі інформація про відвідувачів була повернена за допомогою виклику простого методу для об’єкта Attendees. Нам може знадобитися додавання процентних змін, відсотків за день, бронювання готелю та обробки виключень, що відстежують недоступність даного методу для дзвінка. Наш IDL тоді виглядав би приблизно так:

/**
* Attendees.idl * Приклад IDL для конференції Borland / Inprise
*
*/
module bicon2000 {
/** * Інтерфейс Person визначає персону
*/
interface Person {
string getName();
};
/ *** Інтерфейс Attendees визначає об’єкт конференції * Attendees. Ця конференція є триденної. * /
interface Attendees {
enum ConferenceDays { DAY1, DAY2, DAY3 };
exception RoomNotAvailable {};
long number(in long lastYear);
float percentIncrease();
float percentIncreaseOnDay( in ConferenceDays whichDay );
boolean bookHotelRoom(in Person attendee) raises (
RoomNotAvailable);
};
};

Зауважимо, що цей модуль має більш одного інтерфейсу. Два скелета і proxy – це коди для двох об’єктів, які будуть генеруватися при запуску IDL2JAVA. Важливо зрозуміти, що IDL є дуже багатим мовою, який може повністю описати дизайн нашого об’єкту і, при компіляції, у нас в кінцевому рахунку залишається тільки реалізація об’єктів Java, як і при використанні будь-яких класів Java. Це свідчить про те, що дизайн додатків CORBA не накладає обмежень і не робить ніяких припущень щодо можливої ​​реалізації.

Додаткові сервіси VisiBroker

У нашому прикладі ми торкнулися багато з основних засобів, що надаються VisiBroker зокрема, і в цілому архітектурою CORBA. Існує, однак, кілька додаткових сервісів і процесів, що не використовуються в цьому прикладі, які часто необхідні в великомасштабних розробках CORBA. Наведемо деякі з цих компонентів:

Консоль (console) – Inprise VisiBroker Console є інструментом, який дозволяє вам переглядати і управляти сервісами VisiBroker ORB з використанням графічного інтерфейсу. Зокрема ви можете використовувати браузери сервісів ORB, щоб управляти об’єктними серверами, керувати конфігурацією гейткипером (gatekeepers), переглядати репозитарій інтерфейсів, редагувати контексти іменування, шукати екземпляри об’єктів і переглядати OAD-и у вашій мережі. Дизайн VisiBroker Console подібний графічним інтерфейсам консолей в Inprise Application Server і Inprise AppCenter.

SmartAgent – Smart Agent VisiBroker (osagent) динамічна, розподілена служба каталогів, яка забезпечує засоби, що використовуються як клієнтськими програмами, так і реалізаціями об’єктів. Smart Agent повинен бути запущений принаймні на одному хості в межах вашої локальної мережі. Коли ваша клієнтська програма викликає bind () для об’єкта, Smart Agent автоматично консультує. Smart Agent визначає місцезнаходження зазначеної реалізації так, щоб могло бути встановлено з’єднання між клієнтом і реалізацією. Зв’язок зі Smart Agent повністю прозора для клієнтської програми. Якщо для POA встановлена політика PERSISTENT і використовується activate_with_id, Smart Agent реєструє об’єкт або реалізацію так, щоб клієнтська програма могла їх використовувати. Коли об’єкт або реалізація дезактивовані, Smart Agent видаляє їх зі списку доступних об’єктів. Як і у випадку з клієнтськими програмами, зв’язок з Smart Agent повністю прозора для реалізації об’єкта.

OsFind – Якщо ми хочемо упевнитися, що Smart Agent обізнаний про об’єкт, ми можемо переконатися в цьому, запустивши платформо-залежну утиліту VisiBroker, звану osfind. Коли ми виконуємо osfind, ми бачимо, що наш об’єкт зареєстрований Smart Agent і доступний для клієнтських запитів. SmartAgent, що виконується в середовищі Windows, надає консоль для перегляду зареєстрованих об’єктів. Крім того, ви можете візуально переглядати лог-файл і прив’язки. OSFIND також повідомляє інформацію щодо Object Activation Demon, спеціального процесу VisiBroker, який може активізувати сервери в якості постачальника об’єктів у міру того, як вони будуть затребувані клієнтами.

Отладчик

RMI-over-IIOP – RMI (remote methods invocation – виклик вилучених методів) – механізм Java, який дозволяє створювати і використовувати об’єкти в розподіленому середовищі. В цьому сенсі, RMI являє собою ORB, який є мовно-специфічним (Java) і не-CORBA сумісним. OMG випустила специфікацію відображення мови Java на IDL, яка дозволяє класів Java, написаним з використанням RMI, взаємодіяти з об’єктами CORBA шляхом використання кодування IIOP. VisiBroker має два компілятора, які дозволяють адаптувати ваші існуючі класи Java для роботи з іншими об’єктами, що використовують VisiBroker ORB. Компілятор java2iiop дозволяє адаптувати ваші RMI-сумісні класи для використання IIOP, генеруючи відповідний повний скелет, стаб і класи Helper-а. Компілятор java2idl генерує IDL виходячи з ваших класів Java, дозволяючи вам реалізовувати їх на мовах, відмінних від Java.

Репозиторій інтерфейсів (Interface Repository) – необов’язкова служба, яка може надавати подробиці щодо конкретного інтерфейсу на вимогу клієнтів. Таким чином, клієнти можуть опитувати репозиторій інтерфейсів, щоб вивчити, які методи пропонуються інтерфейсом, і в свою чергу, викликати їх. Репозиторій інтерфейсів може також використовуватися для збереження додаткової інформації щодо інтерфейсу, типу інформації про його активації.

OAD – Раніше коротко згадуваний OAD або Object Activation Demon (Демон активації запитів) може використовуватися для активізації серверних процесів або на вимогу, як об’єктів клієнтських запитів всередині них, або викликом методів для них. OAD використовує відображення, збережені в репозиторії інтерфейсів, для визначення того, які сервери забезпечують які інтерфейси.

Сервіси іменування (Naming Services) – Дозволяє знаходити об’єкти, грунтуючись на контексті іменування – спеціалізованому об’єкті, який зберігає унікальну об’єктну посилання і прив’язку іменування. За допомогою сервісів іменування, розробники і адміністратори можуть привласнювати логічні імена об’єктів, які можуть пізніше бути знайдені за допомогою цих імен.

Перехоплювачі / обробники подій / тригери (Interceptors / Event Handlers / Triggers) – Ці сервіси можуть бути написані для здійснення більш повного контролю над прив’язкою і повторної прив’язкою, обробки відмов і забезпечення сервісів нижчого рівня, таких як балансування завантаження або шифрування.

Гейткіпер (Gatekeeper) – Гейткіпер дозволяє клієнтам VisiBroker зв’язатися з серверами, що знаходяться в різних мережах, при одночасному узгодженні обмежень захисту, накладених web-броузерами і захисними фільтрами (firewalls). Gatekeeper виконує функції шлюзу між клієнтами і сервером, коли обмеження захисту, накладені Java sandbox security або мережевими фільтрами, не допускають для клієнтів безпосереднього зв’язку з серверами. Gatekeeper – це GIOP проксі-сервер, повністю сумісний зі специфікаціями OMG CORBA Firewall. Крім того, Gatekeeper забезпечує наступні функціональні можливості: початкова загрузка, прозорість місця розташування, надання можливості зворотного виклику, тунелювання HTTP, функціонування в якості простого web-сервера для завантаження класів, що настроюються засобах управління доступом, заснованих на IP, балансування завантаження, відмовостійкість.

Інтерфейс динамічних викликів (Dynamic Invocation Interface) – Цей інтерфейс дозволяє клієнтам CORBA викликати методи виконання по імені і виявляти ці методи під час виконання за допомогою звернення в репозитарій інтерфейсів. DII дозволяє формувати клієнтів без використання файлів стаб, сформованих з коду IDL.

Інтерфейс динамічних скелетів (Dynamic Skeleton Interface) – Подібно DII, DSI дозволяє реалізації об’єктів бути сформованою без розширення скелетних класів. Може виявитися корисним надати можливість об’єкту реалізовувати декілька інтерфейсів.

Прив’язка зв’язування (Tie Binding) – Забезпечує створення реалізацій об’єктів CORBA, виходячи з класів, які не успадковуються від org.omg.CORBA.Object. Делегування об’єкта, відоме як об’єкт прив’язки, дозволяє серверу використовувати прямі виклики істинної реалізації об’єкта. Це особливо корисно при створенні об’єктів CORBA, виходячи з існуючих класів, так як Java не підтримує множинне спадкування.

Smart Stubs – Стаб, які втручаються у всі виклики методу, надаючи хороші обробники переривань для додавання коду, призначеного для захисту, кешування і балансування завантаження.

Висновок

Ми обговорили головні концепції VisiBroker CORBA і реалізували простий приклад його використання. Хоча з впевненістю можна сказати, що реальні програми значно складніше, цей приклад представляє багато з всеосяжних концепцій архітектури CORBA. Ясно, що CORBA є погоджувальною стандартом для промисловості, яка значно змінила уявлення про те, як може бути виконана розробка інформаційних систем за допомогою здійснення систем розподілених об’єктів і переходу від успадкованих систем на рівень сучасних архітектур. Прочитавши цю статтю, розробники та архітектори зможуть чітко усвідомити основну архітектуру CORBA і мотивації її використання, а також придбати практичні знання щодо того, як максимально використовувати переваги VisiBroker в майбутніх додатках, розроблених в середовищі JBuilder.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*