通信制御機能 のバックアップ(No.12)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 通信制御機能 へ行く。
  • 1 (2014-08-29 (金) 23:38:51)
  • 2 (2014-09-03 (水) 13:20:20)
  • 3 (2014-09-05 (金) 21:21:25)
  • 4 (2014-09-07 (日) 01:11:38)
  • 5 (2014-09-11 (木) 00:23:17)
  • 6 (2014-09-23 (火) 16:50:37)
  • 7 (2014-09-24 (水) 10:16:31)
  • 8 (2015-10-22 (木) 10:37:16)
  • 9 (2015-12-15 (火) 11:51:37)
  • 10 (2016-02-05 (金) 10:03:48)
  • 11 (2017-08-04 (金) 10:08:04)
  • 12 (2017-08-09 (水) 12:47:25)
  • 13 (2017-08-10 (木) 09:12:58)
  • 14 (2017-08-22 (火) 13:36:23)
  • 15 (2018-01-29 (月) 15:39:19)
  • 16 (2018-03-27 (火) 11:44:01)
  • 17 (2018-06-14 (木) 17:30:10)
  • 18 (2018-07-22 (日) 17:50:14)
  • 19 (2019-08-27 (火) 12:51:10)

---

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

• 戻る

目次 †

概要 †

通信制御機能は、

• 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/C%23/Samples/WebApp_sample/ProjectX_sample/web.config#L318

ASP.NET Web API †

対応未定。

透過性 †

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

位置透過性 †

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

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

規模透過性 †

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

異種透過性 †

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

汎用サービス・インターフェイスを公開することで可能になる。

移行時 †

通信制御部品で.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 を使用すると、他のバージョンの型との互換性を失うことなく、これらのクラスに新しいフィールドを追加できます。

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

参考 †

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

     

Site admin: OpenTouryo

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.032 sec.