JBoss Advent Calendar 2011の12日目のエントリです。 JNDIはJava EEサーバのEJB、JDBCデータソースやJMSのConnectionFactoryなど、各種サービスにアクセスするためのエントリポイントとなる部分なのですが、あまりエキサイティングな技術ではないので注目されることはないですし、どのようなものなのかを調べたりする機会もなかなかないでしょう。というわけでさらっと振り返ります。 まず基本的な機能はリモートアクセスもできるサーバ上のグローバルHashMapみたいなものです。メソッド名がちょっと違い、get()ではなくlookup()、put()ではなくrebind()となっています。 データソースを取得するようなコードはこのようになります。 InitialContext context = new InitialContext(); DataSou
世に出ているEJBの説明はクソみたいなものが多く、簡潔に機能や特徴を記述しているものが見当たらないので書きました。Java EE 6, 7を対象として書いています。 EJBというのはJava EEアプリケーションサーバ上で利用できるJavaのコンポーネントです。トランザクション制御などの煩雑な部分をEJBが自動的に面倒を見てくれるので、開発者はEJBの基本的なルールを抑えたあとはビジネスロジックの記述に集中することができる、というものです。EJBには4種類あります。 基本となるステートレスセッションビーン (Stateless Session Bean, SLSB) 状態を保持できるステートフルセッションビーン (Stateful Session Bean, SFSB) 単一インスタンスのシングルトンセッションビーン (Singleton Session Bean, SSB) メッセージ(
CDIが業務システム開発にもたらすメリットとは? EJBとの使い分けは?──最新Java EE開発“虎の穴” 第3回 上妻宜人氏 「Java EE 6で導入されたCDIの利点は"テスト容易性"と"技術依存の排除"の実現」だと語るのは、NTTコムウェアでJava EE開発や技術支援に携わる上妻宜人氏だ。具体的にどのようなメリットがあるのかを聞いた。 CDIはJava EE開発者待望の標準DI機能。エンタープライズ・システム開発における最大の効用は"テスト容易性"と"技術依存の排除" Java EE 6で新たに導入された「CDI(Contexts and Dependency Injection)」は、多くの開発者が待ち望んでいた標準DI(依存性の注入)機能だ。Java EE 5のEJB 3で先行導入されていたDI機能が、サーブレットやJSFなどを含むJava EEアプリケーション全体で利用可
Open Message Queue (OpenMQ) は オープンソースの メッセージ指向ミドルウェアを開発するプロジェクト。オープンソースアプリケーションサーバ開発プロジェクトGlassFishのサブプロジェクトとしてコミュニティによる開発が進められている。 Java Message Service (JMS) APIを実装している。JMS-APIの基本実装以外にスケーラビリティ・高可用性を実現したOpenMQ Cluster、C-API、JMX対応管理APIなどを搭載している。加えてJMSRAと呼ばれるJava EE Connector Architecture(英語版) (JCA) の実装モジュールを含んでいる。JCA実装によりJava EE準拠のアプリケーションサーバやBPMなどから容易にメッセージキューを使用することを可能としている。2009年現在OpenMQはGlassFis
java-ja忘年会でharu860さんに聞かれたのでエントリを書くよ。と思ってざっくり書いて放置していましたすみません。この質問へのよくある回答として「EJBを使うとき」みたいなものがありますが、この回答は多くの場合何の役にも立ちませんね。このような回答をする人はJBossをあまり良く理解していない可能性があります。 というわけで、JBossを使っているユーザがどのようなモチベーションでTomcatではなくJBossを使うのか、もしくは完全にJBossに乗り換えているのか、実例ベースの理由をいくつか紹介しましょう。 機能 Tomcatで提供される機能は基本的にServlet, JSP, JDBC接続プールのみで、他のものは提供されていません。シンプルですが、他のものが必要になったときに、それらをインテグレーションするコストが発生するなど、少し面倒なことになります。 TomcatになくてJ
Servlet 3.1 実装には、Servlet 3.1 フィーチャーを使用した場合に Servlet 3.0 用に作成されたアプリケーションが異なる動作をしたり、失敗したりする可能性がある動作の変更が含まれています。 動作の変更を考慮して、サーバー・インスタンスごとに、Servlet 3.0 と Servlet 3.1 フィーチャー実装のいずれを使用するかを選択できます。 必要な動作が Servlet 3.1 フィーチャーにのみ含まれている場合、Servlet 3.1 フィーチャーを使用する必要があります。 既存のアプリケーションが Servlet 3.1 フィーチャーの動作変更で悪影響を受ける場合、Servlet 3.0 フィーチャーを使用すれば、そのアプリケーションの既存の動作が保持されます。 同じサーバーで Servlet 3.0 と Servlet 3.1 の両方のフィーチャーを
僕の中では、 Java でロギングするなら log4j 1.2 系で必要十分。 それ以外、最新のトレンドについて考えることなんて数年前から無くなっていたんです。 だって、ライブラリの性能、機能(出力先の種類)が多少増えても現場のロギング要件はそんなには変わりませんから。 でも、今日ご紹介する SLF4J (Simple Logging Facade For Java) は大変興味深いロギングAPIなんですよ。 SLF4J は各種ロギング・ライブラリのアダブタAPIと言ってもよく、これによってロギング・ライブラリの実装を開発フォーズと綺麗に分離することが出来るんです(実装の遅延評価)。 さらに、このアダプタとしての役割を使えば開発者の負担も減らすことが事が出来るんですよ。
これからはメッセージキューが大切ということで、JavaのメッセージングAPIであるJMS(Java Messaging Service)を試してみます。 JMS試すにはメッセージングサーバーが必要で、Open MQとかを使います。けど、わざわざOpen MQとかをインストールして起動させるのもめんどいので、Glassfishを使います。GlassfishにはOpen MQが入ってて、そのまま使える状態になっています。NetBeans使いならGlassfish入ってますよね。 今回はv2.1を使いました。v3 preludeにはJMS入ってないみたい。 https://glassfish.dev.java.net/ 本来ならGlassfishで使う場合にはJNDI経由でJMSサーバーを取得するのですが、今回はめんどうなので、直接つなぎます。 ということで、メッセージ送信側。プロバイダーという
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く