У Java 2 Platform, Enterprise Edition (J2EE) version 1.4 з'явилася можливість інтеграції з Web-сервісами. Web-сервіси тепер є одним із способів надання послуг платформи J2EE. Існуючі J2EE-компоненти можуть бути легко представлені у вигляді Web-сервісів. Web-сервісів тепер доступні багато переваг платформи J2EE, включаючи переносимість, масштабованість, надійність і відсутність прив'язки до одного вендору. Наприклад, J2EE-контейнери надають підтримку транзакцій, підключення до БД, управління життєвим циклом і інші служби - масштабовані і не потребують кодування.
Платформа J2EE надає підтримку Web-сервісів за допомогою JAX-RPC 1.1 API, яке можна використовувати для створення кінцевих точок (endpoints) Web-сервісів на основі SOAP. JAX-RPC 1.1 підтримує взаємодію з Web-сервісами, заснованими на WSDL і SOAP. Платформа J2EE підтримує також і JSR 109, надбудову над JAX-RPC, яка представляє собою програмну модель для реалізації Web-сервісів і на розгортання Web-сервісів на платформі J2EE 1.4. Крім усього іншого, J2EE 1.4 підтримує WS-I Basic Profile. Це означає, що розроблені на платформі J2EE Web-сервіси є переносяться не тільки між реалізаціями J2EE, але і можуть взаємодіяти з будь-якими Web-сервісами, що відповідають стандартам WS-I.
Для розробки Web-сервісів розробнику зазвичай потрібні великі знання XML-стандартів і протоколів (таких, як WSDL і SOAP), а також чималий досвід програмування. На платформі J2EE 1.4, однак, для розробки Web-сервісів не потрібно знання WSDL і SOAP. Перетворення між Java і цими XML-стандартами бере на себе runtime-система Web-сервісів, тим самим звільняючи програміста від низькорівневих деталей.
- Короткий огляд Web-сервісів;
- Огляд JSR 109;
- Приклади Web-сервісів і клієнтів;
- Особливості розробки Web-сервісів з використанням платформи J2EE 1.4.
- Приклади коду, які ви зможете використовувати в своїх додатках.
Огляд Web-сервісів
Малюнок 1. Модель Publish-Discover-Invoke в J2EE 1.4.
З точки зору архітектора ПО, Web-сервіс можна розглядати як сервіс-орієнтовану архітектуру, що складається зі служб, які спілкуються один з одним (і з клієнтом) через строго певні інтерфейси. Одна з переваг сервіс-орієнтованої архітектури полягає в тому, що вона допускає розробку вільно зв'язаних додатків, які можна поширювати по мережі і до яких можна звертатися з будь-якого клієнта.
В J2EE 1.4 SDK є засоби, що дозволяють швидко створювати, тестувати і розгортати Web-сервіси та клієнтів, що взаємодіють з іншими Web-сервісами і клієнтами, що працюють як на платформі Java, так і на інших платформах. Крім того, вони дозволяють представити у вигляді Web-сервісів вже наявні J2EE-додатки. Сервлети і EJB-компоненти можуть бути представлені у вигляді Web-сервісів, до яких згодом можуть отримати доступ як Java-, так і не Java-клієнти. Самі J2EE-додатки можуть виступати в якості клієнтів Web-сервісів, і звертатися до інших Web-сервісів незалежно від того, як вони реалізовані.
J2EE 1.4 SDK
Кращий спосіб дізнатися, що нового з'явилося на платформі J2EE - завантажити J2EE 1.4 SDK, і розібратися в цьому самому. В J2EE 1.4 SDK входить наступне:
- J2EE 1.4 Application Server
- Java 2 Platform, Standard Edition (J2SE) 1.4.2_01
- Приклади використання J2EE (Java Pet Store, Java Adventure Builder, Smart Ticket і т.д.)
- Sun ONE Message Queue
- PointBase Database Server
За замовчуванням J2EE 1.4 SDK на платформі Windows встановлюється в c: \ sun \ AppServer, а JDK 1.4.2_01 в c: \ sun \ AppServer \ jdk.
Після установки потрібно включити в змінну середовища Path шляху до каталогів c: \ sun \ AppServer \ bin і c: \ sun \ AppServer \ jdk \ bin. У цих каталогах міститься кілька інструментальних засобів (включаючи wscompile), що генерують клієнтські заглушки або серверні каркаси, або ж WSDL-опис на основі визначення інтерфейсу сервісу.
Процес розробки і розгортання Web-сервісу тісно пов'язаний з runtime-системою. Наприклад, розгортання Web-сервісу на Apache Axis відрізняється від розгортання того ж Web-сервісу на Apache SOAP або будь-який інший платформі. Специфікація Java Community Process (JCP) JSR 109 (Implementing Enterprise Web Services) визначає створення переносяться Web-сервісів в середовищі J2EE 1.4. Ця специфікація включає:
- Розробку: стандартизує програмну модель Web-сервісів і дескриптори розгортання.
- Розгортання: описує дії з розгортання, очікувані J2EE-контейнером.
- Публікація сервісів: визначає, яким чином WSDL стає доступним клієнтам.
- Використання сервісів: стандартизує дескриптори розгортання клієнта і модель пошуку JNDI.
Web-сервіси J2EE
JAX-RPC - це Java API для XML RPC. Його можна використовувати для створення клієнтів і Web-сервісів, що використовують XML і RPC. RPC працює через такі XML-протоколи, як SOAP, що визначають структуру обгортки, правила кодування і угоди за поданням RPC-викликів і відповідей на них, що передаються у вигляді SOAP-повідомлень через HTTP. Перевага JAX-RPC полягає в тому, що складність SOAP-повідомлень прихована від розробника. Ось як це працює:
Розробник вказує віддалені процедури (Web-сервіси), які можуть бути викликані клієнтами через Java-інтерфейс, і реалізує цей інтерфейс. Для клієнта Web-сервіс виглядає як набір методів, що реалізують бізнес-логіку від імені клієнта. Клієнт звертається до Web-сервісу, використовуючи Service Endpoint Interface, як визначено в JAX-RPC. Розробники клієнта створюють автоматично генерує проксі (локальний об'єкт, який представляє віддалений сервіс), а потім просто викликають методи проксі. Розробнику не потрібно хвилюватися щодо генерування або розбору SOAP-повідомлень, все це виконує runtime JAX-RPC. Зауважте, що J2EE Web-сервіси можуть бути викликані будь-яким Web-клієнтом, і що будь-який J2EE-клієнт може звернутися до будь-якого Web-сервісу.
Малюнок 2. Java-клієнт, що викликає J2EE Web-сервіс.
Зауважте, що клієнт Web-сервісу ніколи не звертається до сервісу безпосередньо, але завжди - через контейнер. Це добре, оскільки дозволяє Web-сервісу використовувати функціональність, що надається контейнером - тобто безпеку, ведення логів і гарантії QoS.
Робота з JAX-RPC
При роботі з JAX-RPC потрібно пам'ятати, що він відображає типи Java на визначення XML / WSDL. Звичайно, добре, що не потрібно знати деталі цих відображень, але слід розуміти, що в JAX-RPC не всі класи J2EE можуть бути використані як параметри методів або повернені значення. JAX-RPC підтримує такі примітивні типи даних. boolean, byte, double, float, int, long, short і масиви. Крім того, підтримуються наступні класи-обгортки і класи-утиліти:
JAX-RPC також підтримує щось під назвою value type. що означає клас, який може передаватися між клієнтом і сервісом в якості параметра або повертається. Value type повинен відповідати наступним правилам:
- Він повинен мати відкритий (public) конструктор за замовчуванням.
- Він не повинен реалізувати java.rmi.Remote.
- У його полів повинні бути типи, підтримувані JAX-RPC. Крім того, поле public не може бути final або transient, а не-public поля повинні мати відповідні getter- і setter-методи.
Створення Web-сервісів
Створення Web-сервісів в стилі XML-RPC з використанням платформи J2EE 1.4 можна розбити на п'ять етапів:
- Дизайн і кодування endpoint-інтерфейсу Web-сервісу.
- Реалізація інтерфейсу.
- Створення конфігураційного файлу.
- Генерування необхідних файлів.
- Використання deploytool для упаковки сервісу в WAR-файл і його поширення.
1. Дизайн і кодування endpoint-інтерфейсу Web-сервісу
Першим кроком у створенні Web-сервісу є розробка і кодування endpoint-інтерфейсу Web-сервісу, де оголошуються методи, які може викликати віддалений клієнт. При розробці такого інтерфейсу переконайтеся, що:
Для початку створіть будь-який каталог за вашим вибором. Для такого прикладу я створив каталог apps в c: \ sun \ AppServer, і підкаталог build в ньому. Каталог apps містить .java-файли, build містить .class, а також інші файли, які будуть згенеровані автоматично.
Web-сервіс, який я збираюся створити, буде підсумовувати два числа. Нічого особливого, але досить, щоб показати, як створюються, поширюються і використовуються Web-сервіси. Лістинг 1 показує endpoint-інтерфейс сервісу, звичайний Java-інтерфейс, який розширює інтерфейс java.rmi.Remote. У цьому інтерфейсі, MathFace, оголошується один метод, add, що приймає два цілочисельних значення і повертає цілочисельне значення, що представляє собою суму двох цілочисельних параметрів.
Лістинг 1: MathFace.java
2. Динамічний проксі.
У цьому випадку клієнт викликає віддалену процедуру через динамічний проксі або клас, який створюється під час виконання. Зауважте, що в разі статичної заглушки код покладається на клас, що залежить від реалізації. В даному ж випадку (динамічного проксі) це обмеження відсутнє. Насамперед потрібно створити конфігураційний файл. Можна використовувати наведений у лістингу 6, змінивши packageName на dynamicproxy або що-небудь на зразок цього. Створіть в каталозі apps підкаталог dynamic-proxy, а в ньому - підкаталог build.
Тепер згенеруйте потрібні інтерфейси за допомогою wscompile.
Після всього цього можна створити клієнта. Лістинг 8 містить приклад реалізації. У ньому створюється екземпляр фабрики сервісів. Фабрика сервісів використовується для створення об'єкта сервісу, який діє як фабрика проксі. Як бачите, метод createService приймає два параметри: URL WSDL-файлів і об'єкт QName, кортеж, який представляє кваліфіковане ім'я сервісу. Потім створюється проксі-об'єкт, і, нарешті, викликається метод add цього об'єкта.
Лістинг 8: MathClient.java
Консольний клієнт - J2EE-додаток
На відміну від автономного клієнта, клієнт-додаток J2EE може отримати інтерфейс сервісу, використовуючи JNDI lookup. В цьому випадку розробник клієнта визначає для Web-сервісу логічне JNDI-ім'я (посилання на сервіс). Контейнер пов'язує реалізацію інтерфейсу сервісу з контекстом середовища клієнта java: comp / env, використовуючи логічне ім'я посилання на сервіс:
Клієнт на базі броузера
Нарешті, розглянемо, як створити Web-клієнта, що викликає Web-сервіс з форми в браузері (тут використовується статична заглушка). Для початку потрібно конфігураційний файл, схожий на наведений у лістингу 6. Замініть в ньому packageName, наприклад, на webclient. Після цього згенеруйте клієнтську заглушку наступною командою:
Наступний крок - створення Web-клієнта в формі сервлету або JSP-сторінки. У лістингах 9 і 10 наведена JSP-реалізація Web-клієнта. Лістинг 9 - це код, що виводить форму користувачеві і приймає параметри. Код в лістингу 10 (статична заглушка) схожий на клієнта з лістингу 7.
Лістинг 9: math.jsp
Лістинг 10: add.jsp
Малюнок 4. JSP-клієнт, що викликає Web-сервіс.
висновок
Web-сервіси- це наступний крок в еволюції Web. Вони пропонують інфраструктуру і засоби для автоматизації відносин В2В через Internet. Інтегрування Web-сервісів в платформу J2EE 1.4 спрощує завдання створення і використання Web-сервісів, звільняючи Java-розробника від низькорівневих деталей.