近年では、私は、サービス指向の基礎となるソフトウェアの研究開発に関連に従事し、徐々に私はビューのサービスは、より正確かつ詳細な定義を必要とすることでより重要だと思ういくつかのアイデアを、形成されています。要するに、サービスは行動（事業活動）抽象化の本質です。
優れた新しいサービスの概念を説明するために、そして伝統的な定義されたSOAのサービスとは異なり容易にするために、私はその後、私はS ++およびマイクロサービスとSOAを比較することに、S ++（サービスプラスプラス）という名前の新しいサービスになります違いは、違いS ++とオブジェクト指向のは、この新しい概念を示しています。
なぜサービスを再定義する必要がありますか？一つの理由は、実際には別の観点からのサービスが同じではないということです、我々は例を与えます。
最後にサービスは次のようになり？これは少しのように多くの異なる角度を渡る非常に興味深い感じです。はい、それはSOAのサービスまたはサービスの定義されたマイクロサービスの伝統的な定義があるかどうか、サービスは最も包括的な定義の一つだけになります、この定義はあまりにも複雑で、最終的には唯一の技術スタッフが理解することができます。それでは、どのようなビジネスの人々はそれを理解することができますすることができますか？一般的に職場でのドキュメントですが、ドキュメントが変更を見ることができない唯一の問題があり、ビジネスサービスへの変更は、最終的な技術者を渡す必要があります。
そのため、サービスの伝統的な定義は、ビジネスと技術を一緒に混合されているすべての参照するための方法することができ、サービスの方法であると理解することができ、それを修正することができますか？これを行うためのS ++で、S ++は、コンテンツサービスは、純粋な事業内容となって聞かせて、伝統的なサービスと拡張サービスの行くにビジネスと技術サービスを分離することにより、ストリッピングビジネス・テクノロジー・コンポーネントの完全に独立となります。
もう一つの理由は、サービス担当者の視点からコーミングの過程を見て、ということである、伝統的なサービスの抽象化レベルは十分ではありません。例えば、ビジネス・プロセスは、最初に行われ、その後、そのようなサービスの口座に支払いを引き落としする必要があります。プロセスのオーケストレーションのスタッフのために、サービスはサービス料はありませんが、すべての最初の支払いの多くの既存のタイプ（電話、水道、ガスが....）がある、しかし、将来的には多くの可能な種があります。
私たちは、最初にビジネスのすべてが可能です含めることはできませんが、我々は、ビジネスのすべてが含まれている必要はありそうでない場合は、私が最初にノンストップの変化に陥るだろうとすることができます。したがって、我々はプロセスでは、より抽象サービス定義を必要とし、この競合を解決するためにS ++を解決すべきもう一つの大きな問題である、抽象サービス事業を呼び出すだけです。
S ++伝統的なSOAおよびマイクロサービスとの違い
概念や定義の違い
SOAのために、構造化情報標準促進（OASIS）とオープングループ（Open Groupが）正式な定義を与えられました。OASISは、SOAをとして定義しています。
組織と異なる所有権ドメインの制御下にあってもよい分散機能を利用するためのパラダイム。それは均一で、提供発見、と相互作用して、測定可能な前提条件と予想と一致所望の効果を生成する機能を使用する手段を提供します。
Open GroupのSOAは、以下のように定義されています。
サービス指向アーキテクチャ（SOA）は、サービス指向をサポート建築様式です。サービス指向は、サービスとサービス・ベースの開発とservices.Aサービスの成果という点で考え方です。
- その反復可能な事業活動の論理的な表現であります
- 指定された結果を有する（例えば、掘削レポートを統合、気象データを提供し、顧客の信用を確認してください）
- 他のサービスで構成することができる自己完結されます
- サービスの消費者に「ブラックボックス」であります
基本的な認知業界では、SOAのアーキテクチャのパターンで、思考のサービス指向の方法です。サービスの定義については、Open Groupのサービスは再利用可能なビジネス活動の論理記述と見なされている自己完結型、で組み合わせることができる「ブラックボックス」。
サービス定義ではマイクロサービス、伝統的なSOAとは大きく異なるものではない、実現の粒径は、アプリケーションが、もちろん、論争のあるものを話題に小さい程度に、十分に小さい強調する。（サービスの我々が表示され、粒子サイズやニーズをバックに関連しているように、小さなに変更すること自由にされていない）私の意見では、マイクロサービス「マイクロ」のサービスはありませんが、実際には、マイクロのアプリケーションです。
Sは++私は、そのサービスが統一行動モデルの必要性は同種の活性のために要約されている一方で、単純に、内部の事業活動の詳細をふさがない抽象抽象行動（事業活動）、であると考えています。だから、S ++は、抽象化の2つのレベルが含まれています。
1、特定の事業活動から、すべてのビジネス発現技術に依存しないコンテンツの事業活動に関係なく動作の詳細との手続きのため、純粋な、そして技術に依存しないの作成、取り除くために、事業活動の内部の詳細を遮蔽し、開始、自己完結型の事業内容。ビジネスと技術の分離のプロセスとして、このプロセスのI。
サービス記述複数の非サービス記述要素を除く、技術サービスによって分離された要約から2は、抽象複合サービス類似の要素は、それによって、より正式な抽象ビジネスモデルを形成します。このプロセスは、マルチステートサービス・プロセス・モデリングと呼ばれています。
実装の違い
実装の観点からは、SOAは、業界は、より一般的な方法Webサービスメソッドである種々の技術が、等DCOM、CORBA、JAVA RMI、、、Webサービスなど、RESTをSOAアーキテクチャの概念を表現することを可能にします。理論的には、実装アーキテクチャは、技術に依存しないで、すべてではない技術は、実用的な観点からいくつかの良いアーキテクチャを実現することができます。
例えば、Webサービスでは、実際にWebサービスは、デリバティブ技術の伝統的なオブジェクト指向の技術、すなわち、いわゆる技術（そのようなインタフェースのJavaの類似概念として）界面配向に属します。キャリア間のシステムの実現をもたらすこのプロセスはまだ必然的にシステムの間の結合をもたらす対話モードの目的に基づいています。
S ++の定義から、原因抽象度の高いの導入に、達成することが伝統的なオブジェクト指向技術と完全にはそれがない結合しました。したがって、マルチ状態モデル及びS ++のサービス変換を処理する専用ベアラS ++ S ++コンテナが存在しなければなりません。もちろん、同時にS ++は、業務システムの構築のための伝統的な技法を用いて、伝統的なオブジェクト指向技術にも対応する必要があり、プロセスのS ++は、ターゲットの変換を行うことなく透過的です。
軽量アーキテクチャの達成にマイクロサービスより多くの重点は、中心にポイントを使用して、マイクロサービスアーキテクチャの粒径との素晴らしい関係を持っているシステムのパフォーマンスを改善するために、合意により軽量プロトコルを選択してみてください。S ++ビューでは、契約の任意の拡張子は、私たちが象に乗って見に異なる役割からしているように、さまざまなサービスと実装のための訪問者は、異なる懸念している、サービス内容の定義には影響しませんが、サービスの一部ですプロトコルや技術的手段が可能です。このような観点から、SOA、およびマイクロサービスは一例++ Sまたは実装されています。
アーキテクチャの観点からは、S ++限り需要があるとして、その中心点がなければならない避けられない、パフォーマンス上の問題は言い訳にすることはできません。アプリケーションサービスのためのアーキテクチャは、そのようなサービスのポートフォリオの導入など、さまざまな用途に適したアーキテクチャは、アプリケーションおよびアーキテクチャのニーズを犠牲にして技術的なニーズのバランスをとるためには、ローカルではないの中央ノードにバインドされます。従来のマイクロSOAサービスは全て異なっていると、この点、S ++、S ++アーキテクチャは、SOAとマイクロサービスとの間のマルチセンターアーキテクチャとの間の推奨される分割領域のビジネスニーズに応じて、各領域に基づいています独自のアプリケーションの機能の異なる技術を選択してください。
カップリングの違い
一方で、伝統的なオブジェクト指向とSOAは、サービスの定義に非常に異なっているが、特別な実装を独自に持っていなかったので、本当にSOAのアーキテクチャを実現するための時間はまだオブジェクト指向のアプローチを使用しています。既存のSOAの実装、おそらくカプセル化され、通話サービスは、リモートオブジェクトに基づいします。
私たちは、あなたがコンパイル時にリモートオブジェクトのクライアントがリモートオブジェクトのスタブクラスの導入でなければならないアクセスしたいことを知って、そしてオブジェクト指向の多状態の実装は、呼び出し側によって決定されなければならないので、その訪問者のサービスのことができるようにするために可能なすべてのスタブクラスを含める必要があります実行時ポリモーフィズムを実現。サービスプロバイダは、新しい派生オブジェクトを追加したら、消費者は、サービスプロバイダとサービスの消費者の間の緊密な結合につながった、コンパイル時に新しいスタブクラスにアクセスするには、このサービスを導入しなければなりません。例えば：
消費者はPerson.hello（）サービスを呼び出す必要があり、人は抽象クラスで、サービスプロバイダは、男と女2つの具象クラスを実装します。サービスの消費者のための多状態の実装は、消費者側で決定されなければならない、それは明確に）プログラムの人物P =新マン（で示されなければならない、または人物P =新しい女性（）;サービスプロバイダーは、このOldPersonを追加した場合この時点では、スタブクラスOldPersonランタイムが含まれていないため、新しいオブジェクトは、サービスの消費者は、アクセスできないとき。
逆に、S ++のために、サービスは、サービスコンシューマ上の例に取り付けられたオブジェクトの定義を必要としない（PERSONIDスティング）ハローハローサービスを導入するだけ抽象的定義を必要とします。その後、とき伝送ESB（ESBサービスプロバイダの必要がない場合、関数の多形の容器を持っている）上に、抽象サービスアクセス、ESBサービスインスタンスは、事前のランタイムサービス定義に基づいて選択され、サービス合意されたルールはキャスト。従来のIT開発者にとっては、このプロセスはより多くの（ビジネスプロセスを呼び出すかを決定するために、ビジネスフィールドの内容を介して）ビジネス・プロセスのようなものです、実際には、開発者向けのSOAサービスは、このプロセスは、透明であり、サービス定義理由サービススタッフの時間の定義には多型のルールを合意されているので、これは直接、技術プラットフォームを実装することが可能な技術の事業の一部となっています。SOAのアーキテクチャでは、このようなグローバル・トランザクションの一貫性を保つために使用された後、伝統的な赤などのビジネス機能の技術に類似不可欠な機能といくつかは、技術をベースとしなければなりません。
マイクロサービスにS ++に関して、またカップリングに大きな差があります。本来必然的にマイクロサービスコールアプリケーション間で互いに、それによって形成カップリングの間になり、ビジネス・ロジックのオブジェクトの間に存在するように、アプリケーションへのマイクロサービスは、オブジェクトに十分に小さく、小さなアプリケーションを分割するため、S ++オブジェクトをそのS ++間組合せ論理は、マイクロアプリとの間の結合が排除されるように、容器を完了するために呼ばれるだけでなく、ロジック・サービス・ディスパッチ・センタを生成しなければなりません。
違いS ++とオブジェクト指向
気になる部分の違い
オブジェクト指向の懸念がある限り同じ固有の特性として、我々は、オブジェクトモデルの作成におけるオブジェクトのクラスに抽象化する必要がある、オブジェクトの固有の特性であるため、オブジェクトの説明の固有の特性は、要素を変更することはできません。この機能は、OOAD方法は、システム内のデータのモデルを確立するために非常に適しており、抽象的な内部エンティティとシステムの説明を通じて、我々は完全なシステムモデルとデータ構造を得ることができ、システムは、これらのオブジェクトの追加と削除によって機能することができますなど、チェック演算処理が完了します。
サービス指向ではない、我々はサービスのクラスに抽象化されたサービスモデルを構築する際に、限り、外部の性能が同じであるとして、サービス指向のサービスの内部ロジックを気にしますが、サービスの外観を懸念していません。例えば、支払クラスのサービスは、それは電気や水道代の支払いを支払うことであるかどうか、その外観は、私達ができる抽象決済サービス行動パターンから、同じです。オブジェクト指向オブジェクトのプロパティが固有の要素は、入力と出力のコンテンツは、サービス指向の行為は、要素は、そのようなこの動作を再生すると、変更することはできませんとなっている構成、変更することはできませんが、我々は参加者でなければならないボールを持っている必要があります。この機能は、SOADサービスメソッドは、組織行動の順序によって、合理的な対象事業に到達することができ、プロセスエンジンを介して、このような外側に、システム間の相互作用のモデルを確立するために、より適しています。
この観点から、そこに現在のITシステムは、冗長性がたくさんあります。こうした口座開設など、この動作は、ビジネスシステムは、すべての人生の歩み、すべての異なる実装を持っているが、実際にやるの違いがあるのですか？確かに、私は、この差は人間によって引き起こされていると言うでしょう、または違いは内部システム、の観点から、外部の行動が、人は仮想のカウンターで登録されたあなたのカウンターに来るか保証されていませんそれは？ビューの抽象的な行動の観点から、私はあなたがテーブル内にあるか、二つの表がそれを埋めるコントロール？私はあなたがそれを承認する必要がありますどのように多くのリンクを制御しますか？実際には、一度サービス指向の概念をより広く、より深い意識である、プロの口座管理機関は、アプリケーションのすべての部門では、そこに持っていることになるアカウントが直接公共サービスに呼び出されるとき、口座を開く必要があり、これは労働者の社会的分裂の必然的な傾向です。ここで私は大胆に、プロのサービスプロバイダ+クロス業界のアプリケーション（またはサービス）プロバイダの様々な置き換え、将来の垂直業界アプリケーションプロバイダーが徐々に消えます予測します。
この図は、アプリケーションのほとんどは彼らのサービスのモデリングを調整することによって、プロ、企業向けクラウドサービスが提供するパブリッククラウドサービスから来て、存在する可能性がある、独自のユニークなインテリアを確立するために、理想的なエンタープライズITのクラウドモデルを確立しますアプリケーション。その後、すぐに自分のビジネスを形成するために、内部および外部のサービス機能の組み合わせによって画策。
多态性的差异
我们都知道，OOAD之所以能成为现今软件界广为接受的一种方法论，有一个关键点在于对象的多态性对系统稳定性带来的好处。
多态性解决了业务流程中不断变化的业务分支产生的代码维护的代价，在面向过程的一段代码中，任何实体发生增加和改变都会导致这段代码需要被修改，于是随着系统的快速膨胀，这种修改变得成本巨大甚至无法承受；而OO的方法巧妙的通过多态性解决了这个问题，所以才会有越来越多的超大系统出现，用于解决更加灵活变化的复杂业务需求。
面向对象的多态主要解决对象实体属性的扩展和操纵方式的差异，也就是说对象属性是不可修改（或重载）但可以增加，对象的方法（操纵方法）可以重载。
那么类似的，S++的方法也希望为跨系统的应用带来稳定性。比如，在传统BPM的一段流程中，任何行为本身发生增加和改变都会导致流程本身的修改，成本也会随着系统的增大而变得不可忍受。
举个例子，通过一个简单的流程去完成查余额然后缴费，传统的BPM需要对所有的缴费方式设立相应的业务分支，一旦有新增的缴费方式出现就必须修改这个流程，增加新的分支；而服务多态性则只需要调用缴费的抽象服务，具体的缴费服务是根据运行时刻的数据由服务的多态性自动完成匹配的。
在服务多态性中，与OO不同的是，由于服务本身就是行为所以没有所谓方法的重载，服务被重载的只有服务对外表达的属性。比如缴费服务中，待缴账号是抽象服务的属性，而被实际服务重载后，就变成电话号码（缴电话费）、水表序号（缴水费）等等实际的行为参与者了。
假如实现了服务的多态性，就可能解决传统的组合流程会随着业务变化而需要修改的问题，从而可能改变传统的业务开发方式，使得大规模使用组合流程引擎开发业务逻辑成为一种可能的选择。
小结
最初のプラスと分離技術に加え、第二ポリモーフィックにサービスを提供するために、サービスの基本的な概念を再定義し、伝統的なサービスを定義することによって拡張Sは++二つの新しいサービス機能を追加しました。これはS ++をさらに管理し、利用するサービスが容易になり、抽象化のサービスレベルを向上させ、サービスの複雑さを軽減、SOAおよびマイクロサービスの利点を継承します。その後、我々はS ++ビジネスで結果として伝統技術から派生した定義とアーキテクチャレベルのさまざまな機能に大きな影響を確認し、改善、伝統的なSOAおよびマイクロサービス、エンタープライズアプリケーション開発と統合技術の未来へS ++代わりにバインドされています主流。