Почему нет сервис-ориентированного языка?

Редактировать:

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

Оригинал:

В области императивного программирования за последние 20 лет (или более) мы увидели две парадигмы: объектно-ориентированную (ОО) и сервисно-ориентированную (SO), то есть. на основе компонентов (CB).

Обе парадигмы расширяют парадигму императивного программирования, вводя свое собственное понятие модулей. ОО называет их объектами (и классами) и позволяет им инкапсулировать как данные (поля), так и процедуры (методы) вместе. SO, напротив, отделяет данные (записи, компоненты, ...) от кода (компоненты, сервисы).

Однако только OO имеет языки программирования, которые изначально поддерживают его парадигму: Smalltalk, C ++, Java и все другие JVM-совместимые, C # и все другие .NET-совместимые, Python и т. Д.

У ТАК нет такого родного языка. Он существует только поверх процедурных языков или ОО-языков: COM / DCOM (двоичный, C, C ++), CORBA, EJB, Spring, Guice (все Java), ...

Эти платформы SO явно страдают от отсутствия поддержки их концепций на родном языке.

• Они начинают использовать ОО-классы для представления сервисов и записей. Это приводит к проектам, в которых существует четкое различие между классами, которые имеют только методы (службы), и классами, которые имеют только поля (записи). Наследование между службами или записями затем моделируется наследованием классов. Технически, это не так строго, но в целом программистам рекомендуется делать уроки, чтобы они играли только одну из двух ролей.
• Они используют дополнительные внешние языки для представления недостающих частей: IDL, конфигурации XML, аннотации в коде Java или даже встроенный DSL, как в Guice. Это особенно необходимо, но не ограничивается этим, поскольку состав служб не является частью самого кода службы. В ОО объекты создают другие объекты, поэтому в таких средствах нет необходимости, но для SO это связано с тем, что службы не создают и не настраивают другие службы.
• Они устанавливают эффект внутренней платформы поверх OO (ранний EJB, CORBA), где программист должен написать весь код, необходимый для «управления» SO. Классы представляют собой только часть характера службы, и нужно создать множество классов, чтобы сформировать службу вместе. Все, что нужно, так как нет никакого компилятора SO, который сделал бы это для программиста. Это так же, как некоторые люди делали это в C для OO, когда не было C ++. Вы просто передаете запись, которая содержит данные объекта, в качестве первого параметра в процедуру, которая является методом. В языке OO этот параметр неявный, и компилятор создает весь код, который нам нужен для виртуальных функций и т. Д. Для SO этого явно не хватает.
• Особенно новые фреймворки широко используют AOP или самоанализ для добавления недостающих частей к языку OO. Это не приносит необходимой языковой выразительности, но позволяет избежать кода платформы котла, описанного в предыдущем пункте.
• Некоторые фреймворки используют генерацию кода для создания кода котельной пластины. Конфигурационные файлы в XML или аннотации в OO-коде являются источником информации для этого.

Не все явления, которые я упомянул выше, могут быть приписаны SO, но я надеюсь, что это ясно показывает, что существует потребность в языке SO. Поскольку эта парадигма так популярна: почему ее нет? Или, может быть, есть некоторые академические, но, по крайней мере, отрасль не использует их.

Потому что <5% кода на самом деле определяет сервис, и я бы поспорил значительно меньше времени. Как только интерфейс определен, это в основном сделано. Остальное время тратится на ОО (или альтернативы), заставляя вещи работать .

Проще говоря, это не большая победа, чтобы сделать специализированный язык для этой небольшой части проблемы. Во всяком случае, наличие двух языков (один для службы и один для реализации / потребления) просто требует дополнительной сложности интеграции.

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

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

Функциональные языки очень ориентированы на обслуживание по своей сути. Вместо того чтобы создавать объекты и вызывать на них функции, вы создаете функции и передаете им сообщения. Erlang является ярким примером этого метода, потому что даже помимо функциональных аспектов языка он имеет межпроцессное и даже межмашинное взаимодействие, встроенное в его базовую структуру, позволяя отправлять сообщения удаленному процессу, как если бы это был локальный процесс. ,

Другие языки, такие как Scala, Clojure и F #, также предоставляют «сервис-ориентированную» семантику. Проблема не в том, что они не существуют, а в том, что население их боится, и поэтому они не так популярны.

Сервис-ориентация была / является архитектурным ответом на проблемы интеграции. В идеале интеграция - это комплексное решение, которое вписывает любой существующий язык, продукт, устройство, ресурс в общую картину.

Нет необходимости в каком-либо новом языке, так как сама проблема заключается в том, чтобы иметь слишком много языков , что приводит к высокой стоимости взаимодействия.

Однако был представлен один вид языка - язык определения веб-службы. WSDL - это мета-язык SOA (и есть другой заброшенный язык для REST с именем WADL)

Я переверну вопрос и задам вопрос: «Как бы выглядел язык SO?»

Как эти контракты между модулями будут написаны?
Как будет выполнена основная механика операции?

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

BPEL - возможный пример языка SO, но он очень высокого уровня и зависит от наличия модулей, доступных для его использования. Эти модули, в свою очередь, написаны на языках, отличных от BPEL, поэтому работа может быть выполнена (или переведена на машинный язык).

Великий вопрос и дал мне хороший момент для размышлений.

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

Некоторые возможности:

• Кажется, трудно построить язык SO. Главным образом из-за разделения реализации услуг и их состава. Есть несколько академических решений, о которых я слышал в университете (нет ссылки, извините), но, похоже, это не вписывается в индустрию. Но я считаю это оправданием, а не реальной причиной. ОО-языки и компиляторы тоже довольно сложно реализовать, но решения на рынке уже давно.

• Программисты используют ОО-языки для СО, потому что они не понимают ОО и используют его неправильно. Я говорю неправильно, потому что в ОО есть два фундаментальных понятия, которые противоречат SO:

  1. Функциональность распространяется на класс, в котором находятся данные, над которыми они работают. Код и данные объединены в одном модуле. Это не стиль ОО - иметь отдельные классы, которые работают с данными других классов. Это подход Züllighofen «Инструменты и материалы» (WAM), который соответствует парадигме SO.

  2. Объекты создают другие объекты и образуют сети объектов. Они могут создавать иерархии или любые сложные отношения. Услуги всегда образуют плоские сети, которые составлены снаружи. Службы обычно имеют только один экземпляр (Singleton), тогда как объекты создаются так часто, как существует сущность, которую они представляют. Записи в SO не подключены в сети.

• Некоторые функции ОО похожи на SO или могут использоваться для упрощения того, что нужно для SO, поэтому удобно использовать язык ОО.

  1. Принцип инверсии зависимости в ОО аналогичен внешнему составу сервисов.

  2. Объекты Singleton похожи на сервисы, фабрики объектов похожи на сервисы-локаторы.

  3. У ОО также есть интерфейсы, которые похожи на сервисные интерфейсы.

  4. Наследование классов может быть аналогичным (тем же самым?), Что и наследование сервисов и записей.

• ОО и СО полезны для разных видов проблем. Поэтому в каждом приложении заманчиво использовать парадигму здесь или там. Наличие отдельного языка затруднит переключение между ними в рамках одной и той же программы.

• SO - это не только парадигма программирования, но и поведение программы: веб-службы, компоненты операционной системы и т. Д. Являются SO, но не обязательно должны быть написаны на языке SO. Этот вид «бинарных компонентов» очень естественен и успешен. Но это другое дело: это то, как программы общаются друг с другом, а не то, как программа общается внутри. Я предполагаю, что люди смешивают это достаточно часто.