Java SEのWebサービス、パート1:ツールの概要

Java Standard Edition(SE)6には、Webサービスのサポートが含まれていました。この投稿では、Java SEのWebサービスとは何かを説明し、Java SEによるそれらのサポートの概要を説明することにより、JavaSEのWebサービスに関する4部構成のシリーズを開始します。今後の投稿では、このサポートを使用してSOAPベースおよびRESTfulベースのWebサービスを構築し、高度なWebサービスのトピックについても取り上げます。

JavaXMLとJSON

このシリーズでは、XMLとJSONを理解していることを前提としています。そうでない場合は、この投稿の最後に宣伝されている私のJavaXMLとJSONの本をチェックしてみてください。

Webサービスとは何ですか?

ウィキペディアでは、Webサービスを「ネットワークを介した相互運用可能なマシン間相互作用をサポートするように設計されたソフトウェアシステム」と定義しています。より詳細な定義は、最初にこの用語の部分を定義することによって取得できます。

  • Web:リソースの相互接続された巨大なネットワーク。リソースは、PDFベースのドキュメント、ビデオストリーム、Webページ、さらにはアプリケーションなど、URI(Uniform Resource Identifier)という名前のデータソースです。これらのリソースには、ハイパーテキスト転送プロトコル(HTTP)やSMTP(Simple Mail Transfer Protocol)などの標準のインターネットプロトコルを使用してアクセスできます。
  • サービス:メッセージ交換パターン(MEP)に従ってメッセージの交換を介してクライアントにリソースを公開する、サーバーベースのアプリケーションまたはソフトウェアコンポーネント。要求/応答MEPが一般的です。

これらの定義を前提とすると、Webサービスは、メッセージの交換を介してWebベースのリソースをクライアントに公開するサーバーベースのアプリケーション/ソフトウェアコンポーネントです。これらのメッセージは、Extensible Markup Language(XML)またはJavaScript Object Notation(JSON)に従ってフォーマットできます。また、これらのメッセージは、Webサービス関数を呼び出し、呼び出し結果を受け取ると考えることができます。図1は、このメッセージ交換を示しています。

図1.クライアントはWebサービスとメッセージを交換することによってリソースにアクセスします

ビジネスとWebサービス

企業がWebサービスを使用する理由は、従来のミドルウェアの問題(たとえば、取得と保守に費用がかかる、インターネット経由でバックエンドソフトウェアやクライアントアプリケーションと通信できない、柔軟性がない)を、無料でオープンな標準に基づいて、保守性に基づいて、 Web、そして柔軟性によって。さらに、大企業がレガシーソフトウェアへの多くの場合重要な投資を維持するのに役立ちます。

Webサービスは、単純または複雑に分類できます。単純なWebサービスは、他のWebサービスと相互作用しません(たとえば、指定されたタイムゾーンの現在の時刻を返す単一の関数を備えたスタンドアロンのサーバーベースのアプリケーション)。対照的に、複雑なWebサービスは他のWebサービスと相互作用することがよくあります。たとえば、一般化されたソーシャルネットワークWebサービスは、TwitterおよびFacebook Webサービスと対話して、特定の個人のすべてのTwitterおよびすべてのFacebook情報を取得してクライアントに返す場合があります。複雑なWebサービスは、複数のWebサービスからのデータをマッシュ(結合)するため、マッシュアップとも呼ばれます。

サービス指向アーキテクチャー

Webサービスは、サービス指向アーキテクチャ(SOA)の実装です。これは、ネットワークを介した通信プロトコルを介してさまざまなソフトウェアコンポーネントにサービスが提供されるソフトウェア設計のスタイルです。SOAは、進化するビジネス要件を満たすためにさまざまな方法で組み合わせることができる再利用可能なサービスとしてビジネスロジックを実装するための一連の設計原則またはフレームワークと考えてください。

SOAPベースのWebサービス

SOAPベースのWebサービスは、に基づいている、広く使用されるWebサービスカテゴリであるSOAP、定義するためのXML言語メッセージネットワーク接続の両端で理解することができる(抽象関数呼び出しまたはそれらの応答を)。SOAPメッセージの交換は操作と呼ばれ、関数呼び出しとその応答に対応します。これを図2に示します。

図2.Webサービスの操作には、入力メッセージと出力メッセージが含まれます

関連する操作は、多くの場合、Javaインターフェースに概念的に類似したインターフェースにグループ化されます。結合は、インタフェースがワイヤ上でコマンド、エラーコード、およびその他の項目を通信するメッセージングプロトコル(特にSOAP)にバインドされている方法の具体的な詳細を提供します。バインディングとネットワークアドレス(IPアドレスとポート)URIはエンドポイントと呼ばれ、エンドポイントのコレクションはWebサービスです。図3は、このアーキテクチャーを示しています。

図3.操作のインターフェースはエンドポイントを介してアクセス可能

SOAPは、Webサービスの操作を定義するためのXML言語であるWebサービス記述言語(WSDL、whiz-dullと発音)でよく使用されますWSDL文書は、Webサービスと対話するためのすべての詳細を提供する、SOAPベースのWebサービスとそのクライアントの間の正式な契約です。このドキュメントでは、メッセージを操作にグループ化し、操作をインターフェイスにグループ化できます。また、各インターフェイスのバインディングとエンドポイントアドレスを定義することもできます。

WSDLドキュメントをサポートするだけでなく、SOAPベースのWebサービスには次のプロパティがあります。

  • セキュリティやトランザクションなどの複雑な非機能要件に対処する機能:これらの要件は、さまざまな仕様を通じて利用可能になります。これらの仕様間の相互運用性を促進するために、Web Services Interoperability Organization(WS-I)(業界コンソーシアム)が設立されました。WS-Iは、一連のプロファイルを確立しました。プロファイルは、特定のリビジョンレベルの名前付きWebサービス仕様のセットであり、相互運用可能なWebサービスを開発するために仕様を使用する方法を推奨する一連の実装および相互運用性ガイドラインがあります。たとえば、最初のプロファイルであるWS-I Basic Profile 1.0は、次の非独占的なWebサービス仕様のセットで構成されています。
  • SOAP 1.1
  • WSDL 1.1
  • Universal Description Discovery and Integration(UDDI)2.0
  • XML 1.0(第2版)
  • XMLスキーマパート1:構造
  • XMLスキーマパート2:データ型
  • RFC2246:トランスポート層セキュリティプロトコルバージョン1.0
  • RFC2459:インターネットX.509公開鍵インフラストラクチャ証明書とCRLプロファイル
  • RFC2616:ハイパーテキスト転送プロトコル1.1
  • RFC2818:HTTP over TLS
  • RFC2965:HTTP状態管理メカニズム
  • Secure Sockets LayerProtocolバージョン3.0

追加のプロファイルの例には、WS-I基本セキュリティプロファイルと単純なSOAPバインディングプロファイルが含まれます。これらおよびその他のプロファイルの詳細については、WS-IWebサイトにアクセスしてください。Java SEは、WS-I基本プロファイルをサポートします。

  • Webサービスと非同期で対話する機能: Webサービスクライアントは、非ブロッキング、非同期の方法でWebサービスと対話できる必要があります。Webサービス操作のクライアント側非同期呼び出しサポートは、JavaSEで提供されます。

SOAPベースのWebサービスは、サービスリクエスター(クライアント)、サービスプロバイダー、およびサービスブローカーを含む環境で実行されます。この環境を図4に示します。

図4.SOAPベースのWebサービスには、サービスリクエスター、サービスプロバイダー、およびサービスブローカー(UDDIなど)が含まれます。

サービスリクエスター、通常はクライアントアプリケーション(Webブラウザーなど)、またはおそらく別のWebサービスは、最初に何らかの方法でサービスプロバイダーを見つけます。たとえば、サービスリクエスターはWSDLドキュメントをサービスブローカーに送信し、サービスブローカーはサービスプロバイダーの場所を識別する別のWSDLドキュメントで応答します。次に、サービスリクエスターはSOAPメッセージを介してサービスプロバイダーと通信します。

サービスプロバイダーは、他の人が見つけて使用できるように公開する必要があります。 2000年8月、Universal Description、Discovery、and Integration(UDDI)と呼ばれるオープンな業界イニシアチブが開始され、企業はサービスリストを公開し、お互いを発見し、サービスまたはソフトウェアアプリケーションがインターネット上でどのように相互作用するかを定義できるようになりました。ただし、このプラットフォームに依存しないXMLベースのレジストリは広く採用されておらず、現在は使用されていません。多くの開発者は、UDDIが非常に複雑で機能が不足していることに気付き、Webサイトで情報を公開するなどの代替手段を選択しました。たとえば、Googleはかつて公開Webサービス(Googleマップなど)を//code.google.com/more/で利用できるようにしました。

サービスリクエスターとサービスプロバイダーの間を流れるSOAPメッセージは、多くの場合、見えず、WebサービスプロトコルスタックのSOAPライブラリ間で要求と応答として渡されます。ただし、このシリーズの後半で説明するように、これらのメッセージに直接アクセスすることは可能です。

ビッグWebサービス

SOAPベースのWebサービスは、前述のWS-Iプロファイルなど、多くの仕様に基づいているため、ビッグWebサービスとも呼ばれます。

RESTfulWebサービス

SOAPベースのWebサービスは、HTTP、SMTP、FTP、Blocks Extensible Exchange Protocol(BEEP)などのプロトコルを介して提供できます。HTTPを介したSOAPメッセージの配信は、特別な種類のRESTfulWebサービスと見なすことができます。

A RESTfulなWebサービスは、に基づいています広く使われているWebサービスのカテゴリでのRepresentational State Transfer(REST)の分散のためのソフトウェアアーキテクチャのスタイル、ハイパーメディアシステム(画像、テキスト、およびその他のリソースがネットワークの周りに位置し、ハイパーリンクを経由してアクセス可能ですされているシステム) 。Webサービスのコンテキストで関心のあるハイパーメディアシステムは、ワールドワイドウェブです。

REST履歴

Roy Fielding(HTTP仕様バージョン1.0および1.1の主な著者であり、Apache Software Foundationの共同創設者)は、2000年に博士論文でRESTを導入および定義しました。FieldingはRESTをWebのアーキテクチャスタイルとして想定していましたが、 Webが懸念されてからずっと後のことです。RESTは、SOAPベースのWebサービスの複雑さが増していると考えられているものに対するソリューションと広く見なされています。

RESTの中心的な部分は、URIで識別可能なリソースです。RESTは、多目的インターネットメール拡張機能(MIME)タイプ(text / xmlなど)によってリソースを識別します。また、リソースには、その表現によってキャプチャされる状態があります。クライアントがRESTfulWebサービスからリソースを要求すると、サービスはリソースのMIMEタイプの表現をクライアントに送信します。

クライアントは、HTTPのPOST、GET、PUT、およびDELETE動詞を使用して、リソース表現を取得し、リソースを操作します。RESTは、次のように、これらの動詞をデータベースの作成、読み取り、更新、および削除(CRUD)操作にマップします。

  • POST:リクエストデータに基づいて新しいリソースを作成します。
  • GET:副作用を発生させずに既存のリソースを読み取ります(リソースを変更しないでください)。
  • PUT:既存のリソースをリクエストデータで更新します。
  • 削除:既存のリソースを削除します。

各動詞の後には、リソースを識別するURIが続きます。(この非常に単純なアプローチは、エンコードされたメッセージを単一のリソースに送信するSOAPのアプローチと基本的に互換性がありません。)URIは、などのコレクション//javajeff.ca/library、またはなどのコレクションの要素を参照する場合があります//javajeff.ca/library/9781484219157。これらのURIは単なる説明です。

POSTおよびPUTリクエストの場合、XMLベースのリソースデータがリクエストの本文として渡されます。たとえば、あなたが解釈可能性がありPOST //javajeff.ca/library HTTP/ 1.1(ここで、HTTP/ 1.1挿入するための要求として要求者のHTTPのバージョンを記述する)POSTへのXMLデータを//javajeff.ca/library収集リソース。

GETおよびDELETE要求の場合、データは通常、クエリ文字列として渡されます。クエリ文字列は、URIの?文字で始まる部分です。たとえばGET //javajeff.ca/librarylibraryリソース内のすべての書籍の識別子のリストを返す可能性がある場合、GET //javajeff.ca/library?isbn=9781484219157クエリ文字列が国際標準図書番号(ISBN)を識別する書籍リソースの表現を返す可能性があります9781484219157

HTTP-CRUDマッピングの詳細

HTTP動詞とそれに対応するCRUDの間のマッピングの詳細については、ウィキペディアのRepresentational StateTransferエントリの「RESTfulWebサービスHTTPメソッド」の表を確認してください。

RESTは、MIMEタイプ(リソース表現が取得されている場合)とともに、404(要求されたリソースが見つかりません)や200(リソース操作が成功した)などのHTTPの標準応答コードにも依存します。

RESTfulと大きなWebサービス

SOAPとRESTのどちらを使用してWebサービスを開発するかについて疑問がある場合は、RESTful Webサービスと「ビッグ」Webサービス:適切なアーキテクチャ上の決定を行うを確認してください。

JavaSEでのWebサービスのサポート

Java SE 6より前は、JavaベースのWebサービスはJava Enterprise Edition(EE)SDKのみを使用して開発されていました。実稼働の観点からWebサービスを開発するには、Java EEが推奨されますが、Java EEベースのサーバーは非常に高度なスケーラビリティ、セキュリティインフラストラクチャ、監視機能などを提供するため、JavaEEへのWebサービスの繰り返し展開コンテナは多くの場合時間がかかり、開発が遅くなります。Java SE 6は、API、注釈、ツール、および軽量HTTPサーバー(Webサービスを単純​​なWebサーバーにデプロイし、この環境でテストするため)をコアに追加することにより、Webサービス開発を簡素化および加速しました。

API

Java SEは、WebサービスをサポートするいくつかのAPIを提供します。JavaXMLおよびJSONで説明するさまざまなJAXPAPI(SAX、DOM、StAXなど)に加えて、Java SEはJAX-WS、JAXB、およびSAAJAPIを提供します。