1234

iAPのおさらいとして、構成に関する説明を行います。

5

iAPでは、アーキテクチャを刷新しました。
これまでiWPに存在したバックエンドサービスの構成を見直し、各サービス機能の改修を実施しております。
また、これまでバックエンドサービスを個別に用意していた部分を見直し、バックエンドサービスを内包するアーキテクチャに変更しております。
また、JavaEE技術におけるJavaEE6 WebProfile環境で動作するよう改修を実施しました、
既に仕様が公開されているJavaEE7、仕様検討中であるJavaEE8等にも追随出来るよう設計されております。
現行では、JavaEE6に対応しているResin, WebSphere, Weblogicに対応しています。
アーキテクチャの刷新とともに、これまでの内部構造を見直し、モジュールという単位での機能分割を実施しております。
これにより、機能単位でのパッチ提供、機能間の連携部分、互換性の向上を行うことが出来ました。

6

バックエンドサービス部分の変更を詳細に説明します。
これまでのiWPでの構成は図のような構成となっていました。

7

この構成は、すべてのサービスは必ずServer Managerにより管理されています。
そして、バックエンドサービス及びサーバマネージャが単一障害点となっておりました。
バックエンドサービス自体は、アクティブスタンバイ構成を組むことが可能でしたが、Server Managerに関しては行えませんでした。

8

iAPではこれまでの構成を見直し、図のように各機能がお互いに監視し、協調動作を行う仕組みとなりました。
Server Manager及び一部のサービスは残っていますが、iAPの仕組みに内包される形となりiAPを構成するクラスタの中で自動的に割り当てられる仕組みに変更されています。

9

Server Manager及び、各サービスの変更点に関して説明します。
分散環境では、自動的にServer Manager及びServiceが特定のサーバ上で起動します。
Server Manager及びServiceの起動場所に関しては設定により指定する事も可能ですがデフォルトでは全てのサーバ上で自動的に選出されるようになっております。

10この状態において、特定のサーバがダウンした場合、そのサーバ上で動作していたサービスは停止してしまいます。

11

iAPでは、サーバの停止を検出すると、自動的に残る他のサーバ上で停止したサービスを起動し処理を継続します。
これにより、これまで存在した単一障害点が無くなります、またサーバの追加も容易に行えるようになっております。
(サーバ停止の検出及びサービスの切り替えには数秒〜10秒程度を要します。)(図にしますと構成に大幅な変更があるように見えますが、これまでの各サービスの持つ機能等は互換性を保っている状態ですので利用する側からは大きな変更点はございません。)

12システムの全体図です。
iAPでは今回のアーキテクチャ変更により、これまでよりクラウド環境での運用が行い易くなっております。
負荷状況に応じた動的なサーバ追加による水平スケールが可能となっています。
また、これまでiWPでは全てのサーバに対してインストール作業が必要でしたが、iAPではwarファイルをデプロイすることにより全てのサーバに対してデプロイされた内容が反映されます。
また、im‐Jugglingツールにより任意の機能の追加、パッチの適用等が一括で行えるようになり、これまでそれぞれのサーバにインストールしていた作業が全て不要となっております。

13

次にモジュールに関して説明します。

14

iAPでは、図のような粒度で機能を分割し、モジュール化を実施しました。
これまでiWPでは、エディションによる差異はありましたが、全ての機能がインストールされる形式をとっておりました。
iAPではこれらのモジュールを任意に付け外し出来るようになりました。

15

モジュールは依存関係を持ちます。
例えば、Forma Designerはim‐Workflowと連携しています、その為Forma Designerはim‐Workflowに依存しています。
また、Forma, im‐Workflow共にスクリプト開発モデルによる実装が行われている為、それぞれのモジュールはスクリプト開発モデルに依存しています。

16

内部的なモジュールの依存関係の例です。
このようにモジュール間の依存関係を全て見直し、かつそれぞれのモジュールにバージョンを持たせることにより機能変更、機能追加における影響度の把握が可能となり、また部分的なパッチの適用等が実現できるようになりました。

17

次にアプリケーションです。
これは一般的にアプリケーション/エクステンションという形のこれは、一般的に複数のモジュールを組み合わせた製品という形をとっています。
例えば、iAC, iAD, BIS, Forma等がそれに該当します。
アプリケーションは、それぞれアプリケーション間の依存関係を持ちます。
例えば、BISはFormaを利用していますので、BISとFormaの間には依存関係が存在します。
また、それぞれのアプリケーションのバージョンによる組み合わせも全て管理しています。

18

これらのモジュール、アプリケーションは全てim‐Jugglingツールにより管理されます。
このim‐Jugglingツールは弊社が管理するリポジトリからアプリケーション、モジュールの配信を受けとります。

19

次に、iAPでの開発についてご紹介致します。

20

iAP上で何か動作するアプリケーションを作成される場合には、ユーザモジュールという形で独自のモジュールを作成して頂く方法を推奨しております。
ユーザモジュールは、iAP上で動作するアプリケーションに関する資材、例えばhtml,javascript, css等を纏めてパッケージングしたものとなっております。
このユーザモジュールをim‐Jugglingを利用して組み込んでいただくことを推奨しております。

21

ユーザモジュールを利用するメリットは以下の通りです。
可搬性の向上モジュール化することにより、必要な資材の持ち運び、やりとりが用意になります。
例えば、プロジェクトを横断して利用される汎用的な機能をお持ちの場合等が考えられます。
次に依存関係の設定
ユーザモジュールは、どのモジュールに依存しているか、どのバージョンで動作するか等の依存関係の設定を埋め込むことが可能です。
これにより、動作が保証されている環境上にのみ組み込むことが出来るようになります。
最後に環境構築面に関して、iAPでは、WebサーバとしてIIS, Apacheをサポートしています。
これらのWebサーバには通常静的なファイルを配置し、APサーバは動的なリクエストのみ捌くような構成を組むことが可能ですが、im‐Juggling, ユーザモジュールを利用する
ことにより、静的ファイルのみの抽出であったり、スタンドアロン構成の為に全てのファイルを抽出する事が可能となります。

22

次にユーザモジュールを作成していく流れに関して説明します。
一般的にユーザモジュールを作成する場合、モジュールプロジェクトを作成します。
このモジュールプロジェクトは、通常eBuilderで作成されるかと思いますが、一部限定公開という形でApache Mavenを利用した開発をサポートするためのMavenリポジトリを公開しております。
モジュールプロジェクトを作成後、弊社が推奨しております3つの開発モデル、スクリプト開発、SA, Terasoluna等を利用して頂きながら開発を進めて頂きます。
開発部分に関する詳細に関しては割愛させて頂きます。

23

次に、作成した成果物をパッケージングします。
これにより、ユーザモジュールファイルが作成されます。
作成されたユーザモジュールをim‐Jugglingを利用して組み込んで頂く流れとなります。
Im‐Jugglingを利用してユーザモジュールを組み込む形となりますが、弊社、開発者ブログにてAntスクリプトによるwarファイルの出力も紹介しておりますのでご覧ください。

24

次に製品に関するカスタマイズに関して照会致します。

25

製品のソースコードは、製品情報一覧よりダウンロード可能となっております。

26

まず、カスタマイズに辺り、im‐Jugglingの機能を紹介させて頂きます。
カスタマイズを行う際に、iAPでは全て機能がモジュールという単位に分かれておりますので、カスタマイズ対象のモジュールがどれかを探す場合があるかと思います。
Im‐Jugglingには、warファイルを出力するウィザードにて、設定されているモジュール構成をExcelファイルで出力する機能があります。

27

Excelファイルにモジュール構成を出力しますと、モジュール毎にどのようなファイルが含まれているか一覧が出てきますのでこちらからカスタマイズ対象のモジュール、ソースを探していただくことが可能です。

28

次にim‐Jugglingからwarファイルを出力する際の流れを説明します。
im‐Jugglingからwarファイルを出力する場合、構成されるモジュールの依存関係を元に、モジュールの展開順序が決定されます。
この例では、Formaはim‐Workflowに依存し、im‐Workflowはスクリプト開発に依存しているという例ですが、モジュールの展開順序は、依存されているモジュールから先に展開されます。
この場合は、スクリプト開発が先に展開され、その後im‐Workflow, Formaの順に展開されます。

29ユーザモジュールを作成される場合、そのユーザモジュールの依存関係を設定することが可能です。
これは、製品のカスタマイズを行ったユーザモジュールを作成する場合、カスタマイズ対象となるモジュールに対して依存関係を記述することにより必ずカスタマイズ対象のモジュールの後にユーザモジュールが展開されるようになります。
この例では、先ほどの依存関係にと共に、ユーザモジュールとしてFormaに依存しているユーザモジュールを追加した例です。
ユーザモジュールはFormaに依存しているため、Formaが展開後にユーザモジュールが展開されるようになります。

30

カスタマイズの際に注意して頂きたいのは、この依存関係を記述していなかった場合展開順序がカスタマイズ対象よりも前になってしまう場合がありますのでご注意下さい。

31

次に、開発モデル毎のカスタマイズ方法について紹介します。

32

スクリプト開発モデルでは、ソースコードを配置するディレクトが標準で4つ存在します。
Src: 独自開発のアプリケーションを配置するディレクトリです、このディレクトリはインタプリタで動作します。
Product: アプリケーション/エクステンションに関するソースコードが配置されるディレク
トリです。
Compatible: 互換モジュールのソースコードが配置されるディレクトリです。
Platform: iAP本体のソースコードが配置されるディレクトリです。

33

これらのディレクトリは、スクリプト開発モデル実行時に順番にソースコードの検索が行われます。

34

その為、iAP本体のソースコードをカスタマイズする場合、直接そのファイルをカスタマイズする必要はなく、カスタマイズ対象のソースコードをsrcディレクトリ配下にコピーし、そのファイルを修正することにより本体に変更を加えること無くカスタマイズを行うことが出来ます。

35

次に、Java言語により実装されているフレームワークを利用したカスタマイズ方法を紹介します。

36

まずはじめに、これはスクリプト開発モデルも含まれますが、intra‐martではPlugin機能を利用した拡張が行えるよう拡張ポイントが存在します。
拡張ポイントに対する設定ファイルを記述することにより任意の処理を埋め込むことが可能となります。

37

拡張ポイント以外に、iAPではAPIの内部実装においてServiceLoaderを利用しています。
ServiceLoaderは、APIの処理に対する実装を差し込めるような仕組みとなっております。
その為、特定のAPIの動作を変更したい場合において、元のソースコードを修正すること無く実装の差し込みを行うことが可能です。

38

上記の方法以外で、直接ソースコードをカスタマイズする必要がある場合には、classesディレクトリにクラスファイルを配置します。
これは、Resin上でのクラスをロードするディレクトリの順序です。

39

Servletの規約により、classesディレクトリは、libディレクトリより先にクラスがロードされます。
その為、カスタマイズしたクラスファイルをclassesに配置することによりその部分のみ差し替えることが可能です。
弊社では、以前Strutsの脆弱性の際に公開したパッチや、特定のお客様向けにお出ししている個別パッチなどでこの差し替えを行っております。

40

ここまでお話しましたカスタマイズ方法を利用し、iAPのカスタマイズを実施されましたらそのカスタマイズ部分の差分のみをユーザモジュールとしてモジュール化します。
Warファイルをデプロイ後、カスタマイズ部分のコードを直接配置される等の方法に関しては推奨しておりません、こちらの方法を実施された場合、変更の追随が困難となる、分散環境の自動スケール等が行えない等のデメリットが存在します。

41

iAPにおけるカスタマイズ方法の紹介でした。
また、弊社では、パートナー様の開発におけるご相談を承っております。
今回お話させて頂いた中で、一部キーワードとして出てきましたApache Maven、Mavenを利用した自動ビルドでしたり、Jenkins等と組み合わせたCIの実現方法等を既に何社かのパートナー様とお話させて頂いております。
また、弊社内における開発の自動化等も直接ご覧頂きながらご紹介できますので興味お持ちになられましたら是非お声がけください。
以上がiAPにおける開発に関する内容となります、ご清聴有難うございました。

42

43