なぜサービス指向の言語がないのですか？

編集：

さらなる混乱を避けるために：私はウェブサービスなどについて話していません。内部でアプリケーションを構造化することについて話しているのですが、それはコンピューターの通信方法についてではありません。プログラミング言語、コンパイラー、および命令型プログラミングパラダイムの拡張方法についてです。

元の：

命令型プログラミングの分野では、過去20年（またはそれ以上）に2つのパラダイムがありました。オブジェクト指向（OO）とサービス指向（SO）です。コンポーネントベース（CB）。

両方のパラダイムは、モジュールの独自の概念を導入することにより、命令型プログラミングパラダイムを拡張します。OOはそれらをオブジェクト（およびクラス）と呼び、データ（フィールド）とプロシージャ（メソッド）の両方を一緒にカプセル化します。SOは対照的に、データ（レコード、Beanなど）をコード（コンポーネント、サービス）から分離します。

ただし、Smalltalk、C ++、Javaおよびその他すべてのJVM互換、C＃およびその他すべての.NET互換、Pythonなど、そのパラダイムをネイティブにサポートするプログラミング言語を持っているのはOOのみです。

SOにはそのような母国語はありません。COM / DCOM（バイナリ、C、C ++）、CORBA、EJB、Spring、Guice（すべてJava）などの手続き型言語またはオブジェクト指向言語の上にのみ存在します。

これらのSOフレームワークは、その概念のネイティブ言語サポートが欠落していることは明らかです。

• OOクラスを使用して、サービスとレコードを表し始めます。これにより、メソッドのみ（サービス）を持つクラスとフィールドのみ（レコード）を持つクラスが明確に区別される設計になります。サービスまたはレコード間の継承は、クラスの継承によってシミュレートされます。技術的には、厳密に保持されていませんが、一般的に、プログラマーは2つの役割のうちの1つだけを行うようにクラスを作成することをお勧めします。
• 追加の外部言語を使用して、欠落している部分を表現します。IDL、XML構成、Javaコードの注釈、またはGuiceのような埋め込みDSLです。サービスの構成はサービスコード自体の一部ではないため、これは特に必要ですが、これに限定されません。OOでは、オブジェクトは他のオブジェクトを作成するため、そのような機能は必要ありませんが、SOでは他のサービスをインスタンス化または構成しないためです。
• それらは、プログラマーがSOを「駆動」するために必要なすべてのコードを書かなければならないOO（初期のEJB、CORBA）の上に内部プラットフォーム効果を確立します。クラスはサービスの性質の一部にすぎず、多くのクラスを作成して一緒にサービスを形成する必要があります。プログラマーのためにそれを行うSOコンパイラーがないため、そのすべてのボイラープレートが必要です。これは、一部の人々がC ++が存在しないときにOO for Cでそれを行ったのと同じです。オブジェクトのデータを保持するレコードを、メソッドであるプロシージャの最初のパラメーターとして渡すだけです。OO言語では、このパラメーターは暗黙的であり、コンパイラーは仮想関数などに必要なすべてのコードを生成します。SOの場合、これは明らかに欠落しています。
• 特に、新しいフレームワークでは、AOPまたはイントロスペクションを使用して、欠落している部分をオブジェクト指向言語に追加しています。これは、必要な言語表現力をもたらしませんが、前のポイントで説明したボイラープラットフォームコードを避けます。
• 一部のフレームワークは、コード生成を使用してボイラープレートコードを生成します。XMLの構成ファイルまたはOOコードの注釈は、このための情報源です。

上記のすべての現象がSOに起因するとは限りませんが、SO言語が必要であることを明確に示すことを望みます。このパラダイムは非常に人気があるため、なぜ存在しないのですか？または、学術的なものもあるかもしれませんが、少なくとも業界では使用していません。

というのは、コードの5％未満が実際にサービスを定義しているからであり、実質的に時間の短縮を主張します。インターフェースが定義されると、ほぼ完了です。残りの時間は、OO（または代替）に費やされているものの作品を作ります。

簡単に言えば、問題のその小さな断片に特化した言語を作成することは大きな勝利ではありません。どちらかといえば、2つの言語（1つはサービス用、もう1つは実装/消費用）を持つことは、統合の複雑さをさらに高めることを求めているだけです。

[アプリケーション境界ではなく、内部アプリケーションレイアウトであることをOPの明確化のために編集]：

このようなサービスレイアウトを持つ主な目的は、サービス間に薄いタッチポイントを持たせることです。私の元々の理由はまだあり（imo）、その答えに加えて、比較的少数の問題がサービスベースの内部アプリケーション構造に向いているという事実に加えています。そのため、問題のほんの一部に対処するだけでなく、全体的な問題の割合を低く抑えることができます。

関数型言語は、コアが非常にサービス指向です。オブジェクトを作成してそれらの関数を呼び出す代わりに、関数を作成してメッセージを渡します。Erlangは、言語の機能的な側面を超えて、コアフレームワークにプロセス間通信やマシン間通信さえ組み込まれているため、ローカルプロセスであるかのようにリモートプロセスにメッセージを送信できるため、この手法の好例です。 。

Scala、Clojure、F＃などの他の言語も「サービス指向」のセマンティクスを提供します。問題は、彼らが存在しないということではなく、一般大衆が彼らを恐れているため、それほど人気が​​ないことです。

サービス指向は、統合の問題に対するアーキテクチャ上の答えでした。統合は、理想的には、既存の言語、製品、デバイス、リソースを全体像に適合させる包括的なソリューションです。

問題はすでに多すぎる言語があることであり、高い相互運用性コストが発生するため、新しい言語は必要ありません。

ただし、Webサービス定義言語という1種類の言語が導入されました。WSDLはSOAのメタ言語です（WADLという名前のREST用に別の放棄された言語があります）

質問を振り返って、「SO言語はどのように見えるでしょうか？」

モジュール間のそれらの契約はどのように書かれますか？
操作の基本的な仕組みはどのように実行されますか？

サービス指向はアプリケーションのプロパティであり、必ずしも使用される言語ではありません。サービスは、機能に依存する構造です。この関数は、プログラミング言語の仕組みに依存して、操作を機械実行可能命令に変換する構造です。

BPELはSO言語の可能な例ですが、非常に高いレベルであり、利用できるモジュールに依存しています。これらのモジュールは順番に非BPEL言語で書かれているため、作業を実行できます（別名機械語に翻訳）。

素晴らしいQと私に良い瞬間の反射を与えた。

自分の質問に対する答えを提供して、どれだけの人が賛成と反対かを確認します。

いくつかの可能性：

• SO言語を構築するのは難しいようです。主に、サービスの実装とその構成が分離されているためです。大学で聞いたいくつかの学術的解決策がありますが（言及はありませんが、申し訳ありません）、それは業界に参入していないようです。しかし、私はこれを言い訳としてカウントしますが、本当の理由ではありません。オブジェクト指向言語とコンパイラも実装が非常に困難ですが、市場には長い間ソリューションがあります。

• プログラマーはオブジェクト指向を理解せず、間違った方法で使用するため、SOにオブジェクト指向言語を使用します。OOにはSOと矛盾する2つの基本概念があるため、私は間違っています。

  1. 機能は、作業対象のデータが配置されているクラスに適用されます。コードとデータは同じモジュール内で結合されます。他のクラスのデータで動作する個別のクラスを持つことはオブジェクト指向スタイルではありません。それがSOパラダイムに一致するZüllighofenのツールと材料のアプローチ（WAM）です。

  2. オブジェクトは他のオブジェクトを作成し、オブジェクトのネットワークを形成します。階層または複雑な関係を作成できます。サービスは常に外部から構成されるフラットネットワークを形成します。通常、サービスにはインスタンスが1つ（シングルトン）しかありませんが、オブジェクトは、それらが表すエンティティが存在するたびにインスタンス化されます。SOのレコードはネットワークで接続されていません。

• OOの一部の機能はSOに似ているか、SOに必要なものを容易にするために使用できるため、OO言語を使用すると便利です。

  1. OOの依存関係反転の原則は、サービスが外部で構成される方法に似ています。

  2. シングルトンオブジェクトはサービスのようなもので、オブジェクトファクトリはサービスロケーターのようなものです。

  3. OOには、サービスインターフェイスに似たインターフェイスもあります。

  4. クラスの継承は、サービスとレコードの継承と同様（同じ？）にできます。

• OOとSOは、さまざまな種類の問題に役立ちます。そのため、すべてのアプリケーションで、パラダイムをここかそこかで使用したいと考えています。別の言語を使用すると、同じプログラム内の2つの言語間の切り替えが妨げられます。

• SOはプログラミングパラダイムであるだけでなく、プログラムの動作でもあります。Webサービス、オペレーティングシステムコンポーネントなどはSOですが、必ずしもSO言語で記述する必要はありません。この種の「バイナリコンポーネント」は非常に自然で成功しています。しかし、それは別のことです。プログラムが内部的に通信する方法ではなく、プログラムが相互に通信する方法です。人々はそれを十分に頻繁に混ぜていると思います。