Чому не існує мови, орієнтованої на обслуговування?

Редагувати:

Щоб уникнути подальшої плутанини: я не говорю про веб-сервіси та інше. Я говорю про внутрішнє структурування додатків, а не про те, як спілкуються комп'ютери. Йдеться про мови програмування, компілятори та про те, як розширюється імперативна парадигма програмування.

Оригінал:

В області імперативного програмування ми бачили дві парадигми за останні 20 років (або більше): об'єктно-орієнтовану (ОО) та службово орієнтовану (SO). на основі компонентів (КБ).

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

Однак лише у OO є мови програмування, які в основному підтримують її парадигму: Smalltalk, C ++, Java та всі інші сумісність з JVM, C # та всі інші .NET-сумісність, Python тощо.

Так немає такої рідної мови. Він з'являється лише на основі процедурних мов або мов OO: COM / DCOM (бінарний, C, C ++), CORBA, EJB, Spring, Guice (всі Java), ...

Ці рамки ПС явно страждають від відсутності підтримки рідною мовою своїх концепцій.

• Вони починають використовувати класи OO для представлення служб та записів. Це призводить до розробок, де чітко розмежовано класи, у яких є лише методи (послуги), і ті, у яких є лише поля (записи). Потім спадкування між службами або записами моделюється успадкуванням класів. Технічно його не дотримується так суворо, але загалом програмістам рекомендується робити класи, щоб грати лише одну з двох ролей.
• Вони використовують додаткові зовнішні мови для представлення відсутніх частин: IDL, XML-конфігурації, Анотації в коді Java або навіть вбудований DSL, як у Guice. Це особливо потрібно, але не обмежується цим, оскільки склад послуг не входить до самого коду послуги. В OO об'єкти створюють інші об'єкти, тому немає необхідності в таких об'єктах, але в SO це так, оскільки служби не інстанціюють і не налаштовують інші служби.
• Вони встановлюють внутрішньоплатформенний ефект поверх OO (ранній EJB, CORBA), де програміст повинен записати весь код, необхідний для "приводу" SO. Заняття представляють лише частину характеру послуги, і багато класів повинні бути написані, щоб формувати послугу разом. Вся ця плита котла необхідна, оскільки немає компілятора SO, який би це зробив для програміста. Це так само, як деякі люди робили це в C для OO, коли не було C ++. Ви просто передаєте запис, який містить дані об'єкта в якості першого параметра, до процедури, що є методом. У мові ОО цей параметр неявний, і компілятор виробляє весь код, який нам потрібен для віртуальних функцій тощо. Для ТА цього явно відсутнє.
• Особливо новіші рамки широко використовують AOP або самоаналіз для додавання відсутніх частин до мови OO. Це не приносить необхідної виразності мови, але уникає коду платформи котла, описаного в попередньому пункті.
• Деякі рамки використовують генерацію коду для створення коду пластини котла. Файли конфігурації в XML або примітки в коді OO є джерелом інформації для цього.

Не всі явища, про які я згадував вище, можна віднести до SO, але я сподіваюся, що це чітко свідчить про необхідність мови SO. Оскільки ця парадигма настільки популярна: чому її немає? Або, можливо, є деякі академічні, але принаймні галузь не використовує.

Тому що <5% коду насправді визначає послугу, і я заперечую значно меншу кількість часу. Після того, як інтерфейс визначений, це значною мірою зроблено. Решту часу проводить в ОО (або альтернативах), щоб справи працювали .

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

[редагуйте для уточнення ОП, що це внутрішній макет програми, а не межа програми]:

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

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

Інші мови, такі як Scala, Clojure і F #, також надають "орієнтовану на сервіс" семантику. Проблема не в тому, що їх не існує, а в тому, що широке населення їх боїться, і тому вони не такі популярні.

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

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

Однак був введений один вид мови, мова визначення веб-служби. WSDL - це мета мова SOA (а для REST є WADL).

Я переверну запитання і запитую "як би виглядала мова SO?"

Як укладаються контракти між модулями?
Як би виконати фундаментальну механіку роботи?

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

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

Великий Q і дав мені хорошу мить на роздуми.

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

Деякі можливості:

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

• Програмісти використовують мови OO для SO, оскільки вони не розуміють ОО та використовують його неправильно. Я кажу неправильно, тому що є два основні поняття в ОО, які суперечать ТА:

  1. Функціональність переходить до класу, де розташовані дані, над якими вони працюють. Код і дані поєднуються в одному модулі. Це не стиль OO мати окремі класи, які працюють на даних інших класів. Це підхід Züllighofen "Інструменти та матеріали" (WAM), який відповідає парадигмі SO.

  2. Об'єкти створюють інші об'єкти і утворюють мережі об’єктів. Вони можуть створювати ієрархії або будь-які складні відносини. Послуги завжди утворюють плоскі мережі, складені ззовні. Служби зазвичай мають лише один екземпляр (Singleton), тоді як об'єкти інстанціюються так часто, як існує сутність, яку вони представляють. Записи в SO не підключені до мереж.

• Деякі функції OO схожі на SO, або їх можна використовувати для полегшення того, що потрібно для SO, тому корисно використовувати мову OO.

  1. Принцип інверсії залежності в ОО схожий із тим, як послуги складаються зовні.

  2. Об'єкти однотонних схожі на послуги, фабрики об'єктів - як локатори обслуговування.

  3. OO також має інтерфейси, схожі на сервісні інтерфейси.

  4. Спадкування класів може бути схожим (таким же?), Як успадкування служб та записів.

• OO і SO корисні при різних видах проблем. Тож у всіх програмах спокусливо використовувати або парадигму тут, або там. Наявність окремої мови перешкоджатиме переходу між двома в межах однієї програми.

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