Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:JAVA. Серверные приложения
.pdf
Часть 4. Распределенные компненты EJB 241
ления, 9. Здесь также отсутствуют сведения о базе данных и используемом драйвере доступа.
Оба метода ejbLoad() и ejbStore() используют другие методы для по-
лучения сведений о базе данных. Сведения об источнике данных хранятся в дескрипторе, и сведения из дескриптора можно получить, используя InitialContext.
Существует еще один метод, работающий с базой данных ejbRemo-
ve(), удаляющий запись из таблицы. Тело метода практически не отличается от тел других методов управления данными, за исключением
SQL-оператора. В методе ejbRemove() это будет DELETE FROM tbl
WHERE id = «xx»
Кроме основных методов по работе с постоянными данными, сущест-
âóþò пользовательские методы findXXX(). Äëÿ каждого метода
findXXX(), описанного в home-интерфейсе, обязательно должен существовать метод-близнец в основном классе Enterprise bean. В отличие от
своих системных коллег, методы find XXX() работают с конкретным
SQL-запросом по поиску определенных постоянных данных.
Создание home-интерфейса с использованием BMP.
Все, что использовалось для создания home с помощью CMP, пригод-
но и для создания с помощью BMP.
33.3. Создание Session bean
Создание session bean практически ничем не отличается от создания
Entity bean, за исключением некоторых деталей, присущих только session bean. Во-первых, в session bean не определен класс первичного
ключа, во-вторых, в home-интерфейсе отсутствуют любые поисковые
методы find(). Каждый session bean состоит из трех основных частей:
•
основной класс EJB;
•
Home-интерфейс;
•
Remote-интерфейс.
Session bean работает с бизнес-методами, описанными в основном
классе EJB. Используя эти классы, контейнер информирует session bean о различных событиях, создает экземпляр bean.
Создание основного класса отвечает следующим требованиям: реали-
зовывать все бизнес-методы, описанные в основном классе Entity bean;
в классе должны существовать методы создания ejbCreate(); класс должен иметь уровень доступа public и не быть абстрактным; родителем
класса выступает интерфейс javax.ejb.SessionBean.
Как уже указывалось, session bean может находиться в одном из
двух состояний stateful stateless, в зависимости от того, в каком состоянии находится session bean.
Создание основного класса session bean должно отвечать следующим
требованиям:
1. Создаваемый класс должен иметь уровень доступа public и реали-
зовывать интерфейс javax.ejb.SessionBean.
2. Он должен определять и использовать бизнес-методы. Реализация
бизнес-методов в session bean определяет способы, которыми клиент
242 Часть 4. Распределенные компненты EJB
может работать с Enterprise bean. Все бизнес-методы создаются в
основном классе EJB и не предоставляют возможности прямого доступа
клиента. Клиент обращается к бизнес-методам, используя дублирующие методы, описанные в интерфейсе remote, принадлежащего session
bean. Каждый-бизнес метод, описанный в основном классе Enterprise
bean, описывается в remote интерфейсе.
3. Обязательно создание ejbCreate() метода для каждого вызываемо-
го экземпляра enterprice bean. В состоянии stateless session bean имеет
только один метод ejbCreate() без аргументов и ничего не возвращающий. В другом состоянии session bean имеет несколько различных методов ejbCreate(). В отличие от Entity bean, не имеет в home-интерфейсе дублирующих методов ejbPostCreate(). Каждый ejbCreate() метод
должен быть описан в EJB-классе. Как и бизнес-методы, ejbCreate ()
метод не может вызываться непосредственно клиентом. Для осуществления вызова, а в дальнейшем и создания экземпляра класса, контейнером вызывается «брат близнец» из home-интерефейса. После успешного завершения метода ejbCreate() будет создан экземпляр Enterprise
bean.
Каждый метод ejbCreate() должен отвечать следующим требованиям:
а. Обязательно возвращать пустое значение, быть void.
б. Может содержать код и множество значений, необходимых для
EJB-объектов.
В момент создания Enterprise bean определяет системное окружение,
в котором будет выполняться. Для получения системных значений используется объект InitialContext. класса javax.naming.Context. После создания объекта методом ejbCreate() объект класса InitialContext добавляет в
системное окружение два значения, необходимых для дальнейших преобразований. Первый параметр javax.naming.Context. PROVIDER _URL
описывает константу — определяющий адрес выполнения. Другой параметр — javax.naming.Context. INITIAL_CONTEXT_FACTORY также
описывает константу, указывающую имя системного свойства. Переменные описываются в дескрипторе, и разработчик должен самостоятельно
определить методы получения переменных из дескриптора. В примере,
описанном ниже, содержатся основные методы session bean:
1. import java.rmi.*;
2. import java.util.*;
3. import javax.ejb.*;
4. import javax.naming.*;
5. public class testSessionBean implements SessionBean {
6. public java.util.Properties env;
7. private java.lang.String INITIAL_URL = «javax.naming.Context.PROVIDER_
URL»;
8. public java.lang.String INITIAL_SYSPROP = «javax.naming.Context.
INITIAL_CONTEXT_FACTORY»;
9. private javax.naming. InitialContext InitialContext;
10. private SessionContext SessionCtx = null;
11. public testSessionBean() { super(); }
12. public void ejbActivate() throws EJBException, RemoteException {}
Часть 4. Распределенные компненты EJB 243
13. public void ejbCreate() throws java.rmi.RemoteException {
14. env=System.getProperties();
15. env.put(INITIAL_URL, getProviderUrl());
16. env.put(INITIAL_SYSPROP, getNamingFactory());
17. InitialContext=new InitialContext(env);}
18. public void ejbPassivate() throws EJBException, RemoteException {}
19. public void ejbRemove() throws EJBException, RemoteException {}
20. public void setSessionContext(SessionContext arg1) throws EJBException,
RemoteException {sessionCtx=arg1;}
21. private String getProviderUrl(){String _sc=SessionCtx. getEnvironment().
getProperty(INITIAL_URL); return _sc;}}
Практически приведен готовый session bean без реализации бизнес-
методов. Операторы импорта описывают пакеты, наиболее часто используемые при создании ejb session bean, это первые четыре строки — 1,
2, 3, 4. Создаваемый класс наследуется от интерфейса javax.ejb.SessionBean. Именно в данном интерфейсе описаны все методы представленной программы, за исключением метода ejbCreate() и пары методов получения системных параметров из дескриптора. Именно два поля
INITIAL_URL и INITIAL_SYSPROP (строки 7, 8) описывают переменные, содержащиеся в дескрипторе, и являются частью системного окружения. Доступ к полям, прописанным в дескрипторе, осуществляется
при использовании метода getEvironment() объекта SessionContext. Значение, возвращаемое этим методом, указывает на специальную переменную, описанную в системном окружении, дополненном параметром
INITIAL_URL. Попробуем еще раз. Итак, в системное окружение добавляется пара с именем INITIAL_URL и значением, полученным из
дескриптора при помощи метода getEnvironment(). Из полученного объекта при помощи метода getProperty() получается необходимое значение. Описание только что сказанного можно пронаблюдать в строке 21,
в которой описан сам метод. Строка 15 содержит вызов метода. Все вышесказанное относится и к переменной INITIAL_SYSPROP, строка 8.
Создание метода getNamingFactory() остается неописанным специально
для пытливых. Вызов метода в строке 16 возвращает значение системной переменной INITIAL_SYSPROP. Все остальные методы описаны в
родительском интерфейсе SessionBean. Очень интересным здесь является создание нового объекта класса InitialContext, строка 17, очень часто он забывается или создается с параметрами по умолчанию. Потом
возникают трудности. После создания объекта InitialContext метод ejbCreate(), используя специальную технологию JNDI, проводит поиск в
дескрипторе значения, имеющего имя EJB, указанное в методе ejbCreate(). Объект InitialContext является мостом между приложением и дескриптором. Используя методы данного объекта, Enterprise bean получает
доступ к переменным, описанным в дескрипторе. Все методы, описанные в интерфейсе, должны переопределяться в каждом Session bean.
Часть методов не имеет тела, поскольку в этом отсутствует явная необходимость.
244 Часть 4. Распределенные компненты EJB
Создание session home-интерфейс
Home-интерфейс содержит методы создания и удаления экземпляра
session bean и получении метаданных о самом Enterprise bean. Доступ к
home-интерфейсу осуществляется при помощи технологии JNDI. В спецификации рекомендуется именовать создаваемый Home-интерфейс,
используя имя основного класса с окончанием Home.
Каждый Session bean home-интерфейс должен отвечать следующим
требованиям:
интерфейс должен расширяется от javax.ejb.EJBHome интерфейса;
у каждого метода, описанного в home интерфейсе должен быть кор-
респондирующий метод в Ejb классе;
параметры возвращаемые в каждом методе должны быть верными
при использовании RMI;
обрабатывать исключения java.rmi.RemoteException
import javax.ejb.*;
public class MyFirsthome implements EJBHome {
public EJBMetaData getEJBMetaData() throws java.rmi.RemoteExcep-
tion {return null;}
public HomeHandle getHomeHandle() throws java.rmi.RemoteExcepti-
on {return null;}
public void remove(Object arg1) throws java.rmi.RemoteException, Re-
moveException {}
public void remove(Handle arg1) throws java.rmi.RemoteException, Re-
moveException {}}
Session Bean может находиться в одном из двух состояний, «полный»
может иметь несколько методов ejbCreate(), в то же время «несостоятельный « описывает только один такой метод.
33.4. Создание EJB клиента
Все для клиента. Но прежде чем клиент сможет воспользоваться
предоставляемыми услугами, ему необходимо совершить ряд последовательных действий. Первое, что должно выполнить клиентское приложение — это получить доступ к home-интерфейсу для основного клас-
Рис. 4.6. Структура клиентского запроса EJB
Часть 4. Распределенные компненты EJB 245
са. Далее необходимо получить ссылку на remote-интерфейс. Для этого
используются методы home-интерфейса. Создать Session bean, либо создать или найти Entity bean. И, наконец, вызвать те или иные бизнесметоды EJB. Клиент не может обращаться непосредственно к методам
собственно EJB. Вместо этого он вызывает методы его remote-интерфейса. Последовательно описанные выше действия программно описываются следующим образом.
Обращение к home-интерфейсу. Делается это с помощью вызова ме-
тодов JNDI API. Клиент создает контекст имен JNDI, а затем использует его метод lookup для поиска home-интерфейса для sample (рис. 4.6):
public class SampleClient {
...
1. public static void main(String[] args) throws Exception {
2. javax.naming.Context context = new javax.naming.InitialContext();
3. Object objref = (SampleHome) context.lookup(«sample»);
4. SampleHome home = (SampleHome) javax.rmi.PortableRemoteObject.narrow(objref, SampleHome.class);
В данном примере клиентом является стандартное приложение, о
чем говорит метод main(), 1-я строка, в теле которого и происходит обращение и инициализация home-инерфейса. Для других клиентов иниализация проводилась бы в других методах. Во 2-й строке создается
объект context. В начале клиент должен получить базовый контекст
службы имен (initial naming context). В программе создается новый объект типа javax.naming.Context, который в примере называется context.
После этого клиент вызывает его метод lookup() для получения ссылки
на home-интерфейс.
Сейчас, после получения home-интерфейса EJB, можно получить
ссылку на его remote-интерфейс. Именно 4-я строка занимается обращением к remote-интерфейсу. Для этого необходимо использовать create- или find-методы home-интерфейса — 5-я строка. Какой именно метод нужно использовать, зависит от вида EJB, session или Entity и того,
какие методы для EJB предусмотрел его разработчик.
При работе с session EJB клиент получает ссылку на remote-интер-
фейс session EJB с помощью вызова одного из create-методов их homeинтерфейсов. Все Session bean должны определять как минимум один
метод create(). Session без состояния (stateless) должен иметь только
один метод с таким именем, причем метод не может иметь аргументов.
Session bean с состоянием (stateful) может иметь один метод create() и
еще несколько таких методов дополнительно, с различными аргументами. Если метод create() получает аргументы, их значения используются
для инициализации создаваемого экземпляра EJB. Базовый метод create() не имеет аргументов. Напрашивается один маленький вывод: session
bean всегда только создаются заново, в отличие от Entity bean, экземпляр которого можно найти в контейнере. Для поиска клиент вызывает
предназначенные для этого методы find(), подобно тому, как это происходит с поиском нужной записи в СУБД. Это подразумевает, что findметоды выполняют поиск экземпляров EJB, чьи данные уже помещены
246 Часть 4. Распределенные компненты EJB
в хранилище данных. Эти данные могут быть добавлены как с помощью
Entity bean, так и с помощью других инструментов, не имеющих отношения к EJB, например, непосредственно средств управления данной
базой данных или, в случае унаследованных (legasy) систем, данные уже
существуют перед инсталляцией контейнера EJB. Для создания экземпляра EJB с помещением его состояния в сопоставленную с ним БД клиент вызывает метод create(). Для инициализации внутренних переменных Entity bean используются аргументы метода create(). Этот метод
всегда возвращает ссылку на remote-интерфейс, хотя соответствующий
ему метод ejbCreate() возвращает ключ (primary key) экземпляра.
Основным методом поиска Entity bean является метод findByPrima-
ryKey(), который выполняет поиск по значению первичного ключа. Метод findByPrimaryKey() должен быть реализован для каждого Entity
bean. Тип единственного аргумента — primaryKey — представляет собой класс, объявленный в дескрипторе. Этот тип должен соответствовать ограничениям RMI-IIOP и может являться как стандартным классом Java, так и классом, созданным разработчиком. Entity bean существует, пока существуют сопоставленные с ним данные в БД. Время
жизни такого EJB не ограничено временем сеанса связи с клиентом. Экземпляр Entity bean может быть уничтожен с помощью вызова одного
из методов remove() — эти методы уничтожают компонент и удаляют
сопоставленную с ним информацию из базы данных. Существуют и
другие способы удаления Entity bean, например, с помощью средств системы управления базой данных или унаследованной системой.
Все Enterprise bean доступны для следующих типов EJB клиентов:
1. Java servlets.
2. Java Server Pages (JSP).
3. Java-приложений, использующих для взаимодействия RMI.
4. Других Enterprise beans.
Доступ и манипуляция над Enterprise bean должны осуществлять
EJB-клиенты, отвечающие некоторым требованиям:
1. Все клиенты должны уметь работать с RMI, в приложение необхо-
димо импортировать пакет по работе с RMI.
2. Для получения информации о EJB-объекте приложение использу-
åò JNDI API.
Обработку неправильных объектов описывают session bean, а не кли-
ентское приложение, как это часто бывает.
Приложение-клиент должно самостоятельно удалять session bean.
Чтобы EJB-клиент был состоятельным клиентом, он должен иметь
несколько классов, обеспечивающих плодотворное взаимодействие с
Enterprise bean. «Джентельментский» набор EJB-клиента. Здесь можно
говорить о динамическом клиенте (servlet, JSP, приложение), если
брать Web-клиента, точнее, HTML-страницу, то обращение из страницы должно проходить одного из динамических EJB клиентов.
1. Пакет java.rmi — это основной пакет для обеспечения связи.
2. Пакет-дублер javax.rmi с расширенными возможностями содержит
один замечательный объект класса PortableRemoteObject, предназначенный для получения свойств EJB.
Часть 4. Распределенные компненты EJB 247
3. Количество утилит в java.util способно удовлетворить любое самое
взыскательное приложение.
4. Пакет javax.ejb совершенно необходим в создании Enterprise bean.
Создать приложение хорошо, но его же надо еще и назвать. Для этой
сложной операции используются классы пакета javax.naming. Если с
импортом разобрались, остается еще один немаловажный предмет обсуждения — получение ссылки на используемый Enterprise bean. Клиент может использовать как методы создания session bean, так и методы findXXX()entity bean. Прежде чем вызвать бизнес-методы Enterprise bean, клиент обязан создать новый или найти уже существующий
экземпляр EJB. Проделать эту операцию можно в два этапа.
Во-первых, EJB-клиент должен обратиться к EJB-серверу для поис-
ка нужного bean. Обращаясь к методу ejbCreate(), описанному в homeинтерфейсе, создается объект с заданными параметрами, а их, т. е. параметров, а значит, и методов может быть несколько. JNDI используется для нахождения имени EJB. Свойства, вызываемые EJB-клиентом
для инициализации и поиска нужного объекта, отличаются в различных
EJB-серверах. Поэтому рекомендуется использовать файлы свойств
или классы ресурсов для свободного перемещения EJB между EJB-серверами, поставляемыми различными производителями. При инициализации используются переменные, описанные в дескрипторе javax.naming.Context.PROVIDER_URL, свойство, указывающие имя хоста, номер порта, используемого клиентом. Данные указываются в следующем
формате:
iiop://hostname:port, где hostname — IP-адрес или имя машины, на
которой установлен Web-сервер с EJB-сервером, port — номер порта,
используемый сервером. Если указать iiop:///, клиент будет искать
сервер на локальной машине. Другая переменная javax.naming.Context.INITIAL_CONTEXT_FACTORY, определяет имя сервиса доступа,
используемого клиентом.
Во-вторых, клиент организует доступ к EJB-объекту при помощи
методов класса InitialContext. Клиент получает ссылку на home-интерфейс с помощью JNDI. Вначале клиент должен получить базовый контекст службы имен (initial naming context). В программе создается новый объект типа javax.naming.Context, который в примере называется
initcontext.
1. private InitialContext InitContext = null;
2. private ResourceBundle bundle = ResourceBundle.getBundle(
3. «com.rrlabs.ejb.sample.ResourceBundle»);
4. private String nameService = null;
5. private String accountName = null;
6. private String providerUrl = null;
7. if (InitContext == null) {
8. try {Properties properties = new Properties();
9. properties.put(javax.naming.Context.PROVIDER_URL,
10. bundle.getString(«providerUrl»));
11. properties.put(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
12. bundle.getString(«nameService»));
248 Часть 4. Распределенные компненты EJB
13. InitContext = new InitialContext(properties);}
14. java.lang.Object homeObject = InitContext.lookup(bundle.getString(«transferName»));
15. transferHome = (TransferHome)javax.rmi.PortableRemoteObject.narrow
((org.omg.CORBA.Object) homeObject, TransferHome.class);}
После того как был создан объект InitialContext, обращаться к нему
можно на всем протяжении клиентской сессии. Далее используется
стандартная операция поиска необходимого объекта при помощи метода
looкup () объекта InitialContext. После этого клиент вызывает его метод
lookup() для получения ссылки на home-интерфейс. Метод lookup() контекста возвращает объект типа java.lang.Object. Методу lookup() передается имя remote-интерфейса («transferName»). Заметьте, что программа
пробует преобразовать результат вызова метода к типу transferHome,
т. е. типу home-интерфейса. По окончании успешного поиска приходит
операция получения самого объекта при помощи метода javax.rmi. PortableRemoteObject.narrow(). После получения ссылки на интерфейс
transferHome клиент может вызвать его метод create() для получения
ссылки на remote-интерфейс. Получив эту ссылку, клиент может вызывать его методы. На самом деле remote-интерфейс перенаправляет вызовы клиента собственно EJB.
После всего вышесказанного о EJB-клиенте, можно подвести малень-
кий итог того, что должен сделать клиент для получения данных, находящихся на EJB-сервере. Независимо от типа клиента, стандартными
операциями считаются следующие пять этапов:
1. Поиск home-объекта.
2. Определение home-объекта.
3. Создание SessionBean экземпляра.
4. Вызов методов.
5. Удаление SessionBean экземпляра.
В распространенной практике принято первые два этапа прописы-
вать в инициализационных методах приложения, а удаление экземпляра описывать в методах освобождения ресурсов destoy() или finally().
Создание экземпляра и вызовы метода распределяются по телу программы в зависимости от типа клиента. Поскольку не все приложения
поддерживают многопоточность, и не все servlet работают с потоками,
то о создании экземпляра и вызове методов можно говорить достаточно
долго, и как это сделать, каждый решает самостоятельно.
ЧАСТЬ 5. РАБОТА С БАЗАМИ ДАННЫХ ПРИ ПОМОЩИ
ЧАСТЬ 5. РАБОТА С БАЗАМИ ДАННЫХ ПРИ ПОМОЩИ
ЯЗЫКА ПРОГРАММИРОВАНИЯ JAVA
Обрабатываемые данные в компьютерном мире хранятся в различ-
ном виде. Самым распространенным видом хранения является файл и
файловая система, описывающая работу с файлом. Другой способ хранения и обработки информации, — система управления базами данных
(СУБД). Информация, хранящаяся в СУБД, так же как и файловая система строго структурирована и в некоторых случаях использует те же
алгоритмы поиска и обработки, что и файловая система. Сама СУБД,
просто система, свод правил и набор механизмов, обеспечивающих доступ к данным, хранящимся в базе данных. СУБД и база данных в большинстве литературных источников по данной тематике не разделяются.
Хотя СУБД описывает данные и механизмы, с чьей помощью обрабатываются данные, база данных — обычный файл, находящийся в файловой системе, файл, содержащий данные, с которыми работает механизм
СУБД. Прелесть СУБД — в строгой структуризации и типизации данных. Все множества данных СУБД хранит в виде таблиц, хотя на самом
деле данные находятся в файле и даже различных файлах, но СУБД
умело скрывает местонахождение данных, заставляя пользователя поверить в таблицы, описывающие данные. Все современные СУБД работают с реляционными (относительными) таблицами, в двух словах —
с таблицами, имеющими отношение друг к другу и использующими для
своих отношений специальный набор правил. Набор правил описывается универсальным языком. Для доступа к данным, хранящимся в реляционных таблицах СУБД, разработан язык SQL — язык структурированных запросов (structured query language).
SQL — англоподобный язык, независимый от конкретной СУБД,
имеет встроенные возможности создания клиент/серверных программ,
что немаловажно для Web-приложений, обеспечивает программный доступ к СУБД. С помощью SQL можно управлять базой данных и выполнять прочие функции работы с данными.
Доступ к базе данных может осуществляться двумя способами: вы-
зов SQL-операторов из клиентской программы или вызов осуществляется в интерактивном режиме, командная строка или командная утилита. Интерактивный доступ использует только чистый SQL, используя
динамические SQL-операторы. Пользователь базы данных вводит SQLзапрос и очень быстро получает ответ в виде таблицы, так как работает
непосредственно с базой. Другой способ — вызов SQL-операторов из
клиентского приложения — идентичен интерактивному по SQL-запро-
JAVA
250 Часть 5. Работа с базами данных при помощи Java
сам, но SQL-операторы вводит не пользователь, а программа. Статический или, как его еще называют встроенный SQL, осуществляет запрос
также при помощи SQL, но из приложения, написанного на другом языке программирования — ADA, Java, C++ и т. д.
Главная идея SQLJ состоит в непосредственном объединении опера-
торов разных языков программирования, в данном случае SQL и Java.
Выше уже упоминалось о достоинствах SQL, стоит ли говорить о до-
стоинствах Java? Хотя SQL и является языком программирования, он
лишен некоторых особенностей, присущих стандартным языкам программирования. Если количество библиотек классов Java достаточно обширно и предназначено для приложения любой сложности, не считая
real-time систем, здесь главенствует ADA. Смесь двух столь мощных
языков программирования, как SQL и Java, приводит к созданию очень
гибких, платформонезависимых, СУБД независимых, программно независимых приложений.
SQLJ не первая попытка слияния Java и SQL. С момента рождения
Java поставляется разработчикам программного обеспечения с набором
классов, предназначенных для работы с базами данных. Java database
Connectivity (JDBC) — набор API, обеспечивающий доступ к СУБД. API
JDBC является частью пакета JDK. JDBC не делает никаких предположений об источнике информации и схеме хранения информации. JDBC
используется при создании приложений, генерирующих SQL-запросы в
момент исполнения, это так называемая динамическая реализация
SQL-запросов.
Программирование с использованием статических операторов требу-
ет значительно меньше затрат, чем создание динамических SQL-операторов, поскольку часть работ выполняется в момент компиляции. Количество статических операторов, используемых для создания SQL-запроса, меньше на òî же количество действий, производимых с
помощью динамических операторов. Пользователю нет необходимости
вводить данные авторизации для доступа к данным. Выполнения операторов идентификации в SQLJ-приложениях основываются на данных, полученных в момент компиляции приложения. Очень часто в
Web приложениях возникает ситуация, требующая обновления таблицы пользователем, введение или удаление данных. Еще чаще пользователь, работающий с таблицей, не является создателем рабочей таблицы. Практически во всех современных базах данных разграничены роли создателей и пользователей таблиц, у каждой роли имеются свои
права, определенные как базой данных, так и системным администратором. Кроме того, нельзя учесть всех внешних пользователей, а в Web
практически невозможно, да и не нужно, но удаленные пользователи
должны обязательно иметь права на совершение ряда действий над
данными таблиц СУБД.
В стандарте SQLJ определены встроенные объекты, облегчающие со-
здание прав доступа различным пользователям или группам пользователей. Создание специальных SQLJ-объектов позволяет создать различное количество пользовательских профилей соединения с базой данных. Каждому пользовательскому профилю задаются собственные
права работы с данными. Комбинирование операторов доступа СУБД
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]