ボーランドの.NET戦略

ボーランド株式会社
マーケティング部 部長
藤井等
ボーランド株式会社
SE部 システムエンジニア
奥村恵子

聞き手、文責:デジタルアドバンテージ
2003/12/25

Page1 Page2 Page3

.NETプラットフォームにEJBエンティティBeanの思想を持ち込むBorland ECO(Enterprise Core Objects) for .NET

―― Togetherを利用して開発されたモデルは、.NETだけでなく、JBuilderやWebSphere Studio、Eclipseなどにもそのまま適用できるのでしょうか。

 

藤井:モデルといってもいくつかのレベルがあります。具体的にはプラットフォームに依存した部分と、依存しない部分があります。例えばJavaでいえば、Javaプラットフォームに特に依存しない抽象度の高いモデルのレベルと、それを現実のシステムとして実装するためにJavaプラットフォームを駆使するレベルがあります。これはシステム開発で「一汗かく」部分で、現状ではここにさまざまなノウハウが存在します。Togetherはクラス図とソースの自動連携機能を提供しますが、ここで作業しているモデル図は、プラットフォーム非依存の抽象度の高いものではなく、あくまで各プラットフォームを前提としたモデルになります。従って抽象度の高いモデル図から始めるには、プラットフォーム依存のモデルを作るというもうひとつ追加の作業が必要になってしまいます。抽象度の高いモデルを設計するだけで、実際のコード生成に至るまでの一連のプラットフォーム依存の実装を自動化するツールとして、ECO(Enterprise Core Objects)があるのです。

 
Borland ECO(Enterprise Core Objects) for .NET
OMGが提唱しているモデル・ドリブン・アーキテクチャを実装している。特定のプラットフォームに依存しないモデルを作成可能で、C# BuilderによりC#のソースコード、実行可能プログラムが生成できる。

―― C# Builderの最上位版であるArchitectに付属するモデル・ドリブン開発フレームワークですね。

 

奥村:ECOは、OMGが提唱しているモデル・ドリブン・アーキテクチャ(MDA:Model Driven Architecture)を実装したものです。ECOでは特定のプラットフォームに依存しないモデルを作成可能で、C# Builderが最終的なC#のソースコードを生成し、実行可能プログラムを生成します。クラスのリレーションなど、実装はすべてECO任せにすることができます。このECOの一部はTogetherの技術を用いて開発されています。

―― 現在はプラットフォームごとに提供されているTogetherの各エディションとECOが連携できるようになれば、プラットフォームに依存しないモデル開発が可能になるということでしょうか。

 

藤井:将来的に目指しているのはそこです。プラットフォームに依存しない抽象度の高いモデルから、共通のインターフェイスを通して現在のTogetherが担当する世界をつなぐことができれば、プラットフォーム非依存のMDAが実現されます。そこまで行けば、.NETとJavaが本当に何の違和感もなく1つの選択肢として同じ土台に立つことになるでしょう。

―― ECOでいうモデルとは、具体的には何でしょうか。

 

奥村:ECOのクラスですね。顧客や在庫など、ECOのクラス・レベルで抽象化したオブジェクトの関係付けなどを作り、実装部分はすべてECOに任せるスタイルです。開発者の作業は、どういうデータをどのように表現するかということをクラス図のデザイナで定義することです。データベースのスキーマ設計を始めとして、Togetherのところでお話しした「汗をかく」という部分をすべてECO任せにできるわけです。そして最終的には、ユーザー・インターフェイス・デザイナを利用して、ECOによって生成された実体とユーザー・インターフェイスとを結び付けます。

―― 抽象度の高いビジネス・オブジェクトからデータベース・スキーマが自動生成できるというのは便利なように見えますが、現実のシステムでは、データベースが先に存在しているのではありませんか。

 

藤井:先にデータベースがあるのに、後からECOが勝手なスキーマを生成してくれても困るということですね。確かに既存のWindowsテクノロジ・ベースのソフトウェア開発では、このような手法は馴染まないかもしれません。しかしJavaプラットフォームには先例があります。EJBには、永続的なストレージ・メカニズムの中でビジネス・オブジェクトを表現するエンティティBeanと呼ばれるものがありますが、ECOによるスキーマ生成はまさにこれにあたります。エンティティBeanを設計して、そのエンティティBeanをどのように永続化するかということは、最終的にデータベースがどのような構成になるかとは関係がありません。ECOは、こうしたエンティティBeanの発想を.NETプラットフォームに持ち込むものです。とはいえ現実には、データベースの構成によってシステムの性能は大きな影響を受けますから、最終的に適用されるデータベースの構成には目を光らせる必要があります。抽象度の高いモデル設計と、最終的なデータベース・チューニングのギャップをいかに埋めるかといった部分が今後のシステム開発のノウハウになっていくでしょう。

CORBAベースのアプリケーション通信によりJavaと.NETの連携を支援するJaneva

―― Javaと.NETの相互運用性を高めるミドルウェアであるJanevaとはどのような製品でしょうか。

 

藤井:現実のシステム開発で、プラットフォームの統一を迫られる具体的な理由は、異なるプラットフォーム間の相互運用におけるパフォーマンスの低下や、トランザクションの不完全性などです。つまりWebサービスのブリッジ・ソフトウェアによるパフォーマンス低下、トランザクション制御不全などからくる問題です。この問題を解決することが、Javaと.NETを両立させるポイントだろうと思います。このために開発されたミドルウェアがJanevaです。具体的には、.NET Framework対応アプリケーションと、J2EE/CORBA(Common Object Request Broker Architecture)のランタイム環境との完全でシームレスな相互運用を実現します。

―― アプリケーション連携のプロトコルとしてCORBAは以前から提唱されていますが、現時点でCORBAはどの程度利用されているのでしょうか。

 

藤井:それはよく質問されます。Webサービスの発表以来、一時は「CORBAの時代はこれで終わった」などといわれたものですが、現実にはいままさに脂が乗ってきたところ、といってよいでしょう。この理由の1つは、J2EEがCORBAの仕様を取り込んだことです。これにより、イントラネット内部での軽量なアプリケーション連携用プロトコルとしてCORBAの採用が徐々に進み始めました。もう1つの理由は、通信事業者などでCORBAの採用が定着してきたことです。例えばCisco社は、ルータのリモート・メンテナンス用プロトコルとしてCORBAを採用しています。

―― J2EE−CORBAと.NETの橋渡しをするのがJanevaということですね。

 

藤井:ええ。.NET側から見れば、相手のシステムが何であれ、CORBAのインターフェイスさえ備えていればJanevaで接続可能になるということです。

―― マイクロソフトは、アプリケーション連携の方法としてWebサービスを提唱しています。.NETの大きな特徴もWebサービス対応にあります。CORBAとWebサービスはどのような関係になるのでしょうか。

 

藤井:アプリケーション連携の方法には、通信するアプリケーションの独立性を高めた疎結合と、独立性よりもパフォーマンスを重視する密結合の2種類があります。このうちWebサービスは疎結合のプロトコルであるのに対し、CORBAは密結合のプロトコルとして位置づけられます。例えていえば、野球で内野手が近距離で素早くボールを回すのが密結合、外野手同士が遠投でボールを回すのが疎結合です。Webサービスの長所は、ファイアウォールを越えてアプリケーション同士が連携できることです。例えばファイアウォールを越えて企業間でのシステム連携を行うならWebサービスを利用するのがよいでしょう。しかしプロトコルとしてのオーバーヘッドは大きく、またトランザクション管理機能などもまだ整備されていません。従ってクライアント・サイドのGUIアプリケーションとサーバとの間で頻繁にデータのやり取りを行ったりする場合にはWebサービスは向きません。またWebアプリケーションのようなもので、セッションを保持しながら、一連の画面遷移の中で処理が完了したかどうかを保証し、処理が途中で失敗した場合にはロールバックするなどのトランザクション管理を実現するにはWebサービスは不向きです。このような用途にはCORBAを採用したほうが有利でしょう。Webサービスでトランザクション管理を行うことも可能ですが、その場合にはそれらの機能を自身で実装する必要があります。

.NET開発者に提唱するオブジェクト指向設計への第一歩

―― 最後に、.NET開発者とオブジェクト指向設計の関わりについてお聞かせください。マイクロソフトの現時点でのモデル開発支援は、Visioを使ってクラス図か描けるという程度で、TogetherのようにUML図とコードを同期させるなどの本格的な支援環境はありません。マイクロソフトの開発環境だけで開発を進めてきた人にとっては、オブジェクト指向設計とかモデル指向開発とかいったもの自体にまだ馴染みがないと思います。これを学習するには、やはりUMLの基礎から学習する必要があるのでしょうか。

 

藤井:それは誤解です。オブジェクト指向設計やモデル指向開発を学習したいと思うなら、理屈から始めるより、まずはTogether for VS.NETをインストールして動かしてみてもらいたいと考えています。すでに述べたとおりTogetherは、ソースコードさえあればそこからクラス図を生成することができます。

―― 習うより慣れよ、ですか。

 

藤井:そうです。世の中の風潮では、オブジェクト指向設計の入門というと「UMLありき」で始まるものが少なくありません。しかしすでに開発中のソースコードがあるなら、そこからツールを使ってモデル指向開発の第一歩を踏み出せばよいのです。それでコードベース開発での問題点が解決するなら、ツールを使い続けてもらえばよいと思います。やれクラス図だ、ユースケース図だと勉強させて「きっといつかは役に立つ」と教えられるより、よほど楽しく学べるはずです。Together for VS.NETはVS.NETのアドオンですから、インストールしても用がなければ使わなければよい。でもコードベース開発で行き詰って、モデル指向開発が何らかの答えを与えてくれるのではと思ったなら、Togetherを呼び出してクラス図を生成してみればよいのです。

―― なるほど。既存のソースコードに対して、まずはTogetherでクラス図を書き出させてみると、意外な発見があるかもしれないということですか。

 

藤井:このようなアプローチはJava開発者にはマッチしないかもしれません。しかしUMLのメリットをこれから知るかもしれないという.NET開発者の方々にUMLツールを紹介する方法としては、このようなアプローチが現実的だろうと考えています。End of Article

 
 

 INDEX
  [Trend Interview] ボーランドの.NET戦略
    1.ソフトウェア開発の現状とボーランドの.NET戦略
    2.C# Builder、Delphi、Together Edition for VS.NET
  3.Borland ECO(Enterprise Core Objects) for .NET、Janeva
 
インデックス・ページヘ  「Trend Interview」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH