MANDALA.net V7 の概要


 ここには、 以下の事柄が書いてあります。

 ■ MANDALA.net の概要・近況

  ※ フレームワーク (より深く正しく技術を理解していただくために)

 ■ 動作環境 (必須ハードウェア、必須ソフトウェア)

 ■ 価格

 ■ 新たな特長

  □ 新たな特長 (1) ビジネスロジック部品の差分プログラミング

  ※ コンポーネントベース開発 (より深く正しく技術を理解していただくために)

  □ 新たな特長 (2) ツーピーススタイル

  ※ 3層構造と操作性 (より深く正しく技術を理解していただくために)

  □ 新たな特長 (3) フレームワーク部分の dll 化

  ※ データ転送量 (より深く正しく技術を理解していただくために)






■ MANDALA.net の概要・近況

 マイクロソフト社の Visual Basic による業務アプリケーション開発の支援ツールおよびフレームワーク MANDALA で 10 年の歴史をもつアプリテック株式会社は、.NET 対応の MANDALA.net を開発しました。
 なお、MANDALA.net の RC (Release Candidate) は、昨年の11月以前から、すでにあるソフト開発会社およびあるパッケージベンダにおける実際の開発業務に使われております。そして、これまでになされた数百の画面プログラムの開発・テストで問題なく動作することが確認されております。

 MANDALA.net は、主に基幹系の業務プログラムの開発をご支援するものであり、フレームワークとコード合成ツールから構成されています。基幹系の業務プログラムの操作や処理の流れに沿ったフックメソッドの呼出し制御や動作モードの管理や通信制御などを司りますので、開発者の方々はこういった制御に関係するプログラムを記述する必要がなくなりビジネスロジックのプログラミングに専念できます。このようにして、高い生産性と品質を実現できます。

 また、移行を容易にするために、Visual Basic 6.0 対応の MANDALA V6 から MANDALA.net V7 への移行ツールも用意されています。これとマイクロソフト社のアップグレードウィザードとを併用することによって、一般の Visual Basic アプリケーションよりも格段に簡単に移行できます。なぜなら、制御に関係する複雑なプログラムは、フレームワークとして私共が移行を済ませていますですので、アプリケーション開発者の方々はビジネスロジック部分だけの移行で済むからです。

 ビジネスロジック部分は、すでに実績のある私共の誇れる部品化技術によって項目対応ビジネスロジック部品に分割することになり、これは高い再利用性をもつことになります。したがって、部品がたまればたまるほどさらに生産性が高くできます。実際にビジネスロジック部品から構成されたパッケージが販売れており、一部の部品を追加修正するだけで (こういうカスタマイズ作業だけで)、顧客企業のお望みの業務プログラムを完成させることができます。

 MANDALA.net V7 で開発した業務プログラムは、マイクロソフト社の .NET プラットフォームの上で動作するので、ネットワークをまたにかけて活躍するプログラムになります。インターネットやイントラネットなど、HTTP プロトコルで通信しあう Web 対応のプログラムになるのです。ただし、一般のブラウザベースの Web ではなく、リッチ UI 対応 Web になる点が特徴的です。



※ より深く正しく技術を理解していただくために

フレームワーク

 フレームワークとは、汎用を目指すのではなく、あるカテゴリーのアプリケーションプログラムを取り上げて、それに集中して深くサポートするものだ言えます。たとえば、MANDALA.net のフレームワークは基幹系業務プログラムと ERP パッケージに的を絞って深くサポートするという具合です。

 OS やプログラミング言語などは、すべてのカテゴリーに汎用的なところを追求します。広い範囲を対象にする分だけ、深さはそこそこになりがちです。これに対して、フレームワークは、対象の範囲を絞っている分だけ深くサポートすることができます。なお、マイクロソフト社では、.NET Framework という名前を用いてフレームワークを装っていますが、.NET Framework は、あくまでも汎用であり、Java プラットフォームと勢力を競っあっている二大プラットフォームの一つだと見るべきです。そして、これらによってネットワークをまたにかけて活躍するアプリケーションプログラムの構築がしやすくなったと。

 フレームワークは、別の見方をすると、サブルーチンなど各種のライブラリと双対をなすものだといえます。ライブラリは、アプリケーションプログラムのメインルーチン側から呼び出されて下請け的な共通的な機能を果たすものです。これに対して、フレームワークは、アプリケーションの処理の流れに着目して、いわば共通のメインルーチンの役割を果たします。アプリケーション固有のビジネスロジックは、フレームワークから呼び出されるオブジェクトとして実装されることになります。

 フレームワークを用いると、すでになされた設計およびプログラムコードを用いることになるので、高い生産性および品質が実現できます。しかし、それはフレームワークがサポートしているカテゴリーのアプリケーションプログラムに限ることになります。フレームワークが広い範囲をサポートすると、必然的にサポートする “肉の厚さ (深さ)” が薄くなってしまいます。したがって、サポートする “肉の厚さ” を確保するには、あるカテゴリーのアプリケーションプログラムに限ることになるのです。


■ 動作環境

必須ハードウェア

 ハードウェア環境としては Visual Studio .NET 2003 が快適に動作するスピードと記憶容量をもつパソコンが必要です。具体的には、以下のとおりです。

 プロセッサ (CPU): Pentium クラスのプロセッサで 450 MHz 以上が推奨。
 主記憶 (RAM): 256 メガバイト (MB) 以上が推奨。
 ハードディスク: 新たに 100 メガバイト (MB) ほど必要。
 モニタ: 解像度 1024 × 768 以上、色の表示 High Color 16 ビット以上が推奨。
 マウス: Microsoft Mouse またはこれと互換性のあるポインティングデバイス。
 CD-ROM ドライブ: インストールの際に必要。


必須ソフトウェア

 MANDALA.net V7 は、次のいずれかのオペレーティングシステム (Windows システム) を必要とします。

 ・ 日本語版の Windows 2003
 ・ 日本語版の Windows XP
 ・ 日本語版の Windows 2000
  (Windows 2000 についてはサービスパック3またはそれ以降の適用が必要)

 なお、サービスパックとは、それぞれのソフトウェア製品のレベルを上げるための修正モジュール群のことです。
 サービスパックは、マイクロソフト社から各種のコンピュータ関係の雑誌の付録の CD-ROM に格納されて提供されていますし、またインターネットを使ってマイクロソフト社の Web サイト http://www.microsoft.com/japan/ からダウンロードすることもできます。

 MANDALA.net V7 は、次のいずれかの Microsoft Visual Studio .NET 2003 を必要とします。2002 年にリリースされた初版の Visual Studio .NET では動作しないことにご注意ください。

 ・ 日本語版の Visual Studio .NET 2003 Enterprise Architect
 ・ 日本語版の Visual Studio .NET 2003 Enterprise Developer
 ・ 日本語版の Visual Studio .NET 2003 Professional

 MANDALA.net V7 は、このいずれかが動作しているパソコンでないと、インストールして動作させることができません。ですから、まずこれらのいずれかをインストールして、動作することを確認してください。


■ 価格

 MANDALA.net は、複合製品であり、開発時に使うコード合成ツールと実行環境で使う実働フレームワークから構成されております。MANDALA.net には、それぞれのライセンスが1つずつ含まれています。

 MANDALA.net は、1ライセンスあたり 300,000 円 + 消費税です。だたし、2004 年 6 月末までは、キャンペーン価格 190,500 円です。
 別売の実働フレームワークは、1ライセンスあたり 30,000 円 + 消費税です。だたし、2004 年 6 月末までは、キャンペーン価格 18,000 円であり、さらにセントラルピース用のライセンスは無料です。また、大幅なボリュームディスカウントなどがあり、個別の事情に応じたお見積もりをいたします。

 コード合成ツールを1ライセンス保有すると、これを1台のパソコンにインストールすることができ、これで開発作業を行なうことができます。
 実働フレームワークには、ワンピース用、ローカルピース用、セントラルピース用、の三種類があります。そして、実働フレームワークの1ライセンスあたり、1台のパソコンに、上記の3種類のどれか一つまたは二つまたは三つをインストールすることができます。1ライセンスを保有するだけでは、2台のパソコンに分散してインストールすることはできません。

 ワンピース用またはローカルピース用の実働フレームワークは、MANDALA.net で開発したプログラムをクライアントパソコン上で動作させる場合に必要です。ただし、MetaFrame または WTS などを搭載したサーバ上で動作させるときには、端末の数だけのライセンスを必要とします。

 セントラルピース用の実働フレームワークは、MANDALA.net で開発したプログラムの片割れ (セントラルピース) をサーバ側で動作させる場合に必要です。この場合は、接続するクライアントパソコンの数によらず、サーバ側ではサーバあたり1ライセンスを必要とします。

 たとえば、1台のパソコンでローカルピースとセントラルピースの折り返しテストをするような場合には、ローカルピース用およびセントラルピース用の実働フレームワークが必要ですが1ライセンスで済みます。
 また、n台のクライアントパソコンと1台のサーバからなるシステムでは、ローカルピース用実働フレームワークnライセンスとセントラルピース用実働フレームワーク 1ライセンスの合計 (n+1) ライセンスを必要とします。


■ 新たな特長

 VB.NET 対応の MANDALA.net は、 Visual Basic 6.0 対応の MANDALA V6 の後継製品です。主なエンハンス項目として次の3つを挙げることができます。

 ・ 更なる生産性の向上 (項目対応ビジネスロジック部品の差分プログラミング)
 ・ 様々なシステム構成への対応 (ツーピーススタイル)
 ・ 業務プログラムサイズの低減 (フレームワーク部分の dll 化)

(1) 更なる生産性の向上

ビジネスロジック部品の差分プログラミング

 MANDALA V6 においては、次の二つによって業務プログラム開発の生産性を向上させてきました。

 ・ フレームワークとの差分だけを項目対応ビジネスロジック部品として記述
 ・ 項目対応ビジネスロジック部品の再利用

 MANDALA.net V7 においては、これらに加えて 「ビジネスロジック部品に関する差分プログラミング」 をサポートすることで、さらなる生産性の向上を実現しました。項目対応ビジネスロジック部品のそれぞれを (オブジェクト指向の) クラスという形態にし、この親クラスを設けることによって、ビジネスロジック部品を記述するとき、親クラスとの差分だけをプログラミングするだけでよいようにしました。VB.NET では、VB 6.0 でサポートされていなかった継承による差分プログラミングが可能になったので、これを活用するようにした効果といえます。

 これが新たな特長の一つなのですが、この説明だけでは、生産性をどう向上させているのか全体像が理解しにくいかもしれませんから、従来の生産性向上策も含めてここにまとめてご説明いたします。

 MANDALA.net においては、業務プログラムの操作性にかかわる部分などのプログラムをフレームワークとしてご提供いたします。ですから、フレームワークとの差分だけを項目対応ビジネスロジック部品としてプログラミングするだけで、業務プログラムを完成させることができます。この点が生産性の向上に最も寄与しております。開発者はビジネスロジックの記述に専念することができるので、開発生産性を大幅に向上させることができるわけです。

 MANDALA.net のパンフレットにあるように、開発者の方々は、項目対応ビジネスロジック部品と画面レイアウトの二つをご用意いただくのが主な開発作業です。後は、MANDALA.net に指示を与えるだけで、ビジネスロジック部品と画面とフレームワークの三つが結び付けられて完全な業務プログラムが完成いたします。

 画面レイアウトはロジックを含まないものであり、Visual Studio .NET のデザイナで比較的簡単に (WYSIWYG に) 作成できます。しかし、一般に言えることですが、ビジネスロジックの方はそう簡単にはいきません。そこで、これをどうご支援するのかという点が生産性向上の第二のポイントだといえます。

 この点に関して MANDALA.net を用いた開発においては、項目対応ビジネスロジック部品という標準化された形態でビジネスロジックをプログラミングするスタイルを採用しております。つまり、データ項目対応に分割するという方針の基に、業務プログラムの構造設計の大半は済んでいるといえます。ここまでお膳立てができているので、後はこの基準に従ってプログラミングをすればよいだけなのですが、この作業をさらに楽にするために今回から新たに、ビジネスロジック部品に関する差分プログラミングをサポートいたしました。
 項目対応ビジネスロジック部品の親クラスを設けることによって、ビジネスロジック部品を記述するときに、親クラスとの差分だけをプログラミングすればよいようにしたのです。

 なお、項目対応ビジネスロジック部品とは、商品コードとか商品名とか受注単価とかというデータ項目に対応するビジネスロジック (フレームワークとの差分だけをメソッドとして記述したものなので一般にフックメソッドと呼ばれるもの) を塊にしたクラス (フックメソッドで構成されるクラスなので一般にフッククラス呼ばれる) を意味します。
 この項目対応ビジネスロジック部品は、従来の MANDALA と同様に再利用性が高いので、すでに蓄積された部品があれば、新たにプログラミングをする必要がありません。ここで特別にご注目いただきたいのは、少し前に 「プログラミングをすればよいだけ」 と申しましたが、再利用をすることでそういう必要がない場合も多いという事実です。
 たとえば、商品コードというデータ項目は、受注計上画面にも、在庫照会画面にも含まれるものですが、商品コードの項目対応ビジネスロジック部品は、どちらの画面でも同じものを再利用できます。ですから、すでに開発済みの部品があればそれを再利用できる場合が多いのです。

 さらに、部品の再利用による現実的かつ実質的な効能をご紹介すると、ビジネスロジックを項目対応ビジネスロジック部品から構成されるようにした ERP パッケージが実際に幾つかの会社から販売されています。これらはカスタマイズ作業が簡単にできるという特長をもっているので、通常は最終顧客企業のご要望に従いカスタマイズして販売されております。しかも、パッケージの開発元とは異なるカスタマイズ業者を募って、そうした会社がカスタマイズ作業を実施することができております。一般には、カスタマイズ作業に高いコストがかかるものですし、パッケージの開発元以外のところではカスタマイズ作業を実施できないというのが常識ですが、ビジネスロジック部品技術はこの常識を覆す実績をもっています。


※ より深く正しく技術を理解していただくために

コンポーネントベース開発

 ActiveX コントロールや EJB (Enterprise JavaBeans) がコンポーネントベース開発の重要性を広めるという貢献をしたのは喜ばしいことですが、コンポーネントつまり "部品" とはどんな実力をもつものなのかを曖昧のままにしているのは困ったことです。

 マイクロソフト社の ActiveX コントロールは、画面デザインの際に貼り付けて使う GUI 部品だと見るべきです。"部品市場" を形成した功績は評価できますが、この中にはビジネスロジックがほとんど含まれていません。また、サンマイクロシステムズ社が打ち出した EJB (Enterprise JavaBeans) なるものを部品だと言ってかついでいる人々も見受けられますが、EJB はアプリケーションサーバと呼ばれる一種のミドルウェアとの相性がよい塊だと捉えるべきであって、ビジネスロジック部品とは言いがたいものです。なぜなら、工夫に工夫を重ねないと EJB の再利用性を高めることができないからです。ちなみに、大抵のソフトウェアは工夫を重ねることによって、再利用性を高めることができるものであり、EJB もこの例外ではありません。EJB という形態にしただけで再利用性が高くなるとは言えないのです。こうしたわけで、EJB は "部品市場" を形成できていないでいます。このような数々の "部品" または部品まがいが世の中に出回ることによって "部品" への関心が高まったのはよいのですが、"部品"の本来の実力が低く評価されることになりはしないかと危惧しております。

 そこで、コンポーネントつまり "部品" だと言える基準を明確にして、これに当てはまるものだけを "部品" と呼ぶべきだと、私どもは提案しております。(詳しくは http://www.applitech.co.jp/compo/ 参照)。そこで、私どもが提唱している「"部品" を活用した再利用システム」のあるべき姿は、以下のとおりです。

 ・ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること
  (汎用サブルーチンのように可能ならば再利用するのでは生ぬるい)
 ・ どんなカスタマイズ要求にも対処できるものであること
  (業務パッケージのようなあらかじめ想定されたカスタマイズ要求への対処だけでは不十分)
 ・ 大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること
  (個人ベースの部品化再利用だけではらちがあかない)

 ちなみに、上記の要件を満たすには何種類かの部品を併用することが必要ですが、私どもの項目対応ビジネスロジック部品は、この要件を満たすための主要構成要素になっています。
 少なくとも、パッケージの開発元とは異なる会社でカスタマイズ作業が実施できるような高度な再利用システムは、私どもの項目対応ビジネスロジック部品を用いたもの以外に、私どもでは見つけることができていません。


(2) 様々なシステム構成への対応

ツーピーススタイル

 MANDALA V6 は、業務プログラム部分が一つの塊となるワンピーススタイル (プレゼンテーション層とビジネスロジック層が一体化した形態) だけをサポートしていました。
 MANDALA.net は、ワンピーススタイルに加えて、ツーピーススタイルにも対応いたしました。従来のワンピーススタイルでは業務プログラムが一つの塊になりましたが、ツーピーススタイルでは業務プログラムがローカルピースとセントラルピースの二つから構成されることになります。このために、インターネットやイントラネットをはじめとする様々なシステムを構築する際に、自由度が広がり、より適切なシステム構成を選択することができるようになりました。

 従来のワンピーススタイルでは、次のシステムを構築することができました。
 ・ スタンドアローンのシステム
 ・ ローカルシステムとデータベースサーバとを組み合わせた2階層システム
 ・ サーバ側に MetaFrame または WTS など用いた2階層システム
 ・ 上記のシステムとデータベースサーバとを組み合わせた3階層システム

 これらに加えて、新たなツーピーススタイルを採用することにより、次のようなシステムも構築できるようになりました。
 ・ ローカルシステムとビジネスロジックサーバからなる2階層システム
 ・ 上記のシステムとデータベースサーバとを組み合わせた3階層システム

 なお、ローカルピースとセントラルピースの間の通信は、HTTP プロトコルによって行なわれます。これは、.NET の Remoting 機構を用いて MANDALA.net がサポートしておりますので、この部分を開発いただく必要はございません。

 一般に、ツーピーススタイルの業務プログラムは、ワンピーススタイルの場合に比べて開発が面倒になりがちです。そこで、いろいろなご支援をすることで、ワンピーススタイルの業務プログラムと同様に容易に開発できるようにすべきだと考えました。そこで、合成時のエラーとコンパイルエラーをなくしたならば、それなりに動作するツーピーススタイルの業務プログラムが出来上がることを目標にしました。

 このために、次のご支援を行なっています。

 ・ フックメソッドのローカル・セントラル分割の支援
   合成時のエラーメッセージのログ、および分割アシスト
 ・ 変数のローカル・セントラル分割の支援
   Common のサポート (ローカル・セントラルの両方で参照できる変数)
 ・ 合成時・コンパイル時のサイトアフィニティ問題の早期検出
   合成時のエラーメッセージのログ、および顕在化されたコンパイルエラー

 なお、こういった支援があっても、デバッグやテストが全く不要になるわけではありません。そこで、さらに次のご支援を行なうことで、デバッグ作業を容易にできるようにしました。

 ・ ワンピーススタイルかツーピーススタイルかを合成時に選択可能にすることで、かなりのデバッグはワンピーススタイルでできるようにする
  ★ ツーピーススタイル向けに開発すれば、合成時の指定で、どちらのスタイルにもできます
 ・ 1台のパソコン上でのツーピーススタイルのプログラムの動作テスト
 ・ フックメソッドログ
 ・ フックメソッドの中での異常状態の検出と表示
 ・ デバッグ支援情報 (メッセージ) の充実


※ より深く正しく技術を理解していただくために

3層構造と操作性

 プレゼンテーション層、ビジネスロジック層、データベース層の3層のうちデータベース層は、独立したものにすることが容易です。しかし、プレゼンテーション層とビジネスロジック層は、操作性や即応答性を犠牲にしないと独立したものにすることが困難です。

 たとえば、数多くの商品を取り扱う業務プログラムにおいては、商品コードのインプットがなされると同時に、商品名や価格などが表示されると便利です。これは、プレゼンテーション層とビジネスロジック層の両方が関係するので、これを実現するには、両者が協調して動作することが必要になります。

 ただし、操作性や即応答性を犠牲にすれば、プレゼンテーション層をローカル側で実施し、ビジネスロジック層をサーバ側で実施するような分離ができます。たとえば、幾つかの商品コードのインプットをプレゼンテーション層で受け付けて、それをビジネスロジック層に送って処理して、その結果を送り返してプレゼンテーション層で表示するというように、昔のホストと端末のようなやりとりをするのであれば、分離可能です。しかし、こうすると操作性や即応答性が犠牲になります。

 これに我慢ができない場合には、プレゼンテーション層とビジネスロジック層の中間あたりの渾然一体とした部分に対応するために、大量の Java スクリプトなどによる記述が必要になったりします (これは、ブラウザベースの Web システムにおける典型的な問題点です)。
 それでも、商品数が少ないときには、開発作業をいとわなければ、何とかなりますが、商品数が多くなるローカル側に商品マスタファイルを持つことが困難なために、即応答性を実現することが実質的にできませんでした。

 そもそも、操作性や即応答性を重視するリッチ UI 業務プログラムは、世の中で言われているような、プレゼンテーション層とビジネスロジック層の分離がうまくできないものです。したがって、必要なら別の分離方法を見つけないと混沌とした構造になりがちです。この問題を解決するために、MANDALA.net では、ビジネスロジック層を分かりやすい形に2分してローカルピースとセントラルピースに配置することで、リッチ UI 業務プログラムを様々なシステム構成に対応できるようにしました。


(3) 業務プログラムサイズおよび転送量の低減

フレームワーク部分の dll 化

 MANDALA V6 においては、業務プログラムの操作性にかかわる部分などのプログラム (フレームワーク部分) を主にコード合成で実現し、業務プログラムの中に含めていました。このために業務プログラムの exe サイズが数百キロバイトほどになることが普通であり、ときには 1 メガバイトを超えることもありました。
 MANDALA.net においては、 フレームワーク部分を独立した dll にして、業務プログラムの中には含めない形態にしました。この効果で業務プログラムの exe サイズを従来の 1/2 から 1/3 にすることができました。これを圧縮するとさらに 1/2 から 1/3 にすることができます。これらの結果、圧縮した exe サイズは、通常百キロバイト以下になるようになりました。
 この程度のサイズになると、Web でやり取りする通常の HTML 文書や画像のサイズと何ら変わらなくなります。ブロードバンド環境の普及にともない、サーバに保管した業務プログラムをローカル側のパソコンにダウンロードすることでプログラムの配布 (ディプロイ) をする時代が到来したといえます。

 なお、dll 化したフレームワーク部分のダウンロードも必要ですが、これは 300 KB ほどであり、1回ダウンロードしておけば、どの業務プログラムからも共通に使うことのできるものです。

 ちなみに、このようにフレームワーク部分の dll 化は、Visual Basic 4.0 の時代から MANDALA ではサポートしておりました。しかし、旧 Visual Basic では、アーリーバインド方式ではなくレイトバインド方式が採用されているためか、繋ぎの部分のサイズが大きくなるために実用的ではありませんでした。たとえば、400 KB のプログラムを exe と dll に分けると、200 キロバイトと 200 キロバイトほどの二つの塊になることを期待したのですが、実際には 400 キロバイトと 300 キロバイトほどの塊に分かれるというような具合で、あまり意味がありませんでした。
 VB.NET においては、アーリーバインド方式が採用されたためか、ほぼ期待通りのサイズに分離が可能になりました。

 MANDALA.net においては、 アプリテック社が提供するフレームワーク部分を独立した dll にして、業務プログラムの中には含めない形態にしました。このために業務プログラムの exe サイズを低減できました。これだけでなく、各開発プロジェクトが独自に開発する項目対応ビジネスロジック部品の親クラスを独立した dll にすることも可能です。こうすることで、exe サイズをさらに低減することもできます。


※ より深く正しく技術を理解していただくために

データ転送量

 ブラウザベースの Web システムでは、データベースに格納されているデータを表示する場合に、その都度 HTML 文書をサーバ側で作成しています。いわゆる ASP とか JSP とか呼ばれている方式は、 このようになっています。こうした文書は、ローカル側のパソコンのキャッシュ機能を働かせることができませんから、毎回ダウンロードしなければならないことになります。この結果、莫大なデータ転送をしているのが現状です。
 これとは対照的に、MANDALA.net によって開発した業務プログラムは、一回ダウンロードしておけば、ローカル側のパソコンのキャッシュできますから、毎回ダウンロードする必要がありません。毎回ダウンロードしても性能上の問題は少ないほどのサイズになったのですが、毎回ダウンロードの必要はないのです (毎回ダウンロードをすべきではありません)。

 この他にもデータ転送に関する性能上の問題として、ブラウザベースの Web システムにおいては、データだけでなくその画面のフォーマット情報を毎回送らなければならない点が挙げられます。これに対して、MANDALA.net によって開発した業務プログラムでは、画面のフォーマット情報の転送は不要であり、データを転送するだけで済みます。

 一般にブラウザベースの Web システムにおいては、キビキビした応答性でないことが多いので、すべての Web システムとはそういうものだと誤解されています。しかし、実際にはブラウザベースではない Web システム、つまり MANDALA.net によって開発した業務プログラムにように画面に表示されるデータの変更部分だけをその都度転送する方式を採用すると、高い応答性が実現できます。


Copyright (C) 1996-2004 By AppliTech, Inc. All Rights Reserved.
AppliTech および MANDALA は、アプリテック株式会社の登録商標です。
ここに掲載の社名、製品名には、各社の商標または登録商標があります。



アプリテック株式会社
http://www.applitech.co.jp/