Oracle SALTには、WebアプリケーションをOracle Tuxedo内で実行し、HTTPサーバー・プラグインによって簡単にアクセスできるようにする機能があります。Apache 2、Oracle HTTP ServerおよびiPlanetなどのHTTPサーバーを使用することで、アプリケーションをワールド・ワイド・ウェブに直接公開できます。HTTPサーバーはOracle Tuxedo固有のプラグイン(
mod_tuxedoと呼ばれる)を使用する必要があり、このプラグインはHTTPリクエストをOracle Tuxedoリクエストに変換し、Oracle TuxedoレスポンスをHTTPレスポンスに変換します。
|
注意:
|
GWWSシステム・サーバーはマルチスレッドのプログラムなので、HPプラットフォーム上では、コンパイラの -mtフラグでマルチスレッディングを有効にしてプラグイン・ライブラリを構築する必要があります。 |
アプリケーションを記述するには、CGIと同様ですがOracle Tuxedoサーバーおよびその通信モードに固有のGatewayインタフェースをCまたはC++で使用するか、PHP、PythonおよびRubyなどの動的言語を使用します。動的言語を使用すると、プログラムではOracle Tuxedoで実行中であることは認識されないため、Symfony (PHP)、Django (Python)またはRails (Ruby)などのアプリケーション・フレームワークをOracle Tuxedoベースの環境で直接、再利用できます。
ネイティブOracle Tuxedo Webアプリケーションの開発
mod_tuxedoはWebリクエスト処理のOracle Tuxedoにおけるクライアント部分を提供しますが、Oracle Tuxedo側でリクエストを処理するメソッドの1つはそのリクエストに直接アクセスすることです。これは受信したバッファ、つまりOracle Tuxedo FML32型付きバッファの形式を記述することで可能になります。
このメソッドでは、Oracle Tuxedoサービスを開発することで動的HTTPコンテンツを生成し、その段階でOracle Tuxedo RASPおよび統合機能を利用できます。
HTTPリクエストの関連要素(メソッド名、問合せ文字列のURL、ファイル名、POSTデータなど)が公開されます。
mod_tuxedo (HTTPレスポンス・ヘッダー(必要な場合)、HTMLドキュメント)への戻りデータも同様です。
開発プロセスは、HTMLコードを生成する通常のOracle Tuxedoサービスの開発と同様ですが、異なる点はRESTfulサービスの開発が、サービスの動作を制御する一連の規則またはルールに準拠するということです(GETを処理するサービスはPUTの処理時と異なる動作をします)。RESTfulサービスは一般的に、HTMLブラウザを使用してアクセスできるように設計されていません(つまり、SOAPサービスと同様です)。
|
•
|
Apache2またはOHSプロセスが、 mod_tuxedoモジュールを使用して特定のURLを処理するように構成されます。 |
|
•
|
mod_tuxedoがリクエストをインターセプトします。
|
|
•
|
mod_tuxedoがリクエストをフォーマットしてOracle Tuxedoサービスに送信します。そのサービス名は SCRIPT_NAME値から導出されます。後で示す例で、該当するサービスは TUXSVCと名付けられます。
|
|
•
|
Oracle Tuxedoサービスがデータを受け取り、それを適宜処理します。 |
|
•
|
REQUEST_METHODには REST操作、すなわち GET、 PUT、 POSTまたは DELETEが含まれます。
|
|
•
|
PATH_INFOにはアクセスされるソースが含まれる場合があります。この例では"/1234"が含まれます。プログラムは、クライアントおよびサーバー間で文書化された規則に従ってこの値を解析して、アカウント番号を取得します。
|
|
•
|
QUERY_STRINGまたは POST_DATA ( GETまたは POSTの場合)には追加パラメータが含まれる場合があります。事前に決められた規則によって、パラメータの表記とその内容が制御されます。これはサービス開発者によって決定され、アプリケーション・ドキュメントとして発行されることで、クライアント・プログラムがこれらのサービスと通信するように開発できます。
|
|
•
|
Oracle Tuxedoサービスがレスポンスを構成し、これは暗黙的に mod_tuxedoに送り返されます。 |
|
•
|
mod_tuxedoがレスポンスをクライアント・プログラムに送り返します。
|
リスト3-1
OHSまたはApache2の構成(httpd.conf引用)
Tuxconfig "/home/maurice/src/tests/secsapp/work/tuxconfig"
Oracle Tuxedoサービスを
リスト3-2に示されているとおりに記述します
char val[1024]; /* TODO: query size first */
/* Fetch PATH_INFO value, which contains the resource */
rc = Fget32((FBFR32 *)inbuf, PATH_INFO, 0, (char *)val, &len);
/* Variable 'val' contains resource name, process it */
/* Fetch QUERY_STRING, which optionally contains
rc = Fget32((FBFR32 *)inbuf, QUERY_STRING, 0, (char *)val, &len);
/* Depending on method, do processing */
rc = Fget32((FBFR32 *)inbuf, REQUEST_METHOD, 0, (char *)val, &len);
if (strcmp(val, "GET") == 0) {
} else if (strcmp(val, "PUT") == 0) {
} else if (strcmp(val, "POST") == 0) {
/* Get POST_DATA, parse it */
} else if (strcmp(val, "DELETE") == 0) {
/* Compose return document, using xml or JSON */
/* Return result document */
tpreturn(TPSUCCESS, 0, result, 0L, 0);
リクエストURL:
http://myhost/ACCOUNT/1234
|
注意:
|
XML生成は既存の libtxmlを使用して実行できます。 |
<customer name="John Smith"/>
|
注意:
|
JSONの生成はJSON-Cを使用して実行できます。JSON-Cは無償で再配布可能なCでのJSON実装(MITライセンス)で、ソース・コードとして提供されています。多くのライブラリが多数の言語(PHP、Perl、Python、Ruby、Javaなど)に存在します。 |
WEBHNDLR Oracle Tuxedoシステム・サーバー内でのPHPアプリケーションの実行方法と同様に、Oracle SALTではWeb用のアプリケーションをPythonで記述できます。PHP (すべてのスクリプトがCGI同様のモデルで実行するように設計されています)とは異なり、Pythonでは特定のWebレイヤーを使用した実行が必要です。
このレイヤーはWSGI (Web Server Gateway Interface)として示され、言語に組み込まれます。これは事実上のPython仕様(PEP 333)です。Pythonでは、アプリケーションがWSGIに対して記述されますが、完全なアプリケーション・フレームワークが使用可能です(WSGIに準拠。Djangoが最も一般的である傾向があります)。
次の項では、Python WSGIアプリケーション(Djangoフレームワークの使用を含む)を実行するために
WEBHNDLRを構成する方法について説明します。
|
•
|
Pythonは共有ライブラリを有効にして構築されている必要があります。通常、初回のインストールではこのような設定になっています。ソースから構築する場合は、 --enable-sharedオプションを構成手順で使用する必要があります。 |
|
•
|
一般的なデータベースまたはサードパーティ・ライブラリのサポートの制約はありません。 |
def application(environ, start_response):
form = cgi.FieldStorage(fp=environ['wsgi.input'],
write = start_response('200 OK', [('Content-type', 'text/html')])
if form.getvalue('name'):
write('<html><head><title>Hello!</title></head>\n')
write('<h1>Hello %s!</h1>\n' % form['name'].value)
write('<html><head><title>Who is there?</title></head>\n')
write('<h1>Who is there?</h1>\n')
write('<form action="%s" method="POST">\n' % environ['SCRIPT_NAME'])
write('What is your name?<br>\n')
write('<input type="text" name="name" value="%s"><br>\n'
% cgi.escape(form.getvalue('name', ''), 1))
write('<input type="submit" value="That is my name"></form>\n')
write('</body></html>\n')
Djangoなどのフレームワークでは、これはハンドラ・スクリプトで実行されます。このスクリプトはアプリケーション開発者には表示されません。
あらゆるPython WSGIアプリケーションは、次の手順に従って
WEBHNDLRシステム・サーバー内で実行される可能性があります。
|
1.
|
Apache (またはOHS)を構成してリクエストを WEBHNDLRに転送します。必要とされる静的ファイル(例: 画像、CSSスタイルシートまたはjavascriptファイル)へのパスを示すために、追加的な構成が必要になる場合があります。 |
|
2.
|
アプリケーション・パスを PYTHONPATH環境変数に追加します。 |
|
3.
|
WEBHNDLRに対するAPP_CONFIGを設定して、アプリケーションまたはミドルウェア・ハンドラをロードします(Djangoなどのフレームワークが対象)。
|
リスト3-6に、WSGIアプリケーションのためのApache構成の例を示します。
リスト3-6
スタンドアロン・スクリプト/アプリケーションの例
<VirtualHost 10.143.7.223:2280>
DocumentRoot "/media/src/tests"
<Directory "/media/src/tests">
Tuxconfig "/media/src/TUX11g/web/tests/tuxconfig"
スタンドアロンWSGIアプリケーションのためのubbconfigファイルおよび設定は、
test_app.py (==module)という名前のスクリプト内にあり、これは
/media/src/testsディレクトリ内にあります(
PYTHONPATHには
/media/src/testsが含まれる必要があります)。
WEBHNDLR SRVGRP=PHPGRP SRVID=1 MIN=5 MAX=8
CLOPT="-A -- -l Python -S PYWEB "
WEBHNDLRを起動する前に次のいずれかを実行してください。
|
•
|
APP_CONFIGを test_app (UNIXの場合は 'export APP_CONFIG=test_app')に設定、または
|
|
•
|
ENVFILEを値 APP_CONFIG=test_appとともに使用。
|
Apache Djangoベースのアプリケーションについては、RewriteEngineルールとAliasに注意する必要があります。これらは、
リスト3-7に示すように、静的ファイル(例: CSS、画像またはjavascript)の場所を示し、ルートURLをアプリケーションにマップ(最後のRewriteRuleを参照)するために存在します。
リスト3-7
Djangoベースのアプリケーション
<VirtualHost 10.143.7.223:2280>
DocumentRoot "/media/src/test_django/mysite"
Alias /media /usr/lib/python2.5/site-packages/django/contrib/admin/media
<Directory "/media/src/test_django/mysite">
Tuxconfig "/media/src/TUX11g/web/tests/tuxconfig"
RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ /mysite/$1 [QSA,L]
環境変数
DJANGO_SETTINGS_MODULEは、
WEBHNDLRを起動する前に設定する必要があります。たとえば、
mysiteというアプリケーションでは次のようになります。
DJANGO_SETTINGS_MODULE=mysite.settings
Djangoの例のための
PYTHONPATH 設定は、
mysiteと呼ばれ、
/media/src/test_djangoディレクトリ内に存在します。
PYTHONPATH=/media/src/test_django
Djangoの例のためのubbconfig設定はここで記述されています。
WEBHNDLR SRVGRP=PHPGRP SRVID=1 MIN=5 MAX=8
CLOPT="-A -- -l Python -S PYWEB"
WEBHNDLRを起動する前に次のいずれかを実行してください。
|
•
|
APP_CONFIGを django.core.handlers.wsgi ( WSGIHandler) (UNIXの場合は 'export APP_CONFIG="django.core.handlers.wsgi ( WSGIHandler)"' )に設定、または
|
|
•
|
ENVFILEを値 APP_CONFIG=" django.core.handlers.wsgi ( WSGIHandler)"とともに使用。
|
WEBHNDLR Oracle Tuxedoシステム・サーバー内でのPHPアプリケーションの実行方法と同様に、Oracle SALTではWeb用のアプリケーションをRubyで記述できます。PHP (すべてのスクリプトがCGI同様のモデルで実行するように設計されています)とは異なり、Rubyでは特定のWebレイヤーを使用した実行が必要です。
WSGIに相当するもの(Rackと呼ばれます)が存在しますが、これは別個にインストールされるライブラリの形式で実行されます。Rubyでは、アプリケーションがRackの最上部に直接記述される場合がありますが、Railsなどの完全なアプリケーション・フレームワークが使用可能です。Rackアプリケーションは、Rubyに対するアプリケーションおよびサーバー間のインタフェースです(WSGIと同様)。これは通常、言語へのアドオンとしてインストールされ、Railsなどのアプリケーション・サーバー環境に対する前提条件となります。次の項では、Ruby Rack準拠のアプリケーション(Railsフレームワークの使用を含む)を実行するために
WEBHNDLRを構成する方法について説明します。
|
•
|
Rubyは共有ライブラリを有効にして構築されている必要があります。通常、初回のインストールではこのような設定になっています。ソースから構築する場合は、 --enable-sharedオプションを構成で使用する必要があります。 |
|
•
|
一般的なデータベースまたはサードパーティ・ライブラリのサポートの制約はありません。 |
リスト3-8では、簡単なRackアプリケーションの例を示します。
[200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
Rubyなどのフレームワークでは、これはハンドラ・スクリプトで実行され、アプリケーション開発者には表示されません。
リスト3-8内のスクリプトはRackUpスクリプトを使用してハンドラに渡されます。RackUpスクリプトではさらに機能性(かなりの例外、LINTラッパーなど)をアプリケーションに追加できます。
アプリケーションをロードしているRackUpスクリプトの例を
リスト3-9に示します。
あらゆるRuby Rack準拠のアプリケーションは、次の手順に従って
WEBHNDLRシステム・サーバー内で実行される可能性があります。
|
1.
|
Apache (またはOHS)を構成してリクエストを WEBHNDLRに転送します。必要とされる静的ファイル(例: CSSスタイルシートまたはjavascriptファイル)へのパスを示すために、追加的な構成が必要になる場合があります。 |
|
2.
|
WEBHNDLRを構成して、アプリケーションまたはミドルウェア・ハンドラをロードします(Railsなどのフレームワークが対象)。
|
リスト3-10に、Apache (またはOHS)の構成の例を示します。
リスト3-10
Apache (またはOHS)の構成の例
<VirtualHost 10.143.7.223:2380>
DocumentRoot "/media/src/tests"
<Directory "/media/src/tests">
Tuxconfig "/media/src/TUX11g/web/tests/tuxconfig"
ubbconfigファイルの
WEBHNDLR設定は次のとおりです。
WEBHNDLR SRVGRP=PHPGRP SRVID=1 MIN=5 MAX=8
CLOPT="-A -- -l Ruby -S RBWEB"
Apache (またはOHS)構成については、
RewriteEngineルールおよび(
SetHandlerとは反対に)
AddHandlerディレクティブに注意する必要があります。これらは、
リスト3-11に示すように、HTTPサーバーを静的ファイル(CSS、画像、javascriptなど)にリダイレクトするために存在します。
リスト3-11
Ruby Railsアプリケーション
<VirtualHost 10.143.7.223:2380>
SetEnv RAILS_RELATIVE_URL_ROOT /media/src/rails_test
DocumentRoot "/media/src/rails_test/public"
RewriteRule ^(/stylesheets/.*)$ - [L]
RewriteRule ^(/javascripts/.*)$ - [L]
RewriteRule ^(/images/.*)$ - [L]
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ /rails3.tuxrb [QSA,L]
<Directory "/media/src/rails_test/public">
AddHandler tuxedo-script .tuxrb
Tuxconfig "/media/src/TUX11g/web/tests/tuxconfig"
ubbconfigファイルの
WEBHNDLR設定(Railsアプリケーションが
/media/src/rails_testディレクトリで設定され、
RailsTestと名付けられていることが前提)は、次のようになります。
WEBHNDLR SRVGRP=PHPGRP SRVID=1 MIN=5 MAX=8
CLOPT="-A -- -l Ruby -S RBWEB'.That is, remove the "-a /media..." portion
WEBHNDLRを起動する前に次のいずれかを実行してください。
|
•
|
APP_CONFIGをRack Upスクリプトへのパスに設定(UNIXの場合は' export APP_CONFIG=" /media/src/rails_test/config.ru"')するか、 ENVFILEを値 APP_CONFIG=" /media/src/rails_test/config.ru"とともに使用します。
|
PHPスクリプトは
WEBHNDLRで直接サポートされているため、アプリケーションをOracle Tuxedo環境で実行するための変更は特に必要ありません。HTTPサーバーにおけるPHPスクリプトの場所の変更だけで十分です。
WEBHNDLRでPHPスクリプトを実行するようにフレームワークが一度設定されると、PHPアプリケーションは自動的にサポートされます。
|
•
|
PHPは--enable-embed構成オプションを使用して構築されている必要があります。 |
|
•
|
一般的なデータベースまたはサードパーティ・ライブラリのサポートの制約はありません。 |
PHPスクリプトは
WEBHNDLRで直接サポートされているため、アプリケーションをOracle Tuxedo環境で実行するための変更は特に必要ありません。HTTPサーバーにおけるPHPスクリプトの場所の変更だけで十分です。
WEBHNDLRでPHPスクリプトを実行するようにフレームワークが一度設定されると、PHPアプリケーションは自動的にサポートされます。
(
リスト3-12に示されている)"
test.php"という名前のスクリプトを、HTTPサーバーのドキュメント・ルート・フォルダ内に配置します。
-- listing x-x test.php script
ブラウザで次の場所を指定します。
http://<your_host>:<port>/test.php
