Дізнайтеся про змінені структурах Web-сервісів для розробок Java
Майбутній рік принесе суттєві зміни в структури Web-сервісів. Для розробників в Java ™ ці зміни означають як нові шаблони Web-сервісів, так і поява функціональних засобів нового рівня, що надбудовуються над Web-сервісами. У першій частині публікацій, присвячених Web-сервісів Java, Денис Сосноскі розгляне ці майбутні зміни і допоможе читачеві зорієнтуватися в них.
Денис Сосноскі. консультант, Sosnoski Software Solutions, Inc.
Денис Сосноскі (Dennis Sosnoski) - засновник і провідний фахівець консалтингової компанії за технологіями Java - Sosnoski Software Solutions, Inc. що спеціалізується в навчанні і консультуванні з проблем XML і Web-сервісів. Він має більш ніж 30-річний досвід роботи в професійному проектуванні ПО, спеціалізуючись на серверних XML і Java-технологіях. Денис є основним розробником інтегрованої системи з відкритим програмним кодом JiBX XML Data Binding. побудованої на базі технології класів Java і пов'язаної системи Web-сервісів JibxSoap. також як і системи Web-сервісів Apache Axis2. Він також був одним їх експертів при розробці специфікацій JAX-WS 2.0.
підготовка ґрунту
Минуло шість років після виходу специфікації SOAP 1.0. Задовго до появи специфікації SOAP розробники обмінювалися XML-повідомленнями за допомогою протоколів інтернет, але введення SOAP обіцяло формалізацію цієї техніки і забезпечувало кращу інтероперабільность. SOAP також надавав можливості для зручного розширення, щоб можна було додавати в інфраструктуру функціональні засоби більш високого рівня для удосконалення обміну XML-повідомленнями в майбутньому. Специфікація WSDL, що вийшла незабаром після SOAP, привнесла стандартизоване уявлення метаданих Web-сервісів. Основні постачальники ПО швидко зрозуміли, яким потенціалом володіє поєднання SOAP і WSDL, і протягом наступних кількох років здавалося, Web-сервіси на базі SOAP будуть технологією майбутнього.
Складнощі, пов'язані з SOAP і WSDL
Незважаючи на швидке поширення SOAP + WSDL в галузі, існує ряд проблем, що перешкоджають досягненню SOAP тієї популярності, якої багато хто очікував. Першою такою проблемою є оперативна сумісність. Хоча оперативна сумісність з'явилася наріжним каменем привабливості SOAP, її реалізація не виправдала очікувань. Спочатку це сталося через орієнтації Web-сервісів на стиль rpc / encoded (відомий також як rpc / enc), де об'єктна модель перетвориться в XML, а потім відновлюється на приймаючій стороні. Це автоматичне двостороннє перетворення робить rpc / enc простим у використанні (до тих пір, поки ви використовуєте відносно прості структури даних, підтримувані їм), але результатом має XML, що не придатний для інших цілей. Більш того, відмінності в підтримці мов програмування і платформ призводять до несумісності програмних реалізацій.
Зараз при розробці Web-сервісів хорошим тоном вважається відмова від використання стилю rpc / enc на користь стилю document / literal (doc / lit). В doc / lit, формати повідомлень XML визначені схемою W3C XML. Теоретично цей хід мав зняти будь-які проблеми оперативної сумісності, оскільки схема визначає реальну структуру XML, а тип обробки цього XML залишений на розсуд платформ. Практично різні рівні підтримки для надзвичайно складної схеми W3C породжують ряд інших проблем оперативної сумісності.
Проблеми сумісності як для більш раннього rpc / enc, так і для розробленого набагато пізніше doc / lit ускладнюються відсутністю підтвердження прийому повідомлення. Це особливо актуально для doc / lit, де інтегроване середовище підтримує різні стандарти схем різного змісту без вказівки відсутніх елементів. Навіть там, де різні середовища підтримують певні функції схеми, їх реалізація часто неповна і породжує проблеми оперативної сумісності при їх використанні. Частково перехід до doc / lit був обумовлений бажанням використовувати стандартні корпоративні або промислові схеми. При проектуванні таких схем зазвичай не враховується їх використання в Web-сервісах, тому вони часто мають функціональні характеристики, слабо підтримувані середовищами SOAP.
Інша проблемна область Web-сервісів SOAP - це постійне змішання над-стуктурних розширень і базової обробки SOAP - додаткові шари обробки, які застосовуються для широкого спектра Web-сервісів. Дизайн SOAP дозволяє легко додавати такі розширення, але вони зазвичай приносять користь лише тоді, коли підтримуються кількома середовищами. Ця умова вимагає всеотраслевого співпраці, що важкодосяжним. Навіть найбільш фундаментальні розширення, для таких функцій як під'єднання і безпеку, розроблялися протягом ряду років і все ще підтримуються далеко не всіма середовищами.
альтернатива SOAP
Крім описаних в попередньому розділі проблем з взаємосумісністю і стандартизацією, що обмежують практичність Web-сервісів SOAP, самі середовища SOAP також часто складно налаштувати і нелегко використовувати. Така комбінація обмеження переваг і значну складність спонукає багатьох розробників до пошуку більш простих альтернатив SOAP. Велика частина "руху опору" SOAP пов'язана з технологією REST. Строго кажучи, REST це формалізація основних правил протоколу HTTP, які застосовні до Web-сервісів. На практиці рух REST часто залишає осторонь формалізацію і охоплює всі, що дозволяє передавати документи XML через HTTP без надбудови SOAP, по суті кооптіруя ідею про прямий обмін документами XML, яка передувала SOAP.
REST набагато менш претензійна, ніж SOAP. REST в своїй основі обмежена використанням HTTP в якості транспортного шару (хоча подібні підходи можуть використовуватися і для інших протоколів передачі даних), тоді як SOAP теоретично є транспортно-агностичний (хоча її широке застосування пояснюється використанням протоколу передачі даних HTTP). REST не має прямих способів додавання інфраструктурних розширень - але лише коли SOAP дійсно стане дозволяти додавання таких розширень, це обмеження можна буде розглядати як недолік.
Оскільки REST менш претензійна, ніж SOAP, немає необхідності використовувати будь-якої фреймовий код для реалізації клієнта або сервера, тому розробникам не потрібно розбиратися в складнощах інфраструктури. Погоджує фактором є те, що їм дійсно потрібно реалізувати обробку HTTP і XML безпосередньо, але багато обробники вже добре знайомі з цими технологіями. Пряма обробка XML може навіть бути перевагою, оскільки дозволяє розробникам вибирати з більш широкого діапазону засобів обробки, ніж пропонований інфраструктурою SOAP.
Отже, чи не час попрощатися з SOAP і перейти до більш простої альтернативи - REST? Можливо, це практично може бути здійснено для багатьох видів додатків Web-сервісів, тому я не стану відмовлятися відразу від цієї ідеї. Однак існують інші програми, зокрема на корпоративному рівні, що вимагають швидше доданої інфраструктури і транспортного агностицизму, які SOAP тільки обіцяє розробити. Перехід до REST означатиме, що для цих програм потрібне буде безпосередньо реалізувати такі функції як безпеку, транзакції, і координація, оскільки вони не будуть забезпечені інфраструктурою. Більшість корпоративних додатків швидше віддадуть перевагу обійтися без Web-сервісів, ніж витратити такі зусилля не подолання цих труднощів.
Але, також, як і в кіно, хоча ситуація виглядає дійсно безнадійної для SOAP, з'являється шанс на порятунок, пов'язаний з появою інфраструктур нового покоління. Ці інфраструктури дозволяють розробку нових можливостей SOAP, роблять доступним весь діапазон SOAP додатків Web-сервісів, в той же час значно покращуючи интероперабельность Web-сервісів doc / lit.
важливість Індиго
Хоча дана серія присвячена технологіям Java, перша нова інфраструктура, про яку я розповім, розроблена головним конкурентом Java технологій: Microsoft® .NET. Це нова інфраструктура Windows Communication Foundation (WCF), також відома як Індиго. Спочатку Індиго був частиною версії "Longhorn" для Windows, випуск якого був запланований на останні кілька років. Але Microsoft оголосила, що в вигляді WCF вона також буде доступна і для більш старих версій Windows. Очікується, що WCF, як тільки стане доступна, замінить інфраструктуру .NET.
Важливість WCF (Індиго) для всього світу Web-сервісів полягає в тому, що Microsoft контролює переважну більшість ПК (це не повний контроль - як і багато інших людей я, наприклад, використовую Linux®, та й Macs також популярні - але більше 90% ). Така розстановка сил означає, що, коли Microsoft виходить на ринок з новою інфраструктурою, то надає переважна вплив на інші компанії і їх продукти. Технології, які підтримуються Microsoft, автоматично підтримуються іншими інфраструктурами, а не підтримувані Microsoft можуть розраховувати лише на другорядне використання, за умови, що системи Microsoft будуть виключені, як з боку клієнта, так і з боку сервера.
Sun і стандарти Java
JAX-RPC 1.0 був вихідним стандартом для Web-сервісів на Java. Хоча JAX-RPC проектувався з урахуванням того, що можуть використовуватися різні реалізації протоколів при фактичній реалізації Web-сервісів, на практиці він використовувався лише для SOAP-сервісів. Було розроблено кілька різних версій JAX-RPC, найбільш широко використовуваної з яких була, мабуть, інфраструктура Apache Axis, за якою слідувала Reference Implementation, включена як частина Пакету програм розробника Java Web-сервісів, розповсюджуваного Sun Microsystems.
На час розробки JAX-RPC 1.0 багато хто вважав, що стиль SOAP rpc / enc є найзручнішим і корисним для Web-сервісів. Специфікація JAX-RPC 1.0 вимагала базової підтримки, як стилю rpc / enc, так і стилю doc / lit, але не вимагала підтримки багатьох елементів схеми. Це мало несприятливий побічний ефект, що виразився в тому, що SOAP doc / lit (який заснований на схемах) став фактично програмним засобом другого класу.
І JAX-WS 2.0 і JAXB 2.0 готувалися для включення в пост-Java 5 версії специфікації J2SE. Внесення цих компонентів як частини до складу стандартної інсталяції JVM поза всяким сумнівом збільшить їх популярність серед розробників, оскільки це виключить необхідність включення цих кілька громіздких інфраструктур в сам додаток. Зворотною стороною включення їх в стандартну JVM (крім збільшення розміру завантажувального файлу) можуть стати труднощі визначення версії в разі необхідності виконання налагоджувальних робіт, що ми вже бачили на прикладі таких компонентів, як JAXP.
Перехід до інтероперабельності
JAX-WS 2.0 безпосередньо підтримує XOP / MTOM, але не інші нові технології WCF. Проте, як частина угоди Sun про інтероперабельності з Microsoft було оголошено про розробку Java-версій з відкритим програмним кодом інших технологій, що входять до складу WCF. Ці програмні продукти будуть розроблені в рамках мегапроекту "GlassFish", що включає в себе всі технології, що використовуються як частина сервера додатків Sun (в тому числі JAX-WS 2.0 і JAXB 2.0 reference implementations).
підхід Apache
Проект Apache тісно пов'язаний з роботою Web-сервісів вже кілька років, в основному фокусуючись на розробці платформ Java. Продукція, що випускається Apache в даний час платформа для Java SOAP Web-сервісів - це інфраструктури Axis третього покоління. Axis широко використовується як розробниками, які завантажують і використовують його безпосередньо, так і будучи вбудованим в якості движка SOAP для декількох різних серверів додатків. Axis вважається найбільш широко використовуваної платформою для Java SOAP Web-сервісів.
Рішення проблеми за допомогою Axis2
Axis2 - нащадок Axis. Він спроектований як полегшений сервер обробки SOAP (хоча, як і JAX-WS 2.0, Axis2 також включає в себе деяку підтримку REST), розширюваний декількома способами. На відміну від оригінального Axis, Axis2 свідомо не обмежений реалізацією якогось певного API (хоча деякі рівні підтримки JAX-WS 2.0 проектувалися з оболонкою для коду ядра Axis2). Axis2 знаходиться в стадії розробки вже більше року і незабаром набуде статусу програмного продукту.
Однією з найбільш зручних характеристик Axis2 є об'єктна модель AXIOM, використовувана для SOAP повідомлень. Об'єктні моделі XML існують так само довго, як і сам XML, беручи початок від стародавнього стандарту DOM від W3C. Відмінність AXIOM від інших об'єктних моделей XML полягає в тому, що її гнучкість забезпечується новими формами парсеров XML, що дозволяє виконувати побудову об'єктної моделі на вимогу. Це означає, що ви платите за побудову об'єктної моделі тільки для тих фрагментів XML документа, доступ до яких можливий лише через об'єктну модель.
Іншою характерною рисою Axis2 є підтримка змінної прив'язки даних. Ця властивість дозволяє вам вибирати найпростіший спосіб роботи з інформаційним наповненням XML ваших документів SOAP, налаштовуючи згенерований код для використання обраного підходу. Можливими варіантами є використання AXIOM безпосередньо; використання простого способу прив'язки даних, схожого з оригінальним Axis; або використання спеціальної схеми прив'язки даних, такий як XMLBeans, JiBX або JAXB 2.0.
розширення Axis2
Хоча Axis2 все ще активно розробляється, є вже ряд проектів, що реалізують технології розширення SOAP поверх Axis2. Ці проекти включають в себе всі головні технології, підтримувані WCF, а також деякі розширення, які Microsoft планує включити в додаються для розширення (іншими словами, що поставляються за окрему плату) додатки. Архітектура Axis2 спрощує розробку таких програм, використовуючи компонент, званий модуль.
нижчі ліги
Крім розробок компаній з гучними іменами, такими як Sun і Apache, в сфері технологій з відкритим програмним кодом також існують різні інноваційні проекти Web-сервісів. Одним з них є мій власний JibxSoap проект, движок SOAP і REST, побудована на моїй інфраструктурі прив'язки XML даних JiBX. Головним достоїнством JibxSoap є її швидкість - в ранніх тестах вона практично зрівнялася з Java RMI при використанні стандартних повідомлень SOAP. XFire-другий движок SOAP, що дозволяє вибирати інфраструктуру прив'язки даних; XFire також показує чудові робочі характеристики. Як JibxSoap, так і XFire, можливо, набудуть статусу програмного продукту в наступному році.
Погляд у майбутнє
- Оригінал статті: Java Web services, Part 1: The year ahead in Java Web services.
- Дізнайся більше про інфраструктуру JibxSoap Web-сервісів, побудованої на прив'язці XML-даних JiBX.
- Технологічна карта стандартів - оцініть вплив і важливість стандартів і специфікацій при розробці SOA і Web сервісів.
- У розділі SOA і Web-сервіси розміщені сотні статей і навчальних посібників для початкової, середньої та просунутого рівнів з розробки додатків Web-сервісів.
Отримати продукти і технології
- Перевірте стан JAX-WS і отримаєте специфікації з сайту Сторінка Товариства Java: створення та експлуатація ПО. потім перейдіть на java.net для завантаження останньої версії reference implementation.
- Отримайте найновішу документацію по Apache Axis2 і файли для завантаження.
- Випробуйте інфраструктуру XFire Web-сервісів, вибираючи при цьому самостійно інфраструктуру прив'язки даних.
- Отримайте інструменти для розробки додатків і проміжне ПО від DB2®, Lotus®, Rational®, Tivoli® і WebSphere®. Ви можете завантажити оціночні версії продуктів безкоштовно або вибрати версію для Linux® або Windows® інструментарію developerWorks для оцінки ПО Software Evaluation Kit.