ServiceLayerを使うと、既存のJavaアプリケーションにSOAPやREST形式のWebサービス・インタフェースを追加するのがポイント・アンド・クリックと同じくらい簡単に出来る上に、運用中にそれを行うことが出来る。GUIを使ってアプリケーションを探索し、サービスとしてデプロイしたいクラスとメソッドを選択するだけ。それだけで完了する。もはやコーディングは不要である。加えてWebサービスはスタンドアローンのアプリケーションにも、コンテナ・ベースのシステムにも、サード・パーティ製のプログラムにも、そしてクラス・ライブラリにも追加することが出来る。
古典的なWebサービス化の方法と比べるとServiceLayerには以下のような特徴がある。
- プロジェクトのコストと実装時間を劇的に縮める
- 高コストなプログラミングを省く
- 学習曲線を短縮する
- JAX-WS、JAXB、XML Schema、REST、JSON、その他のWebサービス関連技術といった複雑なものを習得する必要がない
InfoQは最近AgileITの創業者であり社長でもあるMark Hansen氏と話をした。
まず「どのようにしてServiceLayerのアイディアが浮かんだのですか？」という質問からインタビューを開始した。
基本的なアイディアはJavaアプリケーション向けのWebサービスを作成しデプロイするには「もっと簡単な方法があるはずだ」という私の強い信念から生まれ育ったものです。1990年代、私はKinderhook Systemsというeビジネスに関するコンサルティング・ファームを起業し成長させました。Kinderhookはフロント・エンドにあるWebページのデザインからバック・エンドの統合まで包括的な開発を行っていました。最も困難な部分というのはいつもブラウザの機能をバック・エンドと統合する部分でした。私達はこれを"サービス・レイヤ"と呼びました。これはつまりエンタープライズ・システム上に構築された一連のサービスで、フロント・エンドとの統合のために標準的なAPIを提供していました。
その会社を売却した後、私は「SOA using Java Web Services」(http://www.amazon.com/SOA-Using-Java-Web-Services/dp/0130449687)という書籍の執筆を開始しました。この本の目的は読者にJavaのWebサービス技術を使って"サービス・レイヤ"をどのように設計し構築したらいいのかを教えることでした。しかし残念ながらJAX-WS、JAXB、そしてその他のWEBサービス用のJava APIを使ってこのようなミドルウェア・レイヤを構築するのはとても難しいことであると気付きました。これらの技術はあまりに低レベルなツールで今回のタスクには向かないということが示されました。
このことはとても残念な体験でした。しかし、JavaのAPIに対して積むことの出来た深い経験によって、バイトコードの操作を通して、これらを隠して使うことが出来るということに気付きました。つまりこれらを使えば、バック・エンドにあるJavaアプリケーションやクラス・ライブラリとフロント・エンドの統合に必須となる"サービス・レイヤ"を簡単に公開するためのフレームワークを構築することが出来ると気付いたのです。その結果、1997年に私はServiceLayer製品を構築するためにAgileITを起業しました。ServiceLayerが目指すゴールはSOAPやRESTによるWebサービスの開発とデプロイをなるべくシンプルにすることです。JAX-WSのような難しいAPIの習得が必要となる複雑なプログラミングではなく、ServiceLayerを使うとWebサービスの構築とデプロイはポイント・アンド・クリックの練習のように単純になります。
異なるデータ構造を使い続けるように、異なる内製または外製のAPIを好む企業もあるが、ServiceLayerはこの問題にどのように対応しているのでしょうか。
ServiceLayerでは(管理用のGUIを使って)Webサービスとしてデプロイしたいクラスとメソッドを選択すれば、製品側が自動的にSOAPやREST経由で実行可能なエンドポイントの生成と公開を行います。WSDL（RESTの場合はWADL）も自動的に生成され選択されたクラスに対してJAX-WSやJAX-RSといった標準仕様が反映されます。一部の人々はこれを宣言的なアプローチと呼びます。または"コード・ファースト"によるアプローチとも呼ばれます。これは、Webサービスのインタフェース（WSDLなど）が背後にあるJavaクラスの構造を反映しているからです。
一部の人々はWebサービスは"コントラクト・ファースト(まず契約を決める)"の手順を踏むべきであると主張しています。つまり、最初にWSDLを記述し、次にWSDLに対するプロキシを生成した後でそのプロキシと背後にある業務的な実装をマッピングするということです。"コントラクト・ファースト"を好む人がいる理由の一つはプロキシとマッピングがWebサービスのエンドポイントと背後にある実装との間を分離するためのレイヤを形成することです。
ServiceLayerは"コントラクト・ファースト"なアプローチとの互換性があります。加えてServiceLayerを使えば"コントラクト・ファースト"を実装するためにXML SchemaやWSDLを習得する必要はありません。ServiceLayerではJavaを使ってWebサービスのインタフェースを定義し、これを既存の業務に関する実装と対応付けることが出来ます。あとはServiceLayerのポイント・アンド・クリック・インタフェースを使って完成したJava APIをデプロイするだけです。
ところが実際は、ほとんどのJavaアプリケーションには既にServiceLayerを通してWebサービスとしてデプロイするのに適したAPIを備えているということに私達は気が付きました。新しいレイヤを作る必要がないときになぜそれをつ売る必要があるのでしょうか。さらに、AgileITでは特定のフレームワークを使ったWebサービスのデプロイをどのように行ったらよいのかを判断するための機能をServiceLayerに順次追加しています。例えばServiceLayerはStrutsアプリケーションとの組み合わせにとても効果的です。Strutsがどのようにセッションやワークフローを管理しているのかを判断し、ユーザがログインし商品を選択して買い物かごに入れてから精算するようなサービスをデプロイするためには欠かせないセッションやその他のアプリケーションの状態を維持することが出来るWebサービスをStrutsアプリケーションから生成することが出来るのです。
古典的な"コントラクト・ファースト"なアプローチのもう一つの欠点は自力でWSDLを書かなければならないという点です。ほとんどのJavaプログラマがWSDLやXML Schemaには長けていないので、このことは多くの開発チームにとって大きな障壁となるでしょう。Javaを使って"分離レイヤ"を定義するというServiceLayerのアプローチは最初にWSDLを書くというアプローチよりも実践的であるということに気が付きました。さらに、Strutsに対応する機能を追加したように、引き続き私達はServiceLayerにフレームワークを理解する機能を追加していくつもりですので、これからはより多くの(Springのような)プラットフォームに対応する分離レイヤを最初から手にすることが出来るようになるでしょう。
作成されるエンドポイントはセキュアなのでしょうか。
勿論です。HTTPベーシック認証やSSLを使って暗号化したクッキーなどによりエンドポイントをセキュアにすることが出来ます。SOAPのエンドポイントに対するWebサービス・セキュリティ（WSS；旧称WS-Security）サポートは近い将来に計画されています。
Webサービスの定義はどのようにして別環境へ移行したりインテグレーション・テスト環境と統合するのでしょうか。
ServiceLayerはテスト環境で設定をしテストすることが出来ます。その後ただsl-config.xmlという名前の設定ファイルをエクスポートしてインポートするだけで運用環境への移行が完了します。例えば、qa.host.comという名のサーバでテストしているとしてhttp://qa.host.com/myapp/some-soap-endpointというエンドポイントをデプロイしている場合、sl-config.xmlをhost.comというサーバにある運用環境にインストールされたServiceLayerにロードするだけで、同じエンドポイントがhttp://host.com/myapp/some-soap-endpointというアドレスでデプロイされるのです。
SLは（エンドポイントを）デプロイする全てのJVMにインストールする必要があるのでしょうか。またスケール・アウト／スケール・アップにはどうしたらよいのでしょうか。
全てのJVMに必要なのはServiceLayerの"SL-Provider"というコンポーネントだけになります。SL-ProviderはServiceLayerのサーブレット・コンポーネントでSOAPやRESTのメッセージを送受信し、背後にありWebサービス化の対象となるJavaアプリケーションやクラス・ライブラリへ処理を委譲するものです。(SOAPやRESTによる要求メッセージをJavaメソッドの引数に変換したり、逆にJavaの戻り値をSOAPやRESTの応答に変換するといった)全てのシリアライズ／デシリアライズ処理は"SL-Serializer"という別のコンポーネントで行われます。一つのSL-Serializerは複数のJVM間で共有可能です。このアーキテクチャは多くの利点をもたらします。
- ServiceLayerを実行するには（JAX-WSやJAXB、さらには古典的なJavaによるWebサービスの場合には必須であったアノテーションすらサポートしていない）Java 1.4.2が必要です。なぜならSL-ProviderコンポーネントがJava 1.4.2上で実行されるからです。SL-Serializerコンポーネントを別のバージョン（1.5移行）のJVMで実行することでこれを可能にしています。
- CPUやメモリを酷使するシリアライズ／デシリアライズ処理はWebサービス化するアプリケーションが稼働しているJVMの外で行わせることが出来ます。この結果、Webサービス化するJavaアプリケーションの性能やリソース消費量に与える影響はとても小さなものになります。
- ServiceLayerには高い拡張性があります。SL-ProviderのインストールがJVMのリソースに与える影響は最小限です。一つのSL-Serializerインスタンスを複数のSL-Providerインスタンス間で共有することができる上、必要に応じて好きなだけSL-Serializerインスタンスを追加する（あるいは一つのSL-Providerインスタンスに割り当てるメモリやCPUを追加する）ことが出来ます。
これまでに産業界からはどのような反応があったのでしょうか。
これまでの反応はとても熱心なものです。私達が話をした多くのJavaアプリケーション開発者やアーキテクトが既存のJavaプログラムやクラス・ライブラリにWebサービスとしてアクセスする口をより簡単に提供することに興味を持っています。"コーディング不要"というアプローチが特に人気のようです。とりわけソース・コードが手に入らなかったり、元々の開発チームが解散してしまったりしたアプリケーションの責任者に人気があるようです。このような状況ではそれらのアプリケーションをWebサービス化するためのコードを書くために新しいチームを立ち上げるには多くのコストと時間がかかります。その他の分野では企業内の（カスタマー・サポートのような）アプリケーションを顧客やビジネス・パートナー向けに公開し、Webからのアクセスやインターネット越しのシステム統合をする必要がある企業が大変な興味を示しています。
ServiceLayerに関するより詳細な情報はAgileITのWebサイト(リンク)で見つかるだろう。またServiceLayerをテストするにはhttp://agileitinc.com/downloadを見ればよい。さらに既存のJavaアプリケーションをWebサービス化する様子もビデオ(リンク)で公開されている。