Приклад простого додатка JBuilder-CORBA-Oracle, Різне, Програмування, статті

Введення

Простий приклад програми JBuilder-CORBA-Oracle, описаний в цій статті, призначений для розробників, які тільки починають роботу з Java і CORBA, але вже вивчили основи цих технологій. В даній роботі немає опису Java і CORBA, так як мета статті – показати застосування технологій Java + CORBA на практиці. Читач, який цікавиться теорією, знайде всю необхідну інформацію в літературі, список якої знаходиться в кінці статті.

Приклад демонструє:



Основні характеристики прикладу:


Незалежність від конкретної СУБД. CORBA-сервер використовує для доступу до БД JDBC-драйвер, і тому може працювати з будь-якою СУБД для якої такий драйвер є.


Зручність налагодження CORBA-об’єктів. Об’єкти можуть використовувати звичайний print () для виводу налагоджувальної інформації у вікно сервера.


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


Перегляд і редагування результатів запитів в сітці JBuilder. Сітка є зручним інструментом для перегляду, вставки, редагування і видалення даних. Стандартний приклад ProviderResolver з JBuilder показує, як можна використовувати нестандартний джерело даних у разі текстового файлу, однак в даному прикладі показано, як застосувати цю можливість безпосередньо до об’єктів CORBA. Крім того, виправлені помилки, які містить стандартний приклад.


Звичайно, при промисловій експлуатації CORBA-об’єктів, слід використовувати один з серверів додатків, що є в даний час на ринку (наприклад, Borland AppServer). Однак, для розробки і тестування простих додатків, такого “мінімального” сервера цілком достатньо.


Установка


Для установки і запуску прикладу необхідні наступні продукти:



Після установки JBuilder, необхідно налаштувати середовище для роботи з VisiBroker, використовуючи Enterprise Setup (подробиці див в документації до JBuilder). Також слід перевірити, що змінна оточення CLASSPATH містить шляху до всіх необхідних драйверам і бібліотекам.


Приклад розташований в каталозі OraCorbaSample. Для складання сервера необхідно зайти в каталог OraCorbaSamplecorba-server і виконати наступні команди:


prompt> mkserver – складання сервера


prompt> mkuser – складання прикладу


Також слід в оболонці SQL Plus від SCOTT / TIGER виконати скрипт userdb.sql, який містить об’єкти, необхідні для роботи прикладу.


Тестування сервера:



Для складання клієнта, необхідно за допомогою JBuilder зібрати проект


OraCorbaSamplejb-clientCORBA_Grid.jpx і запустити його. Не забудьте налаштувати середу JBuilder для використання VisiBroker (див. вище).


На екрані повинен з’явитися сітка із записами з таблиці EMP (службовці). Спробуйте відредагувати запис, додати, видалити.


Опис структури каталогів сервера


Структура каталогів сервера має наступний вигляд:



server – класи сервера


test – класи для тестування об’єктів прикладу


user – каталог для об’єктів користувача за замовчуванням


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


Каталог server містить класи, які власне і є сервером об’єктів CORBA. Сервер створює і знищує користувальницькі об’єкти за запитом програми-клієнта. Процес створення користувацьких об’єктів описаний нижче.


Каталог test містить класи для тестування об’єктів. Це необов’язкові програми, написані користувачем, основним призначенням яких є перевірка функціонування розроблених об’єктів. Тестування об’єктів відразу після їх створення, є гарною практикою і дозволяє виявити помилки на ранній стадії, до роботи над реальним додатком, що використовують GUI.


Каталог user є каталогом користувальницьких об’єктів за замовчуванням. Допускається існування і інших каталогів об’єктів, проте в цьому випадку потрібно явно вказувати шлях до об’єкта, наприклад MyPackage.MyObject . Каталог user також містить клас DefaultConnection, який полегшує перенесення користувацьких об’єктів в іншу CORBA-середу.


Кореневий каталог сервера містить наступні файли:


clean.bat – очищення каталогів


client.bat – запуск тестового клієнта


mkserver.bat – компіляція сервера, очищення каталогів сервера


mkuser.bat – компіляція клієнта, очищення каталогів клієнта


server.bat – запуск сервера


db.properties – файл настройки сервера


Файли client.bat, mkuser.bat не є файлами загального призначення і потрібні тільки для збірки і запуску конкретного прикладу, тоді як файли mkserver.bat і server.bat призначені для побудови та запуску сервера об’єктів.


IDL-интерфес сервера


Інтерфейси сервера описані в файлі serverdb.id l (модуль Database) і є ключовими для взаємодії з БД.



Додаткові об’єкти сервера


Інтерфейси допоміжних об’єктів сервера визначені в модулі DBObject файлу serverdb.idl і можуть використовуватися користувачем для спрощення розробки:



Слід зазначити, що ці інтерфейси – теж приклади і використовувати їх необов’язково. Більш того, їх використання може викликати необхідність зміни вихідних. idl-файлів (додавання модуля DBObject ) При перенесенні об’єктів в інше середовище. Однак вони зручні, тому що надають самі основні ф-ії джерела даних. Наприклад, якщо об’єкт успадкований від BaseDataSet, то сесія автоматично викликає метод BaseDataSet.close () при видаленні об’єкта, яким вона володіє. Це може запобігти витоку ресурсів (програміст забуває закрити / видалити об’єкт), майже неминуче виникає у великих проектах.


Опис роботи сервера


Клас DBServer (файл DBServer.java) містить ф-ію main (), яка і запускає сервер об’єктів. Сервер починає свою роботу з ініціалізації ORB. Потім сервер створює новий POA-адаптер, сервант, який реалізує менеджер сесій, і активізує сервант на створеному раніше POA. Після активізації менеджера адаптера і виклику методу orb.run (), сервер очікує запитів від клієнтів в нескінченному циклі.


Запити клієнтів обслуговує сервант менеджера сесій, який реалізує інтерфейс SessionManager. Клієнти можуть отримати доступ до об’єктів БД тільки через цей інтерфейс, так як інші об’єкти створюються і реєструються всередині сервера і не видно зовні. Після отримання посилання на інтерфейс SessionManager, клієнт викликає метод SessionManager.getSession () для доступу до об’єкта Session. При виклику цього методу сервер створює сервант, який реалізує інтерфейс Session і активізує його на POA-адаптері по-замовчуванню. Сесія в свою чергу встановлює JDBC-з’єднання з БД. Саме в контексті об’єкта “сесія” створюються конкретні об’єкти, що реалізують інтерфейси для доступу до БД. Об’єкти створюються методом Session.getObject (). Цей метод може створювати об’єкти будь-якого типу, так як повертає об’єкт CORBA :: Object, який є предком всіх CORBA-об’єктів. Клієнт може отримати конкретний об’єкт, виконавши приведення типу за допомогою методу XXXHelper.narrow ().


Сервер обслуговує користувальницькі об’єкти, які мають конструктор без параметрів. Це зроблено для забезпечення кращої переносимості об’єктів в інші середовища (наприклад, в JServer Oracle). Тоді виникає питання. Як для користувача об’єктів передається JDBC-з’єднання c БД: Connection? Для цього створюється спеціальна хеш-таблиця: ConnectionTable, в яку поміщаються пари об’єкт-з’єднання. Елемент об’єкт-з’єднання додається в таблицю після створення об’єкта, тому не потрібно намагатися отримати з’єднання Connection в конструкторі, так як там воно буде дорівнювати null. Краще помістити код отримання з’єднання в спеціальний метод, і викликати його в міру необхідності (див. EmpImpl.java). Таблиця ConnectionTable є “глобальним” об’єктом, тому що доступ до неї здійснюється за допомогою статичного методу ConnectionTable.getInstance () , Який створює тільки один примірник таблиці і зберігає його в статичної змінної класу.


Слід зазначити, що можливі різні підходи до організації роботи з сполуками. Наприклад, замість того, щоб встановлювати з’єднання при створенні об’єкта Session, можна було б реалізувати пул з’єднань та організувати роботу таким чином, щоб користувальницькі об’єкти отримували з’єднання на час виконання якої-небудь дії з БД, і повертали його назад в пул, після того як ця дія виконана. В цьому випадку можна було б зменшити кількість з’єднань з БД (кол-во клієнтів> кол-во сполук), так як об’єкти утримують постійне з’єднання з БД тільки на час виконання коротких операцій. Однак, в даному прикладі використовується підхід з постійним з’єднанням, так як він простіше і крім того, дозволяє клієнту явно управляти транзакціями.


Сесії і виділені об’єкти звільняються за допомогою методів releaseSession () / releaseObject (). При цьому сервер деактівізірует об’єкт, роблячи його недоступним для клієнта, і привласнює посиланням на об’єкт значення null, щоб віддати його збирачеві сміття Java.


Створення користувальницьких об’єктів


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



Робота з користувацькими об’єктами


Після створення об’єкта, бажано виконати його тестування. Для тестування об’єкта необхідно створити клас-додаток. Приклад такого додатка знаходиться в каталозі test: testEmpClient.java. Це додаток тестує об’єкт прикладу EmpImpl.


Правила роботи з об’єктом:



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


Метод bind () не є стандартом CORBA і реалізований тільки в VisiBroker, проте він досить зручний у застосуванні. Для кращої переносимості слід використовувати стандартний сервіс імен CORBA, проте це вимагає запуску додаткового модуля, що реалізує цей сервіс. Так як даний сервер не є тільки прикладом, то цей компонент опущений, хоча його реалізація досить тривіальна.


Опис клієнтського застосування, реалізованого на JBuilder



Приклад простого додатка JBuilder-CORBA-Oracle
Автор: Олександр Лейтес aleytes@mail.ru
www.blacksoftcastle.com
Введення


Про CORBA і Java написано багато чудових книг (див. [1], [2], [3]), які також містять приклади додатків. Але коли настає час розробити щось реальне, відразу виникають питання, про які автори або не пишуть, або пишуть недостатньо детально, або інформація давно застаріла, що у випадку з CORBA трапляється досить часто. Справедливості заради, варто відзначити, що багато книги і не ставлять перед собою таких цілей, та й неможливо осягнути неосяжне.


Простий приклад програми JBuilder-CORBA-Oracle, описаний в цій статті, призначений для розробників, які тільки починають роботу з Java і CORBA, але вже вивчили основи цих технологій. В даній роботі немає опису Java і CORBA, так як мета статті – показати застосування технологій Java + CORBA на практиці. Читач, який цікавиться теорією, знайде всю необхідну інформацію в літературі, список якої знаходиться в кінці статті.


Додаються повні вихідні тексти прикладу, які можна використовувати у власних розробках без жодних обмежень. (Прим: приклади знаходяться в ZIP-архіві статті).


Приклад демонструє:


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


Незалежність від конкретної СУБД. CORBA-сервер використовує для доступу до БД JDBC-драйвер, і тому може працювати з будь-якою СУБД для якої такий драйвер є.


Зручність налагодження CORBA-об’єктів. Об’єкти можуть використовувати звичайний print () для виводу налагоджувальної інформації у вікно сервера.


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


Перегляд і редагування результатів запитів в сітці JBuilder. Сітка є зручним інструментом для перегляду, вставки, редагування і видалення даних. Стандартний приклад ProviderResolver з JBuilder показує, як можна використовувати нестандартний джерело даних у разі текстового файлу, однак в даному прикладі показано, як застосувати цю можливість безпосередньо до об’єктів CORBA. Крім того, виправлені помилки, які містить стандартний приклад.


Звичайно, при промисловій експлуатації CORBA-об’єктів, слід використовувати один з серверів додатків, що є в даний час на ринку (наприклад, Borland AppServer). Однак, для розробки і тестування простих додатків, такого “мінімального” сервера цілком достатньо.


Установка
Для установки і запуску прикладу необхідні наступні продукти:


VisiBroker for Java 4.5 компанії Inprise: http://www.inprise.com/
JBuilder 4.0 компанії Inprise
Oracle 8: http://www.oracle.com/
Oracle 8 JDBC driver: Oracle817classes12.zip (більш ранній драйвер містить помилки)
Після установки JBuilder, необхідно налаштувати середовище для роботи з VisiBroker, використовуючи Enterprise Setup (подробиці див в документації до JBuilder). Також слід перевірити, що змінна оточення CLASSPATH містить шляху до всіх необхідних драйверам і бібліотекам.


Приклад розташований в каталозі OraCorbaSample. Для складання сервера необхідно зайти в каталог OraCorbaSamplecorba-server і виконати наступні команди:


prompt> mkserver – складання сервера


prompt> mkuser – складання прикладу


Також слід в оболонці SQL Plus від SCOTT / TIGER виконати скрипт userdb.sql, який містить об’єкти, необхідні для роботи прикладу.


Тестування сервера:


Налаштуйте параметр JdbcURL у файлі db.properties на реальний сервер мережі.
Запустіть VisiBroker Smart Agent командою osagent.
Запустіть сервер командою server.bat.
Запустіть клієнта командою client.bat. На екрані повинні з’явитися рядки з таблиці EMP, яка знаходиться в стандартній схемі SCOTT / TIGER. Рядки з’являються в циклі 3 рази.
Для складання клієнта, необхідно за допомогою JBuilder зібрати проект


OraCorbaSamplejb-clientCORBA_Grid.jpx і запустити його. Не забудьте налаштувати середу JBuilder для використання VisiBroker (див. вище).


На екрані повинен з’явитися сітка із записами з таблиці EMP (службовці). Спробуйте відредагувати запис, додати, видалити.


Опис структури каталогів сервера
Структура каталогів сервера має наступний вигляд:


Database – допоміжні класи сервера
DBExample – допоміжні класи для об’єктів прикладу
DBObject – додаткові інтерфейси БД
server – класи сервера


test – класи для тестування об’єктів прикладу


user – каталог для об’єктів користувача за замовчуванням


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


Каталог server містить класи, які власне і є сервером об’єктів CORBA. Сервер створює і знищує користувальницькі об’єкти за запитом програми-клієнта. Процес створення користувацьких об’єктів описаний нижче.


Каталог test містить класи для тестування об’єктів. Це необов’язкові програми, написані користувачем, основним призначенням яких є перевірка функціонування розроблених об’єктів. Тестування об’єктів відразу після їх створення, є гарною практикою і дозволяє виявити помилки на ранній стадії, до роботи над реальним додатком, що використовують GUI.


Каталог user є каталогом користувальницьких об’єктів за замовчуванням. Допускається існування і інших каталогів об’єктів, проте в цьому випадку потрібно явно вказувати шлях до об’єкта, наприклад MyPackage.MyObject. Каталог user також містить клас DefaultConnection, який полегшує перенесення користувацьких об’єктів в іншу CORBA-середу.


Кореневий каталог сервера містить наступні файли:


clean.bat – очищення каталогів


client.bat – запуск тестового клієнта


mkserver.bat – компіляція сервера, очищення каталогів сервера


mkuser.bat – компіляція клієнта, очищення каталогів клієнта


server.bat – запуск сервера


db.properties – файл настройки сервера


Файли client.bat, mkuser.bat не є файлами загального призначення і потрібні тільки для збірки і запуску конкретного прикладу, тоді як файли mkserver.bat і server.bat призначені для побудови та запуску сервера об’єктів.


IDL-интерфес сервера


Інтерфейси сервера описані в файлі serverdb.idl (модуль Database) і є ключовими для взаємодії з БД.


SessionManager – Управляє сполуками з БД, виділяючи і звільняючи з’єднання по запиту клієнта. Цей інтерфейс має тільки два методи: getSession () і releaseSession (), назва яких говорить сама за себе.
Session – З’єднання з БД. Об’єкти БД виділяються в контексті сесії, якої вони належать. При звільненні сесії вона звільняє всі виділені об’єкти. Методи об’єкта Session: commit (), rollback (), getUID (), getObject (), releaseObject (). Найбільший інтерес представляють методи getObject () і releaseObject (), так як вони можуть виділяти і звільняти будь-які об’єкти. Метод getObject () повертає об’єкт CORBA :: Object, який перетворюється клієнтським додатком у конкретний об’єкт за допомогою методу XXXHelper.narrow () (див. документацію до VisiBroker for Java). Доступ до об’єкта здійснюється за його імені. Назва об’єкту збігається з ім’ям класу реалізації без розширення. Class. Якщо об’єкт розташований каталозі відмінному від user, то в імені необхідно вказати повну специфікацію об’єкта: MyPackage.MyObject. Методу releaseObject () необхідно передати посилання на об’єкт CORBA :: Object. Метод getUID () повертає унікальний ID записи, викликаючи збережену процедуру БД: getuid (), і передаючи їй як параметр ім’я об’єкта. Природно, процедура має бути створена заздалегідь. Зауважимо, що додаток може не використовувати цей метод зовсім. Метод зроблений для зручності розробки графічних клієнтських додатків, які використовують сітку для перегляду і редагування даних. Функція getuid () для Oracle знаходиться в файлі userdb.sql і використовується клієнтом JBuilder.
Додаткові об’єкти сервера
Інтерфейси допоміжних об’єктів сервера визначені в модулі DBObject файлу serverdb.idl і можуть використовуватися користувачем для спрощення розробки:


DBException – Виняткова ситуація.
BaseDataSet – Основне джерело даних.
MultiRecordDataSet – Джерело даних, який може містити безліч записів.
Слід зазначити, що ці інтерфейси – теж приклади і використовувати їх необов’язково. Більш того, їх використання може викликати необхідність зміни вихідних. Idl-файлів (додавання модуля DBObject) при перенесенні об’єктів в інше середовище. Однак вони зручні, тому що надають самі основні ф-ії джерела даних. Наприклад, якщо об’єкт успадкований від BaseDataSet, то сесія автоматично викликає метод BaseDataSet.close () при видаленні об’єкта, яким вона володіє. Це може запобігти витоку ресурсів (програміст забуває закрити / видалити об’єкт), майже неминуче виникає у великих проектах.


Опис роботи сервера
Клас DBServer (файл DBServer.java) містить ф-ію main (), яка і запускає сервер об’єктів. Сервер починає свою роботу з ініціалізації ORB. Потім сервер створює новий POA-адаптер, сервант, який реалізує менеджер сесій, і активізує сервант на створеному раніше POA. Після активізації менеджера адаптера і виклику методу orb.run (), сервер очікує запитів від клієнтів в нескінченному циклі.


Запити клієнтів обслуговує сервант менеджера сесій, який реалізує інтерфейс SessionManager. Клієнти можуть отримати доступ до об’єктів БД тільки через цей інтерфейс, так як інші об’єкти створюються і реєструються всередині сервера і не видно зовні. Після отримання посилання на інтерфейс SessionManager, клієнт викликає метод SessionManager.getSession () для доступу до об’єкта Session. При виклику цього методу сервер створює сервант, який реалізує інтерфейс Session і активізує його на POA-адаптері по-замовчуванню. Сесія в свою чергу встановлює JDBC-з’єднання з БД. Саме в контексті об’єкта “сесія” створюються конкретні об’єкти, що реалізують інтерфейси для доступу до БД. Об’єкти створюються методом Session.getObject (). Цей метод може створювати об’єкти будь-якого типу, так як повертає об’єкт CORBA :: Object, який є предком всіх CORBA-об’єктів. Клієнт може отримати конкретний об’єкт, виконавши приведення типу за допомогою методу XXXHelper.narrow ().


Сервер обслуговує користувальницькі об’єкти, які мають конструктор без параметрів. Це зроблено для забезпечення кращої переносимості об’єктів в інші середовища (наприклад, в JServer Oracle). Тоді виникає питання. Як для користувача об’єктів передається JDBC-з’єднання c БД: Connection? Для цього створюється спеціальна хеш-таблиця: ConnectionTable, в яку поміщаються пари об’єкт-з’єднання. Елемент об’єкт-з’єднання додається в таблицю після створення об’єкта, тому не потрібно намагатися отримати з’єднання Connection в конструкторі, так як там воно буде дорівнювати null. Краще помістити код отримання з’єднання в спеціальний метод, і викликати його в міру необхідності (див. EmpImpl.java). Таблиця ConnectionTable є “глобальним” об’єктом, тому що доступ до неї здійснюється за допомогою статичного методу ConnectionTable.getInstance (), який створює тільки один примірник таблиці і зберігає його в статичної змінної класу.


Слід зазначити, що можливі різні підходи до організації роботи з сполуками. Наприклад, замість того, щоб встановлювати з’єднання при створенні об’єкта Session, можна було б реалізувати пул з’єднань та організувати роботу таким чином, щоб користувальницькі об’єкти отримували з’єднання на час виконання якої-небудь дії з БД, і повертали його назад в пул, після того як ця дія виконана. В цьому випадку можна було б зменшити кількість з’єднань з БД (кол-во клієнтів> кол-во сполук), так як об’єкти утримують постійне з’єднання з БД тільки на час виконання коротких операцій. Однак, в даному прикладі використовується підхід з постійним з’єднанням, так як він простіше і крім того, дозволяє клієнту явно управляти транзакціями.


Сесії і виділені об’єкти звільняються за допомогою методів releaseSession () / releaseObject (). При цьому сервер деактівізірует об’єкт, роблячи його недоступним для клієнта, і привласнює посиланням на об’єкт значення null, щоб віддати його збирачеві сміття Java.


Створення користувальницьких об’єктів
При створенні користувальницьких об’єктів слід дотримуватися наступних правил:


Вибрати каталог, в якому будуть знаходиться об’єкти. По-замовчуванню використовується каталог user, проте користувач може створити свій власний каталог, з назвою, що характеризує розробляється.
Створити в цьому каталозі файл інтерфейсів: name.idl (див. наприклад, userexample.idl).
Відкомпілювати вийшов. Idl-файл за допомогою компілятора VisiBroker idl2java.
Створити клас об’єкта (див. userEmpImp.java). Кожен об’єкт повинен реалізовувати один і тільки один інтерфейс з. Idl-файлу програми. Якщо інтерфейс є похідним від іншого інтерфейсу, то клас повинен реалізувати всі методи реалізованого інтерфейсу і його предків. Клас об’єкта повинен бути успадкований від відповідного серванта. Код серванта і пакет, в якому він розташований, повинні з’явитися автоматично, після компіляції. idl-файла.
Відкомпілювати вийшов клас за допомогою компілятора VisiBroker vbjc.
Робота з користувацькими об’єктами
Після створення об’єкта, бажано виконати його тестування. Для тестування об’єкта необхідно створити клас-додаток. Приклад такого додатка знаходиться в каталозі test: testEmpClient.java. Ця програма тестує об’єкт прикладу EmpImpl.


Правила роботи з об’єктом:


Ініціалізувати ORB.
Отримати доступ до менеджера сесій SessionManager, викликавши метод bind (): SessionManager seMgr = Database.SessionManagerHelper.bind (orb, “semgr_poa”, “SessionManager”. GetBytes ()).
Створити нову сесію Session за допомогою виклику методу getSession (): Session mySession = seMgr.getSession (“user”, “passwd”, autoCommitFlag).
Створити в контексті даної сесії потрібний об’єкт: org.omg.CORBA.Object myObject = mySession.getObject (“myPackage.myObject”).
Виконати приведення типу: XXX myXXX = XXXHelper.narrow (myObject), де XXX позначає конкретне ім’я інтерфейсу, який даний об’єкт реалізує.
Викликати методи інтерфейсу об’єкта.
Після закінчення роботи з об’єктом звільнити його, викликавши метод mySession.releaseObject (myObject).
Після завершення роботи з сесією звільнити об’єкт методом seMgr.releaseSession (mySession).
Слід зазначити, що для об’єктів розташованих в каталозі user вказувати повну специфікацію об’єкта необов’язково. Досить одного імені.


Метод bind () не є стандартом CORBA і реалізований тільки в VisiBroker, проте він досить зручний у застосуванні. Для кращої переносимості слід використовувати стандартний сервіс імен CORBA, проте це вимагає запуску додаткового модуля, що реалізує цей сервіс. Так як даний сервер не є тільки прикладом, то цей компонент опущений, хоча його реалізація досить тривіальна.


Опис клієнтського застосування, реалізованого на JBuilder


Клієнтський додаток, написаний на JBuilder використовує компонент JdbTable для перегляду і редагування записів таблиці EMP. При цьому, використовується для користувача джерело даних EmpProvider, успадкований від стандартного класу JBuilder: Provider. Для збереження відредагованих даних використовується клас EmpResolver, успадкований від стандартного класу JBuilder: Resolver. Реалізація цих класів у чому повторює реалізацію класів ProviderBean і ResolverBean з прикладу ProviderResolver, який поставляється разом з JBuilder, однак, замість читання текстового файлу використовуються виклики методів інтерфейсу об’єктів.


Є також ще одне невелике відмінність: для отримання унікального ідентифікатора запису, використовується метод Session.getUID (), описаний раніше. Справа в тому, що приклад ProviderResolver містить помилку, яка не дозволяє ввести новий запис, зберегти її, а потім обновити без перезапроса даних. Причина помилки: ROWID записи формується при пересиланні даних у файл і не зберігається в сітці. Тому програма не знає, яку запис їй оновлювати. Для усунення цього недоліку, у прикладі CORBA_Grid визначається подія джерела даних – inserted (), яке відбувається після додавання в сітку нового запису. Усередині цієї події нового запису присвоюється унікальний ідентифікатор: recordUID = Session.getUID (“object_name”).


Зауваження



Список літератури


1. “Основи CORBA“. Роберт Орфа, Ден Харка, Джері Едвардс. Видавництво” МАЛІП “1999.


2. “JAVA і CORBA в додатках клієнт-сервер“. Роберт Орфа, Ден Харк. Видавництво” Лорі “2000.


3. “Питання створення CORBA-додатків” Олександр Цимбал

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


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

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

Ваш отзыв

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

*

*