サービス指向アプリケーションのコンポーネントを構成するためのオプション

Question

私は複数の異なる言語とアーキテクチャスタイルでコーディングするポリゴン構成のために働いています。

私は約2年前からサービスオリエンテッドアプリケーションを作成しています。私はこれまでのやり方に慣れてきましたが、それが問題です。

大きなSOAレベルでは、SOA原則を使用してソリューション/エンタープライズのさまざまな部分を接続する方法にすべて同意します。

コンポーネントレベルでは、すべてが少し異なります。

現在、SOAへのサービスアプローチとして、すべての上位コンポーネントを使用して、機能駆動型インターフェイスとソフトウェアの要塞を優先しています。 implemenation beanまたはwcfサービスでパターンは変更されません。ファサードの下に標準クラスの豊富なドメインモデルのための私の組織のオプトではそう、SOA Design Pattern

他のような

。 SOAP、RESTなどのアーキテクチャスタイルは、このレベルで両方使用されています。

また、メソッド呼び出しのスタイルが異なります。コマンドスタイルのメッセージと、よりアクティビティを記述するメッセージです。

どちらも使いましたが、私の質問には他のエンジニアがSOAを構成するための方法があります。

私は、SOAを構築するというトピックに関する新しい考え方を刺激するために、どんなに不気味なのか、新しいアイデアに集中しています。

Answer 1

私はしばらくして、SoaKitというコンポーネントベースのSOAへのアプローチを参考にして参考にしました。根拠については、http://bradjcox.blogspot.comを参照してください。

基本的な考え方は、ツールベースのアプローチ（JAX-WS）では、あらかじめ構築されたコンポーネント（SoaKitによって提供されている）を使用して、それぞれが必要とする機能を実行し、仕事全体。コンポーネントの例：SAML署名付きヘッダー、メッセージパーツの復号化/暗号化、XSLT/XQUERY変換などを追加します。各コンポーネントは個別に構成可能です。

企業が都市の場合、サービスはその都市の家であり、SoaKitコンポーネントは家を建てるためのレンガです。ブログには、今日よく使われている泥煉瓦のアプローチとは対照的な記事があります。この類推は、ローマのレンガ造りの建築が建築にもたらした影響を引き起し、同じ影響をソフトウェアにもたらすことを目指すことです。

この概念が役立つことを願っています。世界がモノリシックな魔法のプッシュボタン手法（JAX-WS）で制御や理解がほとんど不可能になっているように思えたため、このアイデアは棚上げされました。それは少なくともJAX-WS/MetroとWSO2の経験でした。