Поради та прийоми роботи з інструментарієм розробки Web-сервісів IBM Rational Application Developer: Частина 2. Перевірка класів Java на відповідність JAX-RPC

При створенні Web-сервісів на основі існуючих додатків ви можете зіткнутися з проблемами, пов'язаними з генеруванням коду. Основною причиною виникнення подібних проблем є невідповідність вихідного додатка специфікації Java API для RPC, заснованого на XML (JAX-RPC). У даній статті перераховані основні помилки, викликані цим невідповідністю, і наведені ради по використанню Rational Application Developer для їх запобігання.


Введення


Дана стаття, друга в циклі, присвячена проблемам генерування коду при розробці на основі існуючого коду Web-сервісів, що використовують Java ™ API для RPC, заснованого на XML (JAX-RPC). У специфікації JAX-RPC визначені стандартні способи перетворення типів Java в типи XML і назад. Тим не менш розробники повинні мати на увазі, що в Web-сервісі, що використовує JAX-RPC, не кожен клас Java може бути типом параметра методу або повертається методом значення.


Якщо в процесі генерування коду ви зіткнулися з проблемами, то, швидше за все, їх джерелом є невідповідність вихідного класу специфікації JAX-RPC. Щоб знайти причину доведеться перевірити вихідні класи на предмет наявності в них несумісних типів Java. Для цього у складі IBM ® Rational ® Application Developer 7 включений новий інструмент, який аналізує вихідний Java-клас сервісу і використовувані в ньому типи і виконує перевірку їх відповідності ключовим вимогам специфікації JAX-RPC.


Навчитися керувати процесом генерування коду за допомогою сторінки налаштування параметрів Web-сервісів можна, прочитавши першу статтю циклу.


Розробка Web-сервісів на основі існуючих додатків


При розробці Web-сервісів використовуються два підходи: "знизу вгору" – на основі існуючих компонентів і "зверху вниз" – розробка компонентів виходячи із загальної концепції Web-сервісу.


При розробці Web-сервісу з використанням підходу "зверху вниз" спочатку розробляється WSDL-код – реалізація Web-сервісу. Після цього, за допомогою майстра Web-сервісів, створюється Web-сервіс і класи skeleton-компонентів, в які потім поміщається бізнес-логіка.


При підході "знизу вгору" Web-сервіс створюється на основі бізнес-логіки, що міститься в існуючих bean-або EJB-компонентах (Enterprise Java ™ Beans), після чого генерується WSDL-код, що описує інтерфейс отриманого Web-сервісу. Підхід "знизу вгору" часто використовується для перетворення на Web-сервіс існуючого додатка.


При реалізації підходу "від низу до верху" за допомогою майстра Web-сервісів Rational Application Developer використовуються засоби генерування коду IBM ® WebSphere ® (Java2WSDL і WSDL2Java). Спочатку майстер генерує WSDL-файл з Java-коду існуючого застосування за допомогою Java2WSDL. Потім на основі отриманого WSDL-файлу майстер за допомогою WSDL2Java створює складові Web-сервісу (допоміжні класи Java, механізми серіалізациі і десеріалізациі, дескриптор розгортання та інше).


Як вже було сказано, в процесі генерування коду Web-сервісу створюються механізми серіалізациі Java-об'єктів в XML (і їх десеріалізациі з XML), при цьому бізнес-логіка, реалізована в коді існуючого додатки, залишається недоторканою. Відповідно, виникнення помилок при генеруванні коли каже про те, що не вдалося створити механізм серіалізациі будь-якого типу параметра методу або повертається значення, що використовується в класі сервісу.


Типи Java, використання яких дозволяється у Web-сервісах, що використовують JAX-RPC


Сервер додатків IBM WebSphere 6.0 і наступних версій підтримує специфікацію JAX-RPC 1.1. Специфікація JAX-RPC забезпечує функціональну сумісність і переносимість розроблених відповідно з нею Web-сервісів і клієнтів. До числа типів Java, підтримуваних JAX-RPC, відносяться:



Перші чотири типи не вимагають особливих пояснень. Розібратися з типами значень JAX-RPC дещо складніше.


Щоб бути сумісним з JAX-RPC типом значення, клас Java повинен відповідати наведеним нижче вимогам:



Концепцію типів значень легко пояснити на прикладах. Person.java (лістинг 1) і Employee.java (лістинг 2) є прикладами коректних типів значень JAX-RPC, оскільки відповідають наведеним вище вимогам.


Лістинг 1. Person.java





public class Person {
private String name;
private Calendar dateOfBirth;
public Person() {
}
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setDateOfBrith(Calendar dateOfBirth) {
this.dateOfBirth = dateOfBirth;
}
public Calendar getDateOfBirth() {
return dateOfBirth;
}
}


Лістинг 2. Employee.java





public class Employee extends Person {
private BigDecimal salary;
private String[] ProjectNames;
public Employee() {}
public String[] getProjectNames() {
return ProjectNames;
}
public void setProjectNames(String[] projectNames) {
ProjectNames = projectNames;
}
public BigDecimal getSalary() {
return salary;
}
public void setSalary(BigDecimal salary) {
this.salary = salary;
}
}

Типи Java, яких варто уникати в Web-сервісах, що використовують JAX-RPC


Відповіді на наведені нижче питання покажуть, які класи не слід застосовувати в Web-сервісах, що використовують JAX-RPC.


Дозволені чи колекції?


Використовувати колекції в Web-сервісах не рекомендується. Це пов'язано з тим, що вони можуть містити елементи різних типів. При відсутності вичерпної інформації від користувача колекцію неможливо перетворити у чітко визначений елемент XML-схеми, що має однозначні правила серіалізациі і десеріалізациі елементів.


Платформа Web-сервісів WebSphere підтримує перераховані нижче типи колекцій (з допомогою успадкованих механізмів перетворення Axis), причому виключно в середовищі WebSphere:



Перераховані типи Java перетворюються в нестандартні типи XML Schema та реального документа (instance document) і не можуть використовуватися при взаємодії з іншими платформами Web-сервісів.


Оскільки функціональна сумісність є основною метою технології Web-сервісів, не варто припускати, що Web-сервіс і його клієнти будуть завжди використовувати виключно платформу WebSphere. Приймаючи до уваги вищесказане, рекомендується уникати використання цих трьох типів колекцій при розробці Web-сервісів, що використовують JAX-RPC. Простіше всього уникнути проблем з колекціями якщо використовувати замість них масиви Java. Якщо вихідний API використовує колекції і змінити його ніяк не можна, можна написати код-обгортку, перетворюючий колекції в масиви.


Дозволені чи інтерфейси?


Ні. Інтерфейси не підтримуються JAX-RPC. Через це вам слід уникати використання інтерфейсів, таких, як, наприклад, org.w3c.dom.Element.


Дозволені чи типи java.sql.Date і java.sql.Timestamp?


Ні. Ці типи не підтримуються JAX-RPC. Замість них потрібно використовувати java.util.Calendar. Якщо вихідний API використовує ці типи і його не можна змінити, можна написати код-обгортку, що перетворює їх в java.util.Calendar.


Дозволено чи тип java.util.Date?


Рекомендується відмовитися від використання цього типу на користь java.util.Calendar з наступних причин. При перетворенні даних Java в XML у Web-сервісах, що використовують JAX-RPC, тип java.util.Date перетвориться в xsd: datetime. Тип xsd: dateTime, у свою чергу, відповідає типу java.util.Calendar при зворотному перетворенні. Це означає, що Web-сервіс і його клієнт будуть сприймати об'єкти типу java.util.Date по-різному.


Додаткові вимоги


Винятки


JAX-RPC наказує наявність у кожному виключення, використовуваному в Web-сервісі, конструктора, що має відповідний параметр для кожної властивості, забезпеченого getter-Методом. У лістингу 3 наведено приклад непідтримуваного класу винятку.


Лістинг 3. UserDoesNotExistException.java (не відповідає вимогам JAX-RPC)





public class UserDoesNotExistException extends Exception {
private String userId;
private String userName;
private Throwable throwable;

public UserDoesNotExistException (String userId, Throwable throwable) {
this.userId = userId;
this.throwable = throwable;
}

public String getUserId() {
return userId;
}

public String getUserName() {
return userName;
}

public Throwable getThrowable() {
return throwable;
}
}


Код, наведений у лістингу 3 містить дві невідповідності специфікації. По-перше, властивість throwable має тип, не підтримується JAX-RPC. По-друге, конструктор не має параметра, відповідного властивості userName. Приклад класу винятку, які відповідають специфікації приведений в лістингу 4.


Лістинг 4. UserDoesNotExistException.java (відповідає вимогам JAX-RPC)





public class UserDoesNotExistException extends Exception {
private String userId;
private String userName;

public UserDoesNotExistException (String userId, String userName) {
this.userId = userId;
}

public String getUserId() {
return userId;
}

public String getUserName() {
return userName;
}
}


Властивості userId і username входять до числа параметрів конструктора класу UserDoesNotExistException, наведеного в лістингу 4. Крім того, ці властивості забезпечені відповідними getter-Методами. Отже, цей клас відповідає специфікації JAX-RPC.


Засіб перевірки відповідності JAX-RPC


До складу Rational Application Developer 7 входить інструмент, що виробляє перевірку класів Java на відповідність вимогам JAX-RPC перед генеруванням на їх основі коду Web-сервісів. Опцію Validate Java classes for compliance (Перевіряти класи Java на відповідність) можна включити у вікні (рисунок 1), який відображається по команді Window> Preferences> Web Services> WebSphere> JAX-RPC Code Generation.


Малюнок 1. Опція Validate Java classes for compliance option (Перевіряти класи Java на відповідність)


За замовчуванням ця опція включена. Перед генеруванням коду Web-сервісу з коду існуючого додатка даний засіб виконає перевірку класу сервісу і використовуваних типів на відповідність специфікації JAX-RPC та, у разі виявлення невідповідностей, видасть попередження.


Приклад класу сервісу, який не відповідає JAX-RPC, приведений в лістингу 5.


Лістинг 5. NoncomplianceTest.java





public class NoncomplianceTest {
//ArrayList is a Java collection types
public void test1(ArrayList al) {
}

//java.lang.Object is not a supported JAX-RPC type.
public void test2(Object obj) {
}

//Primitive type char is not a supported JAX-RPC type.
public void test3(char c) {
}

//Person is an interface
public void test4(Person p) {
}

//java.sql.Timestamp is not a supported JAX-RPC type.
public void test5(java.sql.Timestamp timeStamp) {
}
}

public interface Person {
public void setName(String n);
public String getName();
}


При генеруванні коду Web-сервісу з коду існуючого застосування за допомогою майстра Web-сервісів (для цього натисніть на NoncomplianceTest.java правою кнопкою миші, потім виконайте команду контекстного меню Web Services> Create Web service і натисніть Next) Майстер видасть попередження, як показано на малюнку 2.


Малюнок 2. Попередження про невідповідність JAX-RPC


Повідомлення у діалоговому вікні містить детальну інформацію про виявлену невідповідність в типах даних. Ви можете проігнорувати це попередження і продовжити генерування коду. У цьому випадку при розгортанні отриманого Web-сервісу або в ході його роботи можуть виникнути збої.


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


Якщо цих рад виявилося недостатньо для того, щоб позбутися від помилок при генеруванні коду, то перед тим, як звернутися до служби підтримки IBM, спробуйте виконати наступні дії:


Встановіть останні оновлення для Rational Application Developer


IBM випускає оновлення для Rational Application Developer в середньому кожні три місяці. При цьому кожне оновлення містить значну кількість виправлень. Можливо, проблема, з якою ви зіткнулися, вже вирішена, достатньо лише встановити останнє оновлення. Для установки оновлень використовуйте менеджер інсталяції.


Оновіть тестову середу сервера додатків WebSphere


Якщо установка останніх оновлень для Rational Application Developer не допомогла впоратися з помилками, поновіть тестову середу сервера додатків WebSphere.


Якщо у вас встановлена тестова середу сервера додатків WebSphere 6.1 і розробляється проект призначений для WebSphere 6.1, то Rational Application Developer 7 використовує для генерування коду Web-сервісів файл com.ibm.ws.webservices.thinclient_6.1.0.jar file в каталозі <Каталог установки Rational Application Developer> / runtimes/base_v61/runtimes.


Якщо встановлена тестова середу WebSphere 6.0 і розробляється проект призначений для WebSphere 6.0, то Rational Application Developer 7 використовує файл webservices.jar в каталозі <Каталог установки Rational Application Developer>/runtimes/base_v6/lib/.


IBM регулярно випускає оновлення для сервера додатків WebSphere. Рекомендується встановити оновлення та використовувати останню версію сервера додатків WebSphere.


Зверніться до служби підтримки IBM


Якщо жоден з рад, наведених у статті, не допоміг, і при генеруванні коду Web-сервісів з коду існуючого програми все ще виникають помилки, це може бути викликано дефектом ПЗ. Ви можете звернутися в службу підтримки IBM Rational і зробити повідомлення про помилку (Problem Management Report (PMR)).


Відповідність JAX-RPC


У цій статті я розповів вам про вимоги, яким повинен відповідати початковий клас для створення Web-сервісу, що використовує JAX-RPC. Крім того, ви дізналися про те, що засіб перевірки відповідності JAX-RPC, що входить до складу Rational Application Developer, може допомогти виявити несумісні класи. Тепер у вас набагато більше шансів уникнути проблем при генеруванні коду Web-сервісів з коду існуючих додатків.

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


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

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

Ваш отзыв

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

*

*