JMS 2.0の新機能
待ち望まれていたJava EE 7がついに、JMS 2.0とともにリリースされた。これは10年以上使われてきたJMSに対する最初のアップグレードになる。 最新のJMS仕様で最も注目すべきところは、Oracleが"Simplified" APIと呼んでいるスリムな表現だ。たとえば、メッセージを送受信するための新しいAPIを使うことで、多くのボイラープレートコードを取り除くことができ、必要なコード量を劇的に削減することができる。アプリケーションサーバで動かしているなら、新しいAPIはリソースインジェクションをサポートしている。アプリケーションサーバはJMSオブジェクトを管理できるようになり、アプリケーションはさらにシンプルになる。 フレームワークは完全に後方互換性があり、レガシーコードを使い続けたまま、新規コードにSimplified APIを使うことができる。古いAPIが非サポートになる予定
MDBとJCAのおはなし - nekop's blog
JBoss Advent Calendar 2011の13日目のエントリです。 MDBはメッセージドリブンビーンの略であり、メッセージを処理するEJBコンポーネントです。MDBはJMSのメッセージを処理するコンポーネント、という古い認識の人もたまに居るのですが、MDBはかなり前からJMSに限定しない技術となっています。 最初にMDBが策定されたのはJ2EE 1.3に含まれていたEJB 2.0仕様で、この時点ではMDBはJMSのメッセージを処理するもの、と規程されていました。J2EE 1.4の時代となり、EJB2.1の策定に伴いMDBの動作の仕様の中心はJCA仕様(Java EE Connector Architecture)に移り、メッセージはJMSのものに限定せず、ありとあらゆるメッセージ受信処理ができるよう一段階上の抽象化がなされました。 JCAはJava EEと外部システムをつなぐイ
今からでも遅くない JMSを学ぼう！(後編) Message-Driven Beanの世界へ
Message-Driven Beanとは 前回、JMSをJavaアプリケーションに組み込んで非同期通信を説明しました。ただし、業務ではMessage-Driven Bean（MDB）を使用する方が多いため、今回はMDBを使った非同期通信の仕方を説明します。 あらかじめ知っておくべきこと 前提知識 「今からでも遅くない JMSを学ぼう！」ではJMSを通じて非同期通信を学ぶことを目的としていますが、ドメインはPTPを使用しているため、Pub/Subの知識は必要ありません。PTPについてご存じない方、JMSの知識のない方は前編を読んだ後にその後編の当記事を読まれることをお薦めします。 Webアプリケーションの基礎的な知識が必要です。JSPやServlet、あるいはStrutsなどのWebフレームワークを使用した経験のある方はそのまま読むことが可能です。知識がない方は筆者の「GlassFishか
JBoss Messagingでメッセージの永続化ストアを使わなくする方法 - 達人プログラマーを目指して
JBoss MessagingではデフォルトでHSQLを使ったJMSメッセージの永続化が設定されています。メッセージの永続化は、メッセージの配信を保障するために重要な機構ですが、開発や単体試験実行時に、サーバーを再起動してもキュー内のメッセージが消えないと非常に不便で、逆にトラブルの元になります。 サーバーディレクトリー\deploy\messagingに格納されている、hsqldb-persistence-service.xmlを単純に削除し、 \docs\examples\jms\null-persistence-service.xmlを代わりにコピーするだけでは、以下の例外となってサーバー自体が起動しなくなります。 java.lang.RuntimeException: Unable to locate the transaction manager at org.jboss.tm.
リモート（別プロセス）のJBossサーバー上のキューにXAトランザクション内で正しくメッセージを送受信するには（続編） - 達人プログラマーを目指して
以前にJBoss Messagingでリモートのキューに対してXAトランザクション内でメッセージを送受信するにはResourceAdapterの登録が必要であるということを紹介いたしました。 リモート（別プロセス）のJBossサーバー上のキューにXAトランザクション内で正しくメッセージを送受信するには - 達人プログラマーを目指して JBoss MessagingのクライアントAPIは直接はXAのリソースとしてトランザクションに参加してくれないため、一旦リソースアダプターを使ってJCAのリソースプールとしてサーバーに登録しないといけないということです。ということで、理屈は頭でなんとなく理解できていたつもりだったのですが、今日実際に会社の環境で試したら、ほんのちょっとの設定の違いで正しくリモートのキューがJNDIルックアップできず結構な時間はまってしまいました。上記の記事で説明した通り、de
MOM（メッセージ指向ミドルウェア）の存在意義って何？
日本ではMOMがあまり活用されていないようですが、MOMを使う理由はどこにあって、どうしてあまりはやらないのでしょうか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
