Microsoft .NET を使用して IBM i Web サービスを使用可能にする
.NET Framework を使用して IBM i の Web サービスを開発する
まずは最初に一言。タイトルに "Microsoft" と "IBM i" が付いた記事の場合、口うるさい IBM i コミュニティーの一団の中では、決まってある程度の反感、嘲笑、嫌悪感が生まれます。結局は、IBM は、ILE RPG や ILE COBOL の Integrated Web Server、Java 搭載 WebSphere Application Server、PHP など Web サービスを使用可能にするツールを提供しています。なぜ、嫌な気分にさせるような Microsoft 製品をそうした環境に持ってくるのでしょうか。
最初に、IBM は長きにわたって Microsoft アプリケーションと IBM i またそれ以前のシステムとの接続を簡単にできるようにしてきました。事実、IBM i との接続に必要なツールは、出荷されたどの IBM i にも無償で付属しています。殊勝なことに IBM は、IBM i サーバーをユーザーが使用できるようにするには、Microsoft .NET などあらゆる種類の外部環境からそのサーバーを簡単に使用できるようにすることだと認識しています。
次に、Microsoft .NET を使用して IBM i Web サービスを使用可能にすることを考える必要があります。ご使用の IBM i OS (以前の OS/400) バージョンでは制約があるかもしれないからです。IBM i 6.1 または 7.1 でシステムを使用できる一部の幸運なユーザーもいますが、多くのショップではいまだに IBM ツールを備えていない旧 V5 バージョンを採用しています。
3 つ目の理由は、私としてはこれが最もあてはまると思いますが、多くの IBM i ショップでは、IBM i と並行して Windows サーバーがアプリケーションを実行している混合環境を採用しているためです。そうしたショップには、IBM プログラミング・テクノロジーではなく、Microsoft .NET に精通した開発者が必要になる場合があります。
Microsoft .NET の使用を検討するよう自分を納得させるのではなく、単純に .NET Web サービス・テクノロジーを IBM i と併用する方法を紹介します。何が利用できて、IBM i と .NET がどのように相互作用するか理解できれば、Microsoft .NET を使用して IBM i Web サービスを使用可能にすることに賛成か反対か、優れた事例を積み上げることができるでしょう。
接続する
Windows アプリケーションはさまざまな方法で IBM i に接続できます。例えば、ソケット・プログラミング、WebSphere MQ (MQ Series)、IBM i Access API (データ・キュー、直接プログラム呼び出しなど)、IBM i データベース・プロバイダーなどがあります。この記事では、IBM i データベース・プロバイダーだけを取り上げます。これが、おそらくもっとも簡単で幅広く使用されている技法です。
現在、IBM はその IBM i Access for Windows 製品の一部として、3 つのデータベース・プロバイダーを配布しています。図 1 は、IBM iSeries Access for Windows V5R4M0 のComponent Selection ダイアログ・ボックスを示しています。Data Access コンポーネントの下にプロバイダーがリストアップされているのがわかります (IBM System i Access for Windows V6R1M0、また IBM i Access for Windows V7R1M0 でもプロバイダーは利用できますが、V5R4M0 バージョンを使用してコンポーネントを表示する方が簡単です)。
図 1: プロバイダーのリストを表示する Component Selection ダイアログ・ボックス
Component Selection ダイアログ・ボックスで、Data Transfer アイテムにのみ License Required にチェック・マークが付いている点に注目してください (ダイアログ・ボックスに表示されていない PC5250 コンポーネントもチェックが付いています)。これは、データベース・プロバイダーである ODBC、OLE DB Provider、.NET Data Provider が無償で利用できることを意味しています。
IBM i IFS または IBM i Access for Windows インストール・メディア (CD または DVD) から、データベース・プロバイダーをインストールできます。IFS からデータベース・プロバイダーをインストールする場合、IBM i ではプロバイダーは実行されない点に注意してください。Windows アプリケーションは IBM i では動作しません。
.NET アプリケーションを開発する場合、通常、.NET データ・プロバイダーを操作して、アプリケーションから IBM i データベースにアクセスします。SQL ステートメントの実行をサポートすることに加えて、.NET プロバイダーは .NET アプリケーションから IBM i のストアード・プロシージャーを呼び出すこともできます。ストアード・プロシージャーは、SQL プロシージャー (1 つ以上の SQL ステートメントを含む) または IBM i プログラムを呼び出す外部ストアード・プロシージャーのいずれかです。パラメーターを外部ストアード・プロシージャーに渡し、パラメーターを介して値を呼び出し元に返し、戻り値を設定して、結果セットを 1 つ以上返すことができます。外部ストアード・プロシージャーで、既存の IBM i プログラムを簡単に操作できます。
OLE DB プロバイダーを Windows PC またはサーバーにインストールする場合、実際には、IBMDA400、IBMDARLA、IBMDASQL の 3 種類の OLE DB プロバイダーをインストールしていることになります。1998 年に AS/400 に導入された OLE DB プロバイダーは、当時新登場したMicrosoft の OLE DB テクノロジーを操作するために作成されたものです。.NET アプリケーションでは、IBMDA400 プロバイダーまたは IBMDASQL OLE DB プロバイダーを使用する可能性が高いでしょう。これらのプロバイダーによって、SQL ステートメントを実行し、ストアード・プロシージャーを呼び出すことができます。IBMDASQL プロバイダーには、SQL トランザクションのサポートが組み込まれています。IBMDARLA プロバイダー (レコードレベル・アクセス) には、ファイルレベル操作を模倣する API が入っています (RPG 用語では、CHAIN、SETLL、READ/READE など)。IBMDARLA プロバイダーは .NET アプリケーションで使用できますが、今日のほとんどのアプリケーションが SQL を使用します。
ODBC ドライバーは、単に最も長く利用されているという点で、おそらく最も知られているデータベース接続オプションでしょう。
IBM i と相互作用するよう開発するほとんどの .NET アプリケーションの場合、使用頻度が高い順に .NET プロバイダー、IBMDA400 プロバイダーまたは IBMDASQL プロバイダー、ODBC ドライバーとなります。.NET プロバイダーは、.NET Framework 2.0 機能とうまく統合されています。ただし、IBM .NET プロバイダーは現在、Entity Framework に対応していません。OLE DB プロバイダーや ODBC プロバイダーよりも、.NET プロバイダーのエラー処理が優れている点で .NET プロバイダーを強くお勧めします。
.NET 環境で Web サービスを開発する
.NET で Web サービスを開発するには、開発環境とランタイム環境を明確に区別する必要があります。開発は、Microsoft Visual Studio を使用して PC またはラップトップ上で行われることがほとんどです。.NET Web サービスのランタイム環境は、ほぼ常時 Windows サーバー・システム上にあります。ここでは、Web サーバーは Internet Information Services (IIS) Web サーバーで動作します。図 2 は、この記事で説明している Microsoft および IBM のソフトウェアのバージョンを示しています。一般的に、一部の機能は最新版でのみ利用できますが、必要に応じてバージョンを組み合わせて使用することができます。
図 2: Microsoft および IBM ソフトウェアのバージョン
Microsoft は .NET Framework そのものは無償で提供しています。実行している Windows のバージョンに応じて、PC またはサーバーに、すでに複数のバージョンの Framework がインストールされている場合があります。
.NET 開発に他のツールや単純なテキスト・エディターおよびコマンドライン・ツールを使用するひねくれ者もいますが、.NET の開発は実質的に、Microsoft Visual Studio を使用することと等しいと言えます。Visual Studio の強みの 1 つに、複雑な Web サービス開発を断ち切ってくれる点があります。環境で必要な大量の低レベルインフラストラクチャーをハンド・コーディングしなければならない点には、ほとんど利点はありません。Visual Studio では大量のコードが必要になるため、アプリケーション・レベルで作業して、業務要件に合わせてコードを作成することに集中できます。Web サービスの開発と展開に対する Visual Studio のサポートは、IBM Rational Application Developer スイートで提供されるサポートと似ています (RAD を使用して Java Web サービスを開発しますが)。
図 3 は、IBM i に関して開発環境と展開環境を構成する方法を図式化しています。
主なチェックリスト項目で確認するものとして、開発環境で、実動アプリケーションで使用する Windows サーバー・システムにインストールされている .NET Framework および IBM i データベース・プロバイダーのバージョンが完全に一致しているかどうかという点があります。IBM .NET プロバイダーを使用しているというだけでは十分ではありません。同じバージョン (V6R1M0 バージョンなど) を使用しており、同じサービス・レベルの IBM i Access for Windows を操作していることを認識する必要があります。
開発マシンおよび実動マシンの .NET Framework またはデータベース・プロバイダーのバージョンやサービス・レベルが不一致だと、苛立つほど多くのエラーが発生します。開発マシンで完ぺきに動作するコードが、なぜ見事なほど実動サーバーで失敗するのか、十分に時間を掛けて判断できます。IBM i Access for Windows が、バージョンとサービス・レベル不一致の問題にさらに拍車をかけることになります。インストールできるその製品のバージョンは 1 つのみだからです (例えば V6R1M0 および V7R1M0 の両バージョンはインストールできません)。インストールに制限があるのも、開発者が、仮想マシン (VM) 環境を使用するのに十分な RAM (できれば 8GB) およびディスク・スペースがある PC を操作することをお勧めする理由です。リソースが十分にあれば、開発者のマシンは、展開環境に一致するの VM を 1 つ以上備えることができます。
Web サービスのリハーサル
.NET Web サービスを開発する方法を理解する最良の方法として、そのプロセスをリハーサルすることがあります。すべてのものが開発用 PC (Visual Studio 2010 および IBM i .NET プロバイダー) にセットアップされていると仮定して、IBM i データベースにアクセスできる Web サービスをすぐに開発できます。
Visual Studio 2010 で、図 4 に示すように新しいプロジェクトを開始します。
図 4: Visual Studio 2010 で新しいプロジェクトを開始する
ASP.NET Web Service Application プロジェクトを開始すると、Visual Studio は多少の初期コードを生成します (図 5)。この時点で、HelloWorld という Web メソッドを含む完ぺきに機能する Web サービスが出来上がります。
図 5: Visual Studio で生成される初期コード
ここで、特に魔法のようにコードが生成されるわけではありません。つまるところ、特定のターゲット・プログラミング言語の一連のテキスト文字列を吐き出す、単なるプログラムにすぎません (最もよく使用されている .NET 言語は Visual Basic と C# ですが、この記事の例では Visual Basic を使用しています)。図 5 で覚えておくべき重要な点は、HelloWorld は文字列を返す関数にすぎないということです。この関数を Web サービス対応関数にするには、Visual Studio で生成される他のステートメントともに、関数ステートメントのすぐ上に 属性を追加します。
関数の例を生成することで、Visual Studio は、自分の便利な Web メソッドをソース・コードにどのように追加できるか明確に示してくれます。別の関数またはサブルーチン (C# では、メソッド) をコーディングし、 属性を関数ステートメントの前に配置するだけです。アプリケーションをコンパイルするときに、WebMethods としてタグ付けされた関数は Web サービスで公開されます。内部だけで使用する関数は、タグ付けしないようにすることもできます。それらの関数は、Web サービスで公開されません。Visual Studio は陰で Web Services Description Language (WSDL) ファイルのコードと 、Web サービスで使用する Simple Object Access Protocol (SOAP) 要求および応答 XML を処理するコードを生成します。
Visual Studio には、Web サービスの組み込みテスト環境が組み込まれています。F5 (Run) キーを押してこの環境にアクセスできます。図 6 に、テスト環境を合成して示しています。テスト環境を開始すると、Visual Studio は組み込み Web サーバーを起動し、ブラウザー・ウィンドウが開きます。
図 6: Visual Studio のテスト環境の合成ビュー
通常、Web サービスには、ユーザー・インターフェースはなく、設計上、Web サービスはWeb ページに紐付けられていません。テスト環境では、図 6 のような Web ページは、単に開発とテストのためだけに生成されている点を理解することが大切です。Web サービスを実動サーバーに展開する場合、テスト・ページは Web サービス・コードに従いません。Visual Studio テスト環境内で提供されているだけです。
図 6 で一番左側のウィンドウは、使用可能な Web メソッドを一覧しています。この例では、HelloWorld Web メソッドのみ示しています。リンクをクリックして、HelloWorld Web メソッドのページに移動します (図 6 中央の 2 番目のウィンドウ)。そのページの Invoke ボタンをクリックすると、Web メソッドが実行され 3 番目のブラウザー・ウィンドウ (図 6 の右端) が開き、Web メソッドの実行結果を表示します。
繰り返しますが、.NET Web サービスを実行すると、図 6 のように、XML を表示するブラウザー・ウィンドウが開くと言いたいのではありません。図 6 で表示しているのは、単に Visual Studio テスト環境内に限ったテストおよびデバッグをするためのものです。XML が満載されたブラウザーをエンド・ユーザーに示すなど、誰も期待していません。通常、別のマシンで動作しているプログラムは Web サービスにアクセスします。結果生じる XML を消化するのは、Web サービスを呼び出すプログラムの仕事です。
図 7 は、さらに便利な Web メソッドの例 SelectCustomer を示しています。カスタマー番号が指定されている場合、この関数は IBM i の QCUSTCDT データベース・ファイルにアクセスします。カスタマー番号を見つけると、この関数は顧客のデータを含んだ DataSet オブジェクトを返します。
図 7: SelectCustomer Web メソッドの例
Visual Basic および .NET でデータベースにアクセスする方法の基本に精通していない場合、図 7 のコードはそれほど親しみやすく見えないでしょう。関数は 3 つのセクションで構成されています。最上部にある最初のセクションでは、メソッドに渡された customer パラメーターがすべて数値のフィールドかどうかチェックしています。そうでない場合、関数が戻ります。中央にある 2 つ目のセクションでは、接続する IBM i サーバーを特定する接続文字列が構成ファイルから取得されています。3 つ目のセクションでは、IBM i サーバーへの接続が開き、SELECT ステートメントが呼び出されています。有効なカスタマー番号が指定され、データが取得された場合、データは DataSet オブジェクトに移動します。このオブジェクトは関数から返されます。
図 8 は、テスト・ページおよび有効なオンファイル・カスタマー番号を記載したテストの結果ページを示しています。図 7 のコードと 図 8 の結果を比較すると、大量のコーディング、特に、取得したデータを Web サービスの出力結果となる XML にフォーマットするコーディングが陰でひそかに実行されていることが明らかになります。
図 8: Visual Studio のテスト・ページと結果ページ
XML 生成の自動化を迂回し、コード内で自分で生成することができます。ただし、図 7 のコードは、カスタマー・レコードの取得向けで、簡単に表されています。.NET データは構成体にアクセスします。フォーマットの結果生じる XML の「ノイズ」は、.NET で提供される Web サービス環境に委任されています。
Web サービスを取り込む
Web サービスの作成に加えて、Web サービスを取り込むアプリケーションを開発しなければならない時期がくるかもしれません。Visual Studio は、インフラストラクチャーの問題を解決するよりは、ビジネスでの利用を重視した Web サービス・コンシューマー・アプリケーションの生成をサポートしています。
図 9 は、Visual Studio で Web サービス・コンシューマー・プロジェクトを構成して Web サービスにアクセスする方法を合成して示しています。
図 9: Visual Studio で Web サービス・コンシューマー・アプリを構成する
図の番号 1 から始まり、プロジェクト (この例では WSConsoleTester) を右クリックし、Add Service Reference というアイテムを選択します。番号 2 で、すでに開発しテスト済みの Web サービスを選択します。外部でホストされた Web サービスにアクセスする必要がある場合、Add Service Reference ダイアログ・ボックスの Address ボックスにその WSDL への URL を入力します。番号 3 で、操作する Web サービスを表示して選択し、番号 4 で、Web サービス・リファレンスに名前を割り当てることができます。割り当てる名前は、Web サービス・クライアント・アプリケーションで使用されます。最後に、番号 5 で、WSConsoleTester プロジェクトに CustomerWS という名前の Service Reference が入っていることがわかると思います。
図 10 には、Web サービスにアクセスする Console アプリケーションのコードが入っています。カスタマー番号が要求され、SelectCustomer Web サービス・メソッドが呼び出されて、それにカスタマー番号が渡されます。Web メソッドから返された結果は、何らかのデータが入っているかどうか確認テストされます。
図 10: Web サービスにアクセスし、結果を表示する
例えば、無効なカスタマー番号 (すべて数値でない) またはファイルにないカスタマー番号を入力すると、何も返されません。データが返されると、Console アプリケーションは、Web メソッドから返された DataSet オブジェクトからそのデータにアクセスできます。図 11 は、テスト・プログラムの出力例を示しています。
図 11: 図 10 の Web サービス・コンシューマー・プログラムの出力
Windows Communication Foundation を使用した .NET Web サービス
.NET Framework 3.0 で Microsoft は、いくつか新機能を導入しました。主な追加機能として Windows Communication Foundation (WCF) がありました。WCF の前は、次のような複数の異なる手法を使用して、アプリケーション間のやりとりとしていました。
- TCP/IP ソケット
- Microsoft MSMQ (WebSphere MQ とほぼ同じ)
- Interprocess Communication
- .NET Remoting
- Web Services
- REST 対応 Web サービス
これらの通信手法にはそれぞれ、.NET Framework 内のクラスとして提供されている独自の API があります。各 API は異なるチームが開発しているため、API は .NET Framework 間で一致していませんでした。ソケットを使用してアプリケーションを開発する場合、MSMQ と動作させるためにアプリケーションをかなりの量、再コーディングしなければならない可能性が高くなります。
基本的に、各 API はソースから宛先へメッセージを移動する役割を果たしています。そうした目的を念頭に、Microsoft は、特定の通信手法のランタイム環境への割り当てを据え置くことができる抽象化層として WCF を設計しました。つまり、多くの場合、ターゲット・ランタイム環境とは完全に独立して、アプリケーションのビジネス・ロジックをコーディングできるということです。ランタイム環境は、ビジネス・ロジック・コードに適用された構成オプションを介して指定します。
WCF アプリケーション向けに作成するコードは、本質的に Web サービスの例にあるコードと同じですが、サービス契約 (実行する内容) およびデータ契約 (サービスから送信する内容) を定義するインターフェースが追加されています。XML ベースの構成ファイルまたはアプリケーション自体でプログラム的に WCF を構成できます。ほとんどの WCF アプリケーションは、XML ベースの構成ファイルを選びます。Visual Studio は起動構成ファイルを生成し、構成ファイル・エディターが .NET Framework ツール・セットの一部として提供されているためです。
異なるクライアント・タイプに同じ機能を提供しなければならない場合、Web サービスではなく、WCF を使用する場合があると思います。例えば、従来の WSDL/SOAP 対応 XML Web サービスの開発から開始する場合があります。その場合、前述の ASP.NET Web サービスまたは WCF Web サービスを選ぶことができます。Windows 環境では多くの場合、Windows 対 Windows 通信に対して要件があります。.NET クライアント・アプリケーションが .NET Web サービスを取り込むことがわかっている場合、(.NET Framework の早期バージョンでは「リモーティング」と呼ばれていた) .NET 固有版のサービスを使用できます。リモーティングは、使用しているサービス・コードが .NET 以外のクライアントと相互運用性がなければならない場合には利用できない、チューニングおよびメッセージ圧縮オプションを追加提供します。ユースケースの別の例として、Ajax 対応ブラウザー・アプリケーションに対して RESTful 版のサービス・コードを提供するという要件があります。
3 つの異なるサービス (Web サービス、リモーティング、REST) をコーディングするのではなく、WCF では 1 つのバージョンのサービスをコーディングできます。構成ファイル内で、異なるアクセス要件について 3 つのエンドポイントを定義します。各エンドポイントは、アプリケーションの同じ基礎コードを起動します。基礎サービス・コードのバージョンを 1 つだけ開発、テスト、最適化して、さまざまなユースケースに利用できるという利点があります。
従来の単純な Web サービスで、アプリケーションの要件を満たすことができるとわかっているならば、ASP.NET Web サービスを作成するでしょう。コード成果物が少なくてすみ、通常、はるかに簡単に構成できるためです。しかし、単純にすべての Web サービスを最初から WCF サービスとして作成する方が、メリットがある場合があります。どの作業アプリケーションも継続的に新しく、予見しがたい使用法にシフトしているのははっきりしており、WCF は .NET 環境における Web サービス・アプリケーションの最良の未来を保証します。
アセスメント: .NET の Web サービス
わずかな図と簡単なコード例を使って、この記事では .NET を使用していかに簡単に Web サービスを開発できるかを紹介してきました。それらの作業をうまく実行するのに必要な前提条件を説明するのは簡単ではありません。.NET を使用して IBM i で動作する Web サービス・アプリケーションを開発するには、スキルだけでなく、要件を現実的に査定する必要があります。
他のプログラマーとの共同作業で IBM i で .NET を使用する方法を示す場合、対処すべき次の 3 つの主題を重視したいと思います。
- 使用するプログラミング言語 (通常は Visual Basic または C#)
- .NET Framework 本体 (アプリケーション開発には Framework に多少精通している必要があります)
- 開発、テスト、デバッグにおける Visual Studio の効率的な使用方法
これら 3 つのスキル・セットは、.NET を使用したあらゆるタイプのアプリケーション開発に必要です。また、データベース・プロバイダーを操作して、.NET アプリケーションから IBM i にアクセスする方法を知るという別のスキルも必要です。
時間と労力を費やすにふさわしい
この 6 年間で、数百人の IBM i プログラマーと作業してきましたが、彼らの多くは数週間で .NET ツールが上達したことがわかりました。そのためには、主題を管理できるサイズにせばめる集中トレーニングが必要です。新しい環境での作業を学習する場合の最も重要な点は、数週間にわたる継続的な努力です。通常は、1 日に数時間、毎週一定の時間を確保するということです。わずかな概要が与えられただけで、苦も無くその環境に移行できる例外的なプログラマーもいるかもしれませんが、一般的には、私が見てきた限り成功した人は、時間と労力を投資することに専心してきた人です。
当然、ほとんどのショップでは、新しいスキル開発に時間を割くのは難しいと思います。しかし、Web サービスに取り組んでいこうとする場合、出くわすことのほとんどは新しく、今までのプログラミングとは異なっています。Web サービス・コードをテストし、デバッグすることで取り組み甲斐があることを証明できます。このために、Visual Studio、RAD、その他のツールなど、広範なサポートを提供する開発環境に取り組むのです。
Web サービス・プロデューサー・アプリケーションおよびコンシューマー・アプリケーションを開発する能力は、ほとんどのショップの要件で、今後数年において基本的なスキルになることは間違いありません。.NET Framework およびその関連ツールを使用して IBM i 向けの Web サービスを開発する場合、IBM i と簡単に統合され、包括的で、ツールを十分に備えた開発環境を獲得するでしょう。
