Чи став термін "архітектура, орієнтована на сервіс", безглуздий жаргон? [зачинено]

Мене сьогодні запитали, чи маю досвід роботи з "архітектурою, орієнтованою на сервіс", і хоча я думаю, що це роблю. Концепція, як мені здається, настільки заплутана, що я не знаю, як ви могли б чесно відповісти на це питання.

Я вдався до терміну Гуглінг, намагаючись отримати стисле визначення поняття і чим воно відрізняється від інших архітектур. Прочитавши ряд статей про нього, єдиний загальний потік, який я, здається, зможу знайти, - це система з декількома компонентами, які спілкуються один з одним через якийсь інтерфейс, мабуть, з невеликою перевагою для XML / SOAP.

Здається, майже будь-яку програму можна визначити як SOA, особливо веб-додаток. Чи потрапив цей термін у пастку "Веб 2.0" і став терміном, що означає все, що ви хочете?

Я тут далеко від бази? Коли ви, хлопці, чуєте термін, чи означає це щось конкретне для вас? Якщо так, я б хотів стислого визначення, яке чітко демонструє, що таке, а що конкретно НЕ SOA.

Я вважаю, що початкове значення SOA базувалося на послугах з чітко визначеними інтерфейсами, які можна споживати програмно . У центрі уваги були сервісні інтерфейси, а не термінали, комунікації чи бази даних. Ключовою частиною були послуги, що споживають інші послуги. Сервіс A може зателефонувати до служби B, отримати результат та зателефонувати до служби C або D. Ви можете мати набір спеціалізованих служб та архітектувати рішення, поєднуючи їх у спосіб, який вирішує проблему клієнта.

SOA часто плутають із SaaS (програмне забезпечення як послуга), яке стосується моделі ціноутворення, коли користувач платить за користування послугою, на яку він підписався, а не купує ліцензію на копію програмного продукту. Щоб відповісти на третій параграф у вашому запитанні, веб-додаток, ймовірно, не SOA, але може бути SaaS.

Термін, безумовно, втратив деяке значення. В організації, де я працюю, термін SOA часто використовується взаємозамінно з SaaS і позначається на команді ІТ-фахівців ( інформаційні технології на відміну від розробки програмних продуктів ), які налаштовують сервери та маршрутизатори та встановлюють програмні продукти для роботи на них. Деякі з них мають назви "SOA Architect", але жодна з них не має нічого спільного з архітектурою, проектуванням, реалізацією чи тестуванням програмного забезпечення.

Я зробив те саме, що гугл SOA, щоб побачити, що це насправді, і так, це зловживають зовсім небагато. Коли я думаю про SOA, я думаю про наступне:

1. Відкриваема безголова програма ...
2. Це використовує бездротове з'єднання (ala HTTP) ...
3. Спілкування в незалежних форматах платформи

SOA може контрастувати з архітектурою Client-Server (архітектура, що надає велику кількість послуг) і бібліотекам, які є модулями, підключеними до програм через лінкер.

Тож коли люди про це говорять, я, як правило, приймаю його із зерном солі. Я також схильний просто називати це "веб-сервісами". З веб-сервісами мається на увазі архітектура.

Суворі визначення SOA набагато перевищують лінію витрат / вигод, оскільки теоретична у багатьох випадках.

Якщо ваш продукт не є самими послугами, вам часто потрібна інша точка зору.

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

Крім дебатів щодо того, що це насправді означає, концепція (що б це не означало) зазнала у багатьох колах, застосовуючи її до місць, де вона просто не підходить.

Наприклад, якщо я будую щось, що мається на увазі як процес чорної скриньки і масштабується через паралелізм, а не сегментацію та розповсюдження, я, можливо, маю послугу викрити / поговорити з чорною скринькою, але деякі люди намагаються помістити служби всередину ящик.

Як суворе технічне визначення воно завжди було невизначене, але ідея не без сумнівів, де вона підходить.

Мені довелося попрацювати над парою корпоративних систем, де управління продано на SOA. Як розробник я дивлюся на системи і бачу купу програмного забезпечення за веб-сервісом, який робить речі. Це могло бути написано різними мовами та архітектурами, не з яких матиме значення або має відношення до клієнтів, які звертаються до служб, і які не мають фактично абревіатуру "SOA" в будь-якій точці їх документації.

Але керівництво хоче "SOA" !!! Таким чином, вони придбали по-справжньому дорогі сервери у певної великої компанії, на якій наклейки "SOA" були застосовані поверх попередніх наклейок "Web Service", які були застосовані поверх попередніх наклейок "JEE", які були застосовані поверх .... Ви отримуєте ідею. І як результат, ми як розробники сидимо, перетягуючи і скидаючи піктограми itty-bitty по екрану, щоб створити "SOA" "КОМПОНЕНТИ", які працюють наполовину, а також якби ми це зробили з чимось простим, таким як EBJ3 боби, весняні компоненти тощо. .

Тому моя порада - якщо вас запитають про SOA, скажіть: «Так, я зробив SOA, я написав багато систем, які використовують сервісно-орієнтовану архітектуру, щоб робити щось. Про яку технологію SOA ви просите?». І якщо вони почнуть розмовляти зі світлими очима та туманними поглядами на КОМПОНЕНТИ SOA, DRAG AND DROP та як це полегшує розвиток. Відступайте повільно і уникайте контакту з очима!

Я думаю, що це може мати сенс: одне - коли у вас є "підлеглі" модулі, які викликаються, коли це потрібно, а інша справа, коли у вас процеси обслуговування / демон демонструються незалежно і відповідають на ваші запити, можливо, спілкуєтеся один з одним, живіть своїми власне життя іншими словами. При такому підході ви можете мати величезну, масштабовану, фізично розподілену систему. Я бачив деяких, наприклад, у сфері мобільної телефонії. Але це лише здогадки.

(Тепер давайте подивимося, що говорить Вікіпедія про SOA ... Whoa.)