J2EEアーキテクチャ開発のためのEJBサンプルの詳細な説明

コンピューター技術の分野には、インテル名誉会長のゴードン・ムーアが長期の観察の末に発見した「ムーアの法則」があり、集積回路上に収容できるトランジスタの数は約18個ごとに2倍になるというものです。月。ソフトウェア分野でも同様ではないでしょうか?特にある程度は。 1992 年に初めて大学に入学したとき、私は 8088 マシンに直面しました。プログラム開発は、コマンド ライン インターフェイス Turbo C2.0、Foxbase データベース、その他の「地球砲」、およびネットワーク プログラミング、同時処理、およびネットワーク プログラミングなどの概念に基づいていました。トランザクション制御はまだ前例のないものです。 1996 年に私が 4 年生で卒業プロジェクトを行っていたとき、Teng という名前の教師の 1 人が卒業プロジェクトを主導し、クライアント/サーバー モデルでのプログラム開発を紹介してくれました。使用したツールは、現在ではオリジナルのバージョンでもある Sybase/PowerBuilder でした。 PowerBuilder のソフトウェアはもう利用できません。忘れていましたが、クライアント/サーバー モデルの開発概念を理解する前に学校を辞めてしまいました。 IRS を卒業した後、NetWare ファイル サーバーと Foxpro2.5 を使用した LAN ベースの収集ソフトウェアを見ました。プログラムには、テーブルやレコードのロックとロック解除のためのコードがたくさんありました。あるテーブルの問題を解決するために、プログラマは排他的に開くか共有的に開くか頭を悩ませました。 1990 年代後半、VB+SQL Server モード、PowerBuilder Sybase モード、Delphi+MS SqlServer モードなどの多数の C/S アプリケーションが職場に登場しました。C/S 方式により、プログラマは大きな利益を得ました。無料なので、データベースのロックとロック解除について心配する必要はありませんが、トランザクション処理、2 フェーズのコミットとロールバック、データの整合性などの問題を考慮する必要があります。その後、インターネットの隆盛とともにB/Sアーキテクチャのアプリケーションシステムが登場し、CGI、PHP、ASP、JSPなどの技術が徐々に普及していきました。しかし、クライアント/サーバー アーキテクチャとブラウザ/サーバー アーキテクチャには、どちらも致命的な欠陥があります。最も簡単な例を挙げると、それらは独立して動作し、「情報の島」の悪運を取り除くことができず、分散システムの統合を実現できないということです。あるソフトウェア会社は、購買、販売、在庫管理と在庫管理のためのシステムを開発し、財務ソフトウェアのセットも購入しました。どちらも C/S 構造を持っています。2 つのシステムが通信する方法はありません。 、会計伝票は手動で入力する必要があります。この問題を解決するために、技術者は通常、同じ幅の標準化された TXT ファイルを使用し、データ入力システムで認識できるデータ エクスポート ファイルをデータ出力システム用に作成し、手動でインポートするなどのデータ ファイルを交換する方法を使用します。データ入力システムによってそれらを入力します。この方法はリアルタイム パフォーマンスが低く、交換プロセス中にデータが簡単に失われます。通信用のソケット プログラムを作成するだけの場合もあります [図 1]。たとえば、Golden Tax Project の請求書相互監査システムは、総局、地方局、市局の監査システム間の通信と統合にこの方法を使用しています。