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

11

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

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

Оригинал:

В области императивного программирования за последние 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. Поскольку эта парадигма так популярна: почему ее нет? Или, может быть, есть некоторые академические, но, по крайней мере, отрасль не использует их.

Wolfgang
источник
1
Компонентная архитектура может быть требованием для SOA, но SOA не обязательна для компонентного. ОО-системы, которые не отличаются сервисами от структур данных, также могут быть основаны на компонентах.
Дэнни Варод
1
@ Дэнни: Я не делаю разницы между CB и SOA. Если вы прочитаете определения каждого из них, они в основном идентичны. CB похож на pre-2000 и SOA i post-2000, потому что CB в какой-то момент считался «мертвым», и никто больше не хотел использовать это слово. Я не ограничиваю SOA веб-сервисами или тому подобным, но ссылаюсь на парадигму программирования.
Вольфганг
вы не можете откладывать между ними, но они разные. Узнайте больше о CB и его использовании.
Дэнни Варод
Я долго пытался найти разницу между CB и SO. Не нашел ни одной функции, которую бы другой не требовал.
Вольфганг
Компонентная архитектура может рассматриваться как разъединение зависимостей между классами с использованием интерфейсов, что позволяет внедрять зависимости. Архитектура на основе служб требует этого, но также предоставляет и другие требования, поскольку поддерживает удаленную работу служб и клиентов.
Дэнни Варод

Ответы:

8

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

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

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

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

Telastyn
источник
Это интересный момент. Но вы можете применить его и к ОО: в большинстве случаев это обязательное программирование, и только 5% - это ОО. ОО также является способом склеивания фрагментов императивного кода, в то время как императивный код заставляет вещи работать. Тем не менее, мы получаем большую пользу от наличия специализированных языков для этого. Я хотел сказать, что SO-программы написаны на ОО-языках, потому что они кажутся похожими, но это приводит к проблемам, указанным в вопросе.
Вольфганг
@ Вольфганг, по моему опыту, количество императивного кода не так уж велико.
Теластин
@ Вольфганг, если это так, вы не используете правильный ООП, просто процедурный код с ОО-покрытием
TheCatWhisperer
5

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

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

Майкл Браун
источник
3
Также у Erlang есть OTP, который действительно построен на идее сервисов и делает их надежными. Создать сервер, который будет восстанавливаться после сбоя, легко в OTP. (Это займет
Захари К
3

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

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

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

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

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

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

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

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

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


источник
1
Самая большая проблема - избавиться от ссылок на объекты. Я думаю, что Guice иногда выглядит так, как должно быть. Но им приходится слишком много бороться с тем фактом, что Java всегда нужна ссылка на источник службы. Для службы вам нужен только тип, а не экземпляр. Эти синглтоны просто хаки.
Вольфганг
1

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

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

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

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

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

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

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

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

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

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

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

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

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

Wolfgang
источник