.NET／Java相互運用の現在・未来
― .NET／J2EE相互運用の基礎から最新テクノロジまで ―

第4回　相互運用の実際と今後の課題

岸上：全国の支社からExcelで作成された環境情報データなどを中央で集計し、バックエンド・システムに渡すシステムです。クライアント側はWindows＋Excel、サーバ側はUNIX／Javaベースのアプリケーション・サーバであるBEA社のWebLogicを利用し、両者をWebサービスで接続しています。GreenGlobeとして製品化しました。

岸上：企業では、エンドユーザーが必要に応じて独自のExcelシートを作成し、それでデータ管理をしているケースが非常に多いという事情があります。私たちの間では、このようなExcelシートを「オレさま帳票」と呼んでいます。現場だけで閉じているなら何の問題もないのですが、これらのデータを中央で集計しようとすると、一貫性のない独自帳票が問題になってきます。Webアプリケーションで中央集中型にすれば問題を解消できますが、この場合、ユーザーは使いなれたExcelシートを捨て、共通化された新しいフォームの利用を強制されます。ユーザーの教育やヘルプデスクなどに莫大なコストがかかってしまうのです。そこで私たちは、エンドユーザーがいま持っている、使い慣れた「オレさま帳票」を尊重しながらも、データを中央で集計できるようなしくみを作りたいと考えました。

岸上：確かにテクノロジ的にはそのほうが単純です。しかしビジネス・ロジックやワークフローなどといったサーバ・サイド・システムは、すでにJavaベースで開発されている場合が少なくありません。どこかで.NETとJavaを接続しなければならないなら、正面から.NET／Javaの相互運用に取り組むべきだと考えました。この際、社内ばかりでなく、社外のシステムも接続することを考えると、クライアントとサーバがファイアウォールを越えて通信できる必要があります。また「オレさま帳票」はユーザー独自の仕様なので、そのままサーバ側に送信されると、サーバのデータが不整合を起こしてしまうかもしれない。データをアップロードする前に、論理的な矛盾がないかどうかはクライアント側にロジックを置いて検査できるようにしておきたい。こうした要件を総合して、クライアント側は.NETベースのプログラム、サーバ側はJavaアプリケーションを配置し、両者をWebサービスで接続することになりました。

岸上：Office 2003 Webサービス・ツールキット（以下WSTK：Web Service Took Kit）を利用し、ExcelのVBAプログラムからWebサービスを呼び出しています。現在ではWSTKを強化した後継版のVisual Studio Tools for Office（VSTO）が利用できるのですが、私たちが開発している段階ではまだありませんでしたので。

岸上：結論からいえば人力です。まず、各担当者から部門担当者に「オレさま帳票」を添付したメールを送信します。部門担当者は、メールに添付されているExcelシートを1つ1つ開いてマスターにコピー＆ペーストで転記し、情報不足などでうまく転記できないものは担当者にメールで問い合わせ、送信をさぼっている担当者にはメールで確認するという、純粋に人間系のやりとりです。部門データがまとまったら、事業所とか、工場とかのレベルで複数部門のデータを集計し、本社に送ります。本社は、それらのデータを全社規模のシステムに入力、集計して、やっと全社の状況が分かるというしくみです。予算策定などは典型的なケースのひとつでしょう。

岸上：ええ。たいていの企業の情報システムは3層構造になっています。1つは、レガシーと呼ばれるバックエンドのメインフレーム・システム。もう1つは、ユーザーに近いフロントエンド系システム。前者のバックエンド・システムは、規模も大きく歴史も古いので簡単には変更できない。その一方、フロントエンド系システムは、素早い顧客対応や、ほかのシステムとの連携の必要性などもあって、積極的に新しいテクノロジに移行する傾向がある。このように進化のスピードが異なる両者の中間部分に、人間が手作業で対処している層があります。あまりに負担が大きくなると、人間系をやめてシステム化しようということになりますが、バックエンドとフロントエンドが異なるテクノロジで構成されていると、そのたびにテクノロジをどうするか、考えないといけません。相互運用が容易なシステムなら、こうした人間系の中間層を簡単にコンピュータで置き換えることが可能になります。

岸上：テクノロジは人間系の作業に追いつく方向へ進むものです。よく誤解されている方が多いので強調しておきますが、テクノロジが人間より先行しているのではありません。テクノロジは、人間社会の作業を置き換えられるように、一生懸命追いつくように発展していくものです。今回のケースなら、人間系に電子メールというキラー・アプリケーションがあり、そこにExcelシートを添付すれば国を越えて行ったり来たりできる。しかしこのままでは、後の作業で莫大な手作業がかかってしまう。この作業をサボるために相互運用のテクノロジが検討され、ファイアウォールを越えてくれるWebサービスのテクノロジなどが要件に合致することが分かってきた。さらに、.NETプラットフォームとJavaプラットフォームの双方で、Webサービスの実装および相互接続性の検証が加速してきた。これらを組み合わせて、ようやく人間が行っている作業の部分をシステム化して実現する手段が整ってきたというわけです。

岸上：矛盾する主張のようですが、基本的には、ひとつのシステムで異なる複数のテクノロジを使うことは、できれば避けたいと思います。組み合わせたテクノロジ間や、自分たちで開発したものとベンダから提供されたものの間で進化のスピードにギャップが生じたとき、相互運用が障害を起こすリスクがあるからです。シングルベンダですべて固めれば、ベンダ自身が相互運用を担保しますから、こうしたリスクは小さい。自社製品同士ですから当然ですね。

岸上：リスクはありますが、システム間連携や企業間連携では、相互運用は不可避です。「私とビジネスしたかったら、全部.NETで書き換えろ」なんて相手にいえませんよね。特定のベンダに情報システムをロックインされたくないという企業は多いです。この視点に立つと、やはり
.NETより、さまざまなベンダが関連製品を提供しているJavaを採用したいと考える企業は少なくありません。

岸上：議論されるべきテーマは山ほどあるのに、現状はあまり語られていないものとしてトランザクションの問題があります。営業時間の異なる企業同士をどう接続するのかという問題を考えてみます。例えばAとBという店があったとして、Aは金曜日の午後6時に閉店、一方のBは午後5時で閉店というオペレーションになっているとします。このとき、午後5時半にはAのシステムは動いているので、Bの店に発注を出すことができます。しかし5時閉店のBの店はこの発注を受け取れません。この場合トランザクションは、月曜日の朝まで何らかの格好で待ち続けるか、「発注失敗」にして、月曜日にもう1度発注させるかのどちらかになります。だれが考えても普通に発生しそうなことですが、こうした問題を正面から扱った記事などは見たことがありません。現状のシステム連携は、同一社内や同一グループなど、比較的両者を統制しやすい関係ばかりで、このような問題に直面するような相互運用の実例は、まだまだ少ない証だと思います。

岸上：おっしゃるとおりです。企業のシステム同士を接続する際、技術とは別に、法的な責任分解点をどうするかという問題があります。ハードディスクにデータが書き込まれたら、自分たちに責任が発生すると定義しているシステムを考えてみます。一見すると理にかなっているように思えますが、この方式では、内容がどんなものであれ、受信したデータをハードディスクに書き込んだ瞬間に責任が発生してしまいます。これが人間なら、書類を渡されても、内容に不備があれば突き返すでしょう。いったん手にはしたが、正式に受け取ったことにはならない。この例のように、人間系のプロセスと情報システムのプロセスはイコールではないということを認識する必要があります。

岸上：はい。VBのほうが簡単だと考えるプログラマが多いのも、今後
.NET／Javaの相互運用が必要となる大きな理由の1つだと考えています。マイクロソフトは、VB 6（Visual Basic Ver. 6）プログラマのC#への移行を促しているようですが、本当に移行が進むかどうか、私は懐疑的です。私の経験では、JavaプログラマにC#のコードを見せても違和感がありませんが、VBプログラマにJavaやC#のコードを見せると、非常に高いハードルを感じるようです。こうした経験から、VBプログラマは、ずっとVBを使い続けるのではないかと考えています。すでにVBプログラマは大勢おり、今後もVBアプリケーションを開発し続けるとすれば、それらのVBアプリケーションとJavaアプリケーションとの相互運用が重要になるということです。

岸上：2階層C/Sシステム（クライアント／サーバ・システム）のソフトウェア開発を成功させたという実績と、オブジェクト指向開発でしょう。2階層システムに慣れたVBプログラマは、JavaやC#では常識となった3階層システムのソフトウェア開発がとても難しいものに見えるようですし、オブジェクト指向の活躍の場がほとんどありませんでした。実は3階層システムのソフトウェア開発がとても難しく見えるとかオブジェクト指向を使う機会があまりなかったという特徴は、メインフレーム・ベースのCOBOLプログラマにも当てはまります。COBOLプログラマは、実はJavaやC#が活躍する分散システムよりも、2階層C/Sが多いVBに移行する方が比較的容易なのです。

岸上：基幹系システムを再構築する必要に迫られる場合と、基幹系システムとフロントエンド業務システムとの連携を実現する必要に迫られる場合に、分散システム開発への移行が始まっています。しかしこうしたCOBOLプログラマが分散型アプリケーションの開発に乗り出してくると、新たに習得しなくてはならない技術があるため苦労することが多いようです。

岸上：メインフレームのアプリケーションは基本的に1階層で最初から最後まで実行されます。このためCOBOLプログラマは、処理の最初でBEGIN（COBOLでデータベース・アクセスを開始する命令）を実行し、処理が終わったらCOMMIT（データベース・アクセスを終了する命令）を実行してトランザクションを終了します。メインフレームのように、1階層で閉じているなら、プログラムで必要なだけCOMMITの発行を先延ばしにしてもあまり問題はありません。しかし分散型の多階層システムでは、ユーザーに近いフロントエンドでBEGINが実行され、システム間の行ったり来たりを繰り返し、最後にCOMMITしてトランザクションが終了します。メインフレーム型のアプリケーションを作ってしまうと、この間ずっとセッションを維持してデータベースなどのリソースを確保しなければなりません。これでは限られたリソースを使いまわして多数のトランザクション処理要求を実行するような分散システムは作れません。

岸上：分かりやすい例として、たとえ話をしましょう。例えばいま、電話でコンサートのチケットを予約するとします。まずは、4人くらい来てくれそうな人がいるので、取りあえずは4人分の席を予約します。ここでいったん電話を切ります。その後、2人しか行けないことが分かったら、改めて電話して2人分のチケットをキャンセルする。このように、1つのトランザクションを短くして、それが成功したのか、失敗したのかを知らせる手順を決めておけばよいのです。「4人のつもりだが、2人になるかもしれないから、はっきりするまで電話はつないだまま保留にしておこう」などと考える人はいないでしょう。こうして考えれば当然だと思えますが、メインフレームなどの同一システム内で閉じた空間では、このようなロング・トランザクションが当たり前のように実装されています。一方、例で示したようなショート・トランザクションを実現するための標準仕様も確立されつつあります。そこで、技術者は要件に応じて適切なトランザクション方式を選択して実装することが求められるようになってきています。

岸上：難しい問題ですね。表面的には、Webサービスに対応すればいいとか、非同期トランザクション処理にはメッセージ・キューを導入すればよいとか、2階層システムは3階層システムとして作り直すのがよいなどといった意見を聞きますが、私は何かのテクノロジを押しつけるのはよくないと思っています。弊社開発のGreenGlobeの話を顧客にしているときでも、これこそが王道で、これを使わないと失敗します、などとは絶対にいいません。あくまでもニュートラルに、現状がどうなっているのか、今後どうしていきたいのか、それらをどう整理すればよいのかを検討するお手伝いをします。例えば2階層C/Sシステムがあったとして、とにかく最小限のコストで既存資産を最大限に活かしたいというなら、既存のアプリケーションと新しいアプリケーションでデータベースを共有するというシンプルなソリューションもありうるのです。

岸上：ただし、相互運用のインターフェイス標準としては、Webサービスが利用されるということだけは間違いありません。現在は開発者自身が意識してWebサービスを実装していますが、今後は開発ツールがSOAPなどをサポートし、開発者が意識しないところでアプリケーションがWebサービス対応になるというケースが増えると思います。

岸上：そうです。すでに、Webサービスの仕様を記述するWSDLは自動生成できますし、SOAPもHTTPも意識することなくWebサービス・インターフェイスを実装し、それを呼び出すことが可能になっています。今後はBizTalkのようなミドルウェアによるWebサービス対応が拡充し、開発者は、Visioのようなツールでワークフロー図を設計し、これをBizTalkで展開するだけで、自分が意識しない背後ではWS-*によるアプリケーション間通信が実装されるという時代がやってくるでしょう。こうして、相互運用性の高いアプリケーションは増えていくものと思っています。