お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報（名前、国/地域や会社名）は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

IBM WebSphere DataPower SOAアプライアンスによるCICS、IMSレガシーアプリケーションのサービス化

アーキテクトの視点

Mats Pettersson, シニアITアーキテクト, IBM

Mats PetterssonはスウェーデンのSWG / Financial Servicesに所属するシニアITアーキテクトです。彼は23年間のIT経験を持ち、そのほとんどはアプリケーション開発とシステム統合に携わっていました。ビジネスとITから実装する様々なコンサルティングメソドロジーを使用した異種プラットフォームでの業務経験を持ちます。

概要： IBM® CICS® 及び IMS™レガシーアプリケーションをService-Oriented Architecture (SOA)の世界に取り込み、再利用可能にするインテグレーションテクニックについてご紹介します。IMS SOAPゲートウェイ, CICS Webサービス, IBM WebSphere® DataPower SOAアプライアンスをこの記事の中で取り上げます。

日付: 2007年 10月 30日
レベル: 中級
この記事の原文: 英語
アクティビティー： 2839 ビュー
お気軽にご意見・ご感想をお寄せください：

概要

この記事では、CICS、IMSレガシーアプリケーションを異なる技術および製品を利用してサービス化する方法を紹介しています。ここではSOA transition scenarios for the IBM z/OS platform(参考資料：IBM Redbooks®より)で述べられているコンセプトに基づいています。　このRedbookでは、以下のように述べられています。

"チャレンジとは、SOA概念を利用した新しいアプリケーションを構築することではなく、SOAの世界の中に既存のアプリケーションを取り込むことです。ITインフラストラクチャーにおいても同じことが言えます。SOA概念を利用した新インフラストラクチャーを構築することは、最終的には全ての運用インフラストラクチャーをSOA化されたものに変換することより簡単です。"

サービスインターフェースパターン

この記事では、バックエンドアプリケーションにおいてコーディング不要なサービス統合手法を学習します。サービス統合のためのアーキテクチャーパターンを記載しています。サービス統合のためのインターフェースは基本的に以下に示す4つのパターンに分かれます。

ネイティブサービスインターフェース（N）
ネイティブサービスインターフェースソリューションは、トランザクションサーバー、データベースマネージャー、その他インフラコンポーネントをネイティブ機能として使用することによって、SOAのためのコアシステムを有効にします。

CICS Webサービスはメインフレームとの接続でのネイティブサービスインターフェースの一例です。（メインフレームとの接続は、アダプターが提供するサービスインターフェースの例としてIMS SOAPゲートウェイがあります。これについてはこの記事の後半で触れます。）　図1では、サービスインターフェースはアプリケーションが稼動しているコンテナによって提供されていることを示しています。

図1.から4.までの略字
- P = プレゼンテーションロジック
- B = ビジネスロジック
- D = データアクセスロジック
図1.ネイティブサービスインターフェース
アダプターが提供するサービスインターフェース(A)
可能であればアダプターはシステムが持つインターフェースとSOAベースのプロトコルを変換するものを用いる。

図2.アダプターが提供するサービスインターフェース

通常アダプターは、アプリケーションコンポーネントがサービスを有効にし、これを保有するインフラコンポーネントの外にいます。アダプターは以前はWebアプリケーションサーバーのようなミドルウェアとの連携を提供してきました。
ブローカー、仲介サービスインターフェース(B)
コアアプリケーションの変換を行うサービスインターフェースを提供するESBやブローカーは、仲介役として容易に使用されます。ESBにより、コアアプリケーションを新しいプロトコルに対応させる必要はありません。また、メッセージコンテンツの変換が可能なので、ESBを介して他のサービスからの呼び出しが可能になります。

WebSphere DataPower SOAアプライアンスはブローカー、サービスインターフェースの仲介役の一例です。この記事では後ほど触れます。

図3.ブローカー/メディエーションサービスインターフェース
ネイティブサービスインターフェースでの再開発コード(R)
ネイティブサービスインターフェースパターンでの再開発コードは、既存のコアシステムコードとSOA準拠の構造、プロトコルに合わせた書き換えが含まれます。これは、よりSOAフレンドリーなサービス構造にするリファクタリングされたソースコードとなります。

図4.　ネイティブサービスインターフェースでの再開発コード

再開発コードのメソドロジーとツールについては、本記事の対象外とします。

サービスインターフェースパターンについての詳細はSOA Transition scenarios for the IBM z/OS platform(参考資料：IBM Redbooks®より)を参照してください。

上に戻る

遷移アプローチ

サービス統合、既存のSOA標準のレベルに応じた適切な遷移アプローチを選択します。表1を参照してください。

表1.遷移アプローチ

遷移アプローチ	説明
Improve	既存のアセットのサービス化にフォーカスします。サービス化とは、アセットがサービスコンシューマーに対して公開する新インターフェースとなることを意味します。このアプローチはアプリケーションの再コーディング、再開発の必要はありません。
Adapt	サービス統合にフォーカスします。フレキシブルにサービス統合を行う手段がESBです。
Innovate	リストラクチャーの結果、ESBによりSOA標準、プロトコルにネイティブに適応したアプリケーションに書き換えられます。改変されたアプリケーションは完全にモジュール化され、将来より簡単に再利用することが可能になります。また、サービスインターフェースも持ちます。この記事では新規コーディングなしで既存アセットのSOA化にフォーカスするので、このアプローチについては触れません。

上に戻る

IMS、CICSトランザクションをサービス化するソリューション

典型的なIMS、CICSトランザクションはプレゼンテーション層、ビジネス層、データロジック層に分かれています。しかし、それらは各層の間で比較的強い依存関係を持ち、簡単に切り離すことができず、サービスとして切り出すことができません。これは、デザインが悪いのではなく単にアプリケーションが複数のチャネルや異なる標準をサポートする要件がないときに作成されたからです。

多くのIMSとCICSアプリケーションは3270環境で開発され、様々なトランザクションが順番に使用されています。24 X 80ディスプレイのスクリーンナビゲーションはSOAのサービスインターフェースとは大きく異なります。再利用性可能なサービスを見つけることは困難です。

重要なことはSOA化する際のサービスの粒度と懸念を払拭することです。

SOA“Ambitionレベル”と遷移アプローチ

サービス統合のターゲットレベルによってアプローチは異なります。電話、インターネット、イントラネット、エクストラネットなどのマルチチャネルアクセスを作成したいですか？それともポータルで統合したいですか？あるいはワークフローを実行するビジネスプロセスエンジンですか？サービス統合の種類として何を求めますか？

Improve: Improveアプローチは既存のアセットのサービス化にフォーカスします。サービス化とは、アセットがサービスコンシューマーに対して公開する新インターフェースとなることを意味します。通常、アーキテクチャーの中にオープンスタンダードを取り込むことが求められます。
Adapt: AdaptアプローチはImproveより一つステップが高いambitionレベルをセットします。サービスが動的に配置、呼び出されるためにメディエーション、トランスフォーム、ルーティング、業界標準のサービスレジストリーを取り入れます。結果として、バックエンドのレガシーアプリケーションは新プロトコルに合わせる必要はありません。

Improveアプローチの最初のポイントは、マルチチャネルアーキテクチャーに関わる必要がある多くの古いレガシーアプリケーションがあるということです。新しい技術を使用して全ての機能を再開発することはよいビジネスケースではないかもしれません。サービス化とマルチチャネルアーキテクチャーのためのトランザクションをオープン化することで十分です。

バックエンドトランザクションをサービス化にするには、Quality of Serviceとセキュリティーが非常に重要です。誰が、いつ、どのチャネルのサービスを呼び出すかわからないこともあります。統合プラットフォームにおける信頼性とセキュリティーは非常に重要です。

上に戻る

ソリューションテクニック

ソリューションの中で使用するテクニックは、ソリューションがサービス統合での要求レベルを満たす技術と製品が含まれます。図5ではサービス統合パターンと遷移アプローチの関係性を示しています。

図5.サービス統合パターンと遷移アプローチ

この章では以下のテクニックについて紹介します。

IMS SOAPゲートウェイ
CICS Webサービス機能
IBM WebSphere DataPower SOAアプライアンス
組織内で開発したJ2EEアプリケーション

ソリューションテクニックを選ぶ前に、要件を解析する必要があります。
これらの質問を考慮してください。

ソリューションの範囲はどこまでですか？一時的なソリューションですか？企業間で広範囲に共有されますか？
どのくらいの期間ソリューションを維持しますか？一時的なソリューションですか？それとも長い期間で使用する戦略的な選択ですか？
ESBで相互運用する必要はありますか？サービスレジストリーについてはどうですか？
開発者の熟練度や知識レベルはどうですか？SOA内でサービスを構築するための開発標準はありますか？
非機能要件は何ですか？規模はどの程度ですか？レスポンスタイムは？セキュリティーは？トランザクションは？サービスはUnit of work(UOW)に含まれる必要がありますか？
システム管理は？ツールの要件、監視ソリューションは？

IMS SOAPゲートウェイ

IMS SOAPゲートウェイはIMSトランザクションサーバーの一部です。これは、独自プロトコルをSOA準拠のプロトコルに変換するので、アダプターが提供するサービスインターフェースパターンに合います。IMS SOAPゲートウェイはSOAPを介してIMSアプリケーションの呼び出しを可能にします。

IMS SOAPゲートウェイは二つのメインコンポーネントから成ります。

IMS SOAPゲートウェイサーバーのノードがSOAPサービスとWSDLインターフェースを提供します。IMS SOAPゲートウェイサーバーはMicrosoft® Windows®, IBM AIX®, Linux® on IBM System z® with z/VMで稼動します。
IMS SOAPゲートウェイデプロイメントユーティリティーはプロパティーを設定することによりIMS SOAPゲートウェイのためのランタイムコードを作成します。

図6.IMS SOAPゲートウェイ

IMS SOAPゲートウェイを利用することでコード変換なしにすばやくIMSトランザクションをサービス化することが可能です。

CICS Webサービス

CICS WebサービスはCICSトランザクションサーバーの一部であり、SOAPとWS-Security, WS-Basic Profile, WS-TransactionなどのWS-I標準をサポートしています。インバウンドリクエスト（CICSをサービスプロバイダーとして利用）、アウトバウンドリクエスト（CICSをサービスコンシューマーとして利用）のいずれかをサポートしています。

図7.CICS Webサービス

IBM WebSphere DataPower SOA アプライアンス

WebSphere DataPower SOAアプライアンスはSOA導入にあたりハイパフォーマンスで強固なセキュリティーを提供するアプライアンス製品です。WebSphere DataPowerには3つの製品があります。

XMLアクセラレーター XA35 - サーバーからXML処理をオフロード
XMLセキュリティーゲートウェイ XS40 - 豊富なセキュリティー機能、XML/SOAPファイアーウォール機能
インテグレーションアプライアンス XI50 -プロトコル変換、メッセージ変換機能、XA35,XS40の機能も含む

ここでのシナリオはXI50を想定しており、以下の機能を使用しています。

XI50に搭載されるDataGlueエンジンはany-to-anyの変換を実現します。バイナリー、フラットテキストからXML、XMLからバイナリーやフラットテキスト、バイナリーからバイナリー、XMLからXMLなどのデータフォーマットの変換が可能です。
コンテンツベースのルーティング機能
プロトコル変換（HTTP,MQなど）機能
軽量なメッセージブローカー機能
メッセージレベルのセキュリティー(WS-Security, XML電子署名, XML暗号)

WebSphere DataPower と IMS

IMSとの統合は、WebSphere MQを介しておこないます。IMSトランザクション内のネイティブMQIインターフェースかIMS OTMAブリッジを介します。バックエンドのアプリケーションコードは変更することなく統合させることが可能です。
WebSphere DataPowerはキューマネージャーに接続するためのMQクライアントを保持しています。これによりIMSとの接続が可能です。
WebSphere DataPowerはWebサービスインターフェースを公開し、MQメッセージをSOAP XMLメッセージに変換します。
Webサービスとセキュリティーの標準にはWebSphere DataPowerで対応させるため、バックエンドのIMSアプリケーションは対応させる必要はありません。

図8.WebSphere DataPowerとIMS

WebSphere DataPower とCICS

WebSphere DataPowerとCICSは、CICSのオープントランザクションマネージャーアクセス(OTMA)が利用できないことを除けばIMSとの例とよく似ています。CICSトランザクションとWebSphere DataPowerの間にはMQが必要です。

図9.WebSphere DataPowerとCICS

WebSphere DataPower とIMS ,CICS

IMSとCICS混在環境では、WebSphere DataPowerは両方のフロントエンドとして使用します。以下はこのソリューションの効果です。

フロントエンドとバックエンド間のインターフェースはMQを使用することにより疎結合となる

IMSもCICSもMQによって呼び出されるので、その他のクライアント、プラットフォーム、プログラミング環境には依存しません。

Webサービス標準とその定義はWebSphere DataPowerボックス内で定義されます。WSDL定義はバックエンドシステムから分離されます。
XML処理はバックエンドアプリケーションから切り離され、CPU処理からオフロードされます。
メッセージ、XML変換のルール定義はWebSphere DataPowerで定義します。
セキュリティーモデルはIMS,CICSアプリケーションから分離され、WebSphere DataPowerで実装します。

図10.WebSphere DataPowerとIMS,CICS

コネクターを介した様々な統合技術を使用したJ2EEベースコンポーネント

レガシーアプリケーションのサービス化における他の方法はJava 2™プラットフォームでの開発です。J2EEベースのアプリケーションはレガシーアプリケーションをカプセル化しサービスインターフェースを提供し、中間層にデプロイされます。しかし、上述のようにこれは新規開発、テストツール、メソドロジーを必要とします。

ソリューション技術の違いは中間層から使用可能ということです。例えば、IMSコネクトを使用するとIMSトランザクションはTCP/IPかCICS外部インターフェースからの呼び出しが可能になります。

他のアプローチとしてIMS,CICSレガシーアプリケーションの両方を統合するためにMQを使用する方法があります。MQは強固で効率的で実績のある技術です。

図11.J2EE

上に戻る

まとめ

この記事ではCICSとIMSアプリケーションのサービス化シナリオについて異なる技術をご紹介しました。レガシーアプリケーションのサービス化について重要な捕らえ方を学習しました。"Ambitionレベル"、レガシーコードを再利用できるかどうか、ネイティブサービスインターフェース、アダプターもしくはブローカーを使用してサービスを切り出すか、完全に再開発する必要があるかどうかの決定についてです。

また、IBM WebSphere DataPowerインテグレーションアプライアンスによってどのようにアプリケーションをサービス化するかを学習しました。このケースではMQが存在するバックエンドのメインフレームアプリケーションがWebサービス化されますが、WebSphere DataPowerインテグレーションアプライアンスがこれを可能にします。