1

2

3

DBに接続するために、データソースを定義してフィーチャーを追加します。

データソースには接続プール、接続先DBの情報、JDBCドライバなど、DB接続に必要な情報を定義します。アプリケーションは、接続プール内の接続オブジェクトを使用してDBに接続します。接続プールでは、DB接続処理が終了した接続オブジェクトを開放せずプーリングし再利用します。その結果、切断と再接続によるオーバーヘッドを軽減することができます。

ステートメントキャッシュは、PreparedStatement(プリコンパイルされた SQL ステートメント)をキャッシュします。キャッシュにヒットすればSQLを再利用できパフォーマンスの向上が見込めます。

データソースをserver.xmlに設定するために、jdbc-4.1またはjdbc-4.0フィーチャーを追加します。JNDI名を利用している場合は、jndi-1.0フィーチャーを追加します。

4

この図は、データソースの定義例です。

（設定値はサンプルであり、設定値を推奨するものでありません。）

${DB2_JCC_DRIVER_PATH}はserver.envに事前に設定する必要があります。

5

・jndiName

jndiNameを使用する場合はjndi-1.0フィーチャーを追加します。

・type(デフォルト javax.sql.ConnectionPoolDataSource)

タイプは「javax.sql.DataSource」「javax.sql.ConnectionPoolDataSource」「javax.sql.XADataSource」の3種類あります。

2フェーズコミット対応のデータソースが必要な場合は 「javax.sql.XADataSource」を指定します。

・isolationLevel

アイソレーション・レベル（分離レベル）を指定します。分離レベルとは、DBでのデータ・アクセス処理が複数同時に行われた場合にどれほどの一貫性、正確性で実行するかを定義したものです。

・jdbcDriver

JDBC ドライバーの格納場所と名前を指定します。データソース実装クラスの名前(javax.sql.XADataSource属性など)は jar ファイルの名前から自動的に設定されるので指定する

必要はありません。

・properites.*

接続先のDB名、サーバー名などJDBCドライバー固有の構成情報を指定します。JDBCドライバー毎に固有の properites が提供されています。propertiesエレメントで、データベース接続に使用するuserとpasswordを指定することもできます。ただし、このプロパティーを構成する代わりに、コンテナー管理認証別名を使用することをお勧めします。

・connectionManager[Ref]

接続マネージャー(接続プール)の構成情報を設定します。

・containerAuthData[Ref]

コンテナー管理認証用のデフォルトの認証データを設定します。

・recoveryAuthData[Ref]

トランザクション・リカバリーが発生したときに使用する認証データを設定します。トランザクション・リカバリー発生時、コンテナー管理認証やpropertiesで設定した認証情報よりも優先して使用されます。

6

接続プールとステートメント・キャッシュの設定について説明します。

接続プール

・minPoolSize

接続プールに保持する最少接続数を指定します。ここで指定した数の接続が起動時に作成されるわけではありません。

・maxPoolSize(デフォルト 50)

接続プールに保持する最大接続数を指定します。

・maxIdleTime(デフォルト 30m)

接続プール内に最少接続数を超える接続が存在する場合は、この指定値を超えてアイドル状態にある接続は破棄されます。無制限に設定するには0を指定します。

・agedTimeout(デフォルト -1)

接続確立後の経過時間がこの指定値を超えた接続は破棄されます。-1を指定する(デフォルト)とこの動作を無効化できます。接続中のオブジェクトは指定値を超えた場合でもすぐには破棄されません。

ステートメントキャッシュ

・statementCacheSize(デフォルト 10)

キャッシュする PreparedStatement の最大数(１つ接続当り)を指定します。

7

データソースのチューニング方針について説明します。

DB接続要求が増減する場合は、最大接続数と最小接続数に差をつけます。最小接続数には普段対応できる接続数を設定し、最大接続数にはピーク時に耐えうる接続数を設定します。その結果、定常時にはリソースの消費を抑え、ピーク時にも対応することができます。DB接続要求がある程度一定の場合は、最大接続数と最小接続数を一定にします。その結果、接続・切断のオーバーヘッドを削減できます。

maxIdleTimeは、初期値として、デフォルト値(30分)を使用します。

agedTimeoutは、例えばFirewall などの設定により、長時間接続できない場合など定期的にリソースを解放したい場合は設定します。

ステートメント・キャッシュはstatementCacheSizeで接続当たりのキャッシュに入れる準備済みステートメントの最大数を指定します。破棄されるPreparedStatementの数が多いようであればデフォルトより総数を多く設定します。その際、データベース側のエージェント・プロセスのメモリー使用量が増加する点も考慮します。

8

データソースのタイムアウト値について説明します。

タイムアウトを設定するときは、正整数の後に時間単位 (時間 (h)、分 (m)、または秒 (s)) を付けて指定してください。例：1m30s,90sなど

接続取得のタイムアウト

・connectionTimeout(デフォルト 30s)

アプリケーションの接続要求が、接続オブジェクトを取得するまでのタイムアウトです。プール内の全接続が使用中で更に最大接続数に達している場合、新たな接続取得要求は、使用中の接続オブジェクトがプールに返却されるまで待機させられます。この待機時間が connectionTimeout を超えると、SQLExceptionがスローされます。

・JDBCドライバーのプロパティー

keepAliveTimeOutやloginTimeoutなどが設定可能です。新たにデータベース接続を作成する時のタイムアウトは、JDBCドライバーのプロパティーなどで調整します。

SQL 操作のタイムアウト

・queryTimeout

アプリケーションが、SQL ステートメントの完了を最大どれだけ待つかを指定します。指定した値が Statement / PreparedStatement の queryTimeout に設定されます。

・syncQueryTimeoutWithTransactionTimeout(デフォルト false)

“true” を指定すると、グローバル・トランザクション(JTAトランザクション)の残り時間が Statement / PreparedStatement の queryTimeout に設定されますqueryTimoutで設定していた値はオーバーライドされます。デフォルトは “false”です。

9

DB障害時の動作と調整について説明します。

パージ・ポリシー(デフォルト EntirePool)

無効な接続が検出された場合に、プール内の接続をどのように取り使うかを指定します。 デフォルトではEntirepoolが設定されており、プール内すべての接続を破棄します。

接続検証

LibertyではgetConnection()時に自動的に接続検証を行う機能は提供されておりません。接続検証を行うには、アプリケーション側でisValid()を呼び出す必要があります。

WAS traditional のパージ・ポリシー FailingConnectionOnly の動作は、データソースのカスタム・プロパティー defaultPretestOptimizationOverride の指定により異なります。false (デフォルト) の場合は、WAS Liberty のFailingConnectionOnly の動作と同等に、true の場合は、WAS Liberty のValidateAllConnections の動作と同等になります。

10

この図は、データソースがアプリケーションにバインドさせれるフローを示したものです。

アプリケーションは(1) アノテーションを使用したリソース参照の注入、(2) リソース参照の lookup、(3) リソースの直接 lookup の何れかの方法でデータソースにアクセスします。

アノテーションでは、以下の情報を指定できます。

• リソース参照の名前 (デフォルト：「パッケージ名.クラス名/フィールド名」などの注入先を示す名前)

• 認証タイプ (デフォルト：コンテナー管理認証)

• 接続の共有 (デフォルト：共有する)

• バインド先のデータソースの JNDI 名

アノテーションで指定した内容は、web.xml (ejb-jar.xml) で上書きすることが可能です。web.xml (ejb-jar.xml) でのリソース参照の定義は、アノテーションを使用している場合は任意ですが、リソース参照を lookup している場合は必須となります。更に ibm-web-bnd.xml (ibm-ejb-jar-bnd.xml) で、バインド先のリソースの JNDI 名を上書きできます。また、認証別名(認証データのid)も指定できます。

リソースを直接 lookup している場合は、以下の扱いとなります。（非推奨です。）

• 認証タイプ： アプリケーション管理認証(コンポーネント管理認証)

• 接続の共有： 共有する

認証に必要な情報は以下の優先順位で決定されます。

• コンテナー管理認証の場合

(1) ibm-web-bnd.xml (ibm-ejb-jar-bnd.xml) で指定した認証データ

(2) データソースの containerAuthData[Ref] で指定されている認証データ

(3) JDBCドライバー固有の構成情報(properites.*)で指定されているもの

• アプリケーション管理認証(コンポーネント管理認証)の場合

11

(1) getConnection() 実行時に指定したもの

(2) JDBCドライバー固有の構成情報(properites.*)で指定されているもの

11

DB接続における、WAS Liberty と WAS traditional の差異をまとめました。

・接続検証

WAS Liberty は、接続の検証を行いません。必要であれば、アプリ側で接続の isValid() メソッドを呼び出すことで検証します。

・com.ibm.websphere.ce.cm.StaleConnectionException

データベース障害などにより、接続が使用できない状況であることを示す例外で、主にプールから取得した接続が無効な接続であったことを示す目的で導入されました。

WAS Liberty は com.ibm.websphere.ce.cm.StaleConnectionExceptionをスローしません。

・接続の再作成機能

無効な接続が検出された後に、バックグランド･スレッドで再接続を試行する機能です。WAS Liberty では提供されていません。

12

13

14

メッセージングを活用すると、同期処理では難しかったいくつかの処理が簡単になります。

・並行処理

メッセージングでは、メッセージ送信側と受信側では同期をとりません。メッセージ送信側はメッセージ送信後、処理を継続できますし、メッセージ受信側はメッセージ受信後、すぐに処理を開始します。

・疎結合

送信アプリケーションと受信アプリケーションが従うべき規約が少ないことです。メッセージのフォーマットと利用する宛先が正しければ、利用が可能になるというメリットがあります。

Java では、メッセージング処理の仕様を Java Message Service (JMS) で規定しています。標準のインターフェイスでコーディングすることにより、メッセージング・サービスに依存しないアプリケーションを開発できます。

JMS プロバイダーがメッセージの送受信機能を提供します。アプリケーションはJMS クライアントとして動作します。

15

Libertyでは、組み込みメッセージング・エンジンが用意されています。

組み込みメッセージング・エンジンはJMSプロバイダーの機能を提供し、Libertyサーバーで１つだけ稼動可能です。

組み込みメッセージング・エンジンを使用するには、フィーチャーwasJmsServer-1.0 または javaee-7.0を指定します。仕様はJMS1.1とJMS2.0をサポートしています。

メッセージング・モデルは、point-to-pointとpublish/subscribe方式両方をサポートします。PTP(Point To Point)は、メールに例えられる1対1の通信形態です。Pub/Sub(Publish and Subscribe)は、メーリング・リストに例えられる1対多の通信形態です。

ローカルで稼動するアプリケーションには、in-process接続をします。TCP/IP接続と比べて負荷が少なく接続できます。リモートのLibertyで稼動するアプリケーションにはTCP/IP接続をします。tWASで稼動するアプリケーションも接続可能です。

16

Liberty上で起動するアプリケーションから接続可能なJMSプロバイダーは主に3つあります。

・Libertyの組み込みメッセージング・エンジン

ローカル、リモート両方接続可能です。

･WAS traditional のサービス統合バス(SIBus)

tWASのメッセージング機能です。

・IBM MQ

IBMのメッセージング製品であるIBM MQにも接続可能です。

JMSプロバイダーに接続するために必要なフィーチャーとして、表に記載されているフィーチャーがあげられます。

17

メッセージングを利用する場合、以下のリソースを定義します。

・メッセージング・エンジン

組み込みメッセージング・エンジンを JMS プロバイダーとして使用する場合は定義します。

・JMS 接続ファクトリー

JMS プロバイダーに接続するために必要な情報を定義します。データベース接続のデータソースに該当します。

アプリケーションは JMS 接続ファクトリーを介して JMS プロバイダーに接続します。

・JMS 宛先 （キュー、または、トピック）

JMS プロバイダーが提供するキューやトピックの情報を定義します。

アプリケーションから JMS 宛先の実態を隠ぺいします。

・JMS アクティベーション・スペック

到着したメッセージを処理する MDB (Message-Driven Bean) の稼働に必要な情報を定義します。MDBは、Java EE標準のメッセージ駆動型処理を行うEJBです。アプリケーションから JMS プロバイダーや JMS 宛先の実態を隠ぺいします。

18

この図は、メッセージング・エンジンの定義例です。（設定値はサンプルであり、設定値を推奨するものでありません。）

19

メッセージング・エンジン定義の基本要素を説明します。

・fileStore

パーシスタンス・メッセージの保存先を構成します。耐障害性はLibertyの機能として提供していないため、ディスク構成などにより実現します。

・queue

JMS のキューを定義します。

・wasJmsEndpoint

メッセージング・エンジンがリッスンするホスト名(IPアドレス)とポートを指定します。メッッセージ・エンジンを外部から接続しない場合や、ポートのリッスンをなくしたい場合は enabledを”false”に指定します。

20

WAS traditional のメッセージング・エンジンと同等のメッセージ信頼性を指定可能です。

・パーシステント

メッセージをストアに書き込むことで、高い信頼性を提供します。これに対して、ストアに書き込む分、メッセージングのパフォーマンスが低下します。

・非パーシステント

メッセージをストアに書き込まないので、メッセージを保持しているサーバーに障害が発生した場合には、メッセージを消失する可能性があります。信頼性が低い代わりに、メッセージングのパフォーマンスは向上します。

メッセージ信頼性は処理要件に応じて設定します。

例えば、一方向送信型の処理でメッセージ消失は不可 の場合は、｢AssuredPersistent｣を選択します。要求・応答型のオンライン処理でメッセージ消失を容認 する場合は「ExpressNonPersistent」を選択します。デフォルトでは、AssuredPersistentに設定されております。

21

高可用性については、特別な機能は提供されていません。そのため、プロセス障害やメッセージ・エンジンの障害は、WAS Liberty の再起動で対応します。OS やハードウェアの障害は、クラスタリング・ソフトウェアによる二重化で対応します。

22

この図は、JMS 接続ファクトリーと JMS キューの定義例です。（設定値はサンプルであり、設定値を推奨するものでありません。）

23

JMS 接続ファクトリー定義と JMS キュー定義の基本要素を説明します。

接続ファクトリーのチューニング指針は、データソースのチューニング指針と同様です。

24

この図は、JMSアクティベーション・スペックの定義例です。（設定値はサンプルであり、設定値を推奨するものでありません。）

25

JMSアクティベーション・スペック定義の基本要素を説明します。

・id

JMS アクティベーション･スペックの idです。MDB をアクティベーション･スペックにバインドするために使用されます。

・properites.*

JMS プロバイダー固有の設定を指定します。

・authData[Ref]

メッセージング･プロバイダーに接続するための認証データを設定します。

・destinationType, destinationRef

MDB がメッセージを取り出すキューまたはトピックの情報を設定します。

26

JMS 接続ファクトリーと JMS 宛先のバインド方法は、データソースのバインドと同様です。

アクティベーション･スペックのバインド方法は、ibm-ejb-jar-bnd.xml で、バインド先のアクティベーション・スペックの id を指定します。

デフォルトでは、id が「アプリケーション名/モジュール名/EJB名」のアクティベーション・スペックにバインドされるので、MDB 毎にアクティベーション・スペックの定義が必要となります。

27

IBM MQを利用するには、IBM MQ のリソース・アダプターの定義が必要になります。IBM MQのリソース・アダプターの設定について説明します。

リソース･アダプターは、variable (変数宣言）タグを使用して指定します。

接続方法として、CLIENT接続とBINDINGS 接続の2種類があります。デフォルトはCLIENT接続です。BINDINGS 接続を利用する場合は、更に、wmqJmsClient（WMQ リソース・アダプター）タグで MQ Java JNI ライブラリーのインストール先を指定します。

接続方式としてバインディング接続とクライアント接続があり、ローカル構成ではバインディング接続、リモート構成ではクライアント接続を利用します。

28

properties.wmqJms の arbitraryProperties で指定する MDWRITE, MDREAD および MDMSGCTX に関しては、以下の URL を参照してください。

参照：

IBM MQ classes for JMS オブジェクトのプロパティー： MDWRITE

https://www.ibm.com/support/knowledgecenter/ja/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q112160_.htm

IBM MQ classes for JMS オブジェクトのプロパティー： MDREAD

https://www.ibm.com/support/knowledgecenter/ja/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q112150_.htm

IBM MQ classes for JMS オブジェクトのプロパティー： MDMSGCTX

https://www.ibm.com/support/knowledgecenter/ja/SSFKSJ_9.0.0/com.ibm.mq.ref.dev.doc/q112170_.htm

29

IBM MQリソース・アダプタのチューニング項目について説明します。wmqJmsClient（WMQ リソース・アダプター）タグでチューニングします。

デプロイ可能な 最大MDB 数

maxConnectionsで設定します。デフォルトは50です。デプロイする MDB数がデフォルトの 50 を超える場合は調整します。

MDB 始動時の接続再試行

再試行間隔はstartupRetryIntervalで設定します。デフォルトは30秒です。再試行回数はstartupRetryCountで設定します。デフォルトは0です。

稼働中に接続が途切れた場合の接続再試行

再試行間隔はreconnectionRetryIntervalで設定します。デフォルトは5分です。再試行回数はreconnectionRetryCountで設定します。デフォルトは5回です。

｢reconnectionRetryInterval × reconnectionRetryCount｣ を IBM MQ の再起動(テークオーバー)時間より長く設定することで、IBM MQ の障害によるMDB の停止を抑止できます。

30

31

32

33

トランザクションには大きく分けて2種類あります。

ひとつは1つのリソースを対象としたものでローカル・トランザクションと呼ばれます。もうひとつは複数のリソースを対象としたトランザクション処理でグローバル・トランザクションと呼ばれます。

ローカル・トランザクションは1つのリソースを更新対象とするトランザクション処理です。この場合には各リソースが主体となってトランザクションを管理します。リソースはリソース・マネージャーによって管理されています。リソース・マネージャーはアプリケーションからトランザクションの開始やコミット要求を受付け、各処理ごとにログ出力をして状態を管理します。

グローバル・トランザクションは複数のリソースを更新対象とすることが可能なトランザクション処理です。この場合にはトランザクション全体を制御するトランザクション・マネージャーが存在します。トランザクション・マネージャーがアプリケーションからトランザクションの開始やコミット要求を受付け、リソース・マネージャーに指示しつつトランザクション全体の調停をおこないます。グローバル・トランザクションの場合は、トランザクション・マネージャーもログを出力します。また、コミット時には2フェース・コミットと呼ばれる方法が使用されます。ちなみに更新対象リソースが1つの場合はパフォーマンスの理由からコミット処理は1フェーズに最適化されます。

34

トランザクション処理の障害設計のポイントについて説明します。ここではWASがトランザクション・マネージャーとなり複数のリソース・マネージャーへの更新処理をおこなうグローバル・トランザクションのパターンを考えます。

障害発生時には以下のような問題が生じる可能性があります。

・リソース(DBの行、メッセージなど)に対する更新が確定せずにロックが残る（リソースへのアクセスで待機したり、アクセス不可能な状態になる）

・適切にリカバリーできなかった場合は、データの不整合が生じることがある

従いまして、仕掛かり中のトランザクションに対して、適切なリカバリー処理が必要になります。障害時のトランザクション・リカバリー処理も、トランザクション・マネージャーがコーディネートします。障害発生箇所としては、トランザクション・マネージャーとリソース・マネージャーが考えられます。トランザクション・マネージャーとリソース・マネージャーが別ノードにある場合は、ネットワーク障害も考えられます。

トランザクションのリカバリーには、トランザクション・ログを使ったリカバリー方法と、トランザクション・ログを使用せずに手動でリカバリーする方法があります。通常はトランザクション・ログを使用してリカバリーを行います。

トランザクション・ログを使用したリカバリーは２つの方法があります。

アプリケーション・サーバーを手動で再起動する方法と、代替アプリケーション・サーバーによる方法の2つです。Liberty では、WAS traditional ND 版が提供するピア・リカバリーと同等の機能は提供されません。

トランザクション・ログが何らかの原因で使用できない場合は、確定状態を予測し手動でリカバリーする方法があります。しかし確定状態が判定できなかった場合はデータの不整合が発生する可能性がありますので、トランザクション・ログの保管は重要です。

35

36

アプリケーション・サーバーを再起動することでリカバリーする方法です。

トランザクション･マネージャーの recoverOnStartup の指定によって、リカバリーが行われるタイミングが異なります。

デフォルトでは、false が設定されています。トランザクション・サービスが最初に使用されたときにリカバリーを行います。trueに設定した場合は、サーバー始動時にリカバリーを行います。

37

代替サーバーにトランザクション・ログを引き継ぎ、代替サーバーでリカバリーする方法です。

障害が発生したアプリケーション･サーバーの復旧に時間がかかる場合は、代替アプリケーション・サーバーでリカバリーを実施します。この方法の場合、プロセス障害だけではなくノード障害にも対応することが出来ますが、コールド・スタンバイの場合にはリカバリーに時間がかかることと、自動化する場合には別途、PowerHAなどのクラスタリング・ソフトウェアの購入が必要になることが注意点になります。

代替サーバーでリカバリーを行うには、代替サーバーからもトランザクション・ログを使用できなければいけません。

そのためトランザクション・ログを共有ディスクに配置したり、手動でコピーして使用できる場所に移動したりするなどします。その他、トランザクション・ログをNSF V4 や NAS などの共有ファイル・システムに配置することも可能です。

38

リカバリー時に使用される認証情報の優先順位は以下の通りです。

1. データソースなどの recoveryAuthData[Ref] に指定されたAuthData

2. コンテナー管理認証の場合は、バインドされた認証別名(id)で示される AuthData

認証別名を指定していない場合は、データソースなどのcontainerAuthData[Ref] の指定

3. データソースなどの properites.* で指定された認証情報

リカバリーでの制限事項は以下になります。

対象のリソース･マネージャーにアクセス可能なアプリケーション･サーバーでリカバリーを行うこと

トランザクション･ログを移動する場合は、トランザクション･ログ･ディレクトリー内の全ファイル/ディレクトリーを、そのまま移動すること

データソースなどの id や jndiName は変更しないこと

コンテナー管理認証で使用された AuthData の id は変更しないこと

リカバリー実行前の構成変更

データソースなどの構成情報のうち、id や jnidName 以外はリカバリー実行前に変更することが可能（変更したものがリカバリー時に使用される）

例えば、recoveryAuthData[Ref] の追加なども可能

設定可能なタイムアウト値について説明します。

３つのタイムアウト値を調整できます。

・propogatedOrBMTTranLifetimeTimeout

設定可能なトランザクション・タイムアウト値の上限値を設定します。英単語として伝搬という意味のpropagatedが正しいですが、WASの設定値の項目としてはpropogatedが正しい表記です。

外部から伝播してきたトランザクションのタイムアウト値や、UserTransaction などに対して設定可能なタイムアウト値の上限となります。この値よりも大きな値を設定しようとしても、この値で上書きされます。

・totalTranLifetimeTimeout

このサーバーで開始されるトランザクションのデフォルトのタイムアウト値を設定します。この時間を越えて終了しないトランザクションは、rollbackOnlyにマークされます。propogatedOrBMTTranLifetimeTimeout 以下の値を指定します。

・clientInactivityTimeout

外部から伝播してきたトランザクションの非活動タイムアウト値を設定します。この時間を越えて活動がない伝播トランザクションは、rollbackOnly にマークされます。propogatedOrBMTTranLifetimeTimeout 以下の値を指定します。

39

LPSを容認するかどうかをacceptHeuristicHazardで指定できます。

LPS (Last participant support) とは、2PC トランザクションに、１つだけ 1PCリソースを参加させることができる機能のことです。容認すると、1PC リソースのcommit と TM のログ書き込みの２つの同期点が発生し、障害時に確定状況が分からなくなることがあります（ヒューリスティックな結果となる）。

デフォルトではtrueに設定されておりLPSを容認しているため、ヒューリスティックな結果となる可能性があります。そのため、基幹系システムではfalseに設定し、LPSを容認しないようにします。

40

確定フェーズでの RM 障害時やネットワーク障害時などの動作を指定できます。

heuristicRetryWaitで、2PC の確定処理をリトライする回数を指定します。heuristicRetryIntervalで、2PC の確定処理をリトライする間隔を指定します。

障害時、リトライ回数に達すると確定結果が破棄されてしまいます。破棄されるとトランザクションログの確定記録がなくなり、Libertyは以後リトライを行わなくなります。デフォルトでは5回リトライが失敗すると確定結果が破棄されます。そのため、基幹系システムではリトライを継続するように 0 (無制限) を指定します。

41

42

信頼性を保つ為に、トランザクション・ログの可用性を考慮する必要がありますが、WAS にはトランザクション・ログを2重化する機能はありません。そのため、ハードウェアなどによる高可用性の実現が必要となります。また、2フェーズ・コミット処理では、トランザクション・ログへの書き込みが発生するため、ディスクのパフォーマンスがトランザクションのパフォーマンスに直接影響します。高パフォーマンスを実現するには高速ディスクが必要となります。

43

DBにトランザクションログを保管する方法を説明します。

代替サーバーによるリカバリーを実現したいけれども、NFS V4 や NAS などによるファイル共有が採用できない場合に有効です。

トランザクション・ログをDBに保管するには、transactionエレメント内にトランザクション用DBに接続するためのデータソースを設定します。

データソースの設定方法では、transactional = “false”を指定します。

Libertyはサーバーが最初に始動されたとき、必要なデータベース表を作成します。

44

API Discovery機能によるAPI 連携を解説します。

45

Libertyでは、外部システム連携方法の１つとして、API公開による連携があります。

APIでの連携とは、JAX-RSによるREST API アプリケーションを作成し公開する事です。JAX-RSでアプリケーションを作成すると自動的に外部からそのAPIがコール可能になります。

このAPIのインターフェース情報をSwagger仕様に基づき公開する機能が、LibertyのAPI Discovery機能です。通常Swaggerでの情報公開には、ライブラリーの組み込みやコーディングが必要になりますが、API Discoveryでは設定するだけでSwaggerでの公開が簡単にできます。

IBM API Connectの様にSwagger対応可能な外部システムがある場合、それらのシステムで簡単にREST APIが扱えるようになります。

46

Swaggerは、REST APIのインターフェースを記述するための仕様です。Webサービス（SOAP）に対するWSDLと同様の位置づけです。

Swaggerについては、"http://swagger.io"を参照してください。Swaggerでは他にREST API 開発に役立つツール群を公開しています。

Swagger文書は、JSONもしくはYAML形式で記述する事が可能です。

47

Swaggerを活用したREST API 開発と公開には、２つの方法があります。

設計、コード作成を行ってから、それに基づきSwagger文書を生成するのがボトム・アップで、Swaggerツール等を利用して先にSwagger文書でAPIを規定してからコードを作成するのがトップ・ダウンです。

どちらの方法で開発するかは、プロジェクトの方針により決定します。

Libertyでは、ボトム・アップで開発するにはJAX-RSのアノテーションを利用した方式で開発する必要があります。アノテーションを利用しないJAX-RSでの開発や、サーブレットなどその他の方法でREST API を公開する場合はトップ・ダウンの方式になります。

48

LibertyのAPI Discoveryでは、以下の機能を提供します。

１．Swagger文書をLibertyサーバーで公開します。（詳細は以降のページを参照）

２．公開されているREST APIに変更が発生した場合、その変更情報を通知します。

websocketクライアントで、"http://<host>:<http_port>/ibm/api/docs/subscription"にアクセスするとフィードで更新が通知されます。

詳細は、"http://www.ibm.com/support/knowledgecenter/ja/SSEQTP_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_subscribe_restapi.html"を参照してください。

３．公開しているAPI を、IBM API Connectに登録します。

４．Liberty Collective環境では、Memberサーバーで公開しているREST API 情報を集約して、ControllerサーバーでSwagger公開する事が可能です。

49

API Discovery機能を使用するためには、server.xmlに、"<feature>apiDiscovery-1.0</feature>"を追加してください。また、"ibm/api"に対するユーザレジストリーの設定も必要です。

50

API Discovery機能設定後、いくつかの方法でREST API の情報が取得できるようになります。どの方法で行う場合でも、前ページで設定したユーザレジストリー設定での認証が必要になります。例えば、Basic認証を指定している場合は、ユーザIDとパスワードの入力（もしくはHTTPヘッダーへの付加）を行う事になります。

Swagger文書で情報取得するには、下記URLにGETでアクセスします。

https://<host>:<https_port>/ibm/api/docs

このURLにアクセスするとJSON形式で情報を取得できます。ただし、デフォルトではAPI Discovery機能自身のAPIなどを含む全APIがリストされます。特定のAPIのみにフィルタリングしたい場合は、URLに"?root=xxxx"形式で指定します。これにより、xxxxで指定したコンテキストルートのAPIのみリストされます。

JSON形式でなく、YAML形式で取得したい場合は、HTTPのAcceptヘッダーに「application/yaml 」を指定してください。

51

API Discovery機能を使用すると、設定したLibertyサーバーでSwagger UI ツールが使用可能になります。

Swagger UI ツールは、ブラウザーを利用してAPI情報の表示やAPIのテスト実行をGUIで行う事ができます。

Swagger UI ツールを使用するには、ブラウザーで、"https://<host>:<https_port>/ibm/api/explorer"にアクセスします。

画面に、REST APIのリストが表示されるので、そのAPIをクリックすると詳細情報が表示されます。

52

Swagger UI ツールでは、REST APIをテスト実行する事が可能です。

各APIの「試してみよう」ボタンを押すとテスト実行されて、その結果が表示されます。なお、POSTなどでデータ送信が必要な場合は、必要なデータを入力してから「試してみよう」ボタンを押します。

53

API Discovery機能で公開するSwagger情報はWebモジュール（war）単位で作成され、Libertyサーバ全体で集約されます。

各Webモジュールでは、以下の方法で公開する情報を指定します。

① JAX-RSのアノテーション情報から自動的にSwagger文書を公開する場合は、JAX-RSアプリケーションをデプロイしてください。自動的にSwagger文書が公開されます。

② 既に作成されたswagger.json/.yamlファイルの情報を公開する場合は、「META-INF/swagger.json」（もしくは.yaml）にファイルを配置してください。このファイルがあるとその内容が自動的に公開されます。なお、このファイルが配置されると①の方法が使用できなくなるので注意してください。ファイルの配置場所を他の場所にしたい場合は、<webModuleDoc>で指定してください。

③ 既存のSwagger文書とJAX-RSのアノテーション情報を集約して公開したい場合は、Swagger文書を「META-INF/stub/swagger.json」に配置してください。自動的に２つの情報が集約されたSwagger情報が公開されます。

54

JAX-RSのアノテーションからSwagger文書の情報を生成するには、クラスのレベルで以下のどれかのアノテーションを記述します。

・@Path (JAX-RSのアノテーション)

・@API or @SwaggerDefinition (Swaggerのアノテーション)

これらのアノテーションが見つかると、各メソッドのアノテーション情報からSwagger文書の情報が生成されます。

各アノテーションについては、そのぞれのドキュメントを参照してください。

Swaggerアノテーション ： http://docs.swagger.io/swagger-core/current/apidocs/index.html

55

IBM API Connectと連携するには、２つの方法があります。

① Swagger文書での登録には、

"https://<host>:<https_port>/ibm/api/docs/apiconnect"にGETでアクセスします。

このリターンには、API Discovery機能のAPIは含まれません。

② Libertyから、IBM API Connectに情報をPushするには、以下のURLにPOSTでアクセスします。

https://<host>:<https_port>/ibm/api/docs/apiconnect

（Collective環境）https://<host>:<https_port>/ibm/api/collective/docs/apiconnect

その際には、ヘッダーやパラメーター、送信データを指定する必要があります。

IBM API Connect 連携のしてするデータの詳細情報は、Knowledge Center を参照してください。

http://www.ibm.com/support/knowledgecenter/ja/SSEQTP_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_push_rest_api.html

56

WDTを使用する事により、SwaggerドキュメントからREST Clientの雛形を自動生成できます。

WDTのメニューから、新規作成でNew → RESTful Services → Generate JAX-RS Clientを選択します。

ウィザードでSwagger文書と出力パッケージを指定するとSwaggerのライブラリーが使用されたクライアントコードが自動的に生成されます。

生成された*.api パッケージにあるクラスにREST APIをコールするメソッドが用意されているので、このクラスを利用してコードを作成します。

コード作成に関しては、以下を参照してください。

http://www.rnavagamuwa.com/open-source/generate-client-side-code-using-swagger-codegen/

57

CORSは、W3Cの仕様です。"https://www.w3.org/TR/cors/"

ブラウザーのJavaScriptには、セキュリティー上ダウンロード元以外に通信できないという制約があります。この制約を乗り越えるための仕様がCORSです。ブラウザーのJavaScriptから制約有りのサイトにAjax通信が行われると、ブラウザーからCORSの仕様に基づき許可情報が要求されるので、サーバーは許可情報を返します。これにより、制約があるサーバーの通信を可能にします。

Libertyでは、CORSの仕様をサポートします。これにより、ブラウザーに対してRESTAPIを公開して他システムのアプリから利用してもらう事が可能になります。

LibertyでCORSを使用するには、server.xmlに<cors>を追加します。

<cors>に指定できるパラメータは、以下です。

allowCredentials ： ユーザー資格情報を要求に含めてもよいかどうかを示すブール値。

allowedHeaders ： 構成されたドメインに対する要求の作成時にオリジン・ドメインによる使用が許可されている HTTP ヘッダーのコンマ区切りリスト

allowedMethods 構成されたドメインに対する要求の作成時にオリジン・ドメインが使用することが許可されている HTTP メソッドのコンマ区切りリスト

allowedOrigins ： 構成されたドメインへのアクセスを許可されたオリジンのコンマ区切りリスト

domain ： ドメイン・ネームは、これらの CORS 設定と共にセットアップする URL を表します

exposeHeaders ： 呼び出し側 API に公開しても安全な HTTP ヘッダーのコンマ区切りリスト

maxAge ： プリフライト要求に対する応答を何秒間ブラウザーにキャッシュしておく

58

ことができるかを示す long 値

58

59

60