「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>アプリケーション設計のポイント]]

*目次 [#l07a868e]
#contents

*概要 [#oc157d98]
「[[通信制御機能]]」開発の試行錯誤を纏めておく。

-「[[通信制御機能]]」で最も成功したのは、.NETオブジェクトをBinary転送する~
-「[[通信制御機能]]」で最も成功したのは、.NETオブジェクトをバイナリ転送する~
[[インターフェイスの汎用性>#f7d9c2da]]の高いWebAPIである。
--これが実現できたのは、.NETのBinarySerializer が強力だったため。
--これが実現できたのは、.NETのBinarySerializer が強力だったため。~
例えば、C言語の構造体表現という方法もあるが、これでは、~
ネイティブ・オブジェクト表現へのパースが難しくなってしまい利用されない。
--この場合、下位のプロトコルはなんでも良い。何を使用しても問題なく利用できる。
--問題があるとすれば、[[通信の相互運用性>#e3ce4135]]が無いというところ。

-次に成功するだろうと思われるのは、REST JSON、JSON-RPCの個別インターフェイス。
--共通層を経由してB層・D層にアクセスできる点を除いて特に特徴は無い。~
--個別インターフェイス上で特定の型にパースすれば、~
共通層ではベースの型やobject型を使用して、個別処理にデータを渡すことができる。
--これにより、[[インターフェイスの汎用性>#f7d9c2da]]、[[通信の相互運用性>#e3ce4135]]を両立できるが、~
個別インターフェイスの定義と、個別インターフェイス上で特定の型にパースする処理を書くのは面倒。

**トレード・オフ [#g55a4ddc]
-ソレ以外の方式には、
--[[インターフェイスの汎用性>#f7d9c2da]]
--[[通信の相互運用性>#e3ce4135]]

>の問題が有り、使い難い。

-通信方式は、以下のように評価できる。
|#|評価項目|バイナリ転送|WCF|SOAP|JSON|h
|1|[[インターフェイスの汎用性>#f7d9c2da]]|高|高（選択可能）|低|低|
|2|[[通信の相互運用性>#e3ce4135]]|低|低（選択可能）|中|高|
|3|インターフェイス定義|オブジェクト型|データコントラクト≒オブジェクト型|WSDL|Bean（POJO/POCO）やGenericで構築したobjectの階層構造&br;これは、パースの仕様が言語を跨いで標準的になっているため。|

*ポイント [#ic1ef259]
**インターフェイスの汎用性 [#f7d9c2da]
***要素 [#reea05d2]
-WebAPIはなるべく汎用的に定義したい（インターフェイス定義を増やしたくない）。
-この場合、インターフェイス記述、データ記述言語は１つだが、その中を通るデータのフォーマットが可変となる。
-何かをキーにして、中を通るデータをパースする先の型が明確になればイイだけだが、~
これは、インターフェイス記述、データ記述言語の次の段階のobjectの階層構造やBinary表現の話になる事が多いため、~
これは、インターフェイス記述、データ記述言語の次の段階のobjectの階層構造やbinary表現の話になる事が多いため、~
そもそも、汎用性を追求してしまうと、[[通信の相互運用性>#e3ce4135]]に問題が発生するものと考える。

***例 [#e0488a61]
-.NETオブジェクトのBinary転送がまさにこれに該当する（[[通信の相互運用性>#e3ce4135]]は無い）。
-.NETオブジェクトのバイナリ転送がまさにこれに該当する（[[通信の相互運用性>#e3ce4135]]は無い）。
-SOAPやXML/JSONでも可能だが、SOAPやXML/JSONの[[通信の相互運用性>#e3ce4135]]に問題が発生する。

**通信の相互運用性 [#e3ce4135]
SOAPやXML/JSONなどは通信の相互運用性がある~
（≒異なるテクノロジ間をブリッジできる）~
インターフェイス記述、データ記述言語であると言える。

***データ・フォーマット [#c6b16bd8]
-異なるテクノロジ間で通信の相互運用性を高めるには、~
データ記述言語でデータ・フォーマットが標準化されている必要がある。

-[[インターフェイスの汎用性>#f7d9c2da]]を高めるために、さらにその中を通る~
データ・フォーマット（objectの階層構造やBinary表現）を規定し出すと、~
データ・フォーマット（objectの階層構造やbinary表現）を規定し出すと、~
これは＝言語レベルの話になることが多く、相互運用に問題を与える。

***パーサー [#cd5d93a3]
また、各言語向けのパーサーが拡充してくる必要がある。~
SOAPやXML/JSONなど、標準化されているため各言語向けのパーサーの提供を受けやすい。

***例 [#tb303f1f]
-SOAP
--インターフェイス記述言語はWSDL、データ記述言語はXML。
--サーバーがWSDLを生成し、クライアントはWDSLを理解してプロキシを生成する。
--これで相互運用は可能だが、ライブラリがスクリプト言語には供給されなかった。
--このため、最近では、SOAPより、JSONを使用することが多くなってきた。

-XML
--インターフェイス記述言語は無く、データ記述言語としてXMLを使用する。
--XMLパーサーが必要だが、JavaScriptなどのスクリプト言語には提供されていないことがある。
--JSONと同じく、REST APIを開発可能であったが、JSONのRESTがデファクトになりXMLのRESTは廃れた感がある。

-JSON
--インターフェイス記述言語は無く、データ記述言語としてJSONを使用する。
--各言語間でBean（POJO/POCO）、Genericのパースが同じフォーマットで行われる。
--特にJSONは仕組みが簡単なため、スクリプト言語含めて相互運用が可能になった。

*技術的な問題 [#z3008006]
**[[WCF>https://techinfoofmicrosofttech.osscons.jp/index.php?WCF]] [#l994e898]
***概要 [#da22110b]
WCFのデータコントラクトは、
-通信の相互運用性の低いBinary転送や、SOAPには適合した方式だったが、
-XML/JSONレベルの通信の相互運用性には、問題を起こした。
-ABCを選択可能にするという野心的な試み。
--A：アドレス
--B：バインディング（トランスポート・プロトコル、エンコーディング）
--C：コントラクト
---サービス・コントラクト
---オペレーション・コントラクト
---データ・コントラクト

***Binary転送や、SOAP [#x8c3fd2a]
Binary転送や、SOAPはあまり通信の相互運用性を気にする必要は無いため問題は少ない。
-WCFのTCP/IP（Binaryデータなので相互運用することが少ない）
-ただ、トレードオフがあって結局の所、良い所取りが出来ないため、~
バイナリ転送（汎用性の重視）か、SOAPやJSON（相互運用性の重視）など2択になっている。

-例えば、WCFのデータコントラクトは、
--オブジェクト表現でデータコントラクトを行うため、そもそも相互運用性は低いと言える。
--このため、通信の相互運用性の低いバイナリ転送や、SOAPには適合した方式だった。
--この中で、SOAPは、唯一、相互運用が可能なバインディングだった。
--しかし、XML/JSONなど、高い通信の相互運用性を目的とした場合、問題を起こした。

***バイナリ転送や、SOAP [#x8c3fd2a]
バイナリ転送や、SOAPはあまり通信の相互運用性を気にする必要は無いため問題は少ない。
-WCFのTCP/IP（バイナリ・データなので相互運用することが少ない）
-WCFのSOAP（WSDLで相互運用が保証されている。）

***XML/JSON [#k2bacbc6]
-しかし、XML/JSONについては、データコントラクトはミスマッチ

-理由は、データコントラクトを交換できるということは、
--objectの階層構造やBinary表現が一致しているか、
--objectの階層構造やbinary表現が一致しているか、
--WSDLのような、インターフェイス記述言語が必要だった。

-このため、初期のパーサーは通信の相互運用性が殆ど考えられていなかった。
--このため、XML/JSONなどのRESTfulなAPIを定義するには、WCFは向いていなかった。
--しかし、中期以降は、データコントラクト無しでデータの送受信が可能になった。
--このため、XML/JSONなどのRESTfulなAPIを定義するには、~
データコントラクトを使用するWCFは向いていなかった。
--しかし、中期以降は、特にパースの仕様が言語を跨いで標準的なJSONで、~
データコントラクト無しでデータの送受信が可能になった。

***分析 [#t86a8bd1]
-インターフェイス記述やデータ記述言語を重視すると、
--相互運用性は高まるが、
--複雑なオブジェクトを汎用的にパースする処理の実装は難しくなる。

-データコントラクトを重視すると、
--汎用性は高まるが、
--問題をインターフェイス記述やデータ記述言語に~
移動させているだけなので、相互運用性が犠牲になる。

**[[汎用DTO]] [#ffa6d900]
***概要 [#ka1d94d3]
-DataTableを異なるランタイム間で交換できるようにするために作成した。
-具体的には、.NET FrameworkとSilverlight間でDataTableを交換する。
-ランタイムが異なっても、objectの階層構造を維持してデータ交換できる優れモノ

***パーサーの問題 [#n16e3792]
-しかし、実装量が多く、パーサーを各言語に向けて提供するのは無理があった。

-DataTableはBean（POJO/POCO）、Genericと比べて廃れた感があるが、~
複雑なデータアクセスをするエンタープライズ・システムでは依然として重宝する。~
このため、各言語に向けてパーサーが提供されればイイ気もするが、しかし、その兆候は無い~
（これは、エンタープライズ・システムを実装する言語が限られているためかもしれない）。

***今後の展望 [#eef1812d]
-.NET FrameworkとSilverlightに替り.NET Core間のデータ転送に重宝する。
-しかし、.NET Standard2.0からは、DataTableが供給されているもよう。~
このため、XmlSerializerを使用すれば、.NET Frameworkと.NET Core間で、~
データ交換ができるようになるかもしれない。

**JSON [#f75d43fc]
JSONにもトレードオフがある。

***インターフェイスの汎用性 [#e7bb0652]
-インターフェイスを汎用的にする場合、Genericが利用できる。
--Genericにはstringを使用して、必要に応じて個別にパースする。

-インターフェイスの汎用性を高めるために、object型を使用すると、~
JSON.NETではJObjectが返るため、手動パースが必要になってしまう。

***通信の相互運用性 [#n50e2c18]
-JSONには、インターフェイス記述言語は無いが、~
Bean（POJO/POCO）やGenericのパースの仕様が言語を跨いで標準的になっているので、~
Bean（POJO/POCO）やGenericで構築したobjectの階層構造が≒インターフェイス定義になっている。

-このため、通信の相互運用性を高めるには、~
Bean（POJO/POCO）やGenericで≒インターフェイス定義するとイイ。

**OpenAPI / Swagger [#pc33d888]
REST 用のインターフェイス記述言語っぽいが、多分、流行らないと思う。

-Swagger (OpenAPI) - マイクロソフト系技術情報 Wiki~
https://techinfoofmicrosofttech.osscons.jp/index.php?Swagger%20%28OpenAPI%29

*参考 [#g7f91197]
**[[Webサービス]] [#he20cf95]
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS