ノルウェー最大の金融サービス会社であるStorebrand ASAは、ノルウェー全体で280,000を超えるクライアントの銀行業務および資産管理、ならびに健康保険と生命保険業務を行っています。challengeこのマンモス企業が直面する厳しい難題の1つが、ノルウェーにある約6,500社、延べ390,000人に及ぶ従業員の年金計画を操作する際の従業員レコードの追跡と管理でした。

これまで、この途方もない同期をとる作業の大半は手作業で行われ、関連データベースの項目を更新するために専用スタッフを50人も必要としていました。必要な作業として、日付、給与、住所、契約内容、口座番号などの詳細情報の送信、検証、更新、再チェックに加え、その後にStorebrandの中央データベースにこれらのデータを入力する作業がありました。そのために、複数の顧客の様々な給与計算システムからデータを取り出し、Storebrandに送ることが行われ、その際にオンラインのフォームを使用することもありましたが、大抵の場合は紙に手書きされ、データの認証はスマート・カードと証明書を組み合わせて行っていました。このような面倒なプロセスのため、自動化ソリューションが望まれていましたが、これまでの既存のWeb標準では実現できず、そのため、Storebrandではインターネットを介してパートナーと文書を電子交換するためのオープン標準を利用するための手段を探すことにしました。

従業員レコードの同期のほかに、Storebrandが直面するビジネス上の難題には、生命保険証券と年金基金と金融商品などの、主要な製品とサービスをリンクすることも含まれていました。また、ディストリビューターと顧客に商品をより適切に提供する方法も探していました。最終的にStorebrandが選択したのは、ビジネス・プロセスを自動化して作業コストを下げることによって、社内およびビジネス・パートナーとの効率を改善して経費をコントロールすることでした。

その結果、現在手作業のデータ入力と管理に携わっている従業員の大半を人事異動し、それにより、会社全体の年間労働コストを数千時間削減することで作業効率が改善されるとStorebrandは見込みました。

ビジネス上および技術上の難題

Storebrand ASAは、この問題を解決するため、IBM j(ump)Start Emerging TechnologiesのUKチームに相談を持ちかけました。jStart Engagementのマネージャーに相談した結果、Storebrandは2つの目標を定めました。

1. 従業員が手作業でデータ処理を行うという社内の既存のビジネス習慣を変更する。
2. Webサービスを使用してクライアントの給与計算システムからデータを取り込めるようにし、自動的にデータの計算を行ってから、情報をメインフレーム・データベースに直接転送する。

jStartのインプリメンテーション側では、次のようなプロジェクト目標を定めました。

• Storebrand側のWebサービスを (サーブレットとして) 作成する。
• Webサービスに合わせてベンダーの給与計算システムを変更する。
• 必要なインフラストラクチャーを導入する。
• セキュリティーを確保する。
• 既存のStorebrandのビジネス・パートナーに接続する。
• Webサービスのテクノロジーの可能性を示す。

上に戻る

共通の形式を探す

プロセスの最初のステップは、共通のデータ形式を明らかにし、合意することでした。顧客が一貫した方法でStorebrandにデータを示すためには共通の形式が必要であり、また、Storebrandアプリケーションは、適切なデータを抜き出し、中央のデータベースに入れることができなければなりませんでした。

Storebrandの顧客とパートナーの大多数は、すでに従業員データの電子的な取り込みを行っており、そのほとんどが従業員情報を独自の給与計算システムにリンクしていました。従業員の手当を正確に計算する場合に必要となる情報は、初めから各会社の給与計算システムに保持されていたのです。つまり、一般的には所得などのデータの変更は書面に書き写され、FAXや郵便でStorebrand ASAに送付され、それを手作業で入力していたわけです。

複数の給与計算システムを使用可能にするために (そして、最終的には、Storebrand ASAの顧客である6,500を超えるビジネスのすべてのシステムをサポートするために)、さまざまなハードウェア環境の異なるオペレーティング・システム上で実行されている複数の給与計算システムに導入できる、標準ベースのソリューションを提供する必要がありました。

Storebrand ASAは、この目的のために、業界固有のXML用語である、米国の企業グループACORDのXMLifeを選択しました。タグを少し追加しただけで (変更後の完全なDTDについては、参考文献を参照してください)、Storebrand ASAは、各会社の給与計算システムと独自の手当管理システムとの間でデータを交換する、標準準拠の手段を提供することに成功しました。

XMLifeの選択にあたり、StorebrandとjStartメンバーからなる共同開発チームは、いくつかの要素を考慮しました。まず、共通の形式に必要なのは、1つのベンダーに固有のスキーマではなく、すべてのパートナーに合った汎用のソリューションであるということでした。また、時間や経費を使って独自の標準を開発することもしたくありませんでした。ACORDは保険ビジネス (Storebrandのビジネスの約44%に相当します)の現在の業界標準であり、XMLifeは広く認知され、共通の採用に適したXMLスキーマだったので、この選択の妥当性は明らかでした。

このソリューションを使用して、それぞれの給与計算ベンダーは必要なデータを取り出して、そのデータをXMLifeに変換します。ベンダーから提供されたCOMコンポーネントからSOAP要求が生成され、StorebrandのWebサービスはそのデータを受け取り、IBMのMQSeries Integratorミドルウェアに渡します。

上に戻る

理想的なソリューション: 業界固有のtModel

ビジネス間のデータ交換のためにXML用語を選んだことはすばらしいスタートですが、保険業界が必要としていることは、Webサービスでの標準化です。Webサービスの定義を使用すれば、仕様をtModelの形式で記述することができます。tModelとは、基本的にはメタデータのフリー形式の拡張版で、サービスの包括的な仕様の概要を記述するものです。このように、WSDL文書で定義されたtModelを用いた記述には、使用されているXML用語へのポインターを含めることができるだけでなく、特定のサービスの使用に関するビジネス・ルール、コスト、契約などの詳細な記述を含めることもできます。

ただし、これをStorebrandだけで実行するのは望ましくありません。理想は、保険業界がこれ (つまり、生命保険データの交換) やその他のビジネス・トランザクションをWebサービスとして標準化して、tModelを用いて文書化し、業界全体で迅速に利用できるように定義することです。

Storebrandとその顧客のケースでは、共同で定義したシステムで要求は満たされました。共通のデータ形式について合意した後の次のステップは、異なるプログラミング言語を使用している複数の異なるシステムが互いに通信できるようにすることでした。Storebrandの顧客の多くは、Intelベースのシステム・アーキテクチャーでWindows 2000の操作環境を使用していますが、Storebrandの中央データ・リポジトリーは、実行している操作環境がまったく異なるIBMのメインフレームで作動しています。

チームは、2001年1月初旬に、まずプロジェクト定義ワークシップから開始し、人事部門、ビジネス・パートナー、給与計算ベンダー・プロバイダー、技術チームと共に、現在のインフラストラクチャーを調査しました。2月に開発が始められ、その後2か月間の作業を経て、最初のシステムが完成したのは5月初旬でした。Storebrandはその間、顧客と新しいシステムを使用するための契約を結ばなければならず、これは8月までかかりました。新しいシステムの初期テストでは、2、3の顧客が数百の従業員手当クライアントを処理しました。初期のシステムでは、Storebrandとそのクライアント会社間に直接的な関係が存在しますが、将来的には、給与計算ベンダー・プロバイダーの役割を果たすサード・パーティーを仲介業者として取り入れる予定です。このようなケースでは、給与計算ベンダー・プロバイダーは、手当を受ける従業員がいる実際のクライアント会社に対する、アプリケーション・サービス・プロバイダーとして機能します。

さまざまな環境でデータを共用できるようにするため、jStartはSOAP (Simple Object Access Protocol) 接続を使用してギャップを埋めることにより、大半の給与計算アプリケーションのWindows環境と、Storebrand LifeのWebSphere Java環境とを接続することを提案しました。

チームは、3つの選択肢について検討しました。

1. SOAP単独 -- SOAPを基本的なプログラム間の「接着剤」として使用して、アプリケーションを互いに結合し、ピアツーピアの通信を実現できるようにする。
2. SOAP + WSDL定義 -- WSDLでは、サービスの標準化された記述を提供することはできるが、完全なリポジトリー検索は行えない。アプリケーション・サービスを記述し終えたら、アプリケーション/サービスをWeb「リクエスター」(この場合は、新しいStorebrandのディストリビューター)に認識させることができるサービス・ブローカーを使って発行する。
3. SOAP + WSDL + UDDI (レジストリー内のサービス記述を含む) --UDDIもまた、Webサービス統合のフレームワークである。これには、Storebrandの製品とサービスを記述するための標準ベースの仕様が含まれており、これを使用して、グローバルなレジストリー・アーキテクチャーで検索を行うことができる。

Storebrandは、最初は3つのテクノロジーすべてを組み合わせて使用することにしました。このために、チームは、XML文書を入力として受け取って、HTTPプロトコルを介してインターネットで転送することによりStorebrand Webサービスに送る、COMオブジェクトを作成しました。この事例において、顧客サイトでは、主にMicrosoft Windows NTまたはWindows 2000システムを使用して、手当処理のためのデータ入力を行っていました。したがって、チームはVBでクライアント側のCOMインターフェースを作成することを決定し、インターフェースにはMicrosoftのSOAPツールキットを使用しました。Storebrandのサーバー・サイドでは、単にIBM XML & Web Services Development Environmentで提供されるウィザードを使用することで、既存のJavaアプリケーションをWebサービスに変換しました。このWebサービス対応アプリケーションは、XML文書を受け取り、StorebrandのDB2中央データベースに渡すために必要な検証および更新プロセスに備えてそのデータを変換します。 図1 に、プロジェクト・システムのアーキテクチャー概念を詳しく示します。

表2 に、成果物案と、プロジェクトで使用する個々のソフトウェア・コンポーネントを示します。

最新のテクノロジーを使用するこの規模のプロジェクトであれば、複雑なことは不可避です。2001年初めの時点では、欠如しているWebサービスのセキュリティーをどのように導入すべきか、分かりませんでした。Storebrandの要求は、ファックスや紙の記録の送付の代替手段として顧客に提供したWebページのフォームを利用した既存のオンライン・システム (それでも多くの場合、顧客はすべてのデータをWebフォームに再入力する必要がありました。) と同レベルのセキュリティーを確保することでした。チームは最終的に、多くのビジネスWebサイトで一般的に用いられている、Secure HTTPプロトコルとSSLプロトコルを使用することにしました。ただし、当初はクライアント・エンド開発に使用するMicrosoft SOAPツールキットが、その時点ではSSLをサポートしていなかったという問題がありました。したがって、サーバー・エンド・サービスの呼び出しを開始するには、Microsoft Wininet.dllライブラリーの直接呼び出しを使用しなければなりませんでした。これらのVisual Basic呼び出しの例については、参考文献を参照してください。これで、これらの呼び出しによりSOAP呼び出しが行われます (参考文献を参照してください)。

2つ目の問題は、順次メッセージを1回だけ実行するように、等べき形式で処理することでした。これは、今日のWebサービスで一般的に不足している点です。サービスが同じメッセージの複数のインスタンスを繰り返し処理する可能性があるこの分類問題が発生しないように、チームは、アプリケーション・ソフトウェアでサービス・レベルの上に一意のレコード番号を追加しました。

また、サーバーに対しクライアント側のコンテキストを示す方法もありませんでした。導入するセキュリティー・システムの一部として、SOAPメッセージに証明書を組み込む必要がありました。このために、Apache SOAPのインプリメンテーションで利用できる、交換可能なプロバイダー・インターフェース を使用しました。

最後に、プロジェクトの段階で、チームは、MicrosoftツールキットとIBMツールキットで互換性がないWSDLのインプリメンテーションに直面しました。これが、展開システムで標準のWSDLを使用する代わりに、独自の文書記述形式を選んだ要因の1つです。プロジェクトがより広範なコンテキストに移行し、多くの会社で (つまり、多くのクライアント・システムで) 導入されるようになれば、単一の互換性のあるWSDLのインプリメンテーションに向けて展開する計画です。使用されている文書記述子の例と、その記述子と一致するサーバーの部分の例については、参考文献を参照してください。

Wininetライブラリーからの呼び出しが、サーバー・エンドとのセキュア接続を確立すると、Visual Basicクライアント・アプリケーションは、適切なSOAP呼び出しを行ってデータを送ります。これは、理論的には、WSDLファイル内の記述を介してサービスにアクセスしていることになります。しかし、すでに説明したように、使用しているのは顧客のデプロイメント記述子です。Wininet呼び出し、Microsoft SOAPツールキット、理論上のWSDLファイル、実際の顧客のデプロイメント記述子、およびこの特定の例に対応するサーバー側の部分についての一連のファイル例については、参考文献を参照してください。

新たに採用された給与計算システムのユーザーにとっては、いくつかの成果があります。まず、それぞれの新しいクライアント会社でのクライアント側ソフトウェアのインストールにかかる時間が、1日以内となります。クライアント・ソフトウェアが標準化XMLをサポートしているという前提で、実際に必要なことは、提供されたDLLファイルを給与計算アプリケーションで利用できるようにすることだけです。実行時に、オペレーターは、インターネットを介してSOAP接続を確立し、必要なデータをStorebrandに転送するために、クライアント・データ項目に特別なことは何もする必要がありません。また、XMLをCOMオブジェクトとしてラップしておけば、万一、実行時に障害が発生しても、XMLファイルがクライアント・マシンのファイル・システム上の文書としてアクセスし続けることができるような、セキュリティー上の危険性もありません。データには、給与やその他の個人的な関連情報が含まれており、このようなデータを更新するには相応の責任が求められるので、こうした問題が発生することは、特に望ましくありません。

上に戻る

成功したソリューション

プロジェクトが実行されてから数か月がたちましたが、今後も、この分野でのすべてのStorebrandクライアントの複雑な状況に対応するように、展開を続ける予定です。この初期システムでは、Storebrandのクライアント会社で幅広く使用されている、スカンジナビア企業Tietoenatorの優れた手当処理ソフトウェアに対応しています。しかし、Storebrandの6500を超える顧客全体で幅広く利用できるようにするため、少なくとも30種類の一般的な手当処理パッケージを扱う予定です。これには、クライアント側のかなりの種類のプラットフォームが含まれるため、本当にプラットフォームに依存せず、言語に依存しないシステムの真価が示されることになります。

Storebrandでは、異なるシステム・アーキテクチャーを使用しているディストリビューターやクライアントと(SOAPを使用して) 簡単に通信できるようにすること、サービスを業界に (UDDIを使用して) 認識させること、そしてStorebrandアプリケーションを使用することで金融サービス、金融商品、保険商品の新しいディストリビューターを見つける方法の詳細を公開できること、また、いくつかのビジネス・パートナーのオファリングを将来的にStorebrandアプリケーションのポートフォリオに組み込めるようになることを期待しています。

Storebrandはまた、Storebrand BankやStorebrand Fundsのビジネス単位におけるビジネス領域でもWebサービスを利用し、そこでも内部の作業コストを削減することを期待しています。

StorebrandのWebサービス・ソリューションにより、データ更新の効率は非常に向上し、既存の顧客とパートナーは満足し、会社は、新機能が売り込みに有効であると考えています。データの取り込みと受け渡しにXMLを利用し、Storebrandとその顧客間のビジネス処理を変更し、プログラム間通信にSOAP Web標準を使用することで、Storebrandは、手作業による情報の取り込みと入力時間を数千時間節約でき、それにより会社の直接的な経費となる作業コストを削減することに成功しています。

参考文献

• Storebrand ASA について詳しく調べることができます。
  
  
• IBM jStart チームは、会社が社内システムに新しいテクノロジーを導入するお手伝いをします。
  
  
• Wininet呼び出し、Microsoft SOAPツールキット呼び出し、将来性に使用される可能性のあるWSDLファイル、デプロイメント記述子に関するサンプル・ファイルを参照してください。
  
  
• このプロジェクトが最初に立ち上がってからこれまでに、Webサービス・ツールキットには新しい多くの機能が追加されました。
  
  
• このプロジェクトで使用したXML & Web Services Development Environment もダウンロードできます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ビジネス上および技術上の難題
• 共通の形式を探す
• 理想的なソリューション: 業界固有のtModel
• 成功したソリューション
• 参考文献
• 著者について
• コメント