通信制御機能のバックアップの現在との差分(No.4)

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

[[戻る>FAQ - その他]]
-[[戻る>機能一覧]]
--[[機能一覧 - フレームワーク]]
--[[エンタープライズ・システム開発基盤機能>機能一覧 - エンタープライズ・システム開発基盤機能]]
--[[対応する処理方式と、そのサンプル - V1系>機能一覧 - 対応する処理方式と、そのサンプル - V1系]]

*目次 [#oe1075ce]
#contents

*概要 [#h386f2a1]
通信制御機能は、
-C/S3層、Web3層システム開発で必要となるサービス インターフェイス / サービス ゲートウェイ基盤を提供する。
-分散オブジェクト的な機能をHTTP, TCP/IPなどの通信プロトコルを使用して実現できる。
-.NET以外の異種開発技術との連携も別途、（汎用/個別）[[サービス・インターフェイス]]を公開することで可能になる。

-分散オブジェクト的な機能をWebサービス系の通信プロトコルを使用して実現できる。
-P/B/D層の3層構成の中に、P層/B層呼び出しのアドインとして追加/適用できる。
http://www.slideshare.net/daisukenishino/open-0150/7

*特徴 [#m143ed95]
標準のP/B/D層の3層構成の中に、P層/B層呼び出しのアドインとして追加できる。~
これによりP層 → B層のメソッド呼び出しをネットワーク経由（Webサービスなど）に変換可能。

-通信処理を隠蔽することで、業務処理の実装に専念することが可能。
-P層/B層呼び出しの引数・戻り値は自動的にBinary serialize & deserializeされる。
-通信処理を隠蔽することで、業務処理の実装に専念することが可能。
-３層方式のアプリケーションを２層方式と同様、高い生産性を実現。
-これにより3層方式のアプリケーションを2層方式と同様の、高い生産性で開発できる。

http://www.slideshare.net/daisukenishino/open-0150/8

*詳細 [#q5416506]
**方式 [#w3e41e49]
***リモート呼出し [#ue51365d]
下記は、Webサービスをプロトコルに使用する場合の例であり、

#ref(CC_remote.png,left,nowrap,処理方式（ネットワーク経由時）,80%)

-クライアント側で、使用するプロトコルは、~
「サービス論理名」をキーにして「プロトコル用 名前解決機能」で解決される。
--これにより、実際に使用する「サービス ゲートウェイ内のプロキシ」を選択する。
--プロキシに指定するアドレスは、「アドレス用 名前解決機能」を使用して取得する。
-なお、サーバ側で使用する、呼出し先のモジュールは、同様に、~
「サービス論理名」をキーにして「インプロセス用 名前解決機能」で解決される。

-各「名前解決機能」で使用する「名前解決定義」は、~
XMLのフォーマットにて情報を定義する。

-使用するプロトコルが変われば、上記の
--「サービス ゲートウェイ内のプロキシ」や、
--「サービス インターフェイス」などの

>通信制御基盤の実装も変わってくる。

--クライアント、サーバのユーザ プログラムには、影響を与えることはない。~
通信制御基盤は、要件に合わせて、追加実装することが可能である。

***インプロセス呼出し [#o7769cd1]
クライアント プログラムからネットワークを経由しないで~
「インプロセス呼出し」をする場合は、以下のような処理方式となる。

-「インプロセス呼出し」の場合、使用するプロトコルは、「インプロセス」に解決される。
-この場合、実際に使用する「サービス ゲートウェイ内のプロキシ」には、~
「サービス インターフェイス」上で使用されたものと同じ「インプロセス呼び出し」用のプロキシが使用される。

#ref(CC_inprocess.png,left,nowrap,処理方式（インプロセス呼び出し時）,80%)

**構成要素 [#f1171662]

***サービス ゲートウェイ [#a417c185]
-「サービス論理名」をキーにして、呼び出し先プロトコルへの名前解決を行う。

-プロトコル ＝ インプロセス呼び出しの場合、
++呼び出しモジュール（アセンブリ、クラス）への名前解決を行う。
++レイトバインドを使用して、Ｂ層の既定のメソッドを呼出す。~
++レイトバインド時の例外処理を実行する。~
TargetInvocationExceptionをハンドルしInnerExceptionをリスローする。

-プロトコル ＝ インプロセス呼び出し以外の場合、
++呼び出し先アドレスへの名前解決を行う~
このコードブロックはクライアントAPIのタイプ毎に用意すると良いと考える。
++呼び出しには、プロトコル指定のプロキシを使用する。
++引数オブジェクトから、バイト配列へシリアライズする。
++タイムアウト、認証情報、HTTPプロキシ（ゲートウェイ）.etcなど、オプション設定を行う。
++プロキシを使用した同期呼出し ～ 戻り値の受け取り。
++引数のバイト配列から、引数オブジェクトへデシリアライズする。
++タイプ別の[[例外処理>#w1e9c318]]を実行する。

***サービス インターフェイス [#rc81b006]
各プロトコルにおけるテンプレートを使用して実装する~
（TCP/IP、RPC、Webサービス、WCFなどがある）。

+「サービス論理名」をキーにして、~
呼び出しモジュール（アセンブリ、クラス）への名前解決を行う。
+引数のバイト配列から、引数オブジェクトへデシリアライズする。~
なお、この際、必要になる型情報は、サービス インターフェイスの~
ローカルに配置しておくことで自動的に取り込むことができる。
+[[前述>#a417c185]]と同様、
++インプロセス呼び出しを行う。
++タイプ別の[[例外処理>#w1e9c318]]を実行する。
+[[サービス ゲートウェイ>#a417c185]]に結果を返す。

***名前解決機能 [#n0b5f1e9]
名前解決機能として、

-プロトコル、アドレスへの名前解決を行う、~
「プロトコル名前解決サービス」 （ProtocolNameService）
 <?xml version="1.0" encoding="utf-8" ?>
 <!DOCTYPE TMD[
  <!ELEMENT TMD (Prop*, Url*, Transmission*)>
  <!ELEMENT Url EMPTY><!ELEMENT Prop EMPTY><!ELEMENT Transmission EMPTY>
 
  <!ATTLIST Url id ID #REQUIRED value CDATA #REQUIRED>
  <!ATTLIST Prop id ID #REQUIRED value CDATA #REQUIRED>
  <!ATTLIST Transmission id ID #REQUIRED protocol (1 | 2) #REQUIRED 
    url CDATA #IMPLIED url_ref IDREF #IMPLIED timeout CDATA #IMPLIED prop_ref IDREF #IMPLIED>
 ]>
 <!-- idの先頭には、数字を使用できない。 --><!-- protocol：1=InProcess、2=WebService -->
 <TMD>
  <!-- マスタ データ -->
   <!-- 接続オプション（プロパティ：必要に応じて） -->
   <Prop id="prop_a" value="aaa=AAA;bbb=BBB;ccc=CCC;"/>
   <!-- 接続オプション（URL：必要に応じて） -->
   <Prop id="url_a" value="http://xxx/Service.asmx "/>
 
  <!-- 接続先 データ -->
   <!-- インプロセス -->
   <Transmission id="testInProcess" protocol="1"/>
   <!-- Webサービス -->
   <Transmission id="testWebSrv1" protocol="2" url="http://xxx/Service.asmx" timeout="60" />
   <Transmission id="testWebSrv2" protocol="2" url_ref="url_a" timeout="60" prop_ref="prop_a" />
 </TMD>

-呼び出しモジュール（アセンブリ、クラス）への名前解決を行う、~
「インプロセス名前解決サービス」 （InProcessNameService）
 <?xml version="1.0" encoding="utf-8" ?>
 <!DOCTYPE TMD[
   <!ELEMENT TMD (Transmission*)> <!ELEMENT Transmission EMPTY>
   <!ATTLIST Transmission id ID #REQUIRED assemblyName CDATA #REQUIRED className CDATA #REQUIRED>
 ]>
 <!-- idの先頭には、数字を使用できない。 -->
 <TMD>
   <Transmission id="testInProcess" assemblyName="WSServer_sample"
                 className="WSServer_sample.Business.LayerB" />
   <Transmission id="testWebService" assemblyName="WSServer_sample"
                 className="WSServer_sample.Business.LayerB" />
 </TMD>

の２つのモジュールが存在する。

上記の２つの名前解決定義は、app.configにパスを指定する。

-FxXMLTMProtocolDefinitionパラメタには、~
「呼び出し先（プロトコル、アドレス）」の名前解決定義

-FxXMLTMInProcessDefinitionパラメタには、~「呼び出しモジュール（アセンブリ、クラス）」の名前解決定義

***例外処理 [#w1e9c318]
例外については、全ての例外がシリアル化可能になっていないので、異常系の例外の型情報として、~
「業務例外」、「システム例外」、「フレームワーク例外」、「その他、一般的な例外」の４つを識別し、~
正常系の戻り値で返す（このため、一部データ欠損が発生する）。クライアントでは、この型で復元、リスローする。
-業務例外（BusinessApplicationException）は正常系で返す（クライアント側で復元しない）。
-システム例外（BusinessSystemException）は正常系で返す（クライアント側で復元）。
-フレームワーク例外（FrameworkException）は正常系で返す（クライアント側で復元）。
-その他、一般的な例外（Exception）は正常系で返す（クライアント側で復元）。

**サポートする通信テクノロジ [#se3ed231]

***インプロセス呼び出し [#k04ccda3]
レイトバインドを使用したインプロセスのメソッド呼び出し。

***ASP.NET Web Service [#zf25f1cf]
-HTTP
--SOAP 1.1 & 1.2

***WCF [#z0d0989f]

-HTTP

--basicHttpBinding~
---WS-I Basic Profile 1.1 に準拠

--wsHttpBinding~
---WS-ReliableMessaging、WS-Security を実装します。
---メッセージ エンコーディングは Text/XML エンコーディング

-TCP
--netTcpBinding
---メッセージ セキュリティと認証用 Windows セキュリティ
---メッセージ配信用 TCP、およびバイナリ メッセージ エンコーディング

-Bindingの設定例~
https://github.com/OpenTouryoProject/OpenTouryo/blob/develop/root/programs/C%23/Samples/WebApp_sample/ProjectX_sample/web.config#L318
https://github.com/OpenTouryoProject/OpenTouryo/blob/develop/root/programs/CS/Samples/WebApp_sample/WebForms_Sample/WebForms_Sample/Web.config#L318

***ASP.NET Web API [#ge9aa975]
対応未定。

*特徴 [#m143ed95]
**位置透過性 [#z3628924]
**透過性 [#l921963c]
http://www.slideshare.net/daisukenishino/open-0150/9

***位置透過性 [#z3628924]
定義による呼び出し先の変更が可能。
-インプロセス呼び出し
-リモート呼び出し（アドレス指定）

**規模透過性 [#a84e62cf]
***規模透過性 [#a84e62cf]
スケールアウト（垂直・水平分散）が可能。

**異種透過性 [#b5ff466d]
***異種透過性 [#b5ff466d]
.NET以外の異種開発技術との連携も可能。

汎用サービス・インターフェイスを公開することで可能になる。
別途、別途、（汎用/個別）[[サービス・インターフェイス]]を公開することで可能になる。

-SOAP~
https://github.com/OpenTouryoProject/OpenTouryo/blob/develop/root/programs/C%23/Samples/WS_sample/WSClient_sample/WSClientSL_samples/WSClientSL_sample.Web/App_Code/WebService/ServiceForSb.cs
*移行時 [#v4d269ae]
**バージョン、x86, 64間のバイナリ転送 [#f5772ca6]
***バージョン [#ea818437]
通信制御部品で.NETオブジェクトのバイナリ転送をしているので、~
異なる.NETバージョン間の通信に問題がないか？ですが、

-REST~
https://github.com/OpenTouryoProject/OpenTouryo/blob/develop/root/programs/C%23/Samples/WS_sample/WSClient_sample/WSClientSL_samples/WSClientSL_sample.Web/App_Code/WebService/ServiceForRt.cs
--XML
--JSON
-.NET Framework 4.5 のアプリケーションの互換性~
http://msdn.microsoft.com/ja-jp/library/hh367887(v=vs.110).aspx
--SoapFormatterクラスについては、バージョン間の互換性が保証されません。~
--代わりに、System.Runtime.Serialization.Formatters.Binary.BinaryFormatter クラス~
および System.Runtime.Serialization.NetDataContractSerializer クラスを使用してください。

-バージョン トレラントなシリアル化~
https://msdn.microsoft.com/ja-jp/library/vstudio/ms229752.aspx
--バージョン トレラントなシリアル化 (VTS: Version Tolerant Serialization) は、~
.NET Framework 2.0 で導入された機能セットで、シリアル化可能な型を、長期にわたって簡単に変更できるようにします。
--具体的には、VTS 機能が、ジェネリック型を含め、SerializableAttribute 属性が適用されているクラスに対して有効です。
--VTS を使用すると、他のバージョンの型との互換性を失うことなく、これらのクラスに新しいフィールドを追加できます。 

とあるので問題はなさそうです。

***x86, 64間 [#fcf48397]
以下にIntPtrなどを使用していなければ問題無い旨が書かれています。

- 64bit対応 - マイクロソフト系技術情報 Wiki > .NET > 100％タイプ セーフでない場合~
https://techinfoofmicrosofttech.osscons.jp/index.php?64bit%E5%AF%BE%E5%BF%9C#s6e00db1

**検証用サンプル [#baa829a0]
&ref(TestBinaryFormatter.zip);

下記、添付画像のように、x86、x64切り替えて検証しました。~
TargetFramework(.net version)を切り替えてテストしてもイイと思います。

#ref(TestBinaryFormatter.png,left,nowrap,x86、x64切り替え,50%)

WOW64上でホストされるx86のプロセスは、~
タスクマネージャー上でプロセス名の後ろに「*32」が~
付与されるので、これを確認しながらテストしてみて下さい。

*参考 [#sb715768]

**ライブラリ [#a2179a64]
https://github.com/OpenTouryoProject/OpenTouryo/tree/develop/root/programs/CS/Frameworks/Infrastructure/Framework/Transmission

**SlideShare [#g1fccd89]
-http://www.slideshare.net/daisukenishino/open-0150/6
-http://www.slideshare.net/daisukenishino/open-0150/7
-http://www.slideshare.net/daisukenishino/open-0150/8
-http://www.slideshare.net/daisukenishino/open-0150/9
通信制御機能 のバックアップの現在との差分(No.4)

通信制御機能のバックアップの現在との差分(No.4)
