SOAP に基づく SOA プロジェクトに取り組んでいます。さて、私はインターネットで多くのチュートリアルを読みましたが、私はまだ同じ問題を抱えています。これはすべての記事とブログであり、Eclipse の公式ドキュメントでさえ、IDE アシスタントまたはそのような API とフレームワーク (例: JAX-WS、 CXF) を使用して Web サービスを作成し、おまけとして SOAP、WSDL、および UDDI の定義をいくつか提供しますが、SOA の仕組み、WS の公開と展開のプロセス、および C/S 要求/応答がどのように行われるかについては説明していません。リモート Web サービスを呼び出すプロセスは、これらすべてのエンティティ SOAP、WSDL、UDDI、および SOA プロジェクトに存在するその他のファイル (XML ファイルと Java ファイル) を使用して行われます。多くの電子書籍を読みましたが、まだ SOA の仕組みを理解していません。私はあなたの助けが必要です、私は本当に邪魔されて混乱しています.
2 に答える
サービス指向アーキテクチャ ( SOA )という用語にとらわれすぎないでください。これは、プログラムをさまざまな分野で再利用できる特殊なコンポーネントにする、よく知られて実践されているソフトウェア開発方法論を表すマーケティング用語に近いものです。アプリケーション。また、このソフトウェア開発方法論をビジネス プロセス モデリングに適用することを説明することもできます。ビジネス ユニットとワークフローはモジュール化され、バブルの中に存在するモノリシック プロセスではなく、個々のサービスとして見なされます。サービス指向モデリングという概念の異なるが関連するアプリケーションと呼ぶ人もいます。 .
SOA はモジュール化と多くの共通点を共有していますが、個別のコード モジュールが相互運用および統合 (つまり、うまく連携) するだけでなく、潜在的に世界中の他のすべてのコードと統合するという要件も追加します。それらは、明確に定義されたメカニズムで利用できます。
SOA の「純粋主義者」は、ソフトウェアを「SOA 準拠」にするためには、SOAP Webとして記述する必要があると言うかもしれません (注意: サービスに関する一連の規則や統治機関がないため、これは現実的なことではありません)。 WSDL をサービス、公開、および維持します。これは、あなたと実装当事者間の契約として機能し、関連するWS-* 仕様に従います。ただし、実際には、RESTやその他の軽量なモジュール化/統合/再利用アプローチは、SOA の概念とほぼ同じです。
SOA の「専門家」になりたい場合は、次の仕様のすべての単語を読んでください。
発見
メッセージング
- 石鹸 1.1
- 石鹸 1.2
- SOAP over JMS
- MTOM (メッセージ転送最適化メカニズム)
- WS-アドレッシング
メタデータ
- WSBPEL
- WSDL 1.1
- WSDL 2.0
- WADL
- WSFL
- WS ポリシー
- WS-PolicyAssertions
- WS-PolicyAttachment
- WS-MetadataExchange (WS-MEX)
安全
サービスの質
(これらは最も重要な WS-* 仕様の一部です。完全なリストはこちらを参照してください)
次に、以下の重要な SOA ブックのすべてのページをお読みください。
ただし、読み物が多すぎるため、実際にはお勧めしません。私が提案したいのは、SOA 方法論に従って独自のプログラムをコーディングする際に、これらをリファレンスとして使用し、特定の領域で次に何をすべきかについてのリファレンス マニュアルが役立つことに気付くことです。練習は完璧になり、本を読んで標準と理論についてすべてを学ぶよりも、実際の例を扱うことから多くのことを学ぶことができます. あなたが言及したように、NetBeans や Eclipse などの IDE ですぐに使用できる非常に単純な JAX-WS および JAX-RS Web サービスの例から始めてから、CXF、Axis2などの一般的な SOA フレームワークに付属するいくつかの例を試してください。またはRESTlet。
一般に、コードを書いているときは、自分のコードが次のようになっているかどうかを常に自問してください。
- 他のアプリケーションまたはドメインで再利用可能
- コア機能を内部で拡張可能にし、外部からアクセスできるようにします (特にネットワーク接続、つまりHTTPを介して) 。
- 出力データまたはメタデータを、XML、JSON、または関連する多くのデータ言語およびサブ言語のいずれかのような、解析/処理 (したがって統合) が容易な形式で提供します。
- 内部の仕組みを説明するメタデータをオンデマンドで提供できるため、統合の自動化が可能
- 可能な限り専門化され、モジュール化されています。同時に、他の同様の特殊なAPIや Web サービスが既に存在する場合は、車輪を再発明するのではなく、それらを使用することをお勧めします。
人々が使用する可能性のある質問や基準は他にもたくさんありますが、私見ではこれらが最も重要です.
SOA をあれこれのテクノロジーのセットと見なすのは間違っています。また、SOA が単なるマーケティング用語であることに同意しません。ただし、SOA は評判が悪く、マーケティングや誇大宣伝によってごちゃごちゃになっていました。
サービス指向アーキテクチャはアーキテクチャ スタイルです。アーキテクチャの青写真のように、サービスがどのように、どのようなサービスであるべきかについて制約を設定し、一連のコンポーネントを定義し、それらの相互作用を定義します。以下の図は、SOA と REST を示しています。これらはいくつかの一般的なスタイルから派生していることがわかります (たとえば、どちらもクライアント/サーバー上に構築されます) が、SOA がパイプとフィルター上に構築され、REST が構築されないさまざまなスタイルから派生していることもわかります ( RESTful SOA を構築できますが、もっと頑張らなければなりません :))
SOA はインターフェースに重点を置いています。たとえば、OO とは異なり、インターフェイスを定義する 4 つの異なるコンポーネントがあります。メッセージ、メッセージをバンドルするコントラクト、コントラクトが配信されるエンドポイント、およびコントラクトがいつどのように配信されるかを管理するポリシー。
明確に定義された境界と優れた粒度 (これは注意が必要な部分です) を備えたサービスを構築すると、ビジネス機能をより迅速に実装できる柔軟な方法でサービスを構成できます。私自身のドラムを叩いて申し訳ありませんが、SOA パターンに関する私の本の第 1章と第 10 章で、SOA と REST 対 SOA について詳しく読むことができます。