EJB Advocate: Реалізація слабосвязанних SOA-додатків з використанням Java EE (исходники), Різне, Програмування, статті

У кожній статті EJB Advocate наводиться типовий діалог з реальними користувачами і розробниками в процесі надання рекомендацій щодо вирішення якої-небудь цікавої проблеми. Персональні дані учасників діалогу не повідомляються, також не використовуються недостатньо випробувані і закриті архітектури.


Чи не є ваше визначення слабкого зв’язування занадто жорстким?


Оскільки це остання стаття в 2005 році, розгляд компонентів Java Platform, Enterprise Edition (Java EE), відмінних від сесійних компонентів і компонентів управління даними, – гарний спосіб підсумувати тривалу дискусію в даній рубриці і помістити всі компоненти в контекст сервіс-орієнтованої архітектури.


Проблема: в SOA приділяється занадто багато уваги сесіям і логічним об’єктах


Шановний EJB Advocate!


До сих пір Ваша рубрика була присвячена сесійним EJB-компонентів і компонентів управління даними для сервісів, що дуже добре для безпосередньо підключаються Java-додатків, наприклад, HttpServlets для Web-клієнтів або Swing-додатків для повнофункціональних (rich), оскільки ми не любимо говорити “товстих”, клієнтів. Проте ми чули, що в основі сервіс-орієнтованої архітектури лежить слабке зв’язування. Не мається на увазі чи тут використання SOAP для забезпечення мовної незалежності і асинхронних протоколів, що дозволяють клієнтським і серверним додаткам працювати незалежно, наскільки це можливо? Іншими словами, чому Ви не так часто говорите про JMS і керованих повідомленнями bean-компонентах?


Feeling Disconnected (Не-приєднався)


Існує багато аспектів слабкого зв’язування, які потрібно враховувати


Шановний Disconnected!


EJB Advocate приділяє більше уваги рівням сервісів програми в порівнянні з клієнтською стороною, тому що я великий шанувальник старовинного вислову “форма слідує за функцією”.


Причина невдач багатьох проектів, заснованих на SOA, полягає в тому, що вони грузли в деталях реалізації, не сформувавши перш хорошу моделі для визначення сервісів.


Ця тенденція в певному сенсі природна, оскільки більшість людей, з якими я мав справу в області SOA – це розробники і програмісти, які знають, що диявол ховається в деталях, і охочі зануритися в ці деталі як можна раніше. Тобто, погоджуючись з тим, що хороший сервіс – це крупно-модульний (coarse grained), не вимагає збереження стану, здатний бути посередником, адаптується сервіс, ми очевидністю приходимо до того, що сесійні компоненти з об’єктами передачі даних будуть грати свою роль в реалізації.


Але в попередній статті виникло питання, чи потрібен сесійну компонент взагалі, і була представлена ​​можливість використання компонентів управління даними і їх методів Home замість сесійних компонентів. На малюнку 1 показано одночасне іспользованіеи обох підходів.

Рисунок 1. Сервіс, реалізований за допомогою сесійної EJB-компонента і компонента управління даними, які очікували використання

Такий всебічний підхід гарантує, що:



Дана інформація не надається в сигнатурі методу, незалежно від того, де вона реалізується, але ця інформація життєво важлива для гарної реалізації SOA. В іншому випадку програмісти впадуть в іншу крайність: якщо сумніваєшся – створи заново. Оскільки вартість розробки для SOA вище (потрібно надати всі проміжні модулі і адаптери, необхідні для повної реалізації слабкого зв’язування, показаного на малюнку 4), така тенденція, спрямована проти повторного використання, може мінімізувати одержувані переваги.


Що стосується проблеми простоти, про яку Ви говорите, – дана інформація зовсім не змушує Вас відображати інтерфейси певним чином, а EJB Advocate вчить, що простота – справа смаку. Якщо хочете приховати варіанти вибору, призначені для розробника сервісу, можете просто надати всі “сині” компоненти, показані на малюнку 5, для кожного сервісу:



Ті, хто турбуються про кількість невикористаних компонентів, які буде генерувати даний підхід, можуть (для спрощення) застосувати ще один підхід, який EJB Advocate любить називати клієнт-орієнтованої архітектурою (Client-Oriented Architecture – COA) – дати клієнтові точно те, чого він хоче, для використання сервісу способом, найбільш підходящим для нього.


Такий COA-підхід вимагає аналізу всіх деталей бізнес-процесу і моделей користувальницького інтерфейсу з метою вибору найбільш ймовірних кандидатів для кожного підходу. Наприклад:



Результатами COA-підходу є компоненти, що розробляються “точно в термін”. Ось чому EJB Advocate любить його рекомендувати.


І останнє зауваження, пов’язане з Вашим питанням (чому б не реалізувати все у вигляді сервісів, навіть перетворення, пов’язані з проміжними модулями (mediators) і адаптерами)? Проста відповідь: хорошого не повинно бути занадто багато. При розробці SOA або COA Java EE-додатків найкраще розглядати сервіси як операції в моделі бізнес-процесу. Проміжні модулі і відповідні перетворення асоціюються з нефункціональними вимогами, такими як надійність, зручність використання, ефективність, простота обслуговування і переносимість. Якщо Ви будете розглядати проміжні модулі або відповідні перетворення як справжні сервіси, то в кінцевому підсумку зробите незрозумілим справжнє призначення програми.


Я знаю, що в цьому нелегко розібратися, тому не соромтеся зв’язуватися зі мною, щоб отримати більш докладні роз’яснення щодо застосування даних підходів.


Ваш EJB Advocate.


Висновок


Цей діалог продемонстрував, як Java EE надає повну інтегровану середу реалізації додатків, що використовують сервіс-орієнтовану архітектуру, де кожен компонент або API грають важливу роль в деяких аспектах “слабкого зв’язування”:



Ми впевнені, що Ви знайдете й інші аспекти. Проблема полягає в знаходженні розумних компромісів для кожного з них. Цієї роботи Вам повинно вистачити до наступного року.


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


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

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

Ваш отзыв

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

*

*