196 Часть II. Основные подходы к разработке приложений

Может возникнуть вопрос: как должны выглядеть инструментальные средства, созданные специально для Ajax? На сегодняшний день таковых еще нет, но возможно, что они будут разработаны на основе какой-либо из существующих систем.

5.3.4. Архитектуры, ориентированные на использование Web-служб

Последняя архитектура из рассматриваемых в данной главе, — это SOA (service-oriented architecture), т.е. архитектура, основанная на использовании служб. В данном случае служба — это нечто, к чему можно обратиться по сети, и получить в качестве ответа структурированный документ. Основное внимание здесь уделяется не содержимому, а данным, что вполне соответствует принципам Ajax. В настоящее время наиболее часто используются Web-службы, a XML в качестве основного языка также с энтузиазмом воспринимается разработчиками Ajax-приложений.

На заметку Термин Web-служба можно понимать как в широком, так и в узком смысле. Web-служба в узком смысле — это средства, использующие протокол SOAP. Web-служба в широком смысле — это любая система обмена данными, базирующаяся на протоколе HTTP, независимо от того, применяется ли при ее работе протокол SOAP или формат XML. XML-RPC, JSON-RPC и любая система, которую вы разработаете, используя объект XMLHttpRequest, будет Web-службой в широком смысле.

Используя Web-службу как источник данных, клиент Ajax может обеспечить высокую степень автономности, соизмеримую с той, какой обладает почтовый клиент, взаимодействующий с почтовым сервером. Возможности повторного использования элементов приложения превышают те, которые могут предоставить инструментальные средства, предполагающие использование компонентов. Так, клиент определяется лишь единожды и экспортируется для различных интерфейсов. Служба также определяется один раз и может быть использована различными клиентами, работающими независимо друг от друга. Таким образом, сочетание SOA и Ajax может стать основой достаточно мощной системы. В этом случае разделяются средства, предназначенные для генерации Ajax-приложений и для их обслуживания.

Предоставление доступа к объектам на стороне сервера

Многие инструментальные средства позволяют представить обычный объект, созданный на Java, С# или РНР, как Web-службу. При этом поддерживается отображение методов объекта в интерфейс Web-службы. Такую возможность предоставляют, в частности, Microsoft Visual Studio и Apache Axis for Java. Многие инструменты Ajax, например DWR (для Java) и SAJAX (для РНР,

.NET, Python и некоторых других языков), обеспечивают данную возможность посредством клиентского кода, написанного на языке JavaScript.

Глава 5. Роль сервера в работе Ajax-приложения 197

Применение инструментальных средств может существенно помочь при здании приложения. Если же использовать их неумело, результат будет противоположным. Для того чтобы составить представление о правильном использовании инструментов, рассмотрим простой пример, в котором применяется Java DWR. Мы определим объект на стороне сервера для предостав-

ления персональной информации.

package com.manning.aj axinaction; public class Person{

private String name=null; public Person(){

}

public String getName(){ return name;

}

public void setName(String name){ this.name=name;

}

}

Данный объект должен соответствовать спецификации JavaBeans. Это означает, что он должен предоставлять конструктор, вызываемый без параметров, и обеспечивать доступ к требуемым полям для чтения и записи посредством get- и set-методов. Далее мы сообщаем DWR о том, что данный объект должен быть доступен уровню JavaScript. Для этого мы редактируем файл dwr.xml.

<dwr>

<init>

<convert id="person" converter="bean" match="com.manning.aj axinaction.Person"/>

</init>

<allow>

<create creator="new" javascript="person"> <param name="class"

value="com.manning.aj axinaction.Person"> </create>

</allow>

</dwr>

В разделе i n i t мы определяем средства преобразования нашего класса в тип bean, а в разделе allow определяем средства, представляющие данный объект JavaScript-программам в виде переменной person. Наш объект Person содержит только один общедоступный метод, getName (), таким образом, мы можем включить в код клиента Ajax следующее выражение:

var name=person.getName() ;

Затем можно получать требуемое значение с сервера в асинхронном режиме.

В нашем классе Person содержится только один метод. На первый взгляд может показаться, что им и исчерпывается набор средств, которые предоставляются клиенту. На самом деле это не так. Класс Person является подклассом java.lang.Object и наследует от него ряд общедоступных методов, например hashCode () и tostring (). К ним также может производиться об-

198 Часть II. Основные подходы к разработке приложений

ращение. Эти "скрытые" средства не являются специфическими для DWR. Метод JSONRPCBridge. registerObject (), например, делает то же самое. Следует заметить, что DWR позволяет ограничить доступ к определенным методам, настраивая конфигурационный XML-файл. Однако по умолчанию доступ предоставляется ко всем методам. Такая проблема типична для решений, основанных на отражении. Мы встретились с ней в главе 4 при создании первых вариантов Obj ectviewer. Рассмотрим способы ее решения.

Предоставление ограниченного доступа

Если мы ненамеренно дадим возможность пользователям Web вычислять хэш-коды наших объектов, может ли это представлять опасность для нас? Для рассматриваемого примера, по-видимому, нет, так как суперклассом создаваемого нами класса является java.lang.Object, и эта ситуация вряд ли изменится. Для более сложных моделей, предоставляя информацию о суперклассе, мы не гарантируем, что программа в дальнейшем не подвергнется реструктуризации. Вполне может получиться так, что разработчик клиентской программы захочет воспользоваться методами, доступ к которым вы непреднамеренно предоставили. Затем, когда реструктуризированная модель будет доставлена на сервер, программные средства на стороне клиента внезапно откажутся работать. Другими словами, такое решение препятствует корректному разделению функций между клиентом и сервером. Если вы используете инструментальные средства, подобные DWR или JSON-RPC, вам следует тщательно взвешивать решения относительно состава интерфейса Ajax. Возможно, вам даже придется создать нечто вроде объекта Facade (рис. 5.5).

Использование в данной ситуации образа разработки Facade обеспечивает ряд преимуществ. Во-первых, как было сказано ранее, он позволяет без опасения реструктуризировать модель на стороне сервера. Во-вторых, такое решение упрощает общедоступный интерфейс, используемый клиентом. По сравнению с кодом, написанным для внутреннего применения, расходы на создание интерфейсов, предоставляемых другим элементам приложения, оказываются достаточно высокими. Необходимо создать полную документацию, иначе служба поддержки будет перегружена обращениями пользователей, пытающихся использовать созданный вами общедоступный интерфейс.

Еще одно преимущество Facade состоит в том, что данный образ разработки позволяет определять степень детализации предоставляемых услуг. Хорошая модель предметной области обычно содержит большое количество методов, выполняющих несложные действия. Таким образом, удовлетворяется требование детального управления работой кода на стороне сервера. Ajaxклиент предъявляет к интерфейсу Web-службы совершенно другие требования; они вытекают из наличия задержки, связанной с передачей данных по сети. Большое количество методов, решающих частные задачи, резко снизит практичность клиента, а сервер может не справиться с большим количеством запросов, передаваемых по сети.

Различие требований к интерфейсу, предъявляемых клиентом и сервером, можно проиллюстрировать на примере. Сравним разговор с обменом письмами. (Говоря о письмах, мы имеем в виду не электронную почту, а именно

Глава 5. Роль сервера в работе Ajax-приложения 199

Web-сервер

Рис. 5.5. Одна из систем предоставляет Ajax-клиенту все объекты как Интернет-службы, а при создании другой использован образ разработки Facade, который гарантирует доступ лишь к ограниченному набору функций. Уменьшая число общедоступных методов, мы снижаем риск повредить клиентский код при реструктуризации серверных программ

письма, написанные на бумаге, доставка которых занимает несколько дней.) Когда два человека беседуют, как минимум несколько фраз, которыми они обмениваются друг с другом, посвящено теме "как дела?". При написании письма никто не позволяет себе задать один подобный вопрос и ждать ответа на него. Отправитель подробно описывает, как его здоровье, как он провел отпуск, какие новости он узнал недавно, — все это оформляется в виде одного документа.

Путем объединения отдельных запросов, предназначенных для передачи по сети, в один большой документ архитектура, ориентированная на использование сетевых служб, позволяет более эффективно применять доступные сетевые ресурсы. Как правило, проблема быстродействия линий связи решается проще, чем проблема задержки при передаче по сети. Существует также проблема выработки стандартов для передачи больших объемов данных в формате XML посредством знакомого всем протокола HTTP, но ее Мы рассматривать не будем. Если мы проанализируем возможности, предоставляемые Ajax, то увидим, что в нашем распоряжении есть встроенные в браузер средства поддержки HTTP и XML, поэтому имеет смысл создавать распределенную модель предметной области на базе документов.