2023年12月1日 チャーリー・グアリーノ
IBM i上のAPIの日常的価値について、開発者レイニア・サジュー氏と進行役のチャーリー・グアリーノ氏が議論します。
文字コード変換の重要性
チャーリー・グアリーノ（以下、チャーリーと略記します）：
レイニア、私達が対処しなければならない問題の1つは分かっています。そして、多くの人が対処しなければならない問題は、文字セット、文字セットの違い、通信相手によって変わる CCSID だと思いますが、API を使用したプログラミングに取り組むときに、これらが現実的な問題になるのはなぜでしょうか?
レイニア・サジュー（以下、レイ二アと略記します）：
CCSID が問題になる最大の理由は、IBM が EBCDIC を使っているのに他のメーカーがほとんど使っていないからです。外部から取得するほとんどすべてのデータは、IBM i 上で使い慣れているものと同じ文字セットではありません。なぜなら IBM i 上のすべてが EBCDIC だからです。通常は UTF-8 を扱いますが、場合によっては ASCII にも遭遇することがあり、そのことを認識しておく必要があります。なぜなら、データを設定したり比較したりするとき、同一のものを比較するために、データを変換し戻したり、データをハッシュ、保存、圧縮したりする場合、間違いなくデータが正しい形式であるようにしたいからです。
IBM i は、変数の宣言に CCSID を適用できるようにして、このような作業を容易にしています。これを適用して、「この文字は UTF-8 でいい、これは EBCDIC でいい」と言うことができます。あるいは、デフォルトが EBCDIC で、「ああ、これは ASCII です」と言うと、変数間でデータを移動することで一種の変換ができます。IBM i は親切にもそれを変換してくれるでしょう。ただし、特に UTF-8 から EBCDIC に移行する場合、UTF-8 の文字セットは非常に大きいことに注意する必要があります。
すべての文字が EBCDIC で表現されるわけではありません。そしてそれは、実際に SQL 関数呼び出し間のもう1つの相違点です。Java版では、変換方法が分らない場合に独自の特殊文字をスローしますが、SQL版ではデフォルトの IBM 流の処理が行われます。そのため、変換できないUTF-8 やデータがある場合は、データの中にX’15’が入ることを認識しておく必要があります。X’15’を使用してそのデータを EBCDIC フィールドに取り込もうとすると、多くの場合IBM i は「それは文字データではない」とためらうでしょう。そのため、多くの場合、X’15’を削除するか、X’15’を空白に変更するか、別の文字に変更してこの時点で変換できないデータがあったことを処理プロセスの下流の人が後で知ることができるようにする必要があります。
チャーリー：
ということは、この会話の内容は無視できない話題だということです。
レイニア：
ええ（笑）、これは無視できません。前に述べたように、ビジネスの性質上様々な文字セットを扱うことができ、文字セットが異なれば言語も異なる可能性があるからです。アジア等の外国語や様々な CCSID をもつ様々な楔形文字等に興味を持ち始めると、それらを扱うことになります。 CCSID はこれらすべてにおいて大きな役割を果たしており、相互に変換する方法を理解できる必要があります。あなたは、何かを圧縮したり、ハッシュしたり、変換したり、Base64エンコードまたは URL のエンコードなどのコマンドを使用したりしている場合、間違いなく正しい CCSID を使ってエンコードする必要があります。相手が ASCII を使っていて相手側でハッシュ検査を行っている場合、同じ値が得られるように間違いなく ASCII でエンコードしたいと思うはずです。ハッシュしたけれどそのデータを ASCII に変換していないせいで問題を抱えた人を多く見てきました。彼らはそれをハッシュしなければならず、次にそれを送信しますが、それは一致しません。なぜなら、EBCDICハッシュを ASCIIハッシュと混ぜこぜにしており、それらは同じではないため問題が発生します。
チャーリー：
私には CCSID 及び様々な状況下で実際に CCSID に対処する方法を専門に説明する別のポッドキャストを作成する必要があるように思えます。
レイニア：
ええ、本当に無味乾燥な（笑）会話がお望みなら。なぜなら、それはそういうものですから。
チャーリー：
あなたがそれを言うのは面白いですね。なぜなら、私は多くのカンファレンスが正にこのテーマに関するセッションを行うのを尻込みするかもしれないと知っているからです。その理由は、多分あなたが言う様に非常に無味乾燥なものだからでしょう。でも、「どうしたらそれを無視できるの?」という感じです。それはこのトピック全体の非常に重要なポイントです。
レイニア：
そうですね。私はそれが大きな落とし穴だと考えていますが、通常ユーザーやプログラマー、開発者が一度それに気付いたら、つまり一度それに足を踏み入れたら、それを知りそれに対処し始める方法を知ることになります。なぜなら、一度ある文字セットを扱えば、別の文字セットを扱うことはその点で全く同じだからです。
チャーリー：
そうですね。彼らはそれらが実際に何であるかを理解する練習をしているところです。
レイニア：
はい、それを理解し、エラーが発生したときにそれを追跡して何が起こっているのかを認識する練習をしているところです。先に述べたように、これは Java ベースの SQL HTTP関数間の違いです。Java の場合はそれを後続の処理で継続処理できる文字に変換していましたが、新しい関数を使用していてそれを EBCDIC フィールドにスローしようとした場合、変換エラーが発生して「このフィールドにデータを入力しようとしていますが、入力できません」と言われ、SQLエラーになります。そこにはX’15’かそれに似たものが入っているのですが、間違いなくそれは動作しないので何かをする必要があります。
チャーリー：
分かりました、話を続けましょう。API の使用を開始している顧客がいる場合、進行状況を監視したり、エラー処理のためにエラーを追跡したりするために自由に使えるツール、例えばロギング等が他にありますか? これらの API を実装して稼働させるために使える利用可能なツールは何ですか?
レイニア：
モニタリング等のものに関して言えば、SQL関数を使用している場合、私はできるだけ多くの情報を取得できるようSQL関数の詳細バージョンをよく使用し、それをログに記録します。私達はよくデータベースファイルよりもIFS に記録します。場合によってはデータベースファイルに保存することもありますが、通常は IFS に保存しています。先に述べたように、UTF-8 と ASCII でデータを取得していますが、IFS はこれらの CCSID をより遥かにネイティブにサポートしているので、そのログを記録するのは簡単です。つまり、データを取得してそこにダンプするだけであり少し楽です。ホスティング等に関しては IWS が提供します。デバッグ機能とログ機能をオンにすると、リモート IPアドレスが取得できます。私達がログに記録し、データベースに保存しているもっと多くの接続情報が取得できます。そのため、誰がどのくらいの頻度で接続しているかを確認できます。スロットリングについては前にも触れましたが、これは新しい話題かもしれません。基本的に誰かがあなたのマシンをあまりにも頻繁に攻撃している場合、その人の速度を下げたいと思うでしょう。
スロットリングへの対処
チャーリー：
スロットリングを見たことがあります。例えば、間隔の短いループがあり、とても短時間の内にAmazon に大量のアクセスを発生させた場合です。彼らはスロットリングで有名ですが、サービスがスロットリングされているとはどういう意味ですか?
レイニア：
それは、あなたがちょっと良からぬことを企んでいるかもしれないことを意味します。一定期間内の要求が多過ぎ、基本的に彼らはあなたの速度を下げようとしています。彼らはただ、自分達にとってそれをより管理しやすいものにしたいだけで、あなたの要求ですべての資源が独り占めされないこと及びその要求を処理する際に、確実に他の全員に公平な取り扱いをすることを望んでいます。
チャーリー：
そうですね、それを何とかコード内で処理する必要があります。まずスロットリングされているとの認識をして、次に何とかそれに対処できる必要があります。どのように我々の顧客に対してそれを行うのでしょうか?
レイニア：
私達の顧客ですか? 私は、ログをループし続けてタイムスタンプを監視し、平均して1分または指定された時間枠内で要求が何回受信され、応答時間がどれ位か、そして大規模な大量の要求をしているかあるいは単に小さな要求をしているかに応じて、時々要求時間の長さを確認するプログラムのようなものを開発しました。私達は、あまりにも多くの人々が巨大な要求をするのを望まないし、またピン刺しのような小さな要求をする人々も望まないという立場で均衡を保ちます。
チャーリー：
それはサービス提供側の話ですね。ここで私達は利用と提供という方程式の両面について話していると思います。私達は行ったり来たりしています。できれば、サービスを利用する側にもう一度集中しましょう。なぜなら、私達は世の中の一部の人によってスロットリングされているのを知っているからです。
レイニア：
あなたが言ったように、Amazon はそれで有名です。基本的に Amazon にメッセージを送信すると、メッセージが返されます。Amazon は、あなたをスロットリングしていると伝えており十分親切です。彼らはあなたに HTTPコードを返し、あなたがスロットリングされているという説明を提示します。基本的にそれを見たとき私達が通常よくやることは、コードを追加してシステムに遅延を加え、その後実際に再度リクエストを試み、成功するまで試行し続けることです。あるいは、場合によってはあなたがスロットリングされているときにAmazon があなたにそれを通知するので、5分間か30秒間またはある時間その他の要求ができない場合もあると思います。ですから、割り当てられた時間待ってからもう一度試してください。試してみるというサイクル全体を経てもまだスロットリングされるなら、ほとんどの場合私達は電子メールを送信するか、基本的にメッセージを送り「このジョブはスロットリングされており、それが5回以上連続して発生しました」と単に伝えると思います。おそらく何かが進行中であるか、単にそこに留まって無限にループしないように私達はプロセスを確認する必要があります。
IWSによるサービス提供
チャーリー：
この議論全体またはその大部分は、私達がサービスを利用することについて話していました。しかし、私達は二人共IBM i が Webサービスや API を非常にうまく提供できるのは明らかだと知っていて、そのことは既に述べました。そして、私達は IWS つまり統合Webサービスを使用しています。私達がお客様の現場で IWS を使用した例にはどのようなものがありますか? 通常当社の Webサービスを利用するのは誰ですか?
レイニア：
私達の観点からするとこれは主に顧客ベースで、リアルタイムの在庫などの情報を顧客に提供しています。私達は、毎晩請求書のコピーを Webサーバーに保存することにうんざりしている顧客の所である事をしました。私達は、顧客が自分達の Webページにアクセスして請求書の再印刷を要求したときに、請求書を実際に作成し、カプセル化し、Webサービスの Webサイトに送信してPDF形式で顧客に提示する顧客向けの Webサービスを作成しました。また、社内ではいくつかの Webサービスを使用した倉庫の自動化を何件か行ってきました。ピッカー等があり、注文してもらいたい商品が表示されていることが求められます。そしてその注文の後、多分ラベル貼り等の目的で彼らは配送情報が欲しくなります。そして、私達はそうしたものを提供しました。ご存知のとおり、私達は注文状況のような他の情報等も Webサービスを通じて提供してきました。
チャーリー：
これはAPIなので、これを使うのが PHP や Node、例えばモバイルアプリを実行している人でも構わないのが良いところです。誰がユーザーか誰も気にしません。
レイニア：
ええ、そうです。RESTサービスの HTTP による会話ができ、ペイロードが返されたときにそれを処理できる限り、誰が要求を行っているかは関係ありません。
セキュリティ上の考慮点
チャーリー：
この話のまとめに入る前に最後にお話したいのは、セキュリティのことです。なぜなら、ほとんどの場合あるいはおそらくすべての場合において、セキュリティのことが常に念頭に置かれているからです。しかし、私達が Web サービスを利用している場合、誰がサービスを提供していようともサービス提供者とのセキュリティの問題に遭遇することは分かっています。セキュリティの観点から何が見えてきますか? そして、発生するセキュリティ問題にどう対処しますか?
レイニア：
ほとんどの市場等と同様に、彼らはあるバージョンのユーザー認証機能を使用しています。そこには基本的にトークン（多分プライベートトークンのようなもの）があり、あなたはトークン要求を行う必要があります。次に、トランザクショントークンかアクション可能なトークンを取得すると、基本的にそのトークンは5分から30分程有効になります。30分を超えるものは実際には見たことがありませんが、基本的にトランザクション等のことを行うときにそれを使用します。また、ペイロード及び送信されるものをハッシュする必要があり、それを基本セキュリティとして使用しているのも見たことがあります。基本的に誰かがペイロードを改ざんするとそれが変化します。いずれにせよ、ハッシュが異なるので変更されていることが分かり、ペイロードを受け入れません。もちろん、SSLセキュリティもあります。これはHTTP経由でかつ証明書ベースであり、その点にも注意する必要があります。先に述べたように、特に新しい SQL関数の場合、新しい SQL関数を使用してデータをやり取りしたり、Webサービス、API、マイクロサービス等を利用したりするときに、オプションで参照する必要がある証明書保管場所に HTTP SSL証明書が存在することを確認する必要があります。
コードをモダナイズする
チャーリー：
最後に一つ指摘しておきたいのは、多くの組織には私達が考える近代的アプリケーションや、上手く書かれたコードは存在せず、レガシーコードつまりもっと古いコード、古いスタイルの一枚岩構造のコードが存在するということです。モジュール化されていない等の問題がありますが、それでも何とかして API を導入することはできます。多分モダナイズされたアプリケーションよりも一枚岩構造のプログラムに組み込むほうが難しいのですが、本当の要件を抱えている人にどのようなアドバイスができるでしょうか。例えば、最良の顧客の1人が今日 API の使用を求めています。API を使い始めるために、その顧客用にどのように備えますか、すなわちそのコードベースをどのように準備しますか? 最後に推奨できるベストプラクティスはありますか?
レイニア：
一枚岩構造のプログラムがたくさんある場合、最も重要なのはそれらをモジュール化して分解し始める必要があることです。通常、Webサービスのような新しい話題に出会ったとき、または前に述べたように世界経済との対話を始める必要があるときは、モジュール化を開始してコードを分割し始めるのに最適な時です。一枚岩構造のプログラムがある場合でも、扱っている新しいものだけを処理するWebサービスプログラムや同様のものを作成できます。一枚岩構造のコードがそこにあり、通常はファイル等から読み取る場合、私はよくそのように処理します。つまり、一枚岩構造のプログラムを呼び出す前、またはその周辺、または何でもいいから処理を行う場所のいずれかで呼び出しを行います。私達は顧客に働きかけ、何であれ彼らからデータやペイロード等を取得し、一枚岩構造のプログラムがそれを利用して変換できるようにデータの形式を整え、基本的に一枚岩構造のプログラムを実行させます。これは、私がこのような状況で一枚岩構造のプログラムを使ってよくやることです。私はそれを少し前工程でやっているので、一枚岩構造のプログラムを引き続き使用できます。とは言えはっきり言うなら、こうしたことはサービス、修正または機能の追加にとって最悪なので、多分プログラムを分割するべきです。
チャーリー：
とても素晴らしいですね。私達は本当に幸運です。私達は様々な顧客や一連の要件を扱う仕事をすることになります。今日の IT の需要は間違いなく API なので、これがやる必要のあることなのは分かっています。
レイニア：
最も素晴らしいところは、顧客の会社に行ったときです。彼らはいつもこう尋ねます。「こんな要求が来ていますが、これはできないと思います。」そして私は、「いいえ、できます」と言います。できるのです。その後、それが終わった後で彼らは「ああ、そんなに難しそうではなかった」と言い、実際に難しくありません。ただ基本的にこれらがどのように相互作用するかを理解することです。それは別のプログラムを呼び出すようなものですが、プログラムはあなたのマシン上にあります。要するにこれだけです。誰もがプログラムを呼び出す方法を知っています。あなたがプログラマーであれば、やることはプログラムを呼び出すだけです。つまり、基本的に別のサーバー、別のサイト、場所を問わず可能性のある場所でプログラムを呼び出すとはどういうことかを理解するだけです。あなたはそれを呼び出すことができ、それを使えます。これが、これら API やマイクロサービスの本質です。多くの人がそれらに様々な名前を付けていますが、それらはすべて同じようなものです。結局のところ、それは実際にはリモートプロシージャコール以外の何者でもありません。
チャーリー：
APIを使ってこの道をどんどん進み、プログラミングのモデルを身に付けると、最終的にはそれが本当のデジタル変革への素晴らしい道に進むことになります。なぜなら、新しいテクノロジーに関わり始めると、AI のようなもの（もちろん、AI は今日重要な技術ですが）でさえAPI に依存するようになるのですから。
レイニア：
そうですね、すべてAPIです。現在存在しているもの、最近登場しているもののほとんどはすべてAPI駆動です。本当に望むなら、技術的には IBM i 上で内部的にそれを開始することもできます。私は実際に見たことはありませんが、それは新しいものを開発する別の方法でもある可能性があります。すべてを API として開発し始めるだけです。おそらく IWS と同じSQL関数やその他の方法を使用して、自分でそれを使用することさえできます。それらは世の中に存在し、私が言ったようにそれらはリモートプロシージャコールなので、別のプログラムを呼び出してデータを取得してそれを使用しているだけです。
チャーリー：
レイニア、今日は時間をいただきありがとうございました。素晴らしい会話でした。APIは私にとってとても興味深く魅力的なテクノロジーです。これらはマシン上でできることを本当に拡張します。何か意味のあるアプリケーションを作成するつもりなら、API は間違いなくツールセットの大きな部分を占めることになると思います。
レイニア：
そうです、API はツールセットの大きな部分を占めています。グローバル経済の一員として、IBM i上、Webサイト上、Webサーバー上、または別のデータベース上のどこに情報があろうとも、その情報にアクセスできる必要があります。これらAPIはすべてをより良くするための鍵であり、あなたがその遍在するデータにアクセスし、それを活用するためにその鍵を使える必要があります。
チャーリー：
その通りです。レイニア、もう一度、お礼を言います。ありがとう。それでは皆さん、これでポッドキャストは終わりになります。お聞きいただきありがとうございました。次回まで、さようなら。
