「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のフォーマットにて情報を定義する。
- 使用するプロトコルが変われば、上記の
- 「サービス ゲートウェイ内のプロキシ」や、
- 「サービス インターフェイス」などの
通信制御基盤の実装も変わってくる。
- クライアント、サーバのユーザ プログラムには、影響を与えることはない。
通信制御基盤は、要件に合わせて、追加実装することが可能である。
インプロセス呼出し †
クライアント プログラムからネットワークを経由しないで
「インプロセス呼出し」をする場合は、以下のような処理方式となる。
- 「インプロセス呼出し」の場合、使用するプロトコルは、「インプロセス」に解決される。
- この場合、実際に使用する「サービス ゲートウェイ内のプロキシ」には、
「サービス インターフェイス」上で使用されたものと同じ「インプロセス呼び出し」用のプロキシが使用される。
構成要素 †
サービス ゲートウェイ †
- 「サービス論理名」をキーにして、呼び出し先プロトコルへの名前解決を行う。
- プロトコル = インプロセス呼び出しの場合、
- 呼び出しモジュール(アセンブリ、クラス)への名前解決を行う。
- レイトバインドを使用して、B層の既定のメソッドを呼出す。
- レイトバインド時の例外処理を実行する。
TargetInvocationException?をハンドルしInnerException?をリスローする。
- プロトコル = インプロセス呼び出し以外の場合、
- 呼び出し先アドレスへの名前解決を行う
このコードブロックはクライアントAPIのタイプ毎に用意すると良いと考える。
- 呼び出しには、プロトコル指定のプロキシを使用する。
- 引数オブジェクトから、バイト配列へシリアライズする。
- タイムアウト、認証情報、HTTPプロキシ(ゲートウェイ).etcなど、オプション設定を行う。
- プロキシを使用した同期呼出し ~ 戻り値の受け取り。
- 引数のバイト配列から、引数オブジェクトへデシリアライズする。
- タイプ別の例外処理を実行する。
サービス インターフェイス †
各プロトコルにおけるテンプレートを使用して実装する
(TCP/IP、RPC、Webサービス、WCFなどがある)。
- 「サービス論理名」をキーにして、
呼び出しモジュール(アセンブリ、クラス)への名前解決を行う。
- 引数のバイト配列から、引数オブジェクトへデシリアライズする。
なお、この際、必要になる型情報は、サービス インターフェイスの
ローカルに配置しておくことで自動的に取り込むことができる。
- 前述と同様、
- インプロセス呼び出しを行う。
- タイプ別の例外処理を実行する。
- サービス ゲートウェイに結果を返す。
名前解決機能 †
名前解決機能として、
- プロトコル、アドレスへの名前解決を行う、
「プロトコル名前解決サービス」 (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>
の2つのモジュールが存在する。
上記の2つの名前解決定義は、app.configにパスを指定する。
- FxXMLTMProtocolDefinition?パラメタには、
「呼び出し先(プロトコル、アドレス)」の名前解決定義
- FxXMLTMInProcessDefinition?パラメタには、~「呼び出しモジュール(アセンブリ、クラス)」の名前解決定義
例外処理 †
例外については、全ての例外がシリアル化可能になっていないので、異常系の例外の型情報として、
「業務例外」、「システム例外」、「フレームワーク例外」、「その他、一般的な例外」の4つを識別し、
正常系の戻り値で返す(このため、一部データ欠損が発生する)。クライアントでは、この型で復元、リスローする。
- 業務例外(BusinessApplicationException?)は正常系で返す(クライアント側で復元しない)。
- システム例外(BusinessSystemException?)は正常系で返す(クライアント側で復元)。
- フレームワーク例外(FrameworkException?)は正常系で返す(クライアント側で復元)。
- その他、一般的な例外(Exception)は正常系で返す(クライアント側で復元)。
サポートする通信テクノロジ †
インプロセス呼び出し †
レイトバインドを使用したインプロセスのメソッド呼び出し。
ASP.NET Web Service †
WCF †
- 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バージョン間の通信に問題がないか?ですが、
- バージョン トレラントなシリアル化
https://msdn.microsoft.com/ja-jp/library/vstudio/ms229752.aspx
- バージョン トレラントなシリアル化 (VTS: Version Tolerant Serialization) は、
.NET Framework 2.0 で導入された機能セットで、シリアル化可能な型を、長期にわたって簡単に変更できるようにします。
- 具体的には、VTS 機能が、ジェネリック型を含め、SerializableAttribute? 属性が適用されているクラスに対して有効です。
- VTS を使用すると、他のバージョンの型との互換性を失うことなく、これらのクラスに新しいフィールドを追加できます。
とあるので問題はなさそうです。
x86, 64間 †
以下にIntPtr?などを使用していなければ問題無い旨が書かれています。
検証用サンプル †
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? †