軟件業一直是計算機產業的核心，計算機剛問世的時候，計算機軟件基本處於緩慢發展時期，那時候使用的計算機軟件語言是與硬件緊密相關的機器語言，隨後出現了匯編語言。隨著計算機日益介入到人們的生活中間，軟件也相應的變得更加復雜。
於是以編程人員為中心的高級語言替代了計算機發展初期的低級語言，其中，50年代末和60年代初的FORTRAN語言的出現是一個變革，同時像BASIC和LISP這樣的高級語言也相應的產生了，這些語言使得編程人員可以超脫於具體的硬件結構，使用更接近於實際問題領域的術語表達其設計思想。
但是另一方面，這種新出現的自由度使得不斷復雜的應用程序需要有更加復雜的軟件來實現。軟件工業自由度和復雜性的增加，軟件開發隊伍也不斷膨脹，成本也不斷提高。軟件工業也在不斷的尋求成本低廉而又快速可靠的軟件開發方法，所以在90年代末期，基於組件的軟件開發的思想開始得到了普遍的重視和應用。
軟件組件就是指可以進行獨立分離、易於重復使用的軟件部分。JavaBean就是一種基於Java平台的軟件組件思想。JavaBean也是一種獨立於平台和結構的應用程序編程接口（API）。JavaBean保留了其他軟件組件的技術精華，並增加了被其他軟件組件技術忽略的技術特性，使得它成為完整的軟件組件解決方案的基礎，並在可移植的Java平台上方便地用於網絡世界中。
其實你可以把組件理解成為童年時玩的積木，而把用組件搭起來的軟件則可以理解成為你用積木搭的外形各異的作品。這種比喻也許可以讓你理解為什麼用組件搭建應用程序會比其他方法制作應用程序更加穩定和快速。因為軟件的組件是可重用的，所以它肯定是經過了很多應用程序的測試，所以當你用它的時候出錯的概率肯定比你自己重新寫一個同樣功能的模塊的出錯概率小。而用組件搭建應用程序同時也會更快速，這很輕易理解，就像你用積木搭一座橋比你自己用木頭做一座橋要快一樣。
JavaBean也是一個很成功的組件模型，假如你用過JBuilder，那麼你肯定會受益於它所提供的許多方便的控件，而這些控件幾乎都是JavaBean。其實你已經不知不覺的在使用JavaBean了，只是你一直沒有注重到而已。
1． 編寫Bean的源程序SimpleBean.java如下： import java.awt.*;
import java.io.Serializable;
public class SimpleBean extends
Canvas implements Serializable
{
//該bean從java.awt.Canvas派生，
所以具有了Canvas的所有屬性和方法
public SimpleBean(){
setSize(60,40);
//設置該bean的尺寸
setBackground(Color.red);
//設置該bean的背景顏色
}
}
SimpleBean從java.awt.Canvas組件派生，所以是一個可視化的bean，並且實現了java.io.Serializable接口，這個接口是所有Bean都必須實現的，因為SimpleBean具有Canvas的所有屬性和方法，如背景色和組件尺寸等屬性，並可以調用相應的方法設置這些屬性。
2． 編譯源程序： javac SimpleBean.java產生字節碼文件SimpleBean.class。
3． 編寫制作（nmake）文件 這個nmake文件會編譯這個SimpleBean組件並會產生一個JAR文件。將編寫好的makefile文件存儲為simpe.gmk（UNIX）或simple.mk（windows），並與你的SimpleBean.class放在同一個目錄下，nmake文件清單如下：
＃gmumake文件
CLASSFILES= SimpleBean.class
JARFILE= SimpleBean.jar
all: $(JARFILE)
# 創建一個帶有適當說明文件
（manifest）的JAR文件
$(JARFILE): $(CLASSFILES)
$(DATAFILES)
echo "Name: SimpleBean.class"
>> manifest.tmp
echo "Java-Bean: True"
>> manifest.tmp
jar cfm $(JARFILE) manifest.tmp *.class
@/bin/rm manifest.tmp
# 編譯源程序
%.class: %.java
eXPort CLASSPATH; CLASSPATH=. ;
javac $<
＃刪除產生的中間文件
clean:
/bin/rm -f *.class
/bin/rm -f $(JARFILE)
# nmake 文件
CLASSFILES= simplebean.class
JARFILE= simplebean.jar
all: $(JARFILE)
# 創建一個帶有適當說明文件
（manifest）的JAR文件
$(JARFILE): $(CLASSFILES)
$(DATAFILES)
jar cfm $(JARFILE)
<<manifest.tmp *.class
Name: SimpleBean.class
Java-Bean: True
<<
＃將類打包，"Java-Bean:True"
可以使得類出現在ToolBox窗口中
.SUFFIXES: .java .class
{sunwdemosimple}.java
{sunwdemosimple}.class :
set CLASSPATH=.
javac $<
＃清除中間文件
clean:
-del sunwdemosimple*.class
-del $(JARFILE)
4． 運行makefile文件 對於UNIX，運行gnumake simple.gmk
對於windows，運行nmake -f simple.mk
會在當前目錄下創建一個JAR文件，這個JAR文件裡包含了這個bean的信息。
我們完成了一個很典型的JavaBean，其實就是一個有一定非凡規則的Java類，它有一些非凡的地方比如要實現某些接口類，不過歸根結底它還是一個Java類，它可以使用任何Java語言裡提供的功能比如說繼續於Canvas等。
而上面我們提供的makefile則可以作為模板，你以後要編寫你自己的bean的makefile的時候只需要修改上面提供的makefile就可以了。
RMI定義了一組遠程接口，可以用於生成遠程對象。客戶機可以象調用本地對象的方法一樣用相同的語法調用遠程對象。RMI API提供的類和方法可以處理所有訪問遠程方法的基礎通信和參數引用要求的串行化。
遠程方法調用類似於Sun公司1985年提出的遠程過程調用（RPC）特征。RPC也要求串行化參數和返回數值數據，但由於沒有涉及對象，情況比較簡單。Sun開發了外部數據表示（XDR）系統，支持數據串行化。RPC和RMI之間的一個重要差別是RPC用快速而不夠可靠的UDP協議，RMI用低速而可靠的TCP/IP協議。
遠程方法調用（RMI）和CORBA都是分布式計算技術，在進行分布式時各有其優缺點，為了有助於了解RMI的特點和用途，有必要討論一下CORBA和RMI的區別。
CORBA（Common Object Request Broker Architecture）是OMG的Object Management Architecture（對象治理結構），它是面向對象的分布式系統建立所依據的標准。CORBA被設計成一個能供所有編程語言使用的一個開放性說明，就是說一個機器上的Java客戶可以要求另一個用SmallTalk或C++的機器服務。
正是由於這種語言的獨立性使得CORBA這麼靈活和吸引人。為了適應語言獨立性，CORBA采用了非常通用的標准作為其接口。在不同的語言中，遠程調用、簽名和對象的引入有各自不同的定義，所以CORBA必須盡可能的中立和開放。正是這種通用性是CORBA的一個弱點。當開發人員都采用CORBA時，他們要用一種新的標准定義語言接口，它要求開發者學習新的編程接口，從而減小了遠程模型的透明性。
RMI是為僅在Java對Java的分布式計算中而開發的。遠程調用的標准是為了Java和應用Java的自然Java簽名和調用而開發的，這使得RMI對Java的開發者相當透明而且易於實現。RMI用Java語言緊密集成從而同CORBA相比能夠提供非常好的容錯能力及對異常的處理。盡管Java的RMI標准不像CORBA那樣語言獨立，但Java本身是一個獨立的平台，這就使RMI在跨平台的分布軟件開發中是一個很好的選擇。
RMI是Java語言在分布式計算上的基本模型，很多Java的分布式系統，包括我們本章要涉及的EJB，都是建立在RMI的思想上的。
傳統的分布式應用程序都是基於Client/Server結構的，而近年來人們發現基於Client/Server結構的應用程序有很多缺點，比如：假如客戶端的代碼需要改變，那麼所有機器上的客戶端程序都要重新安裝；假如某台機器有了不可修復的損壞，那麼得去別的機器上重新安裝客戶端軟件才能夠使用。
而基於Browser/Server結構的應用程序就沒有以上的缺點了，我們可以使用任何一台有浏覽器的機器來工作，而因為所有的程序邏輯都在服務器端，所以服務器端的代碼變動不需要作為客戶端的浏覽器再做任何工作。
由於Browser/Server結構的這些優勢，近年來關於Browser/Server的程序開發模式有了很多的研究和實踐。而因為Browser沒有辦法表示復雜的程序邏輯，所以在表示界面的Browser和存儲介質數據庫之間必須還有一層結構，這層結構負責表示復雜的程序邏輯。
這就是我們所說的服務器端構件，在Brower/Server結構中，我們的工作就是開發服務器端構件，但是開發服務器端構件是很麻煩的工作。因為服務器端構件必須接受很多客戶端的請求，因此它必須具有多線程和事務處理等能力，而這些也成為服務器端構件開發的難點所在。
