IIS + .NET + Json。 アプリケーションサーバーを書く

この記事では、アプリケーションサーバーがさまざまなクライアントとやり取りするものについてのビジョンと、.NETでそれを実現する方法について説明しようとしました。 記事の過負荷を避けるために、実装の詳細には触れないようにしましたが、主な考えはあなたの興味を引くと思います。



それでは、アプリケーションサーバーとは正確には何ですか？



私は自分の言葉でそれを定式化しようとします。

-「アプリケーションサーバー」は、分散N層システムのアーキテクチャに関連する用語の1つであり、中央の場所を占め、データの処理と受信の要求を満たし、このデータを保存するクライアント間に配置されます。

-アプリケーションサーバーは、サーバー側で動作する特別なアーキテクチャとテクノロジーに基づくソフトウェアです。 特異性は、その数とタイプの多様性の両方の点で多くの顧客にサービスを提供することにあります。

-アプリケーションサーバーは、クライアントからの受信とクライアントへの送信の両方で、特定の形式のデータの必要な処理と変換を実行します。

-アプリケーションサーバーはアプリケーションレベルのAPIを提供し、そのメソッドを使用して特定のクライアントアプリケーションを実装できます。



このプロジェクトの背景はこれでした。

Windows用のシック.NETクライアントに加えて、新しいMicrosoft Windows Communication Faundationテクノロジー（以下、単にWCFと呼びます）に基づく次のアプリケーションを何らかの形で開発し、このサービス用のWebインターフェイスを作成したいという要望がありました。 ExtJsはマスタリング用に選択されました。 「AjaxクライアントをWCFサービスに接続する方法」というトピックに関する小さな資料をグーグルで調べ、最初のドラフトが作成されました。 レイアウトは機能しましたが、それでも一見基本的なことを達成する方法に不満が生じ始めました。 一見したところ、あまりにも多くの「不必要なこと」を行う必要がありましたが、実際には単に必要でした。



もう少し歴史。

WCFでの実務経験といくつかの成功したプロジェクトがありました。 O'Reillyのあるスマートブックでは、サービスインターフェースで多くのメソッドを作成しないことを推奨しました（12を超えない+-）。 このことから、そしてサービスのための多くの異なるメソッドを持っているという本当の必要性から進んで、1つのメインの実行可能なメソッドと必要に応じていくつかの追加のメソッドを作るという決定は進化しました。 なぜなら 当時はサービスの.NETクライアントのみでした。このメインメソッドは、呼び出されたメソッドの名前と、BinaryFormatterによってシリアル化されたパラメーター、およびメソッドが外部アセンブリにある場合はAssemblyQualifiedNameを受け入れました。

しかし、このようなソリューションはWebクライアントと完全に互換性がなく、サービスインターフェイスに実装された「フラットな」メソッドに戻る必要がありました。

MTOMのサポートにもかかわらず、ストリームの操作時に問題が発生しました。 WCFにプロキシサーバーを介して通常ストリームを渡すことができませんでした。

WCF + Ajaxバンドルのもう1つの問題は、Jsonシリアル化です。 まあ、それはとても簡単に見えました、いいえ、そしてここではそのニュアンスの多くが形成されました。

さらに、WCFベースのソリューションを実装したクライアントは、多くの場合、サーバーに.NET 3.5 SP1をインストールする際に問題が発生することが慣例により示されています。 フレームワーク自体がインストールされていない場合、.svcが登録されていない場合がほとんどです。

少しずつ、静かに、WCFは気に入らなくなりました。



そしてその間、よく知られているソーシャルネットワーク、Webプロジェクト、さまざまなApp Storeのサービスがインターネット上でどのように機能するかについて、考えはいまだに忘れられませんでした。 結局のところ、単一のphpではありません。 これがWindowsではないことは明らかですが、それがポイントではありません。 結論として、これらのサービスはさまざまなタイプの顧客にデータを提供します。 1つのサービス-多くの異なるクライアント、これは現代では「クール」で「重要」ですが、.NETでこれを行う方法は？



.NET 2.0の.asmx WebServiceを使用してみることにしました。さらに、.NET 3.5では、Ajaxの世界とやり取りできる拡張機能を導入しました。 すぐに言いますが、何かが起こったが、そうではなかったが、それでもこれらのXML Webサービスの拡張機能と追加機能はすべて「ネイティブ」ではなく「手に負えない」感じがした。



WCFとWebServiceテクノロジーはWeb 2.0の実装にまったく適していないとは言いたくありませんが、繰り返します-直感的に行われたように思われたことが、たまにやめたいような「誤解」を引き起こしました。 単純なものの実装は何らかの形で複雑に思われ、いくつかのことは完全に不可能でした。

ここでは、開発プロセス中に発生した不快な瞬間のリストを与えることができますが、正直に言うと、今では、すべてがエレガントでシンプルになった後、私も覚えていません。



では、目標を達成するのに適した.NETのようなものがあるべきでしょうか？ 私たちの救いはSystem.NetとSystem.Webです。

そして、IHttpHandlerを選択します。



HttpRequestとHttpResponseでHttpContextを見てください。 彼らはWebengineからのHttpプロトコルの低レベルの詳細をほぼ完全に実装し、それを銀の大皿に載せました。 「青い境界線」しか描くことができません。

/// <summary> /// Enables processing of HTTP Web requests by a custom HttpHandler. /// </summary> /// <param name="httpContext"> Http .</param> void IHttpHandler.ProcessRequest(HttpContext httpContext)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントからリクエストを受け取りました。

そして、それで何をしますか？ 答えはあなたの心が望むすべてです。 はい、はい、正確に。

もう一度、必要なものを定式化します。

1. 1つのアプリケーションサーバー-多くの種類のクライアント（.NET、Java、Web + Ajax、Silverlight、iPhone、Androidなど）。

2.任意のクライアントからアプリケーションサーバーの必要なアプリケーションメソッドを呼び出します。

3.「GET」および「POST」リクエストのサポート、すなわち Urlまたはリクエストボディを介してパラメーターを渡す。

4.クライアントに返されるメソッドのパラメーターと結果の圧縮のサポート。

5.労力をかけずに両方向のフローを処理します。

6.ソリューションのスピード、使いやすさ、非同期性、透明性、明快さ。



最初の段落を実装するときに、ほとんどすべての言語とプラットフォームに存在し、相互に互換性があり、環境の境界を越えてそれらを転送するのに適したデータ型が存在するという結論に達しました（私も発見されたアメリカ）。 「互換」という言葉を強調します これが基本的なポイントです。

文字、文字列（エンコードを考慮）、単純なデータ型（さまざまな種類の数値、ブール値）、バイト配列、およびストリーム。 通常、日付には特定の文字列表現があります。 これには、上記のデータ型のコンテナとして、配列、リスト、および辞書も含まれます。

当然の選択は、交換形式としてのJsonでした。 または、NewtonsoftのJson.NETライブラリが選択されました。



そのため、クライアントはサーバーに特定のアプリケーションメソッド（RPC）を呼び出し、サーバーから明確な回答を取得できる必要があります。 呼び出されたメソッドは、名前付きの文字列で指定されます。 メソッドにはパラメーターが必要です。 彼はそれらを正しく認識して処理しなければなりません。 柔軟性を高めるために、メソッドはサーバー自体に属するだけでなく、サーバーで使用可能な任意のアセンブリにも属することができますが、セキュリティ上の制限があります。

RESTスタイルは一般的ですが、完全に柔軟ではありません。 これは「テンプレート」スタイルです。 左右にステップすると、汎用性が失われます。 不可欠なQueryStringが残っています。



サーバーは、クライアントから次の形式の要求を受け取ります。

/service.ashx？ method = GetImage（“ DSCN2099.JPG”）



キーパラメータの名前は太字で強調表示されています。

メソッドがサービス自体に属していることは明らかです。 それを探す場所を示す他の指示はなく、リクエストされた画像の名前をパラメータとして受け取ります。 写真のある場所は、サービスの開発者としてのみ知られています。 選択するには：ファイルシステムのディレクトリ。 任意のアセンブリのリソース。 DB ランタイム描画; 外部リソースなど これは適用されたロジックです。



完全なクエリ文字列形式：

 /service.ashx？
セッション= xxxxxxxxxxxxxxxxx＆-セッションID
 class = Full AssemblyTypeName＆-「FullTypeName、AssemblyName」
 method = MethodName（パラメーター）＆-（大文字と小文字を区別するメソッド名）
 format = Json / DotNetBinary＆-データ形式（拡張可能）
 zip = on / off-メソッドの入力パラメーターが圧縮されているかどうか

パラメータのいずれかが欠落している場合、デフォルト値が使用されます。 示されなければならない唯一のものは、呼び出されたメソッドの名前です。



お客様に何を返品しますか？ クライアントアプリケーション自体に依存します。 画像がサムネイルの場合、バイトの配列が返されます。 これが大きな画像である場合は、ストリームを返すことをお勧めします。



そのため、アプリケーションサーバーは要求を受信し、それを処理（解析）し、指定されたメソッドの実行コンテキストを作成し、実行のためにメソッドを呼び出します。 メソッドは適用されたロジックを実装し、最終的に戻り結果を返します。 そして、この結果はさらにどこへ行くのでしょうか？ 空中ではありません。 そして、結果はメソッドからユニバーサルオブジェクトとしてアプリケーションサーバーコアに返されます。 次に、戻り値のタイプが分析されます。 typeof（void）の場合、それ以外の処理は行われません; Streamの場合、HttpResponseの出力ストリームにリダイレクトされます。 それ以外の場合、結果は文字列への変換のためにJsonにシリアライザーに返され、この文字列はHttpResponse-> Write（）で書き込まれます。



したがって、Http要求コンテキストにアクセスできるので、アプリケーションサーバーインフラストラクチャコアの実装を自由に選択できました。



SOAP .asmx WebServiceインフラストラクチャは、ほぼ同じ方法で実装されます。 重いが雑食性のXMLだけがあり、ここに軽くて高速なJsonがあります。 .aspxとWCFもハンドラーです。



それでは、誰のためにそれがすべて始まったのでしょうか？



.NETでは、すべてが簡単です。

ここでは、ネイティブバイナリ形式とJsonを選択できます。HttpWebResponse-> GetResponseStream（）は、アプリケーションサーバーのアプリケーションメソッド "GetImage（）"が返したのと同じストリームです。違いは、このストリームのタイプのみです。 .NET Frameworkの内部クラスの1つ。 はい、私たちには関係ありません。 それを読み取って、例えばImage.FromStream（）などにするか、単にファイルに保存することが重要です。 アプリケーションサーバーがバイナリデータの配列（バイト[]）を返した場合、これは基本的に同じです。 GetResponseStream（）以外の方法はありません。 それをこの同じ配列に変換するだけです。 このストリームをどのように処理するかは、アプリケーションサーバーが提供するアプリケーションAPIに基づいて、クライアントアプリケーションの開発者が決定します。



開発者は、クライアントメソッドとサーバーメソッドの両方と、一般的なデータ構造が存在できるアセンブリを作成します。 次に、このアセンブリはサーバー側プロジェクトに配置され、このアセンブリの名前がクライアントのリクエストに示されます。 つまり サービス自体を再コンパイルせずにビジネスロジックを追加できることがわかりました。 設計、組み立て、配置、そして出来上がり-新しい機能はすぐに利用可能になります。



アヤックス

提示されたアプリケーションサーバーのイデオロギーは、Ajaxフレームワークに基づくクライアントの実装に非常に適しています。 結局のところ、JsonはXMLよりも彼らにとってさらに大切です。

 Ext.Ajax.request({ method: 'GET', url: '/service.ashx?method=GetImageInfo(“DSCN2099.JPG”)', success: function(response, options) { var result = Ext.decode(response.responseText); }, failure: function(response, options) { ... } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー方式：

 public ImageInfo GetImageInfo(Json json) { string fileName = json.AsString; string filePath = Path.Combine(IMAGES_DIR, fileName); return new ImageInfo(filePath); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GetImageInfo（）メソッドによって返されるImageInfo構造は、Jsonシリアライザーによって次の行のようなものに変換されます。

 {
    「名前」：「DSCN2099.JPG」、
    「高さ」：1536、
    「幅」：2048、
    「PixelFormat」：137224、
    「RawFormat」：「Jpeg」、
    「Horizo​​ntalResolution」：300.0、
    「垂直解像度」：300.0、
    "ThumbImage"： "/ 9j / 4AAQSkZJRgABAQ ..."、
    「FileInfo」：{
       「FileSize」：1849625、
       「CreationTime」：「\ /日付（1246514398257 + 0400）\ /」、
       「FileAttributes」：32
    }
 }

そして、アプリケーションサーバーはそれをクライアントに送信し、そこでクライアントはjavascriptオブジェクトにデコードされます。

日付は次の呼び出しで取得できます。

 var date = Date.parseDate(result.FileInfo.CreationTime, 'M$').format('dmY h:i'),
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

およびサムネイル：

 var image = { xtype: 'box', autoEl: { tag: 'div', children: [{ tag: 'img', src: String.format('data:image/jpg;base64,{0}', result.ThumbImage) }] }, listeners: { render: function(comp) { comp.getEl().on({ dblclick: function() { var url = '/service.ashx?method=GetImage(result.Name)'; window.open(url, 'imageWindow', 'menubar=no, location=no, resizable=yes, scrollbars=yes, status=no, width=640, height=480'); }, scope: comp }); } } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

base64 ThumbImageは適切なサイズの画像に正常に変換され、それをダブルクリックすると新しいブラウザウィンドウが開き、本格的な画像が表示されます。



たとえば、このようなトリック。 スタイルシートの行。 リソースアセンブリにはアイコンがあります。

 .loading { background-image: url(/service.ashx?method=LoadIcon%28%22loading.gif%22%29) !important; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、それはこれまでのところとても良いようです。 すでに2つのクライアントがあります。



Silverlightを試してみませんか？

「厚い」.NETクライアントとの違いは、HttpWebRequestおよびHttpWebResponseに同期メトが完全に存在しないことです。 Jsonと連携するために、Silverlight用のJson.NETの実装があります。 残りはデスクトップ.N​​ETアプリケーションの場合とほぼ同じです。

アプリケーションサーバーとの対話を簡素化するために、クエリ文字列を形成して実行する特別なRequestクラスが開発されました。 HttpWebRequestとHttpWebResponseの処理をカプセル化します。

 RequestParams requestParams = new RequestParams(); requestParams.Method.Name = "GetImage(fileName)"; requestParams.Method.Params.Add("fileName", "DSCN2099"); Request request = new Request("http://localhost/AppService"); request.Execute(requestParams, Action<RequestCompletedEventArgs> onRequestCompleted);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり 要求パラメーターを準備したら、サーバーメソッドを呼び出して、コールバックメソッドで結果を処理します。 簡単になることはありません！



次の行はJavaです。

メインクラスはHttpURLConnectionで、getInputStream（）メソッドがあります。 呼び出し-.NETとの2つの違いを見つけます（名前はカウントしません）。 考え方は同じです-ヘルパークラスRequestParamsとRequestが作成されます。 RequestParamsクラスは、呼び出されたメソッドとそのパラメーターの名前であり、RequestはHttpURLConnectionを操作するためのロジックをカプセル化します。 Jsonのシリアル化には、Googleのライブラリ-Gsonが使用されます。Gsonは、Android開発にも使用できます。 Javaに対して拮抗的なプラットフォームに実装されたアプリケーションサーバーからJson形式で提供されるものはすべて、問題なく「消化」されます。 Javaがデフォルトで理解しない唯一のものは、MSからの日付形式です。 しかし、Gsonは拡張可能なライブラリであり、問​​題は簡単に解決されます。

 public class MSDateJsonSerializer implements JsonSerializer<Date> { public JsonElement serialize(Date date, Type typeOfT, JsonSerializationContext context) { return new JsonPrimitive("/Date(" + date.getTime() + ")/"); } } public class MSDateJsonDeserializer implements JsonDeserializer<Date> { public Date deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException { String jsonDateToMilliseconds = "\\/(Date\\((.*?)(\\+.*)?\\))\\/"; Pattern pattern = Pattern.compile(jsonDateToMilliseconds); Matcher matcher = pattern.matcher(json.getAsJsonPrimitive().getAsString()); String result = matcher.replaceAll("$2"); return new Date(new Long(result)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

.NETからのストリームもJavaと互換性があります（アフリカでも同様です）。

 ImageIcon icon = new ImageIcon(“http://localhost/AppService/service.ashx? method=GetImage('DSCN2099.JPG')”);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、すでに4つのクライアントがあり、AndroidアプリケーションはJavaで作成されているという事実を考慮して、5つすべてを使用しています。



クライアントの種類に実質的に制限がなく、HttpとJsonで動作するすべてのプラットフォームがアプリケーションサーバーとやり取りできることが明らかになったと思います。