Фаулер М. Архитектура корпоративных программных приложений

Подождите немного. Документ загружается.

474 Часть II. Типовые решения

сеанса. Разумеется, объем сохраняемой информации существенно ограничен размерами

адресов. Тем не менее данный метод прекрасно справляется с двумя-тремя параметрами,

поэтому он весьма популярен для хранения на стороне клиента небольших значений на-

подобие идентификаторов сеансов. Некоторые платформы автоматически перезаписы-

вают адреса URL, добавляя к ним идентификаторы сеансов. Изменение адреса Web-

страницы может повлиять на работу закладок, поэтому данную схему хранения не

рекомендуется использовать на коммерческих сайтах, связанных с обслуживанием по-

требителей.

Скрытое поле — это поле, значение которого передается обозревателю, но не отобра-

жается на Web-странице. Наличие скрытого поля задается дескриптором вида <INPUT

type = "hidden">. Чтобы сохранить данные на стороне клиента, сервер сериализует

состояние сеанса, помещает его в скрытое поле при отправке ответа и вновь считывает

при получении следующего запроса. Как только что отмечалось, помещаемые в скрытое

поле данные должны быть сериализованы. Обычно в качестве формата сериализации

применяют XML, хотя, как известно, он слишком "многословен". Вместо этого данные

можно сериализовать и в какой-нибудь другой текстовый формат. Не забывайте, однако,

что значение скрытого поля скрыто только во время отображения; чтобы добраться к

этому значению, достаточно просмотреть исходный код страницы.

Остерегайтесь сайтов, содержащих старые Web-страницы или страницы с фиксиро-

ванными адресами. Переместившись на них, вы потеряете всю информацию о состоянии

сеанса.

Последний, пожалуй наиболее спорный, метод хранения состояний сеанса — это ис-

пользование файлов cookie, которые автоматически передаются от сервера к клиенту и

наоборот. Как и при работе со скрытыми полями, помещаемые в файл cookie данные

нужно сериализовать. Объем сохраняемой информации ограничивается размерами фай-

лов — они не должны быть слишком большими. Кроме того, многим пользователям не

нравится присутствие файлов cookie, поэтому их отключают, в результате чего сайт пере-

станет функционировать. Тем не менее в наше время все больше и больше сайтов осно-

ваны на использовании файлов cookie, поэтому подобные неприятности случаются не-

часто. И конечно, наличие этих файлов не представляет никакой опасности для чисто

"домашних" систем.

Не забывайте: файлы cookie безопасны не более чем другие способы хранения ин-

формации, а значит, несанкционированное использование данных возможно и здесь.

Кроме того, файлы cookie работают только в пределах одного имени домена, поэтому,

если ваш сайт разнесен по нескольким доменам, файлы cookie не смогут перемещаться

между его частями.

Некоторые платформы автоматически определяют, разрешено ли на стороне клиента

использование файлов cookie; если это не так, они применяют перезаписывание адресов

URL. Данная схема позволяет легко сохранять на стороне клиента небольшие объемы

сведений о сеансе.

Назначение

Типовое решение сохранение состояния сеанса на стороне клиента обладает массой

преимуществ. В частности, оно поддерживает использование серверных объектов без со-

стояний, обеспечивая максимальную степень кластеризации и устойчивости к отказам.

Глава 17. Типовые решения для хранения состояния сеанса 475

Разумеется, при отказе системы клиента все данные будут утеряны, однако в подобных

ситуациях большинство клиентов ожидают именно такого исхода.

Количество аргументов против сохранения состояния сеанса на стороне клиента стре-

мительно возрастает с увеличением объема сохраняемой информации. Все перечислен-

ные схемы прекрасно подходят для хранения нескольких полей, однако при наличии

больших объемов данных вопросы их размещения и временные расходы, вызванные пе-

редачей вместе с каждым запросом большого количества информации, становятся весьма

критичны. Это особенно верно для HTTP-клиентов.

Применение данного типового решения связано и с проблемами безопасности. Све-

дения, отсылаемые клиенту, могут быть перехвачены и изменены. Единственный способ

предотвратить подобные поползновения — воспользоваться шифрованием, однако

шифрование и дешифровка каждого запроса может нанести большой урон производи-

тельности приложения. С другой стороны, все, что не было зашифровано, является по-

тенциальной мишенью для любознательных глаз. Как правило, их хозяева обладают к

тому же "пронырливыми" пальцами, поэтому не ожидайте, что сведения о состоянии се-

анса вернутся в том же виде, в каком они были отосланы. Все данные, возвращаемые

клиентом, должны быть подвергнуты тщательной проверке на правильность.

Без сохранения состояния сеанса на стороне клиента не обойтись при необходимости

хранить идентификаторы сеансов. К счастью, идентификатор — это всего лишь число,

поэтому проблем с его обработкой в перечисленных выше схемах быть не должно. Тем не

менее попытки перехвата данных случаются и здесь, например если злоумышленник из-

менит идентификатор своего сеанса, чтобы перехватить сеанс другого пользователя.

Для снижения подобного риска большинство платформ генерируют идентификаторы се-

ансов методом случайных чисел; если же такая возможность отсутствует, попробуйте

воспользоваться хэшированием.

Сохранение состояния сеанса на стороне сервера (Server Session State)

Сохраняет сериализованное представление состояния сеанса

на стороне сервера

Принцип действия

Самая простая форма данного типового решения предполагает размещение объекта

сеанса в памяти сервера приложений. В этом случае для хранения объектов сеансов при-

меняется коллекция, расположенная в оперативной памяти, а сами объекты индекси-

рованы по идентификатору сеанса. Все, что требуется от клиента, — передать иденти-

фикатор сеанса, после чего необходимый объект сеанса будет извлечен из коллекции и

направлен на обработку запроса.

Подобная базовая схема основана на том предположении, что у сервера приложений

достаточно памяти для выполнения таких задач. Кроме того, предполагается, что сервер

приложений только один (т.е. кластеризация отсутствует) и что при внезапном отказе

сервера приложений сеанс будет утерян, а вся проделанная работа, как говорится,

"пойдет коту под хвост".

476 Часть II. Типовые решения

Некоторые корпоративные системы вполне довольствуются подобным набором

предположений. Однако остальным он может не подойти. Существует несколько спосо-

бов преодолеть названные ограничения, и эти способы подразумевают применение хо-

дов, которые значительно усложняют данное типовое решение.

Первая проблема связана с использованием системных ресурсов, занятых объекта-

ми сеансов. Вообще говоря, чрезмерное использование ресурсов — самый большой не-

достаток сохранения состояния сеанса на стороне сервера. Очевидное решение данной

проблемы состоит в том, чтобы не сохранять объекты сеансов в памяти, а сериализо-

вать состояние сеанса в объект мементо (Memento) [20]. В связи с этим возникает два

вопроса: в каком формате сохранять состояние сеанса на стороне сервера и где именно

его сохранять?

Формат сериализации состояний сеанса должен быть как можно более простым, по-

скольку основной особенностью сохранения состояния сеанса на стороне сервера является

именно простота программирования. Некоторые платформы снабжены простым меха-

низмом, позволяющим сериализовать граф объектов в двоичный формат. Вместо этого

объекты сеансов можно сериализовать в какой-нибудь текстовый формат, например в

популярный сегодня XML.

Как правило, с двоичным форматом сериализации проще работать, потому что он

практически не требует программирования, в то время как для обработки текстового

формата необходимо написать хотя бы несколько строк кода. Кроме того, двоичные объ-

екты занимают гораздо меньше места на диске; хотя в данном случае объем дискового

пространства не является чем-то критичным, большие сериализованные объекты дольше

активизируются в оперативной памяти.

Несмотря на все это, сериализация объектов в двоичный формат обладает двумя су-

щественными недостатками. Во-первых, двоичный код нечитабелен, что может оказаться

неудобным, если разработчик захочет просмотреть сериализованный объект. Во-

вторых, применение двоичного формата чревато проблемами с использованием различ-

ных версий классов. Если после сериализации объекта к соответствующему классу будет

добавлено новое поле, восстановить сериализованный объект будет невозможно. Разуме-

ется, наличие разных версий программного обеспечения сервера вряд ли затронет многие

объекты сеансов, если только речь не идет о круглосуточно функционирующем сервере,

установленном на нескольких машинах, одни из которых содержат обновленное про-

граммное обеспечение, а другие — нет.

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

ние состояния сеанса на стороне сервера? Наиболее очевидным местом для хранения объ-

ектов сеансов является сам сервер приложений. В этом случае объекты сеансов могут

располагаться непосредственно в файловой системе либо в локальной базе данных.

Это простое решение, однако оно не всегда обеспечивает возможность кластеризации и

высокую устойчивость к отказам системы. Для поддержки всех этих требований объекты

сеанса должны находиться где-нибудь в общедоступном месте, например на совместно

используемом сервере. Это обеспечит возможность кластеризации и высокую отказо-

устойчивость за счет большего количества времени, необходимого для активизации сер-

вера (хотя и эти расходы можно значительно уменьшить с помощью кэширования).

Как ни парадоксально, приведенные аргументы подводят нас к концепции сохране-

ния сериализованного состояния сеанса в базе данных с использованием таблицы сеан-

сов, индексированной по их идентификаторам. В этом случае для сохранения состояния

Глава 17. Типовые решения для хранения состояния сеанса 477

сеанса на стороне сервера в таблице базы данных потребуется применить крупный сериа-

лизованный объект (Serialized LOB, 292). Различные базы данных по-разному обрабаты-

вают крупные объекты, поэтому вопрос производительности во многом зависит от ис-

пользуемой базы данных.

На этом этапе обсуждения мы подошли к определению границы между сохранением

состояния сеанса на стороне сервера и сохранением состояния сеанса в базе данных (Da-

tabase Session State, 479). Эта граница весьма условна. На мой взгляд, первое типовое

решение переходит во второе тогда, когда данные вместо сериализации преобразуются в

стандартный табличный формат.

Если сериализованное состояние сеанса хранится в базе данных, необходимо позабо-

титься об обработке утраченных или незаконченных сеансов. Это наиболее важно для

Web-приложений, занимающихся обслуживанием покупателей. Одним из решений дан-

ной проблемы может стать применение демона, который будет обнаруживать и удалять

сеансы, время жизни которых превышает установленный срок. К сожалению, этот под-

ход может привести к большому количеству параллельных обращений к таблице сеансов.

Каи Ю (Kai Yu) рассказал мне о другом подходе, который он успешно применяет на про-

тяжении нескольких лет: разбить таблицу сеансов на 12 сегментов базы данных и каждые

два часа выполнять циклическое чередование сегментов, удаляя содержимое самого ста-

рого сегмента и направляя к нему новые операции вставки сеансов. Данный подход под-

разумевает, что сеанс может существовать не более 24 часов, однако в действительности

необходимость применения таких длительных сеансов возникает крайне редко.

Реализация всех перечисленных идей требует немалых усилий. К счастью, на рынке

программного обеспечения появляется все больше и больше серверов приложений, ав-

томатически поддерживающих данные возможности. Таким образом, вопросы реализа-

ции последних должны заботить не только и не столько разработчиков, сколько малень-

ких толстеньких производителей серверов приложений и прочих мелочей.

ОСОБЕННОСТИ JAVA-РЕАЛИЗАЦИИ

Существует два распространенных способа реализации сохранения состоя-

ния сеанса на стороне сервера: использование HTTP-сеансов и использование

компонентов сеанса с состоянием. Первый способ более прост и заключается в

сохранении состояний сеанса на Web-сервере. В большинстве случаев это

"привязывает" данные к серверу и делает их весьма чувствительными к отказам

последнего. Некоторые производители реализуют возможность совместного

использования HTTP-сеансов, что позволяет хранить параметры НТТР-сеанса

в базе данных, доступной всем серверам приложений. (Разумеется, это можно

сделать и вручную.)

Вместо этого для хранения сведений о сеансе можно воспользоваться ком-

понентами сеанса с состоянием. Данный подход требует применения EJB-

сервера. EJB-контейнер обрабатывает все действия, связанные с сохранением и

пассивацией состояний сеанса, чем значительно облегчает программирование.

К сожалению, данная схема хранения не исключает привязки к серверу. Впро-

чем, некоторые серверы приложений содержат средства, позволяющие избе-

жать этой неприятной возможности. Один из них — сервер WebSphere от ком-

пании IBM — способен сериализовать компонент сеанса с состоянием в объект

BLOB для размещения в базе данных DB2, что позволяет осуществлять доступ к

состоянию сеанса нескольким серверам приложений.

478 Часть II. Типовые решения

Многие считают, что, поскольку компоненты сеанса без состояния лучше

влияют на производительность приложения, их нужно всегда использовать вме-

сто компонентов сеанса с состоянием. По правде говоря, это полная ерунда.

Прежде чем отказываться от компонентов сеанса с состоянием, рекомендую

протестировать свою среду разработки в условиях ожидаемой нагрузки и прове-

рить, существенно ли различается производительность приложений при ис-

пользовании компонентов сеанса с состоянием и без состояния. Компания

ThoughtWorks провела серию тестирований с использованием нагрузки в не-

сколько сотен параллельно работающих пользователей и не обнаружила какого-

либо падения производительности, вызванного применением компонентов

сеанса с состоянием. Таким образом, если последние не оказывают нега-

тивного влияния на производительность системы при ожидаемой степени

нагрузки и намного легче поддаются обработке, использовать следует именно

их. Остерегаться применения компонентов сеанса с состоянием можно по

другим причинам (например, они могут затруднить обеспечение отказоустой-

чивости для некоторых серверов приложений), однако различие в производи-

тельности становится заметным только при поистине гигантских нагрузках.

И наконец, еще одной возможной альтернативой является использование

компонентов сущностей. Вообще говоря, я не люблю работать с компонентами

сущностей, однако в данном случае их можно использовать, чтобы хранить

крупные сериализованные объекты с состояниями сеансов. Это довольно про-

сто и, что приятно, позволяет избежать многих проблем, так часто связанных

с компонентами сущностей.

ОСОБЕННОСТИ .NET-РЕАЛИЗАЦИИ

Сохранение состояния сеанса на стороне сервера легко реализовать, исполь-

зуя встроенные средства .NET, предназначенные для работы с состояниями се-

анса. По умолчанию .NET хранит сведения о сеансе в самом процессе сервера.

Вместо этого для хранения данных можно использовать службу состояний, рас-

положенную на локальном компьютере или любом другом узле сети. Примене-

ние службы состояний позволяет сохранить параметры сеанса даже при переза-

пуске Web-сервера. Переключение между названными способами хранения

выполняется в файле настроек сервера, поэтому изменять само приложение

вам не придется.

Назначение

Основным преимуществом сохранения состояния сеанса на стороне сервера является

его простота. В большинстве случаев для реализации данного типового решения вообще

не нужно писать отдельного кода. Разумеется, это зависит от того, устраивает ли вас хра-

нение состояний сеанса в оперативной памяти, и, если это не так, от набора возможно-

стей используемого сервера приложений.

Даже при отсутствии всех этих условий реализовать сохранение состояния сеанса на

стороне сервера совсем несложно. Сериализация данных в объект BLOB и размещение

его в базе данных требуют намного меньше усилий, чем преобразование тех же данных

в табличный формат.

Глава 17. Типовые решения для хранения состояния сеанса 479

Самые большие объемы работ связаны с обеспечением функционирования сеансов, в

частности если требуется организовать собственную поддержку кластеризации и устой-

чивости к отказам. В этом случае хранение состояний сеанса на стороне сервера может

оказаться не самым удачным решением, особенно если параметров сеанса довольно мало

или же если их проще преобразовать в табличный формат.

Сохранение состояния сеанса в базе данных (Database Session State)

Сохраняет состояние сеанса как обычное содержимое базы данных

Принцип действия

Когда клиент направляет серверу запрос, первое, что делает серверный объект, — об-

ращается к базе данных и извлекает из нее данные, необходимые для удовлетворения за-

проса. Затем он выполняет всю необходимую работу и записывает обновленные данные

обратно в базу данных.

Чтобы извлечь информацию из базы данных, серверному объекту нужны некоторые

сведения о сеансе. Это можно осуществить только тогда, когда на стороне клиента будет

храниться хоть какая-то информация о сеансе, как минимум его идентификатор. Впро-

чем, в большинстве случаев эта информация представляет собой не более чем набор

ключей, необходимых для извлечения соответствующих данных.

Данные, используемые в ходе выполнения запроса, как правило, представляют собой

комбинацию промежуточных данных сеанса, имеющих смысл только в контексте теку-

щего взаимодействия с базой данных, и постоянных данных, имеющих смысл во всех

взаимодействиях.

Ключевым моментом в этой схеме является то, что промежуточные данные сеанса

рассматриваются как локальные по отношению к текущему сеансу и не должны приме-

няться остальными частями системы до тех пор, пока результаты выполнения сеанса не

будут зафиксированы в базе данных. Таким образом, если вы работаете с объектом заказа

в контексте сеанса и хотите сохранить промежуточное состояние этого объекта в базе

данных, вам нужно обрабатывать его отдельно от заказа, сохраненного в базе данных в

конце этого же сеанса. В противном случае в базе данных появится масса "незакон-

ченных" заказов, что особенно неприятно в таких ситуациях, как проверка на наличие

определенных книг и подсчет ежедневной выручки.

Итак, как же отделить данные сеанса от основного содержимого базы данных? Пожа-

луй, самое очевидное решение — добавить к каждой строке базы данных, которая может

содержать промежуточные данные сеанса, специальное поле. В качестве последнего

можно использовать логическое поле с именем наподобие isPending. Однако гораздо

лучше применить поле, содержащее идентификатор сеанса, что позволит легко отобрать

все данные, принадлежащие конкретному сеансу. В этом случае всем запросам, извле-

кающим постоянные данные, понадобится отбросить промежуточные данные с помо-

щью таких выражений, как sessioniD is not NULL, или воспользоваться необходи-

мыми фильтрами.

Применять поле с идентификатором сеанса довольно неудобно, потому что всем при-

ложениям, имеющим дело с записями базы данных, понадобится знать о присутствии

480 Часть 11. Типовые решения

этого поля, чтобы по ошибке не извлечь промежуточные данные сеанса. Иногда это не-

удобство можно устранить с помощью представлений и фильтров, однако применение

представлений связано со своими расходами.

Возможной альтернативой является создание отдельного набора таблиц с промежу-

точными данными. Таким образом, если в базе данных есть таблицы для хранения зака-

зов и пунктов заказов, понадобится добавить еще две таблицы для хранения промежу-

точных состояний заказов и промежуточных состояний пунктов заказов. Промежуточные

данные будут сохраняться в промежуточных таблицах, а их окончательные варианты —

в обычных, "настоящих" таблицах. Это позволит избежать многих неудобств, связанных

с разделением данных, однако потребует реализации в слое отображения дополнитель-

ной логики выбора тех или иных таблиц, что, несомненно, усложнит структуру системы.

Зачастую постоянные данные таблиц подчиняются определенным правилам целост-

ности, которые не распространяются на промежуточные данные. В этом случае вы можете

отключить правила целостности в применении к промежуточным таблицам и активи-

зировать их, если они все-таки понадобятся. К промежуточным данным не применяется

и проверка на логическую правильность. Разумеется, на определенных этапах сеанса мо-

жет понадобиться провести ту или иную проверку на правильность, однако это обычно

определяется в логике серверного объекта.

Промежуточные таблицы должны представлять собой точные копии настоящих таб-

лиц. В этом случае логика отображения будет самой простой. Используйте в промежу-

точных таблицах те же имена полей, что и в настоящих таблицах, а затем снабдите их до-

полнительным полем с идентификаторами сеанса, чтобы легко отбирать данные, при-

надлежащие определенному сеансу.

При сохранении промежуточных данных необходимо реализовать механизм, который

будет удалять записи о брошенных или прерванных сеансах. Используя идентификатор

сеанса, вы можете найти и уничтожить все ненужные данные. Если же пользователь мо-

жет покинуть сеанс без уведомления сервера, понадобится организовать некоторую об-

работку времени ожидания. Для этого можно воспользоваться демоном, который будет

запускаться каждые несколько минут и выполнять проверку наличия устаревших дан-

ных. Подобная схема обработки требует наличия в базе данных специальной таблицы,

которая будет фиксировать время последнего взаимодействия с указанным сеансом.

Реализовать откат обновлений гораздо сложнее. Как выполнить откат сеанса, если

в течение этого сеанса была обновлена существующая запись о заказе? Одно из воз-

можных решений — не допускать отмену подобных сеансов. Все обновления сущест-

вующих данных должны фиксироваться в таблице только в конце выполнения запроса.

Эта схема очень проста и вполне соответствует видению процесса обновления самими

пользователями. Все остальные альтернативы менее удобны, независимо от того, что

вы используете — промежуточные поля или промежуточные таблицы. Для реализации

описанной схемы при наличии промежуточных таблиц все обновляемые данные можно

скопировать в промежуточные таблицы, выполнить в них необходимые изменения и пе-

ренести данные обратно в таблицы с постоянными записями по окончании текущего се-

анса. При использовании промежуточных полей подобные действия возможны только

тогда, когда идентификатор сеанса является частью ключа записи. В этом случае в одной

и той же таблице могут одновременно находиться значения старого и нового идентифи-

каторов, что способно крайне затруднить работу с таблицей.

Глава 17. Типовые решения для хранения состояния сеанса 481

Если промежуточные таблицы будут считываться только объектами, обрабатываю-

щими сеанс, необходимость представления состояния сеанса в табличном формате край-

не мала. В этом случае имеет смысл воспользоваться крупным сериализованным объектом

(Serialized LOB, 292), в результате чего сохранение состояния сеанса в базе данных пре-

вращается в сохранение состояния сеанса на стороне сервера (Server Session State, 475).

При желании вы можете избежать всех этих трудностей, просто отказавшись от ис-

пользования промежуточных данных. Другими словами, приложение можно спроекти-

ровать таким образом, чтобы все его данные рассматривались как постоянные. Разумеется,

это далеко не всегда возможно и зачастую способно привести систему в состояние пол-

ной неразберихи (а потому наталкивает на мысль о необходимости явной обработки

промежуточных данных). Тем не менее, если подобная возможность у вас есть, она зна-

чительно облегчит реализацию сохранения состояния сеанса в базе данных.

Назначение

Сохранение состояния сеанса в базе данных является одним из возможных вариантов

обработки состояний сеанса наряду с типовыми решениями сохранение состояния сеанса

на стороне сервера и сохранение состояния сеанса на стороне клиента. Каждое из них имеет

свои преимущества и недостатки.

Одним из наиболее спорных аспектов сохранения состояния сеанса в базе данных яв-

ляется производительность. Использование серверных объектов без состояния разрешает

применение пула объектов и облегчает выполнение кластеризации, что, разумеется, ока-

зывает благоприятное влияние на производительность приложения. С другой стороны,

необходимость извлечения и записи данных при выполнении каждого запроса влечет за

собой определенные временные затраты. Для снижения этих затрат извлекаемые данные

можно кэшировать, однако расходы на запись сократить нельзя.

Не менее важным аспектом является трудоемкость работ. Большая часть усилий про-

граммистов затрачивается на обработку состояний сеанса. Таким образом, если у вас нет

состояний сеанса и промежуточные данные допускается сохранять наряду с постоянны-

ми, предпочтение следует отдать именно сохранению состояния сеанса в базе данных, по-

скольку оно не требует дополнительных затрат на кодирование и не приводит к падению

производительности приложения (если извлекаемые объекты кэшируются).

Выбирая между сохранением состояния сеанса в базе данных и сохранением состояния

сеанса на стороне сервера, обратите внимание на то, как используемый сервер приложе-

ний поддерживает кластеризацию и отказоустойчивость. В большинстве стандартных

решений реализовать кластеризацию и устойчивость к отказам легче, если состояние се-

анса хранится в базе данных.

Глава 18

Базовые типовые

решения

Шлюз (Gateway)

Объект, инкапсулирующий доступ к внешней системе

или источнику данных

Программное обеспечение редко функционирует само по себе. Даже самые типичные

объектно-ориентированные системы должны взаимодействовать со структурами, не яв-

ляющимися объектами, например с таблицами реляционных баз данных, транзакциями

CICS и документами XML

В большинстве случаев для доступа к внешним источникам применяются интерфей-

сы API. К сожалению, они довольно сложны, так как учитывают характер источника.

Каждый, кто работает с источником, должен понимать и его интерфейс — JDBC или SQL

для реляционных баз данных, W3C или JDOM для XML и т.п. Это не только затрудняет

понимание программного обеспечения, но и значительно усложняет потенциальную за-

мену источника данных с реляционной СУБД документом XML или наоборот.

Решение данной проблемы настолько просто и очевидно, что его вряд ли стоит озву-

чивать. Весь специализированный код API помещается в класс-шлюз, интерфейс кото-

рого не отличается от интерфейса обычного объекта. После этого, чтобы получить доступ