2013-07-01 5 views
9

私たちは確立されたWCF SOAPサービスを持っています。そのインタフェースはWSDLで定義されており、そこからC#クラスが生成されます(顧客は同じWSDLからさまざまな言語のクライアント側のバインディングを生成します)。 WSDLには、少し変更することができる最新バージョンと、廃止予定や相談などがなければ変更や削除ができない古いバージョンがあります。SOAPリクエストは複雑で、同じリクエスト内に複数のXML名前空間を持つ傾向があります。既存のSOAPサービスと新しい角型Webアプリケーション

WCF SOAPサービスには多くの "スマート"があり、必要な新しいWebアプリケーションに必要なフェッチとレポーティング機能を提供します。 AngularJSをそのクライアント側で使用したいと考えています。しかし、これらの複雑なSOAP要求はJavaScriptの世界では容易ではありません。私たちがRESTサービスしか持っていなかったら、角度リソースサービスを使うことができました。そうでなければ、JSONを話しているサーバーはSOAPのようなRPCスタイルではあるが、かなり近い秒を実行するだろう。

私は、サーバーとクライアントの間のインピーダンスの不一致がどのように緩和されるかについて、さまざまな考えを持ってきました。しかし、すばやく簡単なものはありません。

私は考えた: -

  1. 新しいRESTサービスを書きます。クライアント側が望んでいるものとまったく同じですが、深刻な新しい開発です。
  2. WebHttpBindingは何かを提供するように見えます。しかし、カスタム属性のC#マークアップ(WSDLからC#を生成する方法)が必要で、複雑な型をサポートしていない可能性があります。
  3. 呼び出し側のJSを抽象化するために、サービス。しかし、これがWSDLから自動生成されない限り、クライアント側のコードを書くのは膨大な量です。
  4. 私が発明したいくつかのJSON形式のメッセージを受け入れるために、サーバーのIDispatchMessageFormatterを記述します。 IDispatchMessageFormatterを実装して統合する人々の良い例が来るのは難しいようです。
  5. JSONとXMLを入れ替えるMessageEncoderを作成します。しかし、これは本当にエンコード操作ではなく、私がそれを書こうとしたときに非常に明確になりました!

私は提案を探しています。

+0

? WCFサービス実装クラス(1 Webメソッド:1オペレーションコントラクト)を組み込み呼び出すWebAPIサーバーを作成し、jsonとして再パッケージ化されたデータオブジェクトを盲目的に返します(つまり、オペレーション契約の数と複雑さを考えれば実現可能ですか)。可能なはずですが、サービス操作で多型に頼っている場合、それらはJSON(AFAIK)で複製できません。 –

+0

7つのサービスと合計約50の操作があります。 – PeteAC

+0

石鹸サービスに呼び出しを委託する休憩サービスの作成についてはどうですか? –

答えて

8

通常、AngularJSの開発にはRESTサービスを推奨し、Node.js APIサーバーでは多くのレガシーシステムをラップしています。もちろん、「それは依存しています」という膨大な量がありますが、一般的に、ほとんどのプロジェクトはそのルートに従って、より幸せで生産的になります。

考えるようにいくつかのものについて

  1. どれだけあなたの現在のSOAP APIは、ユーザーインターフェイスの要件に適合していますか?
  2. Express、Sinatra、Flask、またはREST APIの迅速な開発を可能にする他のマイクロフレームワークを経験していますか?私はAngularJSアプリケーションを構築する際に、数時間で頑丈なNode.js Express APIサーバーを構築し、それを拡張することができます。
  3. AngularJSではどのような経験がありますか?複雑なデータレイヤーをクライアントサイドで構築するための、より高度なプロジェクトです。RESTは、それが$リソースと$ HTTPを使用して角度のコードを記述するためにはるかに高速ですAngularJS

    1. のために重要である理由

    6つの理由。効果的なAngularJS開発のために、APIの権利を得ることをお勧めします。実際、AngularJSはREST用に設計されていると主張できます。そのため、プレーンJavaScriptがモデルで機能する理由があります(2)。

  4. Angularの普通のJavaScriptオブジェクトデータモデルは、ユーザーインターフェイスと一致するJSONを話すREST APIでうまく機能します。しかし、Angularは正式なデータモデルを持っていないので、APIを合理化してAngularでうまく動作するように多くのコードを書くことになります。 breeze.jsのようなサードパーティ製のライブラリはいくつかの解決策を提供するかもしれませんが、それでもまだ厄介です。
  5. キャッシングを使用して簡単に拡大/縮小できます。 Redisやmemcache、Varnishなどの一般的なHTTPキャッシュソリューションを混在させるのは簡単です。リソースベースの抽象化は、REST APIの透過性と冪等性のためにキャッシュ戦略に最適です。
  6. フロントエンドとサーバーの疎結合 - SOAPを移行したり、他のサービスと統合する必要がある場合、バックエンドの変更をサポートする方が簡単になります。
  7. 一般に、AngularJSロジックとは別にJSON APIをテストする方が簡単なので、テストスイートはより簡単で効果的になります。
  8. 新しいREST APIは、将来のAngularJSおよびJSON指向のプロジェクトに役立ちます。

私は役立つことを望みます。あなたのWCFのサーバーが公開するどのように多くの操作契約(メソッド)

乾杯、 ニック

関連する問題