CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
前回(id:fits:20080929)は ServiceMix 3.2.2 上で Camel を実行してみたが、今回は ServiceMix 4.0 のカーネルを担う ServiceMix Kernel 1.0.0 を使って Camel を実行してみる。(ServiceMix Kernel は OSGi ベースの軽量コンテナ) Camel 実行に必要なパッケージのインストール ServiceMix Kernel はバイナリ用のアーカイブファイルをダウンロードして適当なディレクトリに解凍するだけで実行できるようになるが、この状態ではまだ Apache Camel は使えない。 Camel を使えるようにするには、以下のパッケージを ServiceMix Kernel の管理コンソールからインストールしてやる必要がある。 spring-tx camel-core camel-spring イ
Apache Camel は Apache ActiveMQ プロジェクトの一部、Spring を基盤とした統合フレームワークで EIP (Enterprise Integration Patterns) を実現するためのクラスライブラリが用意されている。 なお、EIP ではエンタープライズアプリケーションを連携させるためのメッセージングに関するパターンが定義されている。 というわけで、今回は以下の環境で Apache Camel の簡単なスタンドアロン実行を試してみた。 Apache Camel 1.4.0 Groovy 1.5.6 Camel を動作させる基本手順は以下の通り。 CamelContext を作成 必要に応じて Component や Endpoint を設定 ルーティングルール(RouteBuilder 内の DSL, XML などで定義)を追加 CamelContex
はじめに 私達はプレゼンテーション(層の)技術に関する現時点での見解を徹底的に見直さなければなりません。というのは、何年にも渡ってさまざまな制約が加えられていたことでIT業界では正道から外れたデザイン・パターンがまるで当然であるかのように考えられているからです。このことが現代においてもよいアプリケーションを作ることの大きな障害となっているのです。この記事では、(静的なWebサイトの対照としての)Webアプリケーションが特徴となるシン・クライアントのパラダイムは"その場しのぎの解決策"であり捨て去らなければならないと考えています。なぜこのようなことを言うのか理解していただくためにインターネットが広まり始めた90年代半ばに立ち戻りましょう。 経緯 インターネットが一般に広まるに連れ、ほぼ同時に2つの相反する発展がありました。(1)アプリケーションを少ない労力で簡単に配布できるという意味でユビキ
RESTはエンタープライズに浸透するか、ファーガソン氏が講演:Web 2.0とWebサービスの似て非なる位置付け WebはますますRESTfulな世界に向かっている。Web上で提供するデータやサービスを、URI指定によるHTTPリクエストだけで実現するという手軽さと分かりやすさから、多くのWeb 2.0系サイトは、Web APIをRESTと呼ばれる設計方針に基づいて定義・公開している。Webブラウザを媒介して人間が使っていたHTTPやURIといったインターフェイスを、そのまま機械処理にも適用するというRESTはシンプルで、瞬く間にWeb APIの標準的手法となった感がある。現在は先進的なWebサイトだけがWeb APIを公開しているが、今後は多くの一般的なWebサイトがRESTを通して情報・サービス提供をしていくケースが増えていくだろう。 では、エンタープライズの世界でもRESTが普及する
SOAP とWSDL(Web Service Description Language)が、ヘテロジニアスなシステム間の通信とデータ交換を容易にするための標準として紹介されてから、8年が経過しました。それ以来、総称してWS*と呼ばれるプロトコルの混乱によって、特定の通信要求とケースの際に容易になるSOAP(そして、場合によってはWDSL)の拡張としても紹介されることとなりました。SOAP とWSDL(Web Service Description Language)が、ヘテロジニアスなシステム間の通信とデータ交換を容易にするための標準として紹介されてから、8年が経過しました。それ以来、総称してWS*と呼ばれるプロトコルの混乱によって、特定の通信要求とケースの際に容易になるSOAP(そして、場合によってはWDSL)の拡張としても紹介されることとなりました。 本稿では、もっともよく耳にするWS
私は、多くのお客様と関わる中で、SOAの基本的な原則をまとめる必要性を感じています。以下のセクションでは、サービス指向アーキテクチャ(SOA)が持つとされる基本原則を紹介します。これらの原則は、絶対的な真理というよりは、SOAに関連した検討を行う際の基準の1つと考えてください。最初の4つは、Don Boxの4つの原則(サイト・英語)に、個人的な解釈を少し加えて紹介します。 1. 明示的な境界 サービスが機能を提供するのに必要なすべてのものは、そのサービスが呼び出されたときに受け渡しされる必要があります。サービスへのアクセスは、必ずパブリックに公開されたインターフェイスを経由します。そのサービスを呼び出すために暗黙の想定の存在が必要であってはいけません。“サービスとのやり取りはすべてメッセージを介して行われるので、サービスはメッセージングとの結びつきが強いと言えます。”(source)一般的
2007年には、SOAの導入や諸問題に関する調査および統計が多数実施された。全般的には、SOAに対する関心が広まっていることを示す結果が出ており、SOAを採用した企業の中にはすでに成果を上げているところもある。 2007年に発表されたSOA実装調査結果を、抜粋して紹介しよう。 57%のエグゼクティブが、SOAの導入にコスト削減が伴うことを期待している。27%はコードの再利用を、23%はビジネスアジリティの向上を望んでいる(出典:Saugatuck)。 2007年に新しく開発されたミッションクリティカル処理アプリケーションおよびビジネスプロセスの55%が、SOAに対応している。この数値は、2010年までに80%以上へ上昇すると予測されている(出典:Gartner)。 40%の企業が、全IT予算の10〜30%をSOAプロジェクトに費やしている。そのほとんどが、SOA予算は2006年を上回ったと
JBoss Rulesをはじめ、Jess、ILOG JRulesなど、ルールエンジンは商用/OSSを問わずいくつか出回っている。ルールエンジンは、SOAの文脈でもよく登場する。しかし、実際のところどうやって使っていいか、なかなかイメージが湧きにくいミドルウェアでもある。 Ronald G. Rossという人が、「ビジネスルールアプローチ」という手法を以下の書籍で提唱しているのだが、その中でルールエンジンの使い方を体系的に分類しているので、参考になる。 Ronald G. Ross, Principles of the Business Rule Approach (Addison-Wesley Information Technology Series) 1. 拒否機能(Rejector)・・・ルールに違反したイベントを棄却する 2. 生成機能(Producer)・・・イベントから何かを生
シスコシステムズは,XMLゲートウエイ「Cisco ACE XML Gateway」(写真)をこの9月より販売している。同製品は,「SOAにとってうれしい機能を提供するというコンセプトを持つ,ACE(Application Control Engine)製品ファミリの一つである」(アライアンス&テクノロジー 先進ソリューション開発 ソフトウェアプロダクトマネージャ 横山晴庸氏)。「SOAにとってうれしい」とはどういう意味なのか,解説しよう。 SOAの考えに基づいたシステムを実現する技術として,現在,最も有望とされているのはWebサービスである。そこでは,SOAPに代表されるようにXMLがベースとなる。Cisco ACE XML Gatewayは,Webサービスの利用者(コンシューマ)と提供者(プロバイダ)を仲介し,XML関連の処理やプロトコルの変換などを行う。実際にはリバース・プロキシのよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く