「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>機能一覧 - フレームワーク]] *目次 [#oe1075ce] #contents *概要 [#h386f2a1] 通信制御機能は、 -C/S3層、Web3層システム開発で必要となるサービス インターフェイス / サービス ゲートウェイ基盤を提供する。 -分散オブジェクト的な機能をHTTP, TCP/IPなどの通信プロトコルを使用して実現できる。 -.NET以外の異種開発技術との連携も別途、(汎用/個別)[[サービス・インターフェイス]]を公開することで可能になる。 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] -「サービス論理名」をキーにして、呼び出し先プロトコルへの名前解決を行う。 -プロトコル = インプロセス呼び出しの場合、 ++呼び出しモジュール(アセンブリ、クラス)への名前解決を行う。 ++レイトバインドを使用して、B層の既定のメソッドを呼出す。~ ++レイトバインド時の例外処理を実行する。~ 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> の2つのモジュールが存在する。 上記の2つの名前解決定義は、app.configにパスを指定する。 -FxXMLTMProtocolDefinitionパラメタには、~ 「呼び出し先(プロトコル、アドレス)」の名前解決定義 -FxXMLTMInProcessDefinitionパラメタには、~「呼び出しモジュール(アセンブリ、クラス)」の名前解決定義 ***例外処理 [#w1e9c318] 例外については、全ての例外がシリアル化可能になっていないので、異常系の例外の型情報として、~ 「業務例外」、「システム例外」、「フレームワーク例外」、「その他、一般的な例外」の4つを識別し、~ 正常系の戻り値で返す(このため、一部データ欠損が発生する)。クライアントでは、この型で復元、リスローする。 -業務例外(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/WebForms_Sample/WebForms_Sample/Web.config#L318 ***ASP.NET Web API [#ge9aa975] 対応未定。 **透過性 [#l921963c] http://www.slideshare.net/daisukenishino/open-0150/9 ***位置透過性 [#z3628924] 定義による呼び出し先の変更が可能。 -インプロセス呼び出し -リモート呼び出し(アドレス指定) ***規模透過性 [#a84e62cf] スケールアウト(垂直・水平分散)が可能。 ***異種透過性 [#b5ff466d] .NET以外の異種開発技術との連携も可能。 別途、別途、(汎用/個別)[[サービス・インターフェイス]]を公開することで可能になる。 *移行時 [#v4d269ae] **バージョン、x86, 64間のバイナリ転送 [#f5772ca6] ***バージョン [#ea818437] 通信制御部品で.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間 [#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] **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