Oswald Regular
OpenSans Regular
Co>Operating System
幅広く、奥が深い…

Co>Operating Systemは、エンタープライズ業務アプリケーションを構築、統合、および実行するための環境です。Co>Operating Systemは、Enterprise Meta>Environment、Continuous>Flows、Conduct>It、Business Rules Environmentを含む、すべてのAb Initioテクノロジの基盤です。これらのテクノロジは、シームレスなアプリケーション開発および実行を行う統合環境として提供されています。

Co>Operating Systemの中核は“データフローエンジン”です。このエンジンが、データ処理をさまざまに行う“コンポーネント”を駆動します。コンポーネントは大規模なデータ処理用ライブラリであるとも言えます。ユーザーは、Ab Initioのグラフィカル開発環境(GDE)を使ってコンポーネントを組み合わせ、アプリケーションをグラフィカルに設計、実装、および保守します。

Co>Operating Systemの基本思想は、システム設計をする際に誰もがホワイトボード(とか、ナプキンとか)に図を描く方法、そのままにアプリケーション開発を行うということです。データの入力と出力、その間の処理など各コンポーネントはわかりやすいアイコンで表され、入力が処理コンポーネントに流れ込み出力へ至るという全体の処理フローを矢印で定義します。豊富なライブラリから適切なコンポーネントを選択し、それらを“繋げる”ことで、Ab Initioアプリケーションが作成されるのです。

この描画した図そのものがアプリケーションです。そして、出来上がったアプリケーションはバッチ、擬似リアルタイム、(本当の)リアルタイム、もしくはそれらを組み合わせたモードであっても、提供する強力なコンピューティング環境にすべてまとめて実現できます。このように、Ab Initioはアプリケーションの設計と実行をシームレスに統合しているのです。

データフローを描画する設計アプローチを採用しているということは、Ab Initioを広範囲にわたる業務アプリケーションの大部分に適用できるということです。業務システム、分散アプリケーション統合、データウェアハウジングの複雑なイベント処理(CEP)、データ品質管理システムなどさまざまなものに適用できます。しかし、グラフィカルな設計と開発のアプローチは、Ab Initioの工夫の一つに過ぎません。これらのアプリケーションは、大事な運用と管理上の要件も満たす必要があります。

歴史的に、グラフィカルプログラミングの技術(処理系)は見た目に綺麗な絵を生み出しはしましたが、現場の要件を記述できる処理能力は持ち合わせていませんでした。ところが、Co>Operating Systemはそれらと全く別物です。現場で使える正真正銘の本物なのです。以下に、導入事例と元となる業務要件をいくつかご紹介しましょう。

  • 世界最大級の証券取引所では、基幹運用システムを構築する何百万行ものCobolコードをAb Initioアプリケーションに変換しました。このソリューションは今や、取引業務のパイプライン処理の主要部分となっています。リアルタイムのバス型ネットワークに接続し、1秒間に50万件以上のトランザクションメッセージを処理します。
  • 世界最大級の小売業者では、数千におよぶ店舗内のレジ端末から売り上げデータをリアルタイムで受け取り、在庫管理と詐欺の検知を行っています。
  • 世界最大級の電話会社では、通話課金、データ利用状況追跡、ネットワーク監視のための通話明細情報を処理しています。1日に何十億もの通話明細レコードが処理され、何百万件もの利用状況照会に応答しています。
  • 世界最大級の半導体メーカーでは、製造品質に関する情報を製造工程からリアルタイムで引き出し、生産量を増加の判断に利用しています。
  • 世界最大級のクレジットカードネットワークでは、Ab Initioをデータ基幹システムとして使用し、すべてのトランザクションをバッチモードとリアルタイムの両方で処理し、バックエンドシステムに渡しています。Ab Initioのデータ保存システムには、毎年、1ペタバイトのトランザクションデータが蓄積されます。顧客サービスコールセンターをサポートするこのシステムは、クエリ照会に1秒未満で応答します。
  • 世界最大級のインターネット会社では1日に何百億もの広告実施データを処理して課金システムで使用し、同時に広告配置の向上に役立てています。
  • 世界最大級の保険会社では、保険金請求処理の大部分をAb Initioで行っています。この会社の再保険および契約処理システムには何万ものルールが含まれており、これらすべてがAb Initioで実装されています。
  • 世界最大級の運送会社では、請求書の作成と、担当営業チームへの販売報酬の計算をすべて、Ab Initioアプリケーションで行っています。
  • 世界最大級の銀行では、全業務部門からのすべての顧客情報をAb Initioソフトウェアで統合し、巨大なデータウェアハウスを構築しています。同社ではAb Initioを使用して、世界各地の子会社間のすべてのSWIFTトランザクションの流れをカスタマイズおよび処理しています。

以上の事例はすべて、“世界最大級の”組織によるものであることにお気づきですか?なぜ、これら大企業の皆さんがAb Initioを選んだのでしょう?Ab Initioソフトウェアが直感的で使いやすいということだけでなく、Ab Initioソフトウェアは、最も複雑な処理ロジックと膨大な量のデータに対応できるからです。そして、これを高速に、かつ、卓越した堅牢性で実現します。この組み合わせを実現できるのはAb Initioだけです。

これらの大企業における導入事例は広範囲にわたっていて、上にご紹介した事例はその中のほんの一部に過ぎません。これらすべてのアプリケーションの要件を満たすには、以下の機能が必要になります。

  • 大量の複雑なロジックを、図を用いて簡単に表現する。
  • ほとんど何にでも接続できる。さまざまなデータベース、キューイングシステム、フラットファイル、ERPシステム、標準メッセージングプロトコル、など。
  • 複雑なデータ構造のネイティブサポート―どこからどんなデータが来ようと: 階層データ(XMLおよびレガシー)、世界の言語に対応、大きなオブジェクト、可変長、パック10進数など、ありとあらゆる種類のデータをサポートする。
  • 多様なオペレーティングシステム(Unix、Linux、Windows、メインフレーム)、および異種プラットフォーム間での分散処理のサポート。
  • レガシーおよびサードパーティのアプリケーション、データ、および環境を迅速に統合できるオープンアーキテクチャ。
  • 高度な効率性とスケーラビリティ、そしてネットワーク上のサーバー群でクラウドの様なコンピューティングを可能にする。
  • 高性能なバッチ処理とリアルタイム処理(Webサービスおよびサービス指向のアーキテクチャ(SOA)、およびストリーミング)。
  • アプリケーションの大部分または一部(業務ルールを含む)を対象にした高度な再利用性。
  • データの問題やシステム障害に対する高い復元力。例外処理に対する強力な管理機能を提供。
  • 総合的な管理能力。バージョン管理とリリース、プロモーションなど、ソフトウェア開発のライフサイクルをサポート。実行スケジューリング、監視、アラート機能。アプリケーション分析、など。

これらの要件を満たす唯一の方法は、最初からすべての要件を同時に満たすように設計されたアーキテクチャを用いることです。アーキテクチャが決定されてしまうと、基本的な機能を後で追加するのは実質的に不可能です。Co>Operating Systemは、これらすべての機能を備えるように、始めから設計されています。堅牢で、実績のあるテクノロジに支えられており、複雑なデータ処理アプリケーション全般で使用されているのです。

Ab Initioアプリケーションとは?

Ab Initioアプリケーションの中核となるものは、データフローグラフ、略して“グラフ”です。グラフは、データ“フロー”によって接続されたコンポーネントで構成されます。

たとえば、下記のグラフをご覧ください。この単純なアプリケーションは、顧客の取引データを含むフラットファイルからレコードを読み込み、ルールを適用してデータを整形し、データを並べ替え、ロールアップ(集約)します。処理結果はOracleなどのデータベーステーブルに書き込まれます。

Ab Initio Co>Operating Systemは、以下のようなコンポーネント(多様な設定およびカスタマイズが可能)を提供しています。これらは業務データ処理の基本的な構成要素となります。

  • データ変換
  • 選択/フィルタリング
  • 重複の排除
  • ジョイン操作/マージ操作
  • 正規化/非正規化
  • 圧縮/解凍
  • 集約(集計)/スキャン(抽出)
  • 並べ替え(ソート)
  • データ生成と検証
  • ... など

さらに、Co>Operating Systemには組み込みコンポーネントの多大なライブラリが備わっており、事実上あらゆる種類のデータソースまたはデータターゲットに対応できます。ライブラリには以下の操作を行うコンポーネントが含まれています。

  • Unix、Windows、およびメインフレーム上のあらゆる種類のフラットファイルへの接続
  • 一般的なデータベース(Oracle、DB2、Teradata、SQL Server、Netezza、Greenplum、メインフレームDB2、IMS、IDMS、Adabasなど)
  • すべての標準メッセージキューイングインフラストラクチャ(IBM MQ、JMS、Microsoft MQ)への接続
  • Webサービスインフラストラクチャ(WebSphere、WebLogic、IIS、Apache/Tomcatなど)への接続
  • サードパーティ製品(SAP、Siebel、SAS、PeopleSoft、Salesforce.comなど)への接続
  • 階層データ構造(XML、ASN.1、Cobolなど)の構文解析とデータ操作
  • 業務固有のデータ形式(Swift、FIX、EDIFACTなど)の解読、操作、および生成
  • コンテンツベースのメッセージルーティング
  • メタデータへの接続性: さまざまなデータ定義やビジネスインテリジェンス製品(ERWin、ERStudio、Microstrategy、Business Objects、Cognosなど)

小規模なアプリケーションは3~5個のコンポーネントで構成されるでしょうし、大規模なアプリケーションであれば百個以上のコンポーネントで構成される場合もあります。さらに、総計数千以上のコンポーネントで構成される巨大なアプリケーションも作成可能です。また、アプリケーションは複数のグラフで構成され、各グラフに多数のコンポーネントを含む場合もあります。

小規模のものから大規模なものまで、すべての利用状況に対して、Ab Initioアプリケーションは再利用可能であるルールやコンポーネントをフル活用し、ビジネスニーズの変化に迅速に対応しているのです。

業務ロジックはすべてグラフィカルに定義される

Co>Operating Systemは、コンポーネント内部に、事実上ユーザーのどんなルールでも、どんなデータ型に対する処理であっても定義できます。これらのルールの指定はすべてグラフィカルな方法で行われます。これが他社の技術と大きく異なる点です。他社のテクノロジによるグラフィカルなルールは、単純なルールにしか適用できません。ルールが複雑になるとルール群になり、ユーザーはすぐさま乗り越えられない壁に突き当たります。ユーザーは結局、複雑なルール群にテクノロジを使用するのをあきらめ、従来のプログラミング方法(Java、C++、スクリプト作成、ストアドプロシージャ、Perlなど)を利用することになります。

しかし、Co>Operating Systemでは違います。Co>Operating Systemをいったん導入すると、Co>Operating Systemを使って複雑なロジックを定義する方が、前よりも簡単なのだということがすぐわかります。生産性、使いやすさ、可視性が大きく向上しそうだということがすぐに感じられるでしょう。ルール群をグラフィカルに定義する方が簡単で速く、業務担当者も簡単に理解できます。

Co>Operating Systemでは、Ab Initioのデータ操作言語(DML)を使用してルールを指定します。これらのルールは、データ処理の基本構成ブロックである“トランスフォーム”コン ポーネント内で指定されます。トランスフォームコンポーネントには、ある種のレコード構造を別の形に変換するもの、データの集約やフィルタリングを行うもの、構造の正規化と非正規化を行うもの、複数のレコードストリームを結合するものなど、多数あります。これらの各コンポーネントは、処理時にDMLを使ってレコードに処理ルールを適用します。

下図は、マッピングを行うコンポーネントの出力を計算する単純なルールを示しています。左側はコンポーネントに入力されるフィールド、右側は出力されるフィールド、中央がルールです。

個々のルールは[式エディタ](下図)で作成できます。式は大きく複雑になることもあり、DMLには組み込みの演算子と関数のライブラリが用意されています。

Ab Initioには、これとは別に、業務ルール指定のためのユーザーインターフェイスがあります。これらのインターフェイスは業務アナリストや各分野の専門家など、非技術系ユーザー向けに設計されています。これらのインターフェイスでは技術専門用語ではなく業務用語を使用し、使い慣れたスプレッドシートで作業するようにルールを構成します。

詳細については、「Business Rules Environment」を参照してください。

Co>Operating Systemは任意のデータ型をネイティブに処理する

Co>Operating Systemを使用すると、データをそのままの状態で、または、ユーザーが望む形式で処理できます。Co>Operating Systemは、自分が理解できる組み込み形式にデータを強制的に変換する必要はありません。データ処理はOSネイティブの形式で行うことができます。これは、サポートされるオペレーティングシステムすべてに対して言えることです。つまり、Co>Operating SystemおよびすべてのAb Initioコンポーネントは、メインフレームのデータをUnixやWindowsサーバー上で、XMLをメインフレーム上で、複雑な階層構造やビットパック構造をどのOS上でも、世界各国の文字データを自動的に変換しながら、それぞれネイティブに処理できます。与えられたデータとアプリケーションが同じであれば、アプリケーションの実行環境に関係なく、Co>Operating Systemは同じ結果を生成します。

アプリケーションは、異機種の混在するシステム群からデータの読み書きを行えます。また、データは、アプリケーション内の処理段階でさまざまな異なる形式に変換していくことができます。下図に示すアプリケーション例は、フラットファイルからメインフレームのデータを読み込み、MQキューからXMLデータを読み込み、データを複数の異なる中間形式で処理し、その国固有のコードセットを使用して結果をフラットファイルに出力します。Co>Operating Systemは国際化対応済みなのです。

Co>Operating Systemは、データ形式の定義をさまざまなところから取得できます。データベースカタログ、スキーマ定義製品、Cobolコピーブック、XML DTDまたはXSD、WSDL、スプレッドシートなどから取得する方法をあらかじめ知っています。そして、独自のデータ定義システムからであっても容易にフォーマット定義を取得できるでしょう。

上の例で“ASCII階層データ”と書かれた中間フローのレコード形式定義は、たとえばこのようになります。

最後に、Co>Operating Systemとそのコンポーネントは必要に応じて自動的にデータ形式変換を行います。たとえば、Oracleデータベースに書き出すコンポーネントにEBCDICとパック10進データが読み込まれた場合、コンポーネントはデータベースのカラムの形式に合わせるため、データをASCIIと10進数へと自動的にフォーマット変換します。

性能と拡張性

Co>Operating Systemは、最大限の性能と拡張性を得るという目的が根底から配慮された設計になっています。お客様のハードウェアから最大限の性能を引き出すため、Co>Operating Systemのすべての側面が最適化されています。そして、大抵の場合“クラウド”テクノロジは不要です。なぜなら、もともとCo>Operating Systemはサーバー群の上で処理を分散実行できるからです。

Co>Operating Systemは、他の高速処理テクノロジと比較して、少なくとも4倍から5倍以上速く処理できます。他の高速なテクノロジとは、ハンドコーディングされたJavaや C++プログラムなどを含んでいます。Ab Initioで実装したものと近い速度で処理できるプログラムを書くことができるプログラマーは非常に稀です。JavaやC++を 使ってこれを実現できる人は、組織内で一人居るか居ないかでしょう。この人をもってしても、Ab Initioなら数日で達成できることに、何週間もの時間を費やすことになるでしょう。普通に考えるなら、そんなに才能のあるプログラマーがプログラミングだけを行うことはなく、アプリケーションの設計、アーキテクチャ、そしてプロジェクト管理にも携わるようになるはずです。

Ab Initioはどのようにして拡張性と性能の両方を達成するのでしょう?Ab Initioの“ひみつ”とは何でしょうか?たくさんの要素が関わっていますが、中で最も重要なものは、アーキテクチャと、隅々にまで徹底的にこだわることです。Co>Operating Systemのアーキテクチャは(コンピュータサイエンスの)“原点”に立ち返って設計されており、スケーラビリティを備えたコンピューティングを可能にします。

Co>Operating Systemのアーキテクチャは“シェアード・ナッシング”として知られています。Co>Operating SystemではCPU間で共有すべきものがないので、互いが完全に独立して動作します。このため、1つのアプリケーションを、複数のサーバー上の複数のCPUで、それぞれ任意の個数を組み合わせた環境で実行できます。Co>Operating Systemには、複数CPU間で均一に負荷分散する機能が備わっています。そのため、ほとんどのアプリケーションは線形の拡張性を実現できます。これは、CPU数を2倍にすると2倍の性能が、CPU数を10倍にすると10倍の性能が得られることを意味します。Co>Operating Systemはデータ並列処理とパイプライン並列処理を組み合わせ、アプリケーションの部分部分を並列実行するチャンスを最大限に引き出します。

下図に示すアプリケーション例は、データをパーティション分割し、複数のCPU(およびサーバー)で「集約計算」コンポーネントを並列実行します。Partition by Round-robinコンポーネントは、トランプのゲームでカードを配るように、顧客データを複数のデータストリームに均等に配分します。そして、Co>Operating Systemは「集約計算」コンポーネントのインスタンスを複数個立ち上げます。各インスタンスはデータストリームの1つを処理します。「集約計算」プログラムの各インスタンスからレコードが出力されると、「データの再統合」コンポーネントが複数のデータストリームをマージして元に戻し、出力ファイルに結果を書き出します。このように大変シンプルです。

完全疎結合アーキテクチャはボトルネックがない間は見事に機能します。しかし、1つでもボトルネックがあると全体に影響します。ここで、“隅々にまでこだわること“が意味を持ちます。システムの一部で並列処理できないボトルネックを引き起こす可能性がある場合は、それが決定的な妨げとならないよう注意して設計および実装する必要があります。すべてのコンポーネント内のアルゴリズムは、あらゆるシナリオの条件下で最適でなければなりません。パーティション間およびコンポーネント間のすべての通信とデータ転送は、最も効率の良いチャネルを使用する必要があります。これらのさまざまな部分の隅々までに注意が払われた場合にのみ、システムの拡張性が実現するのです。

もう一つの重要な“隅っこ”は業務ルールの実行です。システムが適切に設計されている場合、CPU時間の大部分がここに費やされるはずです。業務ルールは、Co>Operating Systemのトランスフォームエンジンで実行されます。このエンジンには、“ジャストインタイムコンパイラ”と呼ばれる特別な設計が施されています。つまり、これから行う処理に関するすべての情報が揃った最終局面ではじめて業務ルールがコンパイルされることを意味します。“ジャストインタイム”方式は多大な柔軟性を生み出します。そして、“コンパイラ”は従来の業務ロジックを最高のパフォーマンスで実行するように高度に最適化されています。このため、従来のテクノロジを使用するプログラマーでは Co>Operating Systemに太刀打ちできません。

Co>Operating Systemの処理モデル

Co>Operating Systemは、分散型ピアツーピア処理システムであり、アプリケーションの実行に関与するすべてのサーバーにインストールする必要があります。これらの各 サーバーが異なるオペレーティングシステム(Unix、LinuxおよびzLinux、Windows、またはz/OS)を稼働させていても問題ありません。

Co>Operating Systemは、サーバーネットワークに分散されたプロセスを以下のように管理します。

Co>Operating Systemでの実行のしくみ
1.
Co>Operating System が実行サーバー上で起動され、アプリケーション定義データ
形式、論理ルール、パラメータの各情報を読み取ります。
2.
Co>Operating Systemはサーバー上のエージェントを起動します。
3.
サーバープロセスは、各エージェントのコンポーネントが処理用コンピュータ上で実行するように命令します。その際、コンポーネントの処理に必要なすべての情報が渡されます。
4.
エージェントがコンポーネントを起動し、ルール、レコード形式、パラメータなどの
各情報を伝えます。
5.
コンポーネントはデータフローを接続し、データ処理を開始します。
エージェントはプロセスを監視します。

1. Co>Operating System が実行サーバー上で起動され、アプリケーション定義データ形式、
論理ルール、パラメータの各情報を読み取ります。

2. Co>Operating Systemはサーバー上のエージェントを起動します。

3. サーバープロセスは、各エージェントのコンポーネントが処理用コンピュータ上で実行するように
命令します。その際、コンポーネントの処理に必要なすべての情報が渡されます。

4. エージェントがコンポーネントを起動し、ルール、レコード形式、パラメータなどの各情報を伝えます。

5. コンポーネントはデータフローを接続し、データ処理を開始します。
エージェントはプロセスを監視します。

これらの図からわかるように、1つのAb Initioアプリケーションを、1つのサーバー内でも、あるいは、ネットワーク構成の複数サーバー上でも実行できます。アプリケーションの定義(開発者によって指定されたグラフィカルな図)は、どちらの場合で同じです。アプリケーション自体を変更する必要は全くありません。どのコンポーネントをどこで実行するかの指定を変更すると、アプリケーションは複数の異なるサーバー上で実行されます。つまり、アプリケーションを変更せずに、たとえば、メインフレームで実行していたアプリケーションをUnixサーバーで実行したり、1つのサーバーで実行していたアプリケーションを複数のサーバーで実行したりできます。

Co>Operating SystemはUnix、Windows、LinuxおよびzLinux、そしてz/OS上で全く同様に動作します。さらに、1つのアプリケーションをこれらのプラットフォームを混在させた環境で実行することもできます。Ab Initioアプリケーション内の各コンポーネントは、Co>Operating Systemがインストールされた任意のプラットフォーム上で実行可能です。(ただし、メインフレーム上のVSAMアクセスなど、プラットフォーム特定のコンポーネントもあります。)Co>Operating Systemはマシン間のデータ移動に伴う複雑性を解決してくれるので、結果として環境をシームレスにするミドルウェアであるとも言えますし、その環境での処理機能を提供していると見ることもできます。コンポーネントをどのマシンに割り当てるかの設定は、アプリケーションを実行するたびごとに変更できます。

任意のコンポーネントまたはコンポーネントのグループを、異なるコンピュータリソースに割り当てることができるのです。

バッチ、リアルタイム、Webサービス – Co>Operating Systemですべて実行

通常、バッチアプリケーションとリアルタイムアプリケーションの構築と実行の要件は大きく異なります。また、それぞれのテクノロジも異なります。しかし、Co>Operating System上ではあまり違いがありません。Co>Operating Systemは1つのアーキテクチャで構成され、バッチ、リアルタイム、およびWebサービス(SOA)のいずれのシステムでも、同様の優れたオペレーションを実現できます。各システムごとに別の開発チームが多数のテクノロジを使用するのでは、同じ業務ロジックを複数の方法で実装する結果にもなり兼ねません。Co>Operating SystemとContinuous>Flowsを使用すると、1つの開発チームが1つのテクノロジを使用して業務ロジックをコード化し、それを異なる複数のシステム間で再利用できます。

Co>Operating Systemでは、アプリケーションがバッチであるかリアルタイムであるかは、アプリケーションが読み込むソースと書き出すターゲットによって決まります。下図は、1つのアプリケーションが、バッチシステム(入力と出力にはフラットファイルを使用)、リアルタイムのキューイングシステム(入力にはMQ、出力にはJMSを使用)、そしてWebサービス(外部システムからサービスリクエストを取得し、同じシステムに結果を返す)で動作する様子を示しています。

一つのアプリケーション、多様な実用例

1. バッチ処理

2. キューイング

3. Webサービス

詳細については、「Continuous>Flows」を参照してください。

レガシーコードとの統合

Ab Initioでは、グラフィカル開発環境(GDE)を使用して完全なエンドツーエンドのアプリケーションを構築でき、これらのアプリケーションはCo>Operating System内で完全に実行されますが、既存のアプリケーションまたはサードパーティ製品がうまく機能している場合、それらを実装し直さずに利用したいことがあります。Ab Initioでは、C、C++、Cobol、Java、シェルスクリプトなどでプログラムされたこれらの既存のアプリケーションを、簡単に再利用できます。実際に、Co>Operating Systemでは、これらのアプリケーションを本来意図されてはいなかった環境に統合することもできるのです。

レガシーのコードは、コンポーネントに形を変えてAb Initioアプリケーションに統合されます。コンポーネントはその他すべてのAb Initioコンポーネントと同じように動作します。ほとんどのレガシーコードについて、それをコンポーネントに変えることは簡単です。プログラムの入力と出力、そしてコマンドラインパラメータを指定するだけです。下の例は、フラットファイルの読み込みと書き出しを行うCobolプログラムをAb Initioアプリケーションにプラグインする方法を示しています。CobolコードはCopybookとJCLと共にAb Initioコンポーネントに置き換えられます。コンポーネントはUnixサーバーとメインフレーム環境で動くAb Initioアプリケーション内に配置されます。そして、アプリケーションはさまざまなデータソースおよびターゲット(SASおよびデータベース)に接続します。最後に、性能向上のため、作業負荷がパーティション分割され、Cobolコードは複数のインスタンスで並列実行されます。

レガシーコードの統合
ユーザーは、以下に挙げるCobol関連データの
収集と追加を行います。
このコンポーネントは、
Ab Initioと互換性のある任意の
システムに接続できます。
Cobolレガシーコードが、SASとRDBMSに接続したUNIXとメインフレームの
両方を使用するシステムの一部として実装されます。
UNIX
メインフレーム

不良データに対する優れた復元力

実システムの構築および管理を行う上で最も難しい点の一つは、予期しないデータまたは不良データへの対処です。この状況は常に発生するものであり、このようなデータが入力されると、ほとんどのアプリケーションが適切に動作しなくなります。運がよければ、アプリケーションがクラッシュするだけで済みますが、運が悪ければ、アプリケーションは不良データを(不正に)処理し、不良な結果が下流システムに送られてデータ品質を落とし、さらには、そのことに気付かないような状況が起きる可能性があります。このようなデータ汚染を一掃するのは時間がかかり、生産性は大きく損なわれます。

Co>Operating Systemには不良データに対する本質的な復元力があり、ユーザー指定およびシステム指定のさまざまな条件を満たすかどうか、常にデータが調べられます。データがこれらの条件に従わない場合、何らかの修正処理がないとデータはそこから先に進めません。そして、開発者は、アプリケーションに自動修正処理とレポーティング機能を簡単に組み込むことができます。修正処理は、誤ったデータを修正してシステムに再度読み込むように設計したり、不正なデータを関連するデータと一緒に分離し、後で整合性を確認して処理するように設計することができます。

下の図は、開発者がAb Initioでどのようにして不良データに対処するアプリケーションを構築するかを示しています。このアプリケーションは、1問題のあるデータを取得し、2それらのデータを“クリーンアップ”するルールセットを実行し、3修正したデータを元のプロセスに戻し、4修正できなかったデータを隔離し、最後に5問題のあるデータについてのレポートを生成し、6問題のあるデータをMQキューに送ります。

多様なデータ処理を行うAb Initioコンポーネントには、オプションのreject(リジェクト)ポート、error(エラー)ポート、およびlog(ログ)ポートがあります。rejectポートには問題のあるデータが、errorポートには各問題を記述するレコードが、logポートにはデバッグ情報が送られます。これは、非常に堅牢なデータ処理パイプラインの構築を可能にします。

システム障害に対する非常に優れた復元力

サーバーが故障する。ネットワークがダウンする。データベースを読み込めない。アプリケーションに関与するサーバーの数が多いほど、何らかの種類のシステム障害が発生する可能性は高くなります。そのような障害から確実に復旧できるアプリケーションを構築するのは難しいものです。多くの開発者はそれが可能であると考えていますが、実際にアーキテクチャが十分に堅牢であるかどうかは、さまざまな障害を切り抜けてみないとわかりません。この学習曲線を乗り越えていくのは非常に面倒な作業です。

それに対し、Co>Operating Systemはすべての種類の障害から確実に復旧できるように始めから設計されています。重要なデータが失われないように環境が設定されている限り、Co>Operating Systemにはチェックポイントおよびリスタートの機能が備わっているので、アプリケーションが複数のネットワーク、サーバー、およびデータベースで実行されている場合でも、アプリケーションがバッチモードまたはリアルタイムモードのいずれで実行されていても、障害が発生して停止する前の時点からアプリケーショ ンを再開できます。Co>Operating Systemは、業界標準のXAプロトコルよりも高速な2フェーズコミット機構を使用しています。もちろん、XAプロトコルを必要とする環境に対してはそれをサポートし、さらには、異なるメーカーによる複数のデータベースおよびキューイングテクノロジの混在環境もサポートします。

Co>Operating Systemの生産性の原動力は再利用

ユーザーが解決しようとする問題の性質によっては、Ab Initioアプリケーションが大きく複雑になることがあります。しかし、ほとんどのシステムにおいて、あるモジュール(部分アプリケーション)に類似するモジュールが多数存在したり、類似業務ごとに多数の類似した構成のバリエーションがあったりします。従来のプログラミングテクノロジでは、開発者はこれらのモジュールのコピーを多数作成し、各コピーを少しずつ変化させていました。その結果、管理が難しくなり生産性も低下します。

Ab Initioは、これらアプリケーションの構成部分を再利用するチャンスを飛躍的に向上させるために多数のメカニズムを提供しています。あらゆる種類のアプリケーションの構成部分は、集中管理リポジトリであるAb Initio Enterprise Meta>Environment(EME)に保存され、アプリケーション内およびアプリケーション間で再利用されます。たとえば、以下のものが集中管理、保存および再利用されます。

  • レコード形式
  • 業務ルールとロジックルール
  • アプリケーションの構成部分(アプリケーションは“グラフ”、構成部分は“サブグラフ”と呼ばれます。)
  • アプリケーション編成(Ab InitioのConduct>Itでは“プラン”と呼ばれます。)

Ab Initioの再利用機能はきわめて強力です。再利用して作成するモジュールは、集中管理されているオリジナルと互いに紐付けられており、その変更を追跡できるようになっています。さらに、これらのモジュールは、ローカルに適用されたカスタマイゼーションをサポートしますが、その際にもオリジナルへのリンクを保ったままです。

下に示すのは、再利用可能なアプリケーションモジュールの1つの例です。これをサブグラフと呼びます。サブグラフには、アプリケーション(グラフ)の構成部分から成るコンポーネントが含まれます。サブグラフのサイズと複雑さには制限がありません。また、サブグラフは入れ子にできます。サブグラフは通常のコンポーネントとすべて同じ動作をします。サブグラフはライブラリに保存され、多くのアプリケーションで再利用されます。

このサブグラフは、前に述べたアプリケーションのエラー処理を行う部分です。

サブグラフ内のコンポーネントは、入力コンポーネントまたは出力コンポーネントに明示的に接続されていません。その代わり、「標準エラー処理プロセス」サブグラフの入力ポートと出力ポートに接続されています。

下図は、前にお見せしたアプリケーションと同じですが、再利用されたエラー処理サブグラフが新しく導入されています。(GDEでは、サブグラフは二重線で囲まれて表示されます。)

結論

Co>Operating SystemはAb Initioアーキテクチャ全体の基盤となるソフトウェアです。Ab Initioアーキテクチャの主な概念はすべてCo>Operating System上で表現されています。そして、Ab Initioが持つすべてのテクノロジは、Co>Operating Systemとさまざまな形で連携するので、これらすべての概念が整合性のある形で統合され、シームレスな環境を提供しています。

このアーキテクチャの結果は以下のとおりです。

  • アプリケーションシステム全体がグラフィカルに構築されます。従来のプログラミングコードは不要です。
  • グラフィカルなパラダイムを使用することで、従来のコードプログラミングと比べて技術開発者と管理者は生産性をはるかに向上できます。
  • 技術者は業務ニーズにはるかに迅速に対応できます。
  • アプリケーションの透明性が増し、業務ユーザーとアナリストが構造を簡単に理解できます。
  • アプリケーションシステムは、すべての面ではるかに堅牢になります。無限の拡張性、複数プラットフォーム間の移植性、複雑なデータの処理、複雑なルールの実装、不良データとシステム障害に対する耐久性など、さまざまな機能を活用できます。
  • アプリケーションは、バッチ、リアルタイム、およびWebサービスアプリケーション間で業務ロジックを再利用できます。

これらのこと、そして、さらなることが実現可能であるのは、Co>Operating Systemが始めから1つのアーキテクチャでこれらの結果を達成するように設計されているからです。

English
Français
Español
Deutsch
简体中文
言語:
日本語