Управління описом сервісів XML із застосуванням програмування на Java, HTML, XML, DHTML, Інтернет-технології, статті

Зазвичай сервіс-орієнтована архітектура (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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*