アプリケーションプラットフォームの領域でコンテナがVMを凌駕 - SDxCentral Survey調査よりSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
SOAの未来はRESTか
最も単純な場合、サービスは必要なものをすべて含んだ、独立して開発、配置、管理、メンテナンスができるソフトウエアの実装であり、企業の特定のビジネスと関係のある機能をに提供し、設計によって"統合可能"である、と言えます。ある“サービス”は動詞で定義できます(例えば、“顧客の信用度を検証する”、というふうに実現する機能を表現します)。 サービスはプログラミングの構成概念ではありません。APIのセットでもありません。むしろ、企業の問題解決のために実装される、設計物(部品の設計、実装、メンテナンス)と配置物です。サービスの機能性はサービスのインターフェイス(そのサービス特有の)によって定義されます。このインターフェイスは複数の実装方法で実現できます。サービスのインターフェイスを定義するにはふたつの基本的な方法があります。RPCスタイルとメッセージングスタイルです。RPCスタイルの実装はサービスの起動
SOAガバナンスの再検討
SOAは導入が増えているにもかかわらず、多数のSOAプロジェクトがいまだ失敗している(参考記事・英語)。あまりにも深刻な状況に陥ることが多いので、最近では「SOAかDOAか」（SOAか失敗か）(source)という受けを狙ったような題名の記事があった。DOAは「Dead on Arrival」、つまり「最初から機能しない」を意味する。この状態を改善する方法の1つが、適切なSOAガバナンス(参考記事リンク)である。 Muhammed Yaseen Muriankara氏は最近の論文「SOA governance framework and solution architecture」（SOAガバナンスのフレームワークとソリューション・アーキテクチャ）(source)で、ガバナンスの基本レベル3つを定義している。エンタープライズ・ガバナンスとは、 責任の連鎖、権限、コミュニケーションを確立して
NetKernel概論
NetKernel は、RESTとUNIXの基本的な機能を、リソース指向コンピューティング(resource oriented computing, 略してROC)と呼ばれる強力な抽象概念に組み込んだソフトウェアシステムです。リソース指向コンピューティングの核は、情報(リソース)に対し、それを配信する物理的なメカニズム(コード)から論理的なリクエストを分離することにあります。ROCを使用して作られたアプリケーションは、コンパクト、シンプル、フレキシブルであり、他のアプローチと比べて少ないコード量で済みます。 Hello World! リソース指向のシステムでは、リクエストはリソースに対して行われ、具体的で不変のリソース表現が返されます。これは、RESTやWorld Wide Webの原則にそのまま従っています。Webでは、http://www.1060research.com といったリソ
NetKernelで実装したRESTfulなESB
歴史的には、その大学ではIBM MQとFTPを用いてビジネスシステムを統合していました。この伝統的なアプローチにより、多くのポイントツーポイント（P2P）の統合がおこなわれました。そして、これらのP2P統合により維持費がかさみ、コンシューマとプロバイダ間が密結合となってしまいました。しかし、既存の環境は、より一層の革新を可能にするための軽量なメッセージ交換の状態遷移アプローチ（MEST）を既に利用していました。メッセージバスアーキテクチャのサブタイプであるエンタープライズサービスバス（ESB）は、より結合度を減らした環境を提供します。配置にはより高い先行投資が必要ですが、システムの拡張に関するコストが線形で予測可能であり続けるので、ESBの価値は時間とともに指数関数的に増加すると確信しています1。 大学のＩＴ部門には、専門のアーキテクトとソフトウェアエンジニアの少人数のグループがあります。
パフォーマンスが大幅に向上したJRuby 1.1のリリース
JRuby 1.0のリリース(参考記事・英語)から9ケ月後、 そして3 Release Candidatesの後(参考記事)、今や最終的なJRuby 1.1が利用可能になっている(source)。InfoQはJRubyのCharles Nutter氏(サイト・英語)およびOla Bini氏(サイト・英語)と情報交換し、JRuby 1.1での変更点とプロジェクトの今後の方向性について詳細を伺った。 Charles氏は、JRuby 1.1での主要な変更として以下の項目を挙げた。 最大の改良点は以下のとおりである。 フルコンパイラで、RubyコードをJavaバイトコードに変換する IOサブシステムが再書き込みされ、Rubyの振る舞いにますます適合する Regexp新エンジンが、大幅に改善されたパフォーマンスで、Rubyのストリングをサポートする 全体的なパフォーマンスは、1.0のリリースの何倍も
Ruby on Rails 2.0が公式リリース
David Heinemeier Hansson（DHH）氏は先日、Ruby on Railsブログ内で、ほぼ1年の制作期間を経てRuby on Rails 2.0をリリース(source)したことを発表した。 今回のリリースでは新機能が目白押しで、多くの修正が加わり、洗練度も大幅に向上している。本リリースについてDavid氏は以下のように語っている。 Ruby on Rails同様、なんとも画期的な出来事である。私は個人的にこのフレームワークの取り組みに約4年半の歳月を費やしてきた。そしてほぼ同じくらいの時間を共にした貢献者もいた。その期間、自分達がどこまでやってきたのかを見てみると実に満足の行くものだった。当初の誇大広告を証明する為、それにこだわってさらに高いレベルを求め続けることができたのですから。 本リリースの「新機能紹介」リストは長い。Rails開発者の興味を最も引くと思われる主
The Futures of Ruby Threading
A recent interview with Matz (Yukihiro Matsumoto), creator of Ruby, and Sasada Koichi, creator of YARV, tackles the topic of Ruby's handling of threads. Current stable releases of Ruby use user space threads (also called "green threads"), which means that the Ruby interpreter takes care of everything to do with threads. This is in contrast to kernel threads, where the creation, scheduling and sync
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkins CIとChefまたはPuppetの統合による，デプロイの完全なトレーサビリティの実現
InfoQ: Node.js - Google V8 ベースの Javascript 用イベント駆動 I/O
Jenkinsによる継続的インテグレーションのススメ(1)
Google App Engine、Goをサポート
クラウドにはサーバ仮想化が必要なのか？
Adobe が Hadoop のための Puppet レシピをリリース
Ruby 1.9 のSymbol#to_procと(入ったばかりの)Procのカリー化
RESTとトランザクション？
Wee：継続ベースのRuby Webフレームワーク
アーキテクチャ決定フレームワークを使ったRESTとWS-*の公正な比較：これで論争は終わりか？
インタビュー:MDDとSOAの関わりについてIBMアーキテクトBertrand Portierに聞く
RubyのMVM APIの共同研究が始まる