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

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

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

class AssetApplicationController . . .

public String getview (String commandString,

Map params) {

return getResponse(commandString,

"bgetAssetStatus(params)).getViewUrl();

}

В нашем случае контроллер приложения не возвращает полный адрес URJL к представ-

лению JSP. Вместо этого он возвращает строку, которую контроллер запросов преобразу-

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

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

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

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

class AssetApplicationController. . .

public void addResponse(String event, Object state,

^Class domainCommand, String view) {

Response newResponse = new Response (domainCommand, view);

if ( ! events.containsKey(event))

events .put (event, new HashMapO);

getResponseMap(event).put(state, newResponse); }

private static void loadApplicationController(

^AssetApplicationController appController) {

appController = AssetApplicationController.getDefault();

appController.addResponse("return", AssetStatus.0N_LEASE,

"bGatherReturnDetailsCommand.class, "return");

appController.addResponse("return", AssetStatus.

4>IN_INVENTORY, NullAssetCommand.class, "illegalAction");

appController.addResponse("damage", AssetStatus.

^>ON_LEASE, InventoryDamageCommand.class, "leaseDamage");

appController.addResponse("damage", AssetStatus.

4>IN_INVENTORY, LeaseDamageCommand.class, "inventoryDamage");

Загрузка контроллера приложения из файла настроек тоже не представляет никакой

сложности. Попробуйте сделать это самостоятельно.

Глава 15

Типовые решения

распределенной

обработки данных

Интерфейс удаленного доступа (Remote Facade)

Предоставляет интерфейс с низкой степенью детализации для доступа

к объектам, имеющим интерфейс с высокой степенью детализации,

в целях повышения эффективности работы в сети

В объектно-ориентированной модели удобно работать с небольшими объектами,

имеющими множество небольших методов. Это предоставляет возможность гибкого из-

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

конкретными именами, что значительно упрощает понимание кода приложения. Одним

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

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

зовов методов.

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

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

вляются между процессами. Выполнение удаленных вызовов связано с довольно

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

между маршрутизаторами и т.п. Если процессы запущены на машинах, находящихся

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

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

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

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

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

системы не могут не принимать во внимание даже самые стойкие приверженцы загрузки

по требованию.

Таким образом, можно сделать вполне логичный вывод: каждый объект, потенциаль-

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

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

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

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

заказа, клиент должен извлекать и обновлять заказ и пункты заказа в одном вызове.

К сожалению, подобная схема не может не повлиять на структуру объектов. Последняя

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

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

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

падает.

Интерфейс удаленного доступа — это интерфейс с низкой степенью детализации [20],

предоставляющий доступ к сети объектов с высокой степенью детализации. Такие объек-

ты не имеют удаленных интерфейсов, а интерфейс удаленного доступа не содержит логики

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

тельности методов с высокой степенью детализации.

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

Интерфейс удаленного доступа решает проблему распределенной обработки данных

путем применения стандартного подхода объектно-ориентированного программирова-

ния, предполагающего разделение разных обязанностей между различными объектами.

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

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

екты с высокой степенью детализации, поэтому вся сложная логика помещается в

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

процесса. Чтобы обеспечить эффективный доступ к этим объектам со стороны удален-

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

По своей сути интерфейс удаленного доступа — это всего лишь оболочка, которая осуще-

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

терфейсами.

В простых случаях, например для объекта, представляющего почтовый адрес, интер-

фейс удаленного доступа заменяет обычные get- и set-методы объекта одним get-методом

и одним set-методом, известными как функции массового доступа (bulk accessors). Когда

удаленный клиент вызывает такой set-метод, интерфейс удаленного доступа считывает па-

раметры, переданные этому методу, после чего последовательно вызывает отдельные,

"настоящие" set-методы объекта Address (рис. 15.1). Этим, собственно, и ограничива-

ются обязанности интерфейса удаленного доступа. Как видите, вся логика проверки на

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

ми объектами с высокой степенью детализации.

Рис. 15.1. Одно обращение удаленного клиента к интерфейсу инициирует несколько

обращений интерфейса к объекту домена

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

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

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

сведений о заказе, обо всех пунктах этого заказа, а также некоторых сведений о покупа-

теле, разместившем заказ.

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

диться в определенном формате. Если соответствующие классы с высокой степенью де-

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

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

getAddressData создает копию исходного объекта адреса. Метод setAddressData по-

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

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

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

объектом адреса.)

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

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

тами может оказаться слишком сложной для сериализации фрагмента модели домена.

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

жество ее данных. В подобных случаях передачу данных рекомендуется осуществлять с

использованием объекта переноса данных (Data Transfer Object, 419).

Ранее упоминался пример, когда интерфейс удаленного доступа соответствовал одному

объекту домена. Это достаточно простая и понятная, но далеко не единственная схема.

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

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

пример, методы getAddressData И setAddressData MOP/T быть определены В классе

CustomerService ("данные о покупателе"), который помимо перечисленных включает

в себя и такие методы, как getPurchasingHistory ("получить список покупок") или

updateCreditData ("обновитьсведения о кредите").

Глава 15. Типовые решения распределенной обработки данных 407

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

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

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

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

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

детализированным системам с гораздо меньшим количеством интерфейсов удаленного

доступа. На мой взгляд, приложениям среднего размера вполне достаточно одного ин-

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

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

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

разработчика.

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

ности конкретного клиента. В большинстве случаев они сводятся к необходимости

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

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

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

вого доступа, загружающий и сохраняющий данные. Щелчок на элементе управления

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

соответствующие команды интерфейса. Очень часто разные методы интерфейса уда-

ленного доступа выполняют схожие операции над объектами домена. Это вполне нор-

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

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

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

сти они соответствуют одному и тому же внутреннему методу.

Интерфейс удаленного доступа может быть с состояниями или без состояний. Приме-

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

ствующих объектов, что оптимизирует использование ресурсов и повысит эффектив-

ность работы приложения, особенно если речь идет о модели "поставщик—потребитель".

Тем не менее, если взаимодействие с клиентами потребует сохранения состояния объек-

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

Обычно для этого применяют типовые решения сохранение состояния сеанса на стороне

клиента (Client Session State, 473), сохранение состояния сеанса в базе данных (Database

Session State, 479) или реализацию сохранения состояния сеанса на стороне сервера (Server

Session State, 475). Поскольку интерфейс удаленного доступа (Remote Facade) может иметь

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

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

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

Помимо предоставления интерфейса с низкой степенью детализации, интерфейс

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

пасности. Использование списков управления доступом позволяет задать, каким поль-

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

решение прекрасно подходит для управления транзакциями. Метод интерфейса удален-

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

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

ние отдельной транзакции. При возвращении результатов клиенту транзакции должны

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

Глава 15. Типовые решения распределенной обработки данных 409

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

фейса удаленного доступа, — это помещение в него логики домена. Запомните: интерфейс

удаленного доступа не содержит логики домена. Как и любой другой интерфейс, он дол-

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

функций. Если вам понадобится реализовать какую-либо логику домена, связанную с

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

терфейсом, или вынесите в отдельный сценарий транзакции (Transaction Script, 133), не

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

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

рования кода.

Интерфейс удаленного доступа и типовое решение интерфейс сеанса

(Session Facade)

На протяжении последних нескольких лет сообщество J2EE активно популяризи-

рует типовое решение интерфейс сеанса, описанное в [3]. В своих ранних черновиках я

отождествлял интерфейс удаленного доступа с типовым решением интерфейс сеанса и

использовал именно это название. Между тем в действительности данные типовые

решения существенно различаются. Интерфейс удаленного доступа — это не более чем

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

язнь к помещению туда логики домена). Напротив, практически все описания типо-

вого решения интерфейс сеанса предполагают размещение в нем некоторых фрагмен-

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

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

J2EE для доступа к компонентам сущностей. Любая координация действий компонентов

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

поддерживают возможность повторного вхождения.

Таким образом, я рассматриваю типовое решение интерфейс сеанса как помещение в

удаленный интерфейс нескольких сценариев транзакции. Это весьма и весьма разумный

подход, однако он не соответствует определению интерфейса удаленного доступа. Вообще

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

сомневаюсь, что оно имеет право называться "facade", т.е. "интерфейс"!

Слой служб

Концепция типовых решений интерфейс удаленного доступа и интерфейс сеанса имеет

немало общего со слоем служб (Service Layer, 156). Основное различие между ними за-

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

зательно должен иметь только методы с низкой степенью детализации. Разумеется,

стремление упростить модель предметной области (Domain Model, 140) зачастую приводит

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

большей ясности, а не для повышения эффективности работы в сети. Кроме того, слой

служб не нуждается в использовании объекта переноса данных (Data Transfer Object, 419)

— в большинстве случаев клиенту возвращаются реальные объекты домена.

Если к модели предметной области будут обращаться и локальные и удаленные объек-

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

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

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

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

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

терфейс удаленного доступа лучше реализовать в виде отдельного объекта.

Назначение

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

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

ции. Это позволит оптимизировать скорость работы в сети, что присуще объектам

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

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

есть и у тех и у других.

Наиболее часто интерфейс удаленного доступа располагают между слоем представ-

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

ных процессах. В качестве примера можно привести взаимодействие интерфейса Swing

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

модели, расположенной на сервере, если приложение и Web-серверы запущены в раз-

ных процессах.

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

щенными на разных машинах. Между тем расходы на межпроцессный вызов в пределах

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

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

мо от того, где запущены эти процессы.

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

ного процесса, необходимость в применении интерфейса удаленного доступа отпадает.

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

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

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

щими на одном Web-сервере. Как правило, интерфейс удаленного доступа не применяется

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

тализации.

В концепции интерфейса удаленного доступа применен синхронный подход к распреде-

ленной обработке данных (с использованием удаленных вызовов процедур). Зачастую

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

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

массу неопровержимых преимуществ. К сожалению, рассмотрение типовых решений,

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

данной книги.

Пример: использование компонента сеанса Java в качестве интерфейса

удаленного доступа (Java)

Если вы работаете с платформой Enterprise Java, в качестве распределенного интер-

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

том и может быть с состояниями или без состояний. В этом примере я запущу группу

объектов POJO (plain old Java objects — простые объекты Java) внутри EJB-контейнера

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

рованного в виде интерфейса удаленного доступа.

Глава 15. Типовые решения распределенной обработки данных 411

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

но удивляет огромное количество людей, которые полагают, будто в ЕШ-контейнере

нельзя запустить простые объекты Java. Меня часто спрашивают, являются ли объекты

домена компонентами сущностей. Разумеется, они могут быть компонентами сущностей,

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

Java. Во-вторых, хочу обратить ваше внимание, что существуют и другие способы приме-

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

В этом примере я буду обращаться к удаленным интерфейсам для получения сведений

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

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

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

стве источников данных (рис. 15.2).

Рис. 15.2. Пакеты, принимающие участие в работе интерфейса удаленного доступа

Пакет dto, показанный на рис. 15.2, содержит объекты переноса данных, которые

применяются для передачи данных по сети удаленному клиенту. Эти объекты имеют

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

собственного содержимого в двоичный формат или текстовый формат XML В пакете

remote содержатся объекты-сборщики, которые помещают данные домена в объекты пе-

реноса данных. Если вас интересует выполнение этого процесса, обратитесь к разделу,

посвященному упомянутому типовому решению.

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

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

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

сконцентрировать все внимание на интерфейсах удаленного доступа. Один логический

компонент сеанса Java в действительности состоит из трех классов. Два из них образу-

ют удаленный API (и, по сути, являются интерфейсами Java), а третий — это класс, реа-

лизующий данный API. Упомянутые интерфейсы НОСЯТ Имена AlbumService И Album-

Home. Объект AlbumHome используется службой AlbumService для получения доступа к

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

опущу. Нас интересует сам интерфейс удаленного доступа, а именно объект AlbumService.

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

в пакете api и представляет собой всего лишь список методов.

class AlbumService...

String play(String id) throws RemoteException;

String getAlbumXml(String id) throws RemoteException;

AlbumDTO getAlbum(String id) throws RemoteException;

void createAlbum(String id, String xml)

throws RemoteException;

void createAlbum(String id, AlbumDTO dto)

throws RemoteException;

void updateAlbum(String id, String xml)

throws RemoteException;

void updateAlbum(String id, AlbumDTO dto)

throws RemoteException;

void addArtistNamed(String id, String name)

throws RemoteException;

void addArtist(String id, String xml)

throws RemoteException;

void addArtist(String id, ArtistDTO dto)

throws RemoteException;

ArtistDTO getArtist(String id) throws RemoteException;

Обратите внимание: даже в этом небольшом примере я применяю методы для доступа

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

Album. Кроме того, в моем интерфейсе можно заметить незначительно отличающиеся

разновидности одного и того же метода. Единственные различия этих методов состоят в

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

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

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

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

доступа большого количества методов.

К счастью, все эти методы очень просты. Приведем реализацию методов, предназна-

ченных для выполнения операций над альбомами.

class AlbumServiceBean.. .

public AlbumDTO getAlbum(String id) throws RemoteException {

Глава 15. Типовые решения распределенной обработки данных 413

return new AlbumAssembler().writeDTO(

Registry.findAlbum(id)); } public String getAlbumXml(String id)

throws RemoteException {

AlbumDTO dto = new AlbumAssembler().writeDTO(

Registry.findAlbum(id));

return dto.toXmlString();

}

public void createAlbum(String id, AlbumDTO dto)

throws RemoteException {

new AlbumAssembler().createAlbum(id, dto); }

public void createAlbum(String id, String xml)

throws RemoteException {

AlbumDTO dto = AlbumDTO.readXmlString(xml); new

AlbumAssembler().createAlbum(id, dto); }

public void updateAlbum(String id, AlbumDTO dto)

throws RemoteException {

new AlbumAssembler().updateAlbum(id, dto);

}

public void updateAlbum(String id, String xml)

•^throws RemoteException {

AlbumDTO dto = AlbumDTO.readXmlString(xml); new

AlbumAssembler().updateAlbum(id, dto); }

Как видите, единственная функция каждого из этих методов заключается в делегиро-

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

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

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

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

низм "упаковки", чем, собственно, он и должен быть.

Прежде чем закончить рассмотрение этого примера, скажу несколько слов о тестиро-

вании. Для достижения максимальной эффективности как можно большую часть тести-

рования рекомендуется проводить в одном процессе. В данном примере я могу написать

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

быть запущены без развертывания компонентов сеанса в EJB-контейнер.

class XmlTester...

private AlbumDTO kob;

private AlbumDTO newkob;

private AlbumServiceBean facade = new AlbumServiceBean();

protected void setUpO throws Exception {

facade.initializeForTesting();

kob = facade.getAlbum("kob");

Writer buffer = new StringWriter();

kob.toXmlString(buffer);

newkob = AlbumDTO.readXmlString(new StringReader(

buffer . toStringO ) ) ; }