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. レイトバインドを使用して、B層の既定のメソッドを呼出す。
    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>

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

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

  • FxXMLTMProtocolDefinition?パラメタには、
    「呼び出し先(プロトコル、アドレス)」の名前解決定義
  • FxXMLTMInProcessDefinition?パラメタには、~「呼び出しモジュール(アセンブリ、クラス)」の名前解決定義

例外処理

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

  • 業務例外(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、およびバイナリ メッセージ エンコーディング

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?などを使用していなければ問題無い旨が書かれています。

検証用サンプル

fileTestBinaryFormatter.zip

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

x86、x64切り替え

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

参考

ライブラリ

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

SlideShare?


添付ファイル: fileTestBinaryFormatter.zip 46件 [詳細] fileTestBinaryFormatter.png 89件 [詳細] fileCC_remote.png 71件 [詳細] fileCC_inprocess.png 64件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-07-22 (日) 17:50:14 (66d)