通信制御機能

「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

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

目次 †

概要 †

通信制御機能は、

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

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

特徴 †

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

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

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

詳細 †

方式 †

リモート呼出し †

下記は、Webサービスをプロトコルに使用する場合の例であり、

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

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

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

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

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

インプロセス呼出し †

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

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

構成要素 †

サービス ゲートウェイ †

• 「サービス論理名」をキーにして、呼び出し先プロトコルへの名前解決を行う。

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

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

サービス インターフェイス †

各プロトコルにおけるテンプレートを使用して実装する
（TCP/IP、RPC、Webサービス、WCFなどがある）。

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

名前解決機能 †

名前解決機能として、

• プロトコル、アドレスへの名前解決を行う、
  「プロトコル名前解決サービス」 （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?パラメタには、~「呼び出しモジュール（アセンブリ、クラス）」の名前解決定義

例外処理 †

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

• 業務例外（BusinessApplicationException?）は正常系で返す（クライアント側で復元しない）。
• システム例外（BusinessSystemException?）は正常系で返す（クライアント側で復元）。
• フレームワーク例外（FrameworkException?）は正常系で返す（クライアント側で復元）。
• その他、一般的な例外（Exception）は正常系で返す（クライアント側で復元）。

サポートする通信テクノロジ †

インプロセス呼び出し †

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

ASP.NET Web Service †

• HTTP
  • SOAP 1.1 & 1.2

WCF †

• 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/CS/Samples/WebApp_sample/WebForms_Sample/WebForms_Sample/Web.config#L318

ASP.NET Web API †

対応未定。

透過性 †

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

位置透過性 †

定義による呼び出し先の変更が可能。

• インプロセス呼び出し
• リモート呼び出し（アドレス指定）

規模透過性 †

スケールアウト（垂直・水平分散）が可能。

異種透過性 †

.NET以外の異種開発技術との連携も可能。

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

移行時 †

バージョン、x86, 64間のバイナリ転送 †

バージョン †

通信制御部品で.NETオブジェクトのバイナリ転送をしているので、
異なる.NETバージョン間の通信に問題がないか？ですが、

• .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間 †

以下にIntPtr?などを使用していなければ問題無い旨が書かれています。

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

検証用サンプル †

TestBinaryFormatter.zip

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

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

参考 †

ライブラリ †

https://github.com/OpenTouryoProject/OpenTouryo/tree/develop/root/programs/CS/Frameworks/Infrastructure/Framework/Transmission

SlideShare? †

• 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