Обычно сервис-ориентированная архитектура (Service-Oriented Architecture, SOA) экспортирует целый ряд сервисов. Технология Java™ предоставляет мощные механизмы обработки данных XML, необходимых для моделирования сервисов XML и их последующего применения пользователями (людьми, машинами и другими сервисами), тем самым формируя базу для применения концепций SOA. Здесь обсуждаются практические вопросы создания SOA с использованием технологий XML и Java и приводятся простые примеры, объясняющие, почему эта, сложная на первый взгляд, технология так популярна.
SOA реализует множество сервисов, одни из которых потребляются пользователями, а другие машинами. Последние в действительности сами часто являются сервисами, что делает SOA рекурсивной структурой. В этой статье описывается простой способ создания сервисов, используемых в контексте провайдеров услуг Интернета (ISP). Я использовал этот тип поставщика услуг по той причине, что большинство читателей знакомо с ним. Однако идея не ограничивается поставщиками услуг связи, она применима ко всем типам поставщиков услуг: банкам, биржевым брокерам, коммунальным службам и так далее.
Предположим в рамках статьи, что поставщик реализовал свою инфраструктуру (целиком или частично) как SOA. Один из сервисов, экспортируемых поставщиком, представляет собой средство на базе Web, с помощью которого пользователи могут менять профиль потребляемых услуг.
На момент написания этой статьи SOA продолжает развиваться, и многие крупные поставщики программного обеспечения все еще разрабатывают свои предложения SOA. В результате этого область SOA на сегодняшний день представляет собой сборную солянку технологий, в число которых входят серверы Java Business Integration (JBI), Intelligent Event Processing и Business Process Execution Language (BPEL). Очень вероятно, что организациям-клиентам, которые захотят воспользоваться преимуществами SOA, перед созданием решения придётся делать крупные инвестиции. Такое усложнение SOA может непреднамеренно привести отрасль к созданию привязки к конкретным поставщикам, несмотря на обещания того, что SOA представляет собой компонентно-ориентированные вычисления, построенные на базе стандартов и не зависящие от поставщиков. Могут ли организации-пользователи получить какой-нибудь положительный опыт работы с SOA до того, как начинать дорогостоящий процесс миграции?
В ответ на этот вопрос в этой статье на примере простого XML и небольшого кода Java демонстрируется несколько важнейших понятий SOA. В статье не ставится цель охватить всю вселенную SOA; в ней рассматриваются лишь некоторые ключевые моменты. Например, для распространения описаний сервисов XML можно было бы использовать RSS. Однако в примерах этой статьи для этой цели используются средства Java.
Достоинство такого узкоориентированного подхода состоит в том, что разработчики Java организации-пользователя могут применить демонстрируемые здесь идеи для создания собственной пилотной SOA. Такие пилотные схемы могут помочь организациям оценить преимущества SOA для своего бизнеса. К последним относится моделирование бизнес-услуг в виде вычислительных сервисов, самообслуживание пользователей, большая степень автоматизации и более высокая скорость реакции. Миграцию, подобно описанной, можно реализовать в рамках автономного пилотного проекта, работающего параллельно с существующими бизнес-процессами.
Такой подход можно реализовать без значительных инвестиций со стороны организации-пользователя. Тем самым требования организации к SOA можно определить вне зависимости от реализации конкретного поставщика. На практике же небольшие организации могут продолжать использовать пилотную схему SOA и только спустя некоторое время переходить на крупные коммерческие решения от поставщиков программного обеспечения.
Самообслуживание набирает популярность у большинства поставщиков услуг, а в особенности у поставщиков услуг Интернета, стеснённых в средствах. Например, если вам необходима большая ширина канала (для скачивания больших файлов или онлайн-игр), вы можете войти на сайт поставщика и автоматически изменить тип своего подключения. Давайте рассмотрим конкретный пример: в листинге 1 показан простой профиль сервиса пользователя на основе XML.
Листинг 1. Простое описание сервиса на основе XML
<ServiceInstance> <Customer>Josephine Bloggs</Customer> <Package>Internet</Package> <Bandwidth>1mbps</Bandwidth> <DownloadLimit>1Gbyte</DownloadLimit> <Uptime>95</Uptime> </ServiceInstance> |
Этот код иллюстрирует XML-модель обслуживания пользователя. Эта модель включает в себя следующие данные:
- Экземпляр сервиса
- Имя клиента
- Название пакета услуг
- Разрешенная полоса пропускания
- Разрешенный месячный лимит скачивания
- Гарантированное поставщиком время бесперебойной работы
Очевидно, что описание сервиса может быть гораздо более сложным, чем показано здесь. В него могут входить и другие сведения, например, адрес клиента, банковские реквизиты, величина двухсторонней задержки, шифрование, размер кредита. Главное состоит в том, что всё больше и больше поставщиков услуг открывают доступ через Интернет к информации, схожей с представленной в листинге 1. Отчасти это связано со стремлением к сокращению издержек и числа звонков в службу поддержки. Более того, наличие подобной поддержки услуг через Интернет придает провайдеру более современный облик! Это ситуация, выгодная обеим сторонам, поскольку клиент получает больший доступ к данным о получаемых им услугах, тогда как поставщик получает возможность продавать пакеты услуг с меньшими затратами на обслуживание. Авторизованные пользователи могут изменять некоторые параметры услуг, показанные в листинге 1 - например, разрешенную полосу пропускания. В соответствии с внесенными изменениями изменяется и ежемесячная абонентская плата (в сторону увеличения или уменьшения).
Итак, код, приведенный в листинге 1, формирует основу модели сервиса на базе XML. В одном из возможных вариантов пользователь может менять доступные элементы услуги (например, полосу пропускания) через интерактивную форму. Изменения, сделанные в этой форме, регистрируются и отражаются в соответствующих серверных службах, отвечающих за взаимодействие с пользователем. Это достаточно стандартный способ реализации самообслуживания.
Однако мы собираемся рассказать вам о другой, более гибкой возможности самообслуживания, когда пользователь может изменять данные путем передачи содержимого XML, приведенного в листинге 1, по сети. В этом сценарии передаваемые данные XML редактируются локально в Java-клиенте, установленном на настольном компьютере, ноутбуке или даже на устройстве с ограниченными ресурсами, например, на мобильном телефоне, после чего отправляются обратно поставщику сетевых услуг. Такой механизм выходит за рамки простой модели страницы HTML и реализует философию SOA.
Передача документа определения сервиса XML клиенту с использованием технологии Java
Технология Java предлагает ряд очень мощных инструментов работы с данными XML (см. врезку Технология Java и XML). Если рассматривать листинг 1 как представление заданного множества данных в виде XML, эти данные всегда можно представить и в других видах. Исходные данные, формирующие основу для листинга 1 обычно хранятся в базе данных. Итак, как упаковать имеющиеся данные в XML?
В листинге 2 приведен фрагмент Java-файла encodeXML.java. (Этот и другие связанные с ним файлы можно найти в разделе Материалы для загрузки.) Класс encodeXML.java создает экземпляр класса XMLEncoder. Как вы можете видеть, этот объект создает в текущей папке файл xmldata.xml . Следующий шаг состоит в добавлении в этот файл данных XML, что выполняется посредством ряда вызовов метода writeObject() (также показано в листинге 2). Очевидно, что жестко заданные в листинге 2 текстовые строки в рабочей системе будут браться из хранилища, например, базы данных. Как бы то ни было, мы видим, что файл данных XML создается очень просто.
Листинг 2. Кодирование данных в формат XML
XMLEncoder e = new XMLEncoder(
new BufferedOutputStream(
new FileOutputStream("xmldata.xml")));
e.writeObject("Josephine Bloggs");
e.writeObject("Internet");
e.writeObject("1mbps");
e.writeObject("Gbyte");
e.writeObject("295");
e.close();
|
После выполнения программы, приведенной в листинге 2, в директории, где будет запущена программа, появится файл xmldata.xml . В листинге 3 показано содержимое этого файла.
Листинг 3. Сформированные данные XML
<?xml version="1.0" encoding="UTF-8"?> <java version="1.5.0_06" class="java.beans.XMLDecoder"> <string>Josephine Bloggs</string> <string>Internet</string> <string>1mbps</string> <string>Gbyte</string> <string>295</string> </java> |
Теперь мы передаём файл, приведенный в листинге 3, ожидающему клиенту по сети, что совсем несложно сделать, используя технологию Java. В листинге 4 показан простой пример.
Листинг 4. Передача файла по сети
byte[] bytes = new byte[BUFFER_SIZE];
FileInputStream inputFile = null;
try
{
File file = new File("xmldata.xml");
if (file.exists())
{
inputFile = new FileInputStream(file);
int ch = inputFile.read(bytes, 0, BUFFER_SIZE);
while (ch != -1)
{
output.write(bytes, 0, ch);
ch = inputFile.read(bytes, 0, BUFFER_SIZE);
}
}
|
Код, приведенный в листинге 4, создаёт буфер длиной BUFFER_SIZE. Константа BUFFER_SIZE может иметь значение 1024 или больше. Содержимое входного файла (xmldata.xml) считывается в буфер посредством вызова метода inputFile.read(). Из буфера данные файла записываются в сокет объекта OutputStream посредством вызова метода output.write(). Это приводит к отправке данных по сети ожидающему клиенту. Какая мощь скрыта в таком маленьком фрагменте кода!
Теперь нам нужно, чтобы клиент обработал полученные данные XML.
Получение клиентом Java содержимого XML (не файла XML)
Как клиент будет получать данные XML? Как и в прошлый раз, это легко делается с помощью Java. Данные получаются через объект сокета. В листинге 5 показан код, получающий входящие данные и направляющий их в объект класса ArrayList.
Теперь клиент должен решить две очень важных задачи, относящиеся к количеству полученных элементов. Поскольку этот сценарий не предусматривает жесткой связи клиента и сервера, необходимо исходить из того, что клиент не знает, сколько именно элементов данных XML содержится в профиле сервиса (то есть в коде, приведенном в листинге 1). Поэтому необходимо определить средства получения и обработки точно определенного количества элементов данных. Следующая (более сложная) задача состоит в сохранении обработанных данных. Как решаются обе задачи, показано в листинге 5.
Листинг 5. Извлечение данных из XML
XMLDecoder d = new XMLDecoder(input);
try
{
while (true)
ArrayList<Object[]> rowList = new ArrayList<Object[]>();
{
String dataItem = (String)d.readObject();
System.out.println("XML decoded data: " + dataItem);
rowList.add(dataItem);
}
}
}
catch (Exception exc)
{
if (exc instanceof ArrayIndexOutOfBoundsException)
{
// No more records to process
System.out.println("Parsed all XML records - " +
"threw exception. Number of rows: " + rowList.size());
}
}
d.close();
|
Определить количество ожидаемых элементов данных можно в бесконечном цикле while (true). Этот код будет циклически проходить по всем элементам до конца, пока не сработает исключение (ArrayIndexOutOfBoundsException). Механизм исключений необходимо использовать, если клиент не знает, сколько элементов данных предполагается получить.
Данные XML, получаемые из объекта InputStream, хранятся в объекте класса ArrayList. Этот класс очень удобен для приложений такого рода. При определении у объекта класса ArrayList указывается ёмкость, соответствующая размеру списка. При добавлении элементов ёмкость объекта ArrayList автоматически расширяется. Поэтому нам не нужно беспокоиться о превышении границ массива, об этом позаботились за нас.
Теперь у клиента есть копия данных, представленных в листинге 1. Клиент может изменить элемент разрешенной полосы пропускания, присвоив ему нужное значение, после чего процесс передачи файла повторится в обратном направлении, от клиента на сервер. Перемещая файл XML с сервера на клиент, клиент фактически потребляет сервис. Обновлённые данные отправляются обратно на сервер для завершения операции. Конечно же, поставщик услуг должен проверить полученные данные и провести необходимые изменения полосы пропускания.
Описанная здесь схема начинается с создания файла XML и его передачи по сети. Клиент получает данные файла в виде потока, который он разбирает в хранящийся в памяти объект. После этого клиент вносит изменения в этот объект и вызывает процедуру, отправляющую объект обратно на сервер.
В другом возможном варианте сервиса файл данных XML передаётся с сервера на клиент в неизменном виде. Здесь клиент для получения копии файла использует какой-либо протокол передачи данных, например, FTP. Поскольку передача файлов является стандартной технологией, я не буду вдаваться в детали, скажу только, что клиент загружает копию файла профиля сервиса, приведенного в листинге 1. Теперь клиент должен разобрать и изменить файл для последующей передачи на сервер. Как может работать такая схема?
Механизм Java, построенный на файлах XML
Теперь у клиента есть копия профиля сервиса, сохранённая на диске. Для извлечения данных XML нужно произвести разбор файла. Как ни удивительно, это может быть проблемой, особенно в случае, если файл велик. Наиболее важным моментом здесь является выбор подходящих инструментов. Мы будем использовать инструмент dom4j, который позволяет разобрать данные XML в объект Java. Можно было бы использовать парсер на базе Simple API for XML (SAX), но SAX является технологией более низкого уровня. Как вы сейчас увидите, применение dom4j не требует больших усилий. В листинге 6 представлен фрагмент файла ProcessEventXml.java, иллюстрирующий основные элементы, необходимые для использования dom4j в разборе файлов.
Листинг 6. Обработка данных XML с помощью dom4j
try
{
handler.treeWalk(handler.parse(new File(argv[0])));
}
catch (Throwable t)
{
t.printStackTrace();
}
}
public Document parse(File url)
throws DocumentException
{
SAXReader reader = new SAXReader();
Document document = reader.read(url);
return document;
}
public void treeWalk(Document document)
throws Exception
{
treeWalk(document.getRootElement());
}
|
По существу нам нужны два метода: parse() и treeWalk(). Если запустить скомпилированную версию этого класса, результат работы должен быть похож на приведенный в листинге 7. Если вы собираетесь запустить код самостоятельно, не забудьте загрузить, установить и добавить dom4j в CLASSPATH. (Последнее действие заключается в добавлении соответствующего файла JAR в переменную CLASSPATH.) После этого скомпилируйте файл ProcessEventXml.java и запустите программу с помощью команды:
java ProcessEventXml ServiceDefinition.xml |
Листинг 7. Использование dom4j для обработки файла XML
java ProcessEventXml ServiceDefinition.xml Josephine Bloggs Internet 1mbps 1Gbyte 95 |
Как вы можете видеть, мы получили представление данных XML с минимальными затратами сил. Всю тяжелую работу берет на себя dom4j. На самом деле метод treeWalk() выполняет огромный объём работы, он является рекурсивным методом, который вызывается лишь после достижения конца файла. Это иллюстрирует одну из отличительных особенностей dom4j: обработку в оперативной памяти. Следует отметить, что использовать эту методику для обработки больших файлов XML, особенно на маленьких Java-устройствах, может быть нецелесообразно. Однако в рассматриваемом примере набор данных XML невелик, поэтому никаких проблем возникнуть не должно.
Файловый клиент успешно получил данные XML. Он может изменить их нужным образом и записать в новый файл XML. После этого файл передаётся на сервер для последующей обработки. Как и раньше, тем самым клиент выступает как потребитель сервиса.
Технология Java предоставляет удобные решения для проектирования и реализации SOA. Используя простой профиль сервиса, основанный на файле XML, вы можете с лёгкостью передавать данные клиентов по сети. Клиенты могут просматривать и изменять эти данные для изменения настроек обслуживания. В качестве услуги в нашем случае выступает доступ в Интернет, но этот подход подходит для поставщиков любых услуг.
Важным элементом доступа клиента к такому сервису является процесс документооборота. В коммерческих предложениях SOA подобные функции обычно реализуются через BPEL. В пилотной схеме SOA можно использовать простую схему обмена сообщениями - например, API-интерфейса Java Message Service (JMS). Как я упоминал во введении, преимущество такого подхода состоит в том, что организация может получить опыт работы с SOA до начала значительных инвестиций, необходимых для перехода на коммерческое решение SOA.
Ещё одним важным вопросом, кроме процесса документооборота, который я не рассмотрел в этой статье, является безопасность. Вопрос защиты данных может стоять очень остро, если клиент изменяет профиль сервиса. Технология Java и здесь предлагает широкий спектр возможностей.
Можно использовать и более крупноструктурный подход, в котором XML-данные профилей сервиса представляются в виде файлов. Клиент с помощью какой-либо схемы получает этих данные в локальное хранилище, после чего производится разбор и изменение файла данных, например, посредством dom4j. Технология Java и в этом случае предлагает простые и мощные инструменты. Благодаря этим технологиям в реализациях SOA могут в полной мере использоваться любые клиенты Java.