Що таке SOA "простою англійською мовою"? [зачинено]

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

Усі документи, включаючи вікі, трохи абстрактні, або, можливо, я ідіот і не розумію. Чи є в цьому путівник ідіотів?

Що саме стоїть за цими трьома літерами?

Ви можете знайти цю статтю (Що таке SOA - SOA і Web - сервіси Роз'яснення) корисно.

Трохи тизер:

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

• У SOA є дві ролі - постачальник послуг та споживач послуг. Програмний агент може грати обидві ролі. SOA не є абсолютно новою концепцією, однак ця стаття в основному присвячена SOA, як реалізовано з веб-сервісами.

SOA - це новий значок для деяких дуже старих ідей:

• Розділіть свій код на багаторазові модулі.

• Інкапсулюйте в модуль будь-яке дизайнерське рішення, яке, ймовірно, зміниться.

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

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

Що нового в SOA є

• Ви це робите в мережі.

• Модулі спілкуються, передаючи повідомлення один одному по мережі, а не за допомогою більш традиційних механізмів мови програмування, таких як процедурні дзвінки. Зокрема, в сервісно-орієнтованій архітектурі частини зазвичай не поділяють змінний стан (глобальні змінні в традиційній програмі). Або якщо вони поділяють стан, цей стан ретельно блокується в базі даних, яка сама по собі є агентом і яка може легко керувати кількома одночасно клієнтами.

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

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

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

Аналогія
Уявіть собі будинок на селі, який багато в чому є частиною більшої громади, наприклад міста чи містечка. У місті є власні складні системи для забезпечення водою та електроенергією, обслуговування санітарії, забезпечення транспорту та інших комунальних послуг. Будинок є споживачем в цій моделі, місто (або спільнота) є постачальником і труби, каналізаційні труби, ЛЕП, оптичні волокна і т.д. є інфраструктура , в якій вони спілкуються.

Цю модель можна було б порівняно з SOA. Люди в будинку використовують декілька різних «застосунків», таких як радіатори, комп’ютери, туалети, світильники, підлогове опалення, ванни тощо. Ці програми не цікавляться, як місто виробляє воду, створює електрику або поводиться з відходами до тих пір, як це працює. Компоненти міста - генератори, водяні насоси та санітарні приміщення. Він забезпечує будинок усіма цими потребами, але дозволити його використовувати тим, що вважатиме за потрібне.

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

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

Як ти це робиш? Ну, ви спочатку визначитесь із ролями та інтерфейсом - кухар 1 зробить салат, кухар 2 зробить суп, кухар 3 зробить стейк тощо. Потім ви розмістите страви добре організованими на столі (так це інтерфейси) і скажіть: "Всі, будь ласка, помістіть своє творіння у призначений вам посуд. Не хвилюйтесь ні про кого іншого".

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

Це також означає, що ви можете комбінувати посуд (послуги), як вам подобається. Наприклад, ви можете просто використовувати десерт для обслуговування кафе, або просто взяти суп і поєднати його з хлібом, який ви купили у іншої компанії, щоб запропонувати більш дешеве меню, або дозволити іншим ресторанам використовувати ваші салати, щоб поєднати їх страви тощо. .

Одне з найуспішніших реалізацій SOA було в Amazon. Через їх дизайн вони могли перекомпонувати всю свою інфраструктуру та продати її як веб-сервіс Amazon.

* Це лише один аспект SOA.

SOA - це архітектурний стиль, але також бачення того, як слід розробити та інтегрувати різнорідне застосування. Основна мета SOA - відмовитися від монолітних застосунків і натомість мати набір служб багаторазового використання, які можна складати для створення додатків.

IMHO, SOA має сенс лише на рівні підприємства і нічого не означає для однієї програми.

На багатьох підприємствах кожен відділ мав власний набір корпоративних застосунків, який мав на увазі

1. Подібна функція була реалізована кілька разів

2. Дані (наприклад, дані клієнта чи працівника) повинні бути надані між кількома програмами

3. Заявки орієнтовані на відділ.

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

1. Не потрібно повторно реалізовувати подібні функції (наприклад, надавати послуги клієнту чи працівникові)

2. Сприяє інтеграції програм та доступу до загальних даних чи функцій

3. Розвиток, орієнтований на підприємство.

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

Це перегляд 1000 футів SOA. Однак це не зупиняється на цьому. Існують і інші концепції, що доповнюють SOA, такі як організація бізнес-процесів (BPM), службова шина обслуговування підприємств (ESB), комплексна обробка подій (CEP) тощо. Всі вони вирішують проблему розподілу ІТ / бізнесу , тобто як мати ІТ вміти ефективно підтримувати бізнес.

SOA є абревіатурою для сервісно орієнтованої архітектури.

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

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

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

Практикуючий SOA дає високу ступінь повторної експлуатації, застосовуючи DRY [Не повторюй себе], що призводить до високорентабельного програмного забезпечення. Ремонтопридатність - це перше, про що думає будь-яка архітектура програмного забезпечення - SOA це дає вам.

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

Таким чином, ви визначаєте протокол, який ви будете використовувати для взаємодії (скажімо, це можуть бути веб-сервіси SOAP) і дозволяєте вашій "системі, що робить щось бізнес-робота" взаємодіяти з невеликими службами для досягнення вашої "великої мети" .

Я б запропонував вам прочитати статті Томаса Ерла та Роджера Сеансів, це дозволить вам чітко вирішити, про що йдеться у SOA. Це також непогані ресурси, дивіться на пояснення SOA для вашого начальника для пояснення неспеціалістів

Побудова SOA

Шаблон дизайну SOA

Досягнення цілісності в SOA

Чому ваш SOA має бути схожим на VW Beetle

SOA пояснив для вашого начальника

Продуктивність послуги WCF

Що має місце у великих організаціях, це те, що з часом все є або монолітними, або розрізненими системами скрізь, або трохи обох. Хтось врешті-решт заходить і каже, що у нас безлад. Тепер ви хочете переробити (гроші комусь), щоб все було орієнтоване на певну монолітність, залежить від того, кому ви платите парадигму, але в той же час зможете додавати шматки та деталі незалежно від майстра / моноліту.

Таким чином, ви купуєте SOA Oracle і Oracle стає босом у всіх ваших частинах. Всі інші гравці, які приходять, повинні працювати з SOA за допомогою сервісу (веб-сервісу або будь-якого іншого). Моноліт Oracle піклується про все (моноліт не означає приниження). О так, у вас ASP.NET MVC на передній панелі чи щось інше.

головне - переміщення речей у систему та поза їх системою без впливу та збереження постачальника Oracle SOA, Microsoft WCF, як мізки усього цього. все - все на кшталт «рідини», «рідина», речі, що рухаються і виходять з невеликим впливом, навіть людські служби, не лише комп’ютери.

Для мене це просто означає купу веб-служб (або, як ми їх називатимемо в майбутньому) з хорошим переднім кінцем. А якщо у вас є база даних, просто натисніть на базу даних і перестаньте турбуватися про мовні слова. все добре.

Лише одна пропозиція: -

Читайте концепції, технології та дизайн SOA від Томаса Ерла.

У ній дуже красиво представлені деталі про SOA на звичайній англійській мові та з тематичними дослідженнями.

Ну ви бачите .. SOA розшифровується як сервісно-орієнтована архітектура .... Простішими словами, ви пишете фрагмент коду, який є дуже загальним, тобто він робить щось, що може бути використано у багатьох програмах ... адресна книга або може бути калькулятором. і ви запускаєте цей код на IIS. Таким чином, ви надаєте послугу через свій код. Отже ви - постачальник послуг. Тепер хтось хоче використовувати подібний код, тоді йому не доведеться писати код ще раз. Він просто використовує ваш код, можливо, через веб-сервіс. Отже, він стає споживачем послуг. Тому створення програми за допомогою таких сервісів називається SOA. І вільна зв'язок існує, оскільки постачальник послуг та споживач можуть взаємодіяти, навіть якщо вони використовують різні мови програмування. Сподіваюся, ти зрозумієш.

з блогів ittoolbox.

Далі викладено схожість та відмінності з минулими методами дизайну:

• SOA проти структурованого програмування o Подібності: Найбільш схожий на виклики підпрограми, де передаються параметри і функція функції абстрагується від абонента - наприклад, посилання та виконання CICS та зарезервоване слово COBOL CALL. Копірні книги використовуються для визначення структури даних, яка, як правило, визначається як XML-схема для служб. o Відмінності: SOA слабко пов'язаний, що означає, що зміни в послузі надають менший вплив на споживача (програма "дзвінки"), а послуги є взаємодіючими на різних мовах та платформах.

• SOA порівняно з OOA / OOD o подібності: інкапсуляція, абстракція та визначені інтерфейси o відмінності: SOA слабко поєднаний без ієрархії чи успадкування класів, абстракції низького рівня - рівня класу порівняно з службовим обслуговуванням

• SOA порівняно зі спадкоємними компонентними розробками (CBD) - наприклад, CORBA, DCOM, EJB o подібності: повторне використання за допомогою складання компонентів, інтерфейсів, віддалених викликів o відмінності: широке прийняття стандартів, XML-схеми проти маршованих об'єктів, сервісне впорядкування, проектування для повторного використання простіше, послуги орієнтовані на бізнес порівняно з ІТ, бізнес-послуги є курсовими (широкий спектр)

• SOA (для інтеграції) проти інтеграції корпоративних програм (EAI) o подібності: кращі практики (чітко визначені інтерфейси, стандартизовані схеми, архітектура, керована подіями), багаторазові інтерфейси, загальні схеми

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

Це також може означати "Struct of Arrays" (на відміну від "Array of Structs"), що є поширеною темою паралельного (особливо SIMD) програмування, але я здогадуюсь, що це не те, що ви тут маєте на увазі!

SOA - це модна фраза, яку винайшли виробники технологій, щоб допомогти продати пов'язані з ними технології Enterprise Service Bus. Ідея полягає в тому, щоб ви зробили свої невеликі програми на острові на підприємстві (наприклад: система бухгалтерського обліку, система контролю за запасами тощо), все виставляти послуги, щоб вони могли гнучко організуватись у "програми", а точніше стати частинами сукупного бізнесу, який охоплює сферу діяльності. логіка.

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

Послухайте видання цього тижня Floss Weekly цього тижня подкасту , який висвітлює SOA. Описи досить високого рівня і не заглиблюються в занадто багато технічних деталей (хоча більш конкретні та впізнавані приклади проектів SOA були б корисні.

Традиційна архітектура додатків:

• Інтерфейс користувача
• Не визначений матеріал (реалізація), який інкапсульований / прихований за користувальницьким інтерфейсом

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

SOA мені здається архітектурою, яка фокусується на викритті машиночитаних даних та / або API, а не на відкритті інтерфейсів користувача.

SOA або Service-орієнтована архітектура - це модель архітектури програмного забезпечення, в якій програми або системи будуються з базових (і зазвичай розподілених) програмних послуг, що відповідають певному набору характеристик, а саме:

1. На основі інтерфейсу, політики та контракту
2. Прозорість місцеположення
3. Автономний
4. Анотація
5. Багаторазові
6. Композиційний
7. Без громадянства
8. Відкриваються
9. Розширюваний
10. Нещільно з'єднані

Основна мета SOA - це гнучкість розвитку програмного забезпечення, тобто здатність легко та дешево реагувати на зміни, тим самим дозволяючи бізнесу швидко реагувати на зміни ринків.

Послуги зазвичай (але далеко не виключно) реалізуються як веб-сервіси, тобто вони працюють над всюдисущим протоколом веб-HTTP та реалізуються за допомогою XML на основі SOAP або легкої (і більш популярної) парадигми REST.

Залежить від того, хто ти!

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

Ви повинні прочитати 100-SOA-питань [pdf]

Ура

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