Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Louvel氏と話す機会を得ました。Restletはバージョン1.0がリリース(source)されたばかりです。311への期待、Restletの今後の計画といった内容について話を伺いました。Restletは何のためにあるのか、簡単に説明してください。Restlet(サイト・英語)はJava向けの軽量REST(source)フレームワークです。Restletは、ウェブのアーキテクチャスタイルであるRESTを採用していますので、ウェブサイトとウェブサービスが明瞭に区別されていないウェブアプリケーションを構築することができます。すべての主要なREST概念には該当するJavaクラスがあるので、RESTfulなウェブ設計とコードを頭の中でマッピングするのは簡単です。関連スポンサーコンテンツRestletは、CDDLライセンスまたはGPLライセンス(クラスパス例外を含む)のもとで配布される、オープンソースプロジェクトです。エンジン)、および拡張セットから構成されます。サーブレットAPIは1998年にリリースされ、そのコアデザインはそのときから大きく変わっていません。APIのうちの一つですが、いくつかの設計フローと制限が悩みの種でした。URIパターンとハンドラの間のマッピングは限定され、1つの設定ファイルで集中管理されます。アプリケーションの開発者が直接ソケットストリームを制御するので、NIO機能を十分に利用するようなサーブレットコンテナが、何らかのIOの最適化を行うことができません。結局、キャッシング、コンテンツネゴシエーション、コンテンツの圧縮といったHTTP機能を十分にサポートしないため、結果として開発者が非常に苦しむことになり、アプリケーション固有のコードに集中することができません。HTTPクライアントAPIが欠落していたことです。JDKのHttpURLConnectionクラスは使うのが難しく、またコンテンツネゴシエーションのためにクライアントプレファレンスを伝達するといったHTTP機能が、数多くサポートされないまま残っています。これらの制限が回避するために、サードパーティのHTTPクライアントAPIに頼るといったがよくありました。HttpURLConnectionはNIOをサポートできないかもしれません。2005年に、これらの制限すべてを乗り越え、REST原理に照らして斬新なAPIを設計する好機を見出しました。クライアント側とサーバ側のウェブアプリケーションを一元管理するAPI、NIOを完全にサポートするAPI、そしてXML記述子に常に依存する必要なく、開発者がプログラムによってコンテナ、コネクタ、デプロイされたアプリケーションを制御できるAPIが手に入るのです。これらは使えますが、かなり限定されていると思います。私が抱えている主要な課題は、これらのプロジェクトがWS-*/SOAPスタックとして設計されており、全く新しいパラダイムであるRESTの世界にうまく合わないということです。RESTはリモートメソッド呼び出しとは対照的に、リソース指向設計を定義しています。Axis2を例に挙げますと、サポートするのはGETとPOSTメソッドだけですし、URIパラメータとして渡すためにリモートメソッドが必要です。これはあきらかにRESTでは許されないことですし、RESTfulと銘打つべきでさえありません。1.2はRESTをサポートしていませんが、POJOをRESTfulなウェブサービスにマッピングするプロジェクトを公表しています。それは最近JSR-311(source)が追求しているアプローチに似たものになるでしょう。JSR-311は、一連のアノテーションとヘルパークラスをベースに、そういったマッピングを標準化することを目的としています。私が期待するのは、RESTリソースとPOJOドメインオブジェクトとの間に良いマッピングを作ることです。JPAがRDBMSデータベースとPOJOの間で成し得たことができるといいと思っています。APIに完全に相補的になるといいと思っています。陣営の折り合いをつける良い機会となると思っています。Restletを利用するいくつかのプロジェクトについて何か話してください。いくつかのアプリケーションが、様々な規模の組織において既にデプロイされて稼動中です。その中には、格安でブランド商品を販売するインターネット大手のOverstock.com社があります。Restletプロジェクトはまた、RESTアーキテクチャスタイルをカバーする様々なソフトウェアアーキテクチャクラスをサポートする技術として使われます。カリフォルニア大学アーバイン校や、インサ工科大学ルーアン校といったところで使われています。われわれのウェブサイトはすべて自社製品を使い、自社のRestletエンジンで運営しています。サービス妨害による攻撃を受けた量を考えると、拡張性には自信をもっています。最近、性能品質を示す公式なベンチマーク(source)も公表しました。フレームワーク(source)に基づくNIO最適化コネクタを完全にサポートする次のリリースでは、その上を行くと期待しています。RailsやDjango(サイト・英語)といった有名なRESTfulなオルタナティブを経験することで、Java/Restletのオルタナティブは、RESTfulなアプリケーションをより良く、より高性能でサポートすることを提案していると思うようになりました。RailsやDjangoはRESTを念頭に入れて設計されたわけではなく、これらの概念は後から付け加えられたものでした。その結果、Restletより不自然なコードになってしまいました。Djangoを例に挙げると、元はURIとリソースをマップするURIテンプレートをサポートしていません。CRUDパラダイムとREST/HTTPメソッドの不自然なマッピングを無理に押し進め、不満足な結果になってしまいました。結局、多くの制約を回避しなくてはならず、リソース指向の設計をRailsの世界観に合うように変えなければならないのです。Restletは持続的技術を課すことは一切なく、リソース、リソースの表現、およびドメインオブジェクトやデータベースとのマップ方法を自由に定義できます。SELECTおよびDELETE文にうまくマップされていますが、「作成」するのにRailsのPOSTメソッドを使ったのはちょっと残念だと思います。RESTにおいて「作成」に一番良いメソッドは、更新にも使うPUTです。PUTがPOSTより良いところは、操作が失敗した場合にPUTは支障なく繰り返すことができますが、POSTはそうではないという点です。リソースのリストはテーブル名および数字の列IDを基にマップされますが、それが実際にいつもうまくいくとは限りません。RestletではURIに何ら制約を課すことがなく、馴染みのある持続的技術(JPAの注釈付きPOJO、そのままのJDBC呼び出し、オブジェクトデータベースなど)を何でも使ってリソースや表現を自由にマップできます。一つ、小さい批判ですが、リソースとしてウェブページにアクセスするのにRailsは場違いな“;edit”サフィックスを使うことを勧めています。これはちょっと誤解を招く恐れがあります。RESTはURIパラメータを渡すのに、複数の方法を指定することを勧めていないからです。ブラウザがGETした後でPOSTまたはPUTする別々のウェブフォームリソースを使うべきなのです。Restletにかなりの時間を費やしたようですね。このプロジェクトは、当初から趣味などでは決してありません。他の重要なプライベートプロジェクトを構築した際に必要性を感じたのですが、それに対する答えなのです。Consultingが提供するプロフェッショナルサービス(サポート計画、コンサルティング)によって、今までに費やしてきた時間と同じくらいは投資し続けることができると期待しています。バグ修正リリースである1.0系の保守バージョンの他に、間もなく1.1系を開始します。パッケージングのサポート(XML記述子を必要としない)、管理者の仕事を助けられるような、XML記述子を通してRestletコンポーネント(ポータブルアプリケーションおよび仮想ホストのコンテナ)を設定するオプションなどです。完成しなければならないコネクタのプロトタイプがいくつかあります。NIOフレームワークコアに基づいたHTTPサーバコネクタで、これによってさらなる拡張性と応答性が得られるはずです。あとは2つのHTTPコネクタですが、JXTA仮想ソケット(1つはクライアント、1つはサーバ)に基づいています。認証といったHTTP機能のサポートを引き続き深めたいと思っています。APIをJCPに提出する計画もあります。これは、サーブレットAPIをだんだんと廃止していくための良い機会になるかもしれません。Consulting社(サイト・英語)の創立者です。ヨーロッパおよび北アメリカにおいて8年以上のソフトウェアの作成とコンサルティングの経験があります。氏はJava、REST、セマンティックウェブ、およびビジネスプロセス統合に特に関心を寄せています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。