wpEnterpriseSvr.doc

(1)

(2)

はじめに

このホワイトペーパーは、COBOL、Java、.NET、Web サービスなどの複雑で多様なテクノロジを理解しようとしている設計者や IT 管理者を対象にしています。ここ で説明する内容は、「プラットフォームとしてのCOBOL」の考え方および Micro

Focus Enterprise Server という新製品の基になっている概念です。Enterprise Server の登場により、COBOL の役割は単なるプログラミング言語からアプリケーションサービスのプラットフォームにまで高められました。Enterprise Server の使用により、各種要素からなるエンタープライズアプリケーションの最新プラットフォームにとって、COBOL は重要な要素となります。Enterprise Server を使用した環境では、各種要素からなるこのようなアプリケーションのキーコンポーネントとして COBOL アプリケーションを簡単に再利用することが可能です。 COBOL は長い歴史のある言語です。COBOL とそのアプリケーションは、長い歴史によってもたらされた高い安定性と完成度という強みを持っています。一方、新しいテクノロジである Java および .NET には、優れた柔軟性と広い適用範囲といった特長があります。しかし、IT 企業にとっては、新しいビジネス要件をどのように解決するか、また統合化と「現代化」のイニシアチブをどのように取るかといったようなアーキテクチャ上のアプローチ方法が非常に難しい問題となっています。このような背景にあって、問題を簡単にするための打開策が求められています。このホワイトペーパーでは、新旧のテクノロジを組み合わせるときに「サービス」という概念が非常に役立つことを説明します。また、Micro Focus 製品を使用して、 COBOL、J2EE、.NET、および Web サービスを取り込んだ幅広いアプリケーションプラットフォームで、COBOL アプリケーションを主役に仕立てる方法についても説明します。最大の効果を発揮できるように新旧のテクノロジを調和させて組み合わせること。この方法こそが、コスト対効果の高いビジネスシステムの構築を可能とします。

また、Enterprise Server をどのように使えば、Java プラットフォームとシームレスに統合できるようなトランザクション処理用プラットフォームを COBOL アプリケーションに対して提供できるかを説明するとともに、Web サービスを基本にしたアーキテクチャで COBOL アプリケーションを使用することの利点を明確にします。最後に、Enterprise Server では COBOL が Java および .NET プラットフォームと同じレベルで扱えることを説明します。こうした位置付けにより、既存のエンタープライズシステムとその維持管理要員の利用価値を将来に向けてさらに高めていくことができます。COBOL アプリケーションの開発者は、Enterprise Server を使う

(3)

概要... 1

サービスベースのアーキテクチャとは... 4

DIRECT COBOL WEB サービス ... 6

ENTERPRISE SERVER ... 9

COBOLサービスの統一実行アーキテクチャ 9 エンタープライズアプリケーションプログラミングインターフェイス 10 柔軟性のあるインターフェイス管理ツール 10 クライアントアプリケーションプログラミングインターフェイス 11

おわりに... 13

用語集... 14

(4)

概要

「COBOL に対する関心や期待は、時とともに変わっていくはずです。短期的にみれば、 COBOL 資産をより有効に管理することが関心の的となるでしょう。中期的には、 COBOL 資産を Web にどう展開していくか、また長期的には COBOL 資産を Web サー ビスのフレームワークにどう組み込んでいくかの戦略と方法が最大のテーマとなるかもし れません。利用者が COBOL の将来に期待すること、これこそが Micro Focus の目指す ところです。」1 インターネットの到来以来、すべての利用者は、以前に比べてより多くの情報を即座に入手したいと思っています。この情報化時代において企業が競合力を維持していくためには、顧客やパートナーに、高度に統合された情報サービスを「リアルタイム」で提供していかなければなりません。このようなニーズがあって、「しなやかな企業」という概念が生まれてきました。しなやかな企業は、顧客の差し迫った要求事項に素早く対応できるだけでなく、新しいビジネスチャンスに対して、しなやかさに劣る競合企業よりも迅速に適応できるプロセスとシステムを実現しています。しかしここ数年は経済の動きが鈍り、IT に対する新しい投資予算が厳しく査定されるようになっています。IT の予算は平均して 7% 低下し、しかもその額は基本的に変化がありません2_{。このように、大} 半の企業は新たな IT インフラに予算を配分できない状況にあります。レガシーシステムを入れ替える多くのプロジェクトでは、その目的の一環として IT インフラを簡素化しようとしていますが、膨大なコストがかかるため成功していません。また、企業の吸収と合併によって、アーキテクチャ上の多様性や複雑さが増大してきました。このような状況の中、コアとなるビジネスシステムのために新たなテクノロジへ投資すると、コストが高くなるだけでなく、かなり大きなリスクを伴うことが明確になってきました。一言で言うと、2003 年のビジネスは、「少ない投資で大きな成果」という課題を避けて通れない状況にあります。オンラインユーザが要求する情報のほとんどは、既存のアプリケーションとデータベースの中にあります。これらは、ビジネスに従事している人々を対象に、手作業や時間のかかる作業を支援する目的で開発されてきたアプリケーションです。しかし、これらのアプリケーションは新しい顧客のために設計されたものではなかったため、迅速な対応はもとより、現場の生の声も考慮されていませんでした。それでもこれらのシステムには、ビジネスの遂行に欠くことのできない基本的なデータとルールが蓄積されています。またこれらのアプリケーションには、データを安全に保護するとともに必要な量だけのトランザクションを処理できるような、厳密な手順とシステムが実装されています。 Micro Focus が行った最近の調査では、多くのプロジェクトでインターネットからビジネスシステムにアクセスできるようにしていることがわかりました。また、このような組織では、Java プラットフォームを重要なプロジェクトとして推進中でした。これらのプロジェクトの多くでは、現在、レガシーデータおよびプロセスを統合して Web ベースの新しいクライアントアプリケーションを構築するプラットフォームとして Java を候補に挙げ、精力的に調査しています。

(5)

サービスベースのアーキテクチャとは

「サービスベース」のアーキテクチャでは、中心となる「サービス」を基本にして、要求者と提供者との間の統合関係を明確に定義します。また、サービスを、サービスの要求者 (クライアント) から分離して定義します。そのため、サーバ (サービス要求を受け付けて実行するプラットフォーム) におけるサービスの実行方法を最適化して、サービスに対するスケーラビリティ、信頼性、可用性を高めることができます。IBM CICS などのトランザクション処理 (TP) システムでは、端末オペレータやアプリケーションに対してスケーラブルな「サービス」を提供します。このため、Java アプリケーションサーバにサービスを配信するシステムとしては、TP システムが理想的です。

ここが COM、CORBA および Java (J2EE) といった「コンポーネントベース」のアーキテクチャとは大きく異なる点です。コンポーネントベースのアーキテクチャでは、ネットワーク内の各コンポーネントが複雑に関係し合って動作します。オブジェクトが分散していて複雑なシステムは、オブジェクトモデルを使用することで明確に定義し理解することができます。しかし、分散オブジェクトモデルを実行するプラットフォームでは 2 つの情報を追跡する必要があります。一つは、長時間にわたって実行される多数の並行セッションで、もう一つは、各スレッドが分散コンポーネントからなる入り組んだ網を通過する際の「実行スレッド」の状態です。コンポーネントベースのアーキテクチャは、クライアントで発生したスレッドがサーバを通して送られるような複雑な場合に適しています。この状況は、クライアントスレッドがブラウザ (ユーザ) であってもプログラム (アプリケーション) であっても同様です。一般に、ビジネスサービスを提供し終えるまでには多くの処理を連携させる必要があります。コンポーネントベースのアーキテクチャでは、こうした連携に必要となる長時間の処理フローを明確に定義できます。ただし、ここでいう長時間とは、「セッション」の中でクライアント側から起動した対話シーケンスの時間のことです。サービスベースのアーキテクチャは、要求/応答の単純なやりとりが非常に多い場合を管理するのに適しています。それぞれの対話がお互いに独立したものとして扱われるので、本質的に「ステートレス」です。この点が、IBM の CICS、Microsoft の COM+、および BEA の Tuxedo といった TP システムの基本的な特性です。TP システムに精通しているプログラマは、トランザクションを構成する多数の処理単位 (サービス) からアプリケーションを構築する方法を知っています。その結果、従来のアプリケーションでは、対象としているビジネスプロセスに基づいて、オペレータが全体の流れを制御するようになっていました。しかし、対象とするサービスを大きな単位で適切に定義することにより、クライアントの要求に対して「ビジネスサービス」を直接配信するために必要なすべてのロジックをカプセル化することができます。サービスベースのプラットフォームを使えば、サービス全体の実行を完了した状態で終わらせるか、またはシステムを整合性のある状態にロールバックすることができます。サービスは、IT 企業の運用データを保護するのに必要なスケーラビリティ、信頼性、および可用性といった特性を提供するために、短時間で実行されます。ここでいう短時間とは、リソースを更新する際にそのリソースをロック状態にしておく「妥当な」時間を意味します。より単純なアーキテクチャが求められていますが、そうしたアーキテクチャは、中間層の統合にはコンポーネントベースのプラットフォーム (J2EE や .NET など) の強みを生かし、バックエンドサービスにはサービスベースのプラットフォーム (CICS や COM+ など) の長所を生かすという方法で実現できます。この例を図 2 に示します。この統合方式では、サービスが最終目的地になります。「セッション固有の」処理が別の統合ノードに波及することはありません。Java のようなコンポーネントベースのプラットフォームと、COBOL を扱うサービスベースのプラットフォームとの間にコネクションを確立する方法はたくさんあります。次にその例を示します。

(8)

• J2EE コネクタアーキテクチャの仕様では、Java アプリケーションサーバと COBOL アプリケーションなどのエンタープライズ情報システム (EIS)との間でサービスベースの規約が定義されています。 • IBM の MQ シリーズでは、中間層のプラットフォームとサーバベースのトランザクションとの間で、要求/応答メッセージの処理をエンドツーエンドで行うように設定できます。その場合、送信した要求と受信した応答を MQ シリーズの相関処理 ID 機能を使って関連付け、セッションの「スレッド」を維持します。

• Microsoft の COM オブジェクトモデルは、Microsoft の COM+ トランザクションサーバとシームレスに連携します。また、Microsoft のホスト統合サーバには、メインフレームの CICS や IMS COBOL アプリケーションへ簡単に接続できる機能があります。 • エンタープライズアプリケーションインテグレーション製品では、COBOL アプリケーションなど一般的に普及しているバックエンドサービスとの間に、「アダプタ」や「コネクタ」を採用しています。 Web サーバ Java アプリケーションサーバ COBOL サーバ Java アプリケーションのコンポーネントは、クライアントのコンテキストに応じて関連付けられるトランザクションサーバでは、サービスが互いに依存することなく実行される多くのクライアントが同時に接続する現在アクティブなコンポーネント 図 2 – コンポーネントベースの Java アーキテクチャとサービスベースの CICS アーキテクチャ どのケースにも言えることですが、これらのコネクションを使う場合は、外部エージェントから容易に起動できるように、前もって「サービス」を定義しておく必要があります。COBOL の場合を例にあげれば、画面を使用しないトランザクションを作成するということがこの要件に該当します。データは、連絡レコードを経由してこれらのトランザクションに渡され、サービスはリモートプロシージャコールを使って呼び出されます。多くの企業では、こうしたアーキテクチャ上の変革が到来することを期待してきました。また、2000 年問題のバグを修正して以降、COBOL アプリケーションを再構築して、自分たちのプラットフォームに合った API を使えるようなサービスレベルのインターフェイスの実現に努力してきました。中間層の統合プラットフォームから使うサービスベースのインターフェイスを考えた場合、こうしたインターフェイスは非常に理に適っていると言えます。次の節では、Web サービスベースアーキテクチャでの COBOL アプリケーションの役割を説明します。具体的には、Micro Focus の Enterprise Server で COBOL アプリケーションのためのトランザクション処理プラットフォームをどのように実現しているかを説明します。このプラットフォームは、 Java プラットフォームと Web サービスにシームレスに統合できます。

(9)

Direct COBOL Web サービス

Micro Focus は、WS-I5_{のメンバであり、COBOL の今後の推進および COBOL アプリケーションの} Web サービス化の推進をコミットしています。WS-I は、100 社を超える技術系ベンダーから構成されるコンソーシアムであり、非常に積極的な活動を展開しています。ここでは、各ベンダーが協力して、さまざまなプラットフォームおよびプログラミング言語間の相互運用性を保証する Web サービス「プロファイル」を開発しています。

COBOL アプリケーションを使うことで、価値の高いビジネスサービスを豊富に実現できます。また、 COBOL アプリケーションはさまざまな方法で再利用できます。Micro Focus では、COBOL アプリケーションから簡単に Web サービスを作成したり利用したりできる製品を提供していく予定です。また、 Micro Focus は WS-I が相互運用のために行っているオープンスタンダードの開発活動をサポートしていきます。

簡単に言えば、Web サービスは、サービスベースアーキテクチャの中で「サービス」を定義したり呼び出したりするための新しいミドルウェアプロトコルです。Web サービスは、ステートレスでアトミック、つまり、処理上の状態がなく 1 回の処理ですべてが完了するサービスです。そのため、サービスベースのアーキテクチャがカバーするクライアントの範囲を、イントラネットを越えてインターネットにまで広げることができます。Web サービスの中心となるプロトコルは、SOAP (Simple Object Access Protocol) です。SOAP は XML ドキュメントに基づいており、http 経由で送信されます。リモートクライアントがサービスに「サブスクライブ」して「バインド」するためのサービスインターフェイスは、WSDL (Web サービス記述言語) で記述できます。また、UDDI (Universal Description, Discovery, and Integration) を使うことで、サービスの検索を容易にするための「イエローページ」 (サービスディレクトリ) を作成し、利用することができます。 Web サービスが一般化してきた大きな要因として、これらのサービスが、ベンダーの各種プラットフォームを橋渡しする新しい標準を使って、既存の Web 標準 (TCP/IP 、HTTP および XML) 上に構築されているという事実があります。 Web サービスは、統合化の促進とコスト低減、再利用の改善、そしてインフラの展開コスト節約といったような目的で使われようとしています。しかし、セキュリティや関連標準が欠如しているために、ビジネス分野における Web サービスの採用はあまり進んでいません。それにもかかわらず先進的な企業では、すでにサプライチェーンの取引パートナーとの間でWeb サービスを使用しつつあります。この資料では、Web サービスを詳細には定義していません。しかし、Web サービスプロトコルを使った Web ベースのサービス呼び出し機構は、Java や .NET サービスに適用できるのと同様に、COBOL サービスにも適用可能です。Micro Focus では、「Direct COBOL Web サービス」を定義しています。この機能を使うことで、COBOL プログラマは、その他のプログラミング言語を使わなくても Web サービスとインターフェイスをとれるように、Web サービスを構築できます。

COBOL 関連者の間には既存の COBOL アプリケーション群を再利用して大規模な統合を行いたいというニーズがありますが、その要望に応えるのが Direct COBOL Web サービスです。Enterprise Server には、サービスベースの COBOL 用「バックエンド」プラットフォームを提供する Direct COBOL Web サービスが実装されています。また、コンポーネントベースの「中間層」統合プラットフォームには、J2EE、.NET などのテクノロジが使われています。この組み合わせによって、ユーザはスケーラブルで柔軟性の高い統合化 Web アプリケーションを構築することができます。Direct COBOL Web サービスを使えば、プログラミングチームは、これらのプラットフォーム内/間でビジネス情報をどのように流したらよいかの検討に集中することができます。Java プログラマは、J2EE の 5_{次の URLで、プレスリリースを参照してください。http://www.microfocus.com/press/releases}

(10)

セッションおよびセキュリティ機能を使う新しいビジネスプロセス (ワークフロー) を定義することで、同時にアクセスする多数のクライアントのコンテキストを管理できます。COBOL プログラマは、バックエンドの提供する基本サービスを、馴染みのあるトランザクション処理のパラダイムに従って開発し拡張することになります。Enterprise Server では、情報の流れに COBOL のサービスを完全に組み込むためのインフラが整備されているので、プログラミングチームの編成までして、さまざまなプラットフォームを連携させるための複雑な仕組みを構築する必要はありません。 Web サービスに関する論評 (前述した IBM の著作など) の多くは、「バックエンド」サーバが「素材」サービスを提供すること、および J2EE (または .NET) がインターネットに対するサービス「ブローカ」(仲介) テクノロジを提供するという前提に立っています。少し考えればわかることですが、J2EE (または .NET) プラットフォームが提供しているのは、CICS アプリケーションとの間のサービス「ゲートウェイ」機能だけです。Java ゲートウェイを導入しても、新しいロジックやワークフローが追加されることはほとんどなく、サービスインターフェイスが単に COBOL から SOAP へ変換されるだけです。そうであるとすると、Web サーバとバックエンドサービスとの間の Java 階層は、単なる邪魔者にすぎません。プラットフォームが複合化されている場合に Java 階層を組み込むと、その統合機能を使用しない限りは、セットアップ、管理、テスト、および展開が一層複雑になるだけです。このような「プラットフォームの複合化」は、最終的には Web サービスを呼び出すクライアント側で統合が行われることになるので、生み出される価値に比べてコストがかかりすぎます。 Javaアプリケーションサーバ .NET サービス Java サービス COBOL サービス SOAP HTTP 図 3 – SOAP を使ったサービス集約アーキテクチャ (web サーバは省略)

Net Express および Enterprise Server は、Web サービスのクライアントに Web サービスを直接パブリッシュするためのインフラと、Web サービスを実装言語に関係なく呼び出すためのインフラを提供します。この例を図 3 に示します。図では、COBOL、Java、.NET といったさまざまなソースから提供されるバックエンドサービスが、SOAP を使って Java アプリケーションサーバに集約される様子を示しています。これまでの説明で、中間層の統合化と COBOL、Java、および .NET に対するバックエンドサービスの区別を形式化しました。Java や .NET を使えば、どちらのニーズに対してもサービスをある程度提供できますが、それでも、異なるプラットフォームで実行させたいという要求とこれらを結合したい

(11)

アプリケーションを統合する目的で Web サービスを採用した企業からは、IT インフラにかかるコストが大幅に低減したことが報告されています。こうしたコストの低減メリットは、コストのかかる独自のミドルウェアソリューションに頼ってポイントツーポイントの統合化を行う必要がなくなるため、長期間に渡って得ることができます。多くのプラットフォームベンダー、ソフトウェアベンダー、アプリケーションパッケージベンダーが Web サービスの標準を採用しているので、このコスト低減は、種類の異なる多数のシステムや接続形態で実現できます。

Direct COBOL Web サービスを使えば、さらにコストを低減できます。このサービスを実装することで、今までに培ってきた IT 技術を再利用することができます。多くの IT 部門では、今までのアプリケーションを廃棄して新しく作り直そうとすると、新しいアプリケーションの概念を実証するためにプロジェクトチームを編成し、そこで、複雑なプログラミングパラダイムを短い期間で習得しなければなりません。このためには、かなりの追加費用を使ってスタッフを再トレーニングする必要があります。対応を間違えると、ビジネスを継続してその灯りを絶やさないようにするためのアプリケーションがスキル不足で維持できなくなります。しかし、Micro Focus の Net Express® と Enterprise Server を使えば、プログラマの再トレーニングを少し実施するだけで、最新の複合アプリケーションを開発し、SOAP を使って COBOL サーバ上に配備することができます。

(12)

Enterprise Server

図 4a6_{に、COBOL サービスを構築してクライアントにまで広くパブリッシュするために必要な、サ} ービスプラットフォームのキーコンポーネントを示します。Enterprise Server と呼ぶこのプラットフォームでは、ミッションクリティカルなビジネス問題を解決するために COBOL の豊富な言語環境をさらに拡張した環境が利用可能です。Enterprise Server を使うことで、より広い複合アプリケーション領域 (EAI) を始めとし、究極的にはビジネス領域 (B2B) のアプリケーションにまで COBOL サービスを適用することができます。 エンター プライズ API クライ アント API インターフェイス 管理 クライアント からのアクセス サービスの実行 図 4a – サービスのプラットフォーム

今までに投資してきた COBOL の財産がある場合は、Enterprise Server を使うことでプラットフォームの統一が可能となり、COBOL 財産を新しい複合アプリケーションへ統合するための投資が容易になるだけでなく、コストを抑えることも可能となります。COBOL サービスのプラットフォームが統一できないと、この資料で提唱する費用効果の高い再利用戦略が納得を得られないものとなるばかりでなく、再利用やリプレースのために独自のプラットフォームを構築する必要が生じて、ビジネスの展開にかかる費用が増大します。

Enterprise Server には柔軟性のあるインターフェイス管理ツールがあり、Windows、Linux (z/OS を含む)、および UNIX の各プラットフォーム用サービスを結合して、統一したサービス実行アーキテクチャを構築することができます。図 4b ∼ 4e を参照しながら、Enterprise Server の基本となる機能を詳細に説明します。わからない用語があれば、用語集でその意味を調べてください。

COBOL サービスの統一実行アーキテクチャ

Micro Focus は、革新的なビジョンを提供することにより、長年に渡ってユーザの COBOL 技術開発を手助けしてきました。Enterprise Server の目指すところは、標準の COBOL プラットフォームを構築することでした。 Direct COBOL Web サービスのサポート、および、コンポーネントベースとサービスベースが混在する複合アーキテクチャのサポートには、COBOL プラットフォームが欠かせません。COBOL 用の J2EE コネクタを使う場合は、COBOL サービスで J2EE に合ったセッション、トランザクション、およびセキュリティの各プロトコルを使う必要があります。Web サービスプロトコルには、多くのインターフェイス規約 (セキュリティなど) が組み込まれています。そのため、Web サービスプロトコルを使うサーバにも同様の機構が必要になります。たとえば、SOAP メッセージと独自の MQ メッセージはどちらも XML を使いますが、その詳細は大きく異なります。しかし「サービスの規約」は要求側と提供側との間で、論理的に同一です。 サービスの実行 UNIX COBOL サービス Windows COBOL サービス Linux COBOL サービス トランザクション / セキュリティ …

(13)

Enterprise Server は、Net Express と Server Express の COBOL アプリケーションに対してサービスプラットフォーム機能を提供します。このアーキテクチャには、XML 処理、SOAP 処理、J2EE リソースアダプタ、オーディット、フェールオーバー、セキュリティ、トランザクション、ログ、復元、管理などの機能が含まれています。J2EE が Java の位置をプログラミング言語からプラットフォームにまで高めたように、Enterprise Server も COBOL をプログラミング言語からプラットフォームにまで高めます。

エンタープライズアプリケーションプログラミングインターフェイス

エンタープライズアプリケーションプログラミングインターフェイス (API) は、既存のアプリケーションインターフェイスと新しいアプリケーションインターフェイスから構成されており、クライアントに提供する API は、これらのインターフェイスを素材にして作成します。エンタープライズ API には、企業がビジネスシステムを構築するために使用する一連の共通サービスが定義されています。広範なアプリケーション群を所有する企業には、多くの既存インターフェイスが必ず存在します。この中には、素材として他のインターフェイスより適しているものがあります。COBOL プログラムには、COBOL プログラムの入口点や連絡パラメータ形式、CICS の COMMAREA 定義、あるいは IMS のメッセージ定義といった形式で定義されたインターフェイスがあります。画面インターフェイスも、分類とアクセスが容易な API の形式に簡単に変換できます。

Micro Focus Revolve®7_{および Revolve Enterprise Edition で} は、素材となるこうしたインターフェイスを探して把握し、カタログ化することができます。Revolve には、COBOL のすべての構文および方言を完全にサポートする機能とともに、企業の所有しているさまざまなアプリケーション資産を相互に参照できる機能があります。このように、Revolve を導入することでエンタープライズアーキテクチャの総合的な全体像を構築することができます。ユーザはこの情報を使って所有アプリケーションのポートフォリオを文書化し、重要なビジネスサービスのアクセスに使うクライアント API の「サービス」要素をカタログ化することができます。アプリケーションが適切に構造化されていないと、プログラムのロジックを修正または抽出して、新しいエンタープライズ API として動作させなければならないことがあります。Revolve を利用すると、サービス全体を作成するために必要なコードセクションの識別が容易になります。

柔軟性のあるインターフェイス管理ツール

素材となるサービスベースのインターフェイスには、さまざまなフォームがあります。フォームは、プログラムの連絡レコードを含む COBOL の COPY ファイルであることもあれば、CICS の COMMAREA レコードや画面定義であることもあります。これらの「素材」インターフェイスは、既 7_{ここで引用している製品については、次の当社の Web サイトを参照してください。} 図 4c サービスの実行 エンタープライズ API プログラム の解釈 トランザクション / セキュリティ … UNIX COBOL サービス Windows COBOL サービス Linux COBOL サービス 図 4c

(14)

存プログラムのデータモデルと制御フローに関する仮定とから抽出されてきました。この「素材」インターフェイスの一例として、呼び出されるプログラムの機能を制御するために 1 文字の入力フィールドを定義するパラメータがあります。また別の例として、応答に含まれている日付が COBOL アプリケーションの内部形式で表されている場合もあります。統合プラットフォームに合った新しいデータモデルを使って、物理的なプログラムインターフェイスを論理的なサービス定義に変える理由はたくさんあります。そのような変更を行うことにより、素材にするサービスのデータモデルとフローに関する仮定に基づいて、新しいサービスインターフェイスを分離し、抽象化することができます。 サービスの実行 エンタープライズ API プログラム の解釈 インターフェイス 管理 インター フェイス マッピング コード生成 プロセス ワークフロー UNIX COBOL サービス Windows COBOL サービス Linux COBOL サービス トランザクション / セキュリティ … 図 4d

Net Expresss の Interface Mapping Toolkit6_{を使うと、既存の COBOL プログラムを基にして、新し} い論理「サービス」インターフェイスを設計することができます。こうすることにより、クライアント環境に存在する実際の型モデルに基づいて、サービスインターフェイスのデータモデルを単純化することができます。また Interface Mapping Toolkit を使うと、サービスインターフェイスを定義できるだけでなく、さらには Enterprise Server で動作する COBOL アプリケーションを自動的に配備することができます。

クライアントアプリケーションプログラミングインターフェイス

Interface Mapping Toolkit の重要な特長は、ミドルウェアテクノロジの領域にサービスをパブリッシュできることです。たとえば、Enterprise Server の J2EE コネクタを使って Java アプリケーションサーバと統合させるために、サービスをパブリッシュするということが可能です。またこれとは別の方法として、Enterprise Server の Direct COBOL Web サービスサポートを使うこともできます。さ

(15)

また Enterprise Server には、メッセージ配信用のフォーマットとプロトコルをカスタマイズできる機能もあります。このように共通のミドルウェア階層を通すことで、クライアントテクノロジを使う複合アプリケーションに COBOL サービスを加えることができます。Interface Mapping Toolkit のマッピングおよびコード生成機能を使うことにより、J2EE と Web サービスの標準仕様を通して、Java や COM といった多くのクライアントで使用可能なクライアント API を作成することができます。 サービスの実行 エンタープライズ API プログラム の解釈 クライアント API J2EE Web サービス その他 … インターフェイス 管理 UNIX COBOL サービス Windows COBOL サービス Linux COBOL サービス Java クライアント .NET クライアント ブラウザ クライアント レガシー クライアント MQ クライアント インター フェイス マッピング コード生成 プロセス ワークフロー トランザクション / セキュリティ … 図 4e – COBOLのサービスプラットフォーム

Micro Focus の Enterprise Server および Application Server8_{は、同じ Micro Focus の Net Express} および Server Express™ を使って開発した COBOL アプリケーションを配備するために必要なテクノロジを提供します。両者の違いは、Micro Focus Application Server が単層構成のアプリケーションに COBOL のコアサービスを提供するのに対して、Enterprise Server の方は 2 層構成のクライアント/サーバアプリケーション、および 3 層構成の複合アプリケーションにトランザクション、セッション、およびセキュリティサービスを追加します。Enterprise Server には、Direct COBOL Web サービスのためのサポートと、J2EE 接続のための COBOL リソースアダプタが組み込まれています。

Enterprise Server は、Net Express と Server Express のどちらとも組み合わせて使用できます。これら 2 つの製品には、Interface Mapping Toolkit が組み込まれており、開発者はこのツールキットを使って COBOL サービスを定義し、Enterprise Server に配備することができます。

Micro Focus の Application Server または Enterprise Server を使用すれば、COBOL プログラムで、 COBOL の提供する Web サービスや、Java および .NET など他の Web サービスプラットフォームが提供する Web サービスを呼び出すこともできます。また COBOL プログラムで、COBOL 自身と融和した自然な構文を使って XML ドキュメントを解析、加工、および生成することができます。Net Express および Server Express についての詳細は、Micro Focus の次の Web サイトを参照してください。 http://www.microfocus.com

(16)

おわりに

すでに言及したように、J2EE が Java の位置付けをプログラミング言語からプラットフォームに高めるのと同様、Enterprise Server も COBOL の位置付けをプログラミング言語からプラットフォームに高めます。これを COBOL プラットフォームと呼びます。Enterprise Server は、新しい複合アプリケーションの中で COBOL 開発者がどこまでレガシーアプリケーションサービスを利用できるかという課題に対し、直接影響を与えます。

Enterprise Server を使用することにより、新しい複合プラットフォーム上で COBOL アプリケーションをシームレスに動作させることが可能になり、今後のビジネス展開にはかりしれない価値を与えることでしょう。COBOL は、現在でも大規模なビジネスアプリケーションで最も広く使用されている言語です。人々が働くビルのように、COBOL アプリケーションは、費用効果の高いビジネス価値を提供し続け、経済の回復に貢献することでしょう。既存のビジネスアプリケーション、そして COBOL と最新テクノロジを組み合わせて生まれる力。この両者を利用することによって、ビジネスの新たなニーズに対応できるリアルタイム統合情報システムを構築することができます。システムの統合を可能とするこの革新的なアプローチは、他の大きなリプレースプロジェクトに比べてリスクが少なく、また、コストも大幅に減ります。さらに、信頼のおけるサービス指向のアーキテクチャを使って従来のシステムから新しいシステムを構築すれば、最初の努力は必要であっても、いったん完成すると、そのシステムが基礎となり、新たなビジネスの要請が発生しても、以前より迅速に新しい統合システムを構築して対応することができます。このようになれば、ビジネスに対する即応体制が整い、真の競合力を保ち続けることができます。

(17)

用語集

.NET

.NET は、Microsoft が提唱している Windows プラットフォームの最新版であり、Java (J2EE) プラ ットフォームと同様なアプリケーションサーバ機能を提供します。また .NET には、Web サービスの開発および配備を簡単にするための機能が多く組み込まれています。.NET アプリケーションを構築するための統合化された開発環境として、Visual Studio.NET が用意されています。

API

API (Application Programming Interface; アプリケーションプログラミングインターフェイス) は、 別のプログラムからソフトウェアモジュールを呼び出すためのインターフェイスであり、厳密に定義されています。API には、プラットフォーム (Microsoft Windows など) の提供するサービス要素が定義されています。エンタープライズ API、つまり、企業がビジネスシステムを構築するために必要な共通サービスを定義するときにも同様の概念を使うことができます。

B2B

business-to-business の略語で、EDI (電子データ交換) などのネットワーク接続または Web を使って 行う企業間の電子的な取引を指します。この用語は、B2C (business-to-consumer; Web ブラウザを通して行う企業・一般消費者間の取引) や EAI (Enterprise Application Integration; 企業内部の企業業務統合) と区別するために使われます。

BPM

Business Process Management (ビジネスプロセス管理) の略語で比較的新しい用語です。ワークフロ ーを使ったビジネスサービスの統合を高度に抽象化した概念です。BPM ツールを使うことで、活動フロー全体における人間の行動/作業や電子的な処理を利用した高度なビジネスプロセスを定義し、実行することができます。このような活動/処理は待ち行列に入れられ、ビジネスルールに従った順序とタイミングで実行されるようにスケジュール化されます。ワークフローエンジンは、並行して流れるいくつものビジネスプロセスの実行を調整します。対象となるビジネスプロセスにはいくつものタイプがあり、なかには、完了するまでに数時間、数日、または数週間かかるものもあります。

CICS

Customer Information Control System の略語です。CICS は、メインフレームのアプリケーションに スケーラブルなオンライントランザクション処理環境を提供するために開発されたシステムです。現時点で実装されているCICS には、Transaction Server (最新のリリースレベルは 2.2) としてメインフレームに実装されている CICS と、TX シリーズ (WebSphere Application Server の一部) として中間層に実装されている CICS があります。

COM

COM は Microsoft の Component Object Model を表す略語です。COM はコンポーネントのフレーム ワークを提供します。Microsoft のアプリケーションは、このフレームワークの中でアプリケーションの機能とデータを作成し、共有することができます。COM のコンポーネントは、コンポーネントベースの分散アプリケーションを構築するために、言語、プロセス、およびコンピュータの境界を越えて呼び出すことができます。COM+ はトランザクションサービスに対応できる COM の拡張版です。

(18)

COMMAREA

COMMAREA (Communications Area の略語) は、オペレータセッションが長時間続く場合に、CICS の各トランザクション間でアプリケーションデータを受け渡すための標準的で効率のよい方法です。オペレータが呼び出した各トランザクションは、COMMAREA にデータを置いて次のトランザクションに渡すことができます。CICS トランザクションでは、端末が接続されていない場合に、入力データの唯一のソースとして COMMAREA を使うことができます。リモートのクライアントは、このようなプログラムを呼び出してアプリケーションサービスを提供することができます。

CORBA

CORBA は、 OMG (Object Management Group) の定義した Common Object Request Broker Architecture を表す略語です。CORBA は、言語に依存しないオープンスタンダード仕様です。多く のベンダーがこの仕様を実装し、コンポーネントベースのアプリケーションに対する分散プラットフォームとして提供しています。

EAI

アナリストが考え出した用語 Enterprise Application Integration (エンタープライズアプリケーショ ンインテグレーション) の略語で、多くのアプリケーションを組み合わせて「スーパー」アプリケーシ ョンを実現する一般的な活動を表します。Web を使ってクライアントに広範なサービスを提供するときは、多くの場合、統合化が必要です。しかし、アプリケーションの多くは、オペレータ (画面やウィンドウを使用) およびファイルだけを相手に動作するように作られているため、統合化は困難です。

EJB

Enterprise JavaBeans の略語です。EJB は JavaBean の 1 つの形式であり、リモートのクライアン ト (Java) アプリケーションから呼び出すことができます。EJB には、処理の対象とするデータやトランザクションの意味に合わせて、様々な種類があります。Session Bean は、クライアント固有のセッション状態を維持し、Entity Bean は、データベースのレコードを表す共有データを提供します。

HTML

HyperText Markup Language の略語です。HTML は、ブラウザに表示する Web ページを作成する ための言語です。HTML は、標準的な Web ブラウザであればどのブラウザでも理解できるように、 http を使ってインターネット上を転送されます。

HTTP

HyperText Transfer Protocol の略語です。HTTP は、インターネットかイントラネットかに関係なく、 HTML や XML などのデータを転送するために使われるネットワークプロトコルです。

IMS

IBM の Information Management System (情報管理システム) の略語です。IMS は、銀行業務など 非常に高速のトランザクション処理が要求されるアプリケーションをサポートするために、多くの企

(19)

J2EE

Java 2.0 Enterprise Edition の略語です。J2EE は、トランザクション、セッション、およびセキュ リティ管理といったアプリケーションサービスのプラットフォームを、完全な形で提供します。J2EE は Java の拡張版であり、Java アプリケーション用のアプリケーションサーバを提供します。このサーバを Java プラットフォームと呼ぶことがよくあります。

J2EE コネクタアーキテクチャ

J2EE コネクタアーキテクチャは、Java アプリケーションから Java 以外のアプリケーション (Enterprise Information Systems または EIS とも呼ばれる) にアクセスするための一般的な機構を規定した仕様です。このアーキテクチャでは、コネクションを「管理」することによって、Java の厳密な制約に違反する EIS の動作から、Java クライアントおよび Java プラットフォームを保護します。

Java

Sun Microsystems の提供するプログラミング言語であり、ハードウェアプラットフォームに合ったバイトコードインタプリタと仮想マシン (実行時) を使うことにより、ほとんどすべてのプラットフォームで実行できます。Java 言語は、SUN9_{の管理下にある JCP (Java Community Process) が標準化と} 維持管理を行っています。

JavaBean

JavaBean は、自己検証可能なインターフェイスを提供する Java クラスです。そのため、アプリケー ションは、ソースコードがなくても、そのクラスおよびメソッドの署名を調べてクラスを呼び出すことができます。また、Java ツールを使って自己検証を行うことにより、プログラマは自分の作成するアプリケーションに JavaBean を簡単に組み込むことができます。

Java プラットフォーム

Java プラットフォームは、Java 言語、J2EE サービス、Web サーバ、および Java アプリケーション サーバで実現される Java ベースのアプリケーション環境です。Java プラットフォームには、多くの Web ユーザが並行使用できるようなアプリケーションを構築するためのトランザクション、セッション、およびセキュリティサービスが用意されています。

MQ

MQ シリーズは、メッセージキューイングを目的とした IBM のミドルウェアであり、リモートコン ピュータとの間で、配信を保証するスケーラビリティの高いメッセージ配信サービスを提供します。

SOAP

Simple Object Access Protocol の略語です。SOAP は、コンピュータ間で情報を交換するための XML ベースのプロトコルです。SOAP メッセージは、http を使ってインターネットやイントラネット上に配信されるのが普通で、リモートプロシージャを呼び出したりドキュメントを配信したりすることができます。SOAP メッセージは、エンベロープにヘッダと本体を含めて配信します。ヘッダには要求の配信に役立つ情報を設定し、本体には、送信先アプリケーションで必要となる情報を入れます。 9

(20)

TP

Transaction Processor (トランザクションプロセッサ) の略語です。TP は、同時にアクセスする多数 のオンラインユーザにサービスを提供するシステムに対して、ビジネスデータの完全性を保証するとともに処理とリソースの利用を最適化するためのアプリケーションサービスを提供します。TP システムの例としては、IBM の CICS Transaction Server、 XSeries、および BEA の Tuxedo があります。 TP システムでは、情報システムの構成要素となっている複数のデータベースを、整合性のある状態で維持します。ユーザの要求した各処理単位 (トランザクション) は、完全に実行されるか、またはまったく実行されないかのどちらかで、処理途中で終了するということはありません。トランザクションの処理中にシステム障害が発生したときは、復旧機構が働いて、すべてのデータベースを整合性のある元の状態に戻します。

UDDI

Universal Description, Discovery, and Integration の略語です。UDDI には、開発者やアプリケーシ ョンが Web サービスを検出してその位置を特定するための機構があります。UDDI は、Web サービスのイエローページと呼ばれることがあります。一般的に、開発者用のツールでは、UDDI レジストリにアクセスして、対象とするサービスの WSDL を探します。次に WSDL を使って、クライアントアプリケーションを作成します。このときリモートコンピュータと通信するための複雑なコードを生成するツールを使います。アプリケーションが UDDI レジストリを調べて、複数の候補から 1 つを選択し、そこへ要求を送信する場合もあります。

Web サービス

Web サービスは、クライアントプログラムがインターネットを通して利用できるアプリケーションサ ービス (たとえばプログラム) のことです。Web サービスを利用する場合は、http を使って Web サーバに要求を送ります。Web Services のこの定義はあいまいなので、Web Services Interoperability Organization10_{では、標準化されているプロトコル (http、XML、SOAP、WSDL、および UDDI) の} 組み合わせ (Web サービス相互運用プロファイルと呼ばれている) を使った、より厳密な定義に置き換えようとしています。

WSDL

Web Services Description Language (Web サービス記述言語) の略語です。WSDL は、Web サービス との間でインターフェイスに関する情報を指定するための、XML スキーマのことです。WSDL によって定義されている公開インターフェイスには、次の情報を含めることができます。 • 公に利用できる全操作の情報 • 全メッセージのデータ型の情報 • 使用する特定の転送プロトコルに関するバインド情報 • 指定したサービスの位置を特定するためのアドレス情報

XML

(21)

ベースになっています。多くの企業は、種々の業種やアプリケーションで11_{XML スキーマを定義しよ} うとしています。

アプリケーションサーバ

アプリケーションサーバという用語は、さまざまなクライアントから送られてきたメッセージに応じ て、複数のアプリケーションを同時に実行できる環境を表すときに使います。この用語は、IBM の WebSphere Application Server や BEA の WebLogic Application Server といった Java アプリケーションサーバを参照するときによく使います。これらのサーバでは、Web ベースのクライアントセッションやその他のクライアントセッションに代わって Java アプリケーションを実行するための、スケーラビリティの高い J2EE サービスを利用できます。一般的に Java アプリケーションサーバは、イ

ンターネットを利用しているクライアントに対してWeb サーバ経由で応答します。

CICS と IMS は多数の 3270 端末使用クライアントに実行環境を提供するので、これらもアプリケーションサーバといえます。Microsoft の Windows は、COM および .NET フレームワークを使ってアプリケーションサーバ機能を提供しています。Micro Focus の Application Server は、Windows、 UNIX、および Linux の各プラットフォームで COBOL アプリケーションを動作させるための実行環境を提供しています。

インターフェイスマッピング

インターフェイスマッピングは、2 つのインターフェイス間の関係を定義して、それらインターフェイス間でデータを移動させるプログラムコードを自動的に作成できるようにする技法です。インターフェイスマッピングは、COBOL プログラムの内部インターフェイス (COMMAREA や連絡節など) を、外部インターフェイス (SOAP 要求など) にマッピングする方法を定義するために使用されます。

可用性

可用性は、アプリケーションサーバの「サービス品質」特性であるRAS (信頼性、可用性、保守性) の 1 つです。可用性の高いシステムでは、オペレータがサービスを必要とするときに、いつでも迅速に、そのサービスを利用できます。

コンポーネント

コンポーネントは、複数のクライアントが同時に共有できるアプリケーションサービスです。コンポ ーネントのインターフェイスは、一般的にオブジェクト指向型です (コンポーネントは、クラスおよびそのクラスの提供するサービスを定義するメソッドで定義されます)。各クライアントは、コンポーネントの既存インスタンスに接続することで、他のクライアントと同じコンテキストを利用することができます。もちろん、新しいインスタンスを呼び出すこともできます。Microsoft のコンポーネントモデルは COM です。CORBA はより一般的なコンポーネントモデルであり、種類の異なる多くのプラットフォームで利用できます。

サービス

サービスは、サーバの処理対象となる要求をカテゴリ (タイプ) に分けて定義したものです。サービスは通常、サービス名 (たとえば、UDDI レジストリ内の Web サービス名) とサービスインターフェイス (たとえば、サポート対象の操作およびメッセージを定義するための WSDL) で定義します。サービスの実行は、サーバが待ち行列から要求を取り出した時点で、対応する「インスタンス」が生成され開始されます。多くのサービスインスタンスが並行して実行されることもありますが、その場合、タイプの異なるサービスインスタンスどうしはもちろんですが、タイプの同じインスタンスどうしであっ 11

(22)

ても、それぞれが完全に切り離されて実行されます。

サービスブローカ

サービスブローカとは、入ってくるサービス要求を受け付けるとともに、そのサービスを提供するア プリケーションへ、そのサービスの実行に適した形式で配信するミドルウェアのことです。ブローカは、サービスインスタンスの位置を特定して実行の準備をするとともに、入ってきた要求データをパラメータデータに変換します。サービスインスタンスの実行が終わると、サービスブローカはその出力データを変換してクライアントに返します。サービスインスタンスはその時点で消滅します。

処理単位

処理単位とは、(最小単位の) 完結したトランザクションを実行するプログラムコードのことです。処理単位は、最後まで処理されるかロールバックされるかのいずれかです。CICS のトランザクションは 1 つの処理単位です。COBOL プログラムが処理単位になることもあります。その場合、プログラムの入口が開始位置になり、プログラムの出口が処理単位の終了位置になります。

信頼性

信頼性 は、アプリケーションサーバの「サービス品質」特性である、RAS (信頼性、可用性、保守性) の 1 つです。信頼性は、何らかの原因でシステムに障害が発生する可能性を定義したものです。障害が発生すると、クライアントに間違った応答が返ったり、データが壊れたりします。

ステートレスサービス

ステートレスサービスとは、サービスの動作内容が以前の実行履歴から影響を受けないサービスのこ とです。データベースに対する単純なクエリー (たとえば、Get Customer by ID) はステートレスサービスの一例です。ステートレスサービスは、異なるクライアント間でサービスを効率よく再利用できるという特長から、サーバにとっては重要なサービスです。

セッション

セッションとは、3 層構成の (複合) プラットフォームで、種々の技術階層にわたって実行される論理的な制御スレッドのことです。どのセッションも、コンテキストの提供対象となるクライアントは 1 つのみです。このコンテキストは、クライアントがその前のやりとりでアクセスしたデータを使用したいような場合、長時間にわたって維持させることができます。セッション管理は、クライアントに対するセッションの継続性を保証するだけでなく、同じ Web サーバおよびアプリケーションサーバで複数のセッションが並行して実行される場合でも、それぞれのセッションを完全に切り離して実行させます。

層

層は、複合プラットフォームアーキテクチャにおける論理的なプラットフォーム要素です。3 層アーキテクチャでは、層 1 がクライアント (または Web ブラウザ)、層 2 が中間層、層 3 がバックエンドにそれぞれ対応します。3 層アーキテクチャの場合は、フロントエンド (クライアント) から発信されたサービス要求が、論理層を通ってバックエンド (メインフレーム) に送られます。N 層と呼ぶ場合は、分散コンピューティング用の複合プラットフォームで (アーキテクチャ上の)「対等」なコンピュータを

(23)

中間層

中間層とは、3 層アーキテクチャの中間にある層のことです。中間層の多くは複数の Web サーバとアプリケーションサーバから構成されており、Windows または UNIX プラットフォームで動作します。中間層は、スケーラビリティを高める目的で複数のコンピュータに実装されることがあります。また、いわゆる 2 層アーキテクチャとよく呼ぶものを提供するために、(たとえば Linux の動作する) メインフレームに組み込まれることもあります。

バックエンド

バックエンドとは、3 層アーキテクチャにおける 3 番目の層のことです。バックエンドは、中間層 (中間つまり 2 番目の層) に対して、トランザクションサービスやデータアクセスサービスを提供します。バックエンドサービスは、従来型のトランザクション処理プラットフォームで実行されることがあります。3 層アーキテクチャによって、3270 端末からアプリケーションサービスにアクセスするという形態が、MQ などのミドルウェアを通した中間層アクセスに取って代わられました。

ファイアウォール

ファイアウォールは、外部のアクセスから内部のシステムとデータを保護するためのセキュリティを 提供します。ファイアウォールは、インターネットへ出ていくトラフィックとインターネットから入 ってくるトラフィックがすべて通るゲートウェイであり、送信元アドレスと送信先アドレスを監視して、許されているトラフィックのみを通過させます。

複合プラットフォーム

複合プラットフォームはハードウェアプラットフォームとソフトウェアプラットフォームから構成さ れ、そのアーキテクチャは 3 層または n 層になっています。Windows NT Server 上で Web サーバと Java アプリケーションサーバを動作させるとともに、MQ シリーズを通して OS/390、CICS、および DB2 の実行されている IBM メインフレームに接続している場合、その Windows NT Server は、複合プラットフォームの一例といえます。

保守性

保守性は、アプリケーションサーバの「サービス品質」特性である RAS (信頼性、可用性、保守性) の 1 つです。保守性は、システムエンジニアがシステムの性能、完全性、監査などをどこまで管理および変更できるかというレベルを定義したものです。

リソースアダプタ

リソースアダプタは、Java からベンダーのアプリケーションにアクセスするための Java アプリケーションサーバ用プラグインコンポーネントです。リソースアダプタを使うことで、Java アプリケーションサーバとベンダーアプリケーションとの間の橋渡しが可能となります。リソースアダプタは、基本的に Java 以外の言語で作成されており、異なるプラットフォームで実行させることができます。リソースアダプタを使うことにより、アプリケーションと J2EE との間でトランザクション、セキュリティ、および接続の各機構を連携させることができます。

リモートプロシージャコール

何回も行う操作を一連の命令としてまとめたものをプロシージャと呼び、その基本となるインターフェイスは、データを渡して結果を返してもらうというかたちをとります。通常は、アプリケーション に組み込みます。リモートプロシージャコールは、リモートコンピュータ上の操作を呼び出すための

(24)

機構です。リモートプロシージャコールの構文は、アプリケーション内の操作を呼び出す場合と同じです。リモートプロシージャとの間のデータの受け渡しは、通信ソフトウェアを使って行います。

ワークフロー

ワークフローは、注文に対応するといったような複雑なビジネスプロセスを遂行するために、関連す る複数の処理/活動をどのように統合するかという方法を定義したものです。WSFL (Web Services Flow Language) は、こうしたワークフローを記述する言語の一例です。