当社にはOracle Service Bus Architecture(OSB)があります。私の部門では、この OSB にいくつかのサービスを公開する必要があります。この OSB は、後でさまざまな部門やテクノロジのさまざまなアプリケーションによって使用されます。7 ~ 8 個のアプリケーションがあり、すべて Microsoft ベース (VB6、C#、SQL Server) です。私の質問は、WCF がデータベース ベースのサービスを開発するための適切なオプションであるかどうかです。OSB とうまく統合できますか? 統合の問題はありますか? このシナリオでは、どのようなベスト プラクティスと wcf のトランスポート プロトコルを使用する必要がありますか?
2 に答える
私は、トランスポートプロトコルとしてSOAP / HTTPを使用して、WCFとOSBを統合したプロジェクトの成功に携わってきました。
以前の経験から、避けるべき2つの重要なリスク:
- アーキテクチャの描写-両方のフレームワークがオーケストレーションをサポートしており、WCFにはパフォーマンス上の利点を提供できるあらゆる種類の奇妙で奇抜な機能があるため、オーケストレーションがどこにあるかを整理する必要があります。
- セキュリティの統合-両方のフレームワークが共通のセキュリティ標準の実装を提供しますが、数年前の私の経験では、それらは一緒にうまく機能しませんでした。
アプローチがデータ統合を提供するWCFであり、アクセスと実施の中心点を提供するOSB(場合によっては統合とともに)である場合、それは素晴らしいことです。それは砂の中の明確な線です。
私はケビンの答えに同意します。私が見た限りでは、WCF は Microsoft 製品ではうまく機能しますが、他の製品ではうまく機能しません。WCF サービスの実装をごく普通の状態に保ち、面倒な作業 (セキュリティ、ポリシー、アドレス指定など) をすべて OSB に任せれば、問題ないかもしれません。
注意すべきもう 1 つの落とし穴は、WCF が XML 型をネイティブの .NET 型にバインドしているように見えることです。これはほとんどのタイプで問題ありませんが、頭痛の種の 1 つは日付でした。XML では日付を null にすることができますが、.NET では日付はオブジェクトではなくプリミティブ型であるため、null にしようとすると死んでしまいます。これらを文字列 (yuk) として処理し、アプリケーションで変換することでこれを回避できます。または、日付型を DateWrapper オブジェクトでラップして null に対応できるカスタム バインディングを作成することもできると思います。 .
個人的には、サービス バスのモデルが、別の場所でホストされる実装の単なるファサードであることを好みます。そのため、その観点から、OSB 公開サービスの裏でどのようなテクノロジが使用されるかは問題ではないと思います。
- WCF の機能が気に入っていて、アプリとうまく統合されているという理由で WCF を使用したい場合は、それを選択してください。
- それがすべてサービスに関するものであり、OSB に適していると思われるという理由だけでそれを選択している場合は、おそらく、あなたと開発チームのオーバーヘッドが少ない他の選択肢がないかどうかを確認してください。
トランスポートに関しては、データ サービスがトランザクション以外の方法でデータにアクセスする場合 (顧客の詳細を取得するなど) は、SOAP/HTTP で問題ありません。トランザクション データを扱っている場合は、JMS や MQ などのメッセージング ベースのトランスポートを検討してください。これは、経験上、WS-ReliableMessaging のサポートがまだどこでも、または一貫して行われていないためです。
それが役立つことを願っています。