前言

到目前為止，我們已經知道，Jini技術是一個以Java平台為基礎的分散式系統架構，達到具簡單、彈性以及合作的目的。在Jini的架構下，允許一群機器設備或是軟體程式形成一種合作的模式，提供其他成員自己所擁有的資源，同時也可以索取自己所需要的資源。而這些所謂的資源，在客戶端所呈現出來的是以Java程式語言所設計的物件，但是實作的部份可以是軟體，也可以是硬體。在本期中我們將要探討這些在硬體部份的實作，有哪些可能的方式，以及在功能及設備的複雜度上會有哪些可能的取捨問題。

基本的設備架構型態

Jini架構的主要概念，就是讓分散式系統的運作彈性儘可能的單純。所有的服務都是透過所謂的類別介面(interface)來定義，而代理人(proxy)的實作部份則必須支援這些介面。這個代理人可以讓使用服務的客戶端看見，而且是由服務提供者上載並登記在查詢服務中，而這些實作部份最後可以下載到客戶端。這種以服務導向為中心的設計方法，可以讓代理人程式碼到達客戶端，又因為代理人完全了解服務端的實作(因為都是由服務端所撰寫)，所以這簡直就是專為服務端的硬體或軟體所設計的服務，你要稱它為網路層級的「驅動程式」也不為過，這樣的驅動程式是由Java程式語言所設計，並透過網路來使用遠端的硬體資源的方法。

接下來，我們就來看看在硬體上有哪些實作Jini服務的方式。這其中每一種方式，對使用服務的客戶端來說都是一樣的，只是不同的方式或使用不同的途徑來和Jini查詢服務溝通，同時也會使用不同的形式來提供使用服務的客戶端Java的類別介面。在每一種方式中，都會針對設備的複雜度而有不同的設計取捨，對設備所具有的彈性、溝通形式的直接程度也都是如此。在此之前，我們要先了解所謂的位置關係(interposition)，也就是在服務提供者本身以及其客戶端之間加入代理人的形式和能力。這個服務代理人可以用來當作Jini技術基礎架構上的中介者，將服務本身要和Jini系統合作的部份分離出來。以下幾種方式，只是給予服務設計者一些基本的建議，在設計硬體組件的服務上所能採取的幾種基本方式。另外要強調一點，就是並沒有所謂的單一Jini設備架構，相對的，應該是存在一個可以容納不同服務的設備虛擬空間，而這些服務是由不同價格、效能、功能、以及彈性的硬體所實作構成的。以下便是這幾種方式的描述：

1.使用現有Java虛擬機器的設備

首先，最簡單的設計方法，就是將運算效能、記憶體以及儲存媒體都涵括進來，並加入完整的JVM以及支援Jini基礎架構所需的Java應用程式環境(也就是那些支援程式碼載入、RMI、以及特別的安全功能者)以加入Jini合作環境之中。這樣的做法，設備便會成為一個很特別的運算單元，對外提供具有設備能力的Java API。在這樣的方式下，硬體的實作都會被隱藏在設備的軟體實作後面，而這樣的軟體實作又會隱藏在客戶端所使用的服務代理人後面，這樣兩階層式的架構如(圖一)所示：

《圖一　使用現有Java虛擬機器設備的組態》

這樣的設備可以使用到完整的Java以及Jini技術，來上載和設備溝通的程式碼，以及下載該服務可能會用到的程式碼。這樣的設備可以使用基本的RMI協定來透過網路做溝通工作，並且在通訊協定及設備的軟體協定間有一定的連結。在這樣的形式下，設備便成了透過內嵌的Java平台來提供特定服務的網路應用。實際上，這樣的方式使用了在硬體上實作RMI伺服器的方式，而將硬體獨立在兩階層的間接溝通模式下。其中第一層是代理人程式碼的部份，這部份被上載到Jini查詢服務中，且由使用服務的客戶端來下載。第二層則是本機上的JVM以及由Java所設計的程式碼，這部份用來當作代理人和硬體之間的中介單元。

使用這種方式來實作的設備，可以視為在設備上實作多種服務，並透過JVM來對外提供。此外，這樣的設備本身的進步也不會影響到客戶端或是主從端之間的網路通訊協定，因為硬體上的任何改變都只有JVM以及伺服端和硬體直接溝通的程式碼才會看見。這樣的方式雖然簡單且具有彈性，但卻為設備本身帶來了額外的成本，因為這個設備將會需要一個微處理器來執行JVM，以及一定數量的記憶體來建立並存放所撰寫的類別程式，還需要一些儲存媒介來提供所需載入的JVM以及JDK軟體。這些部份對實作硬體設備所提供的Jini服務來說都是必要的，而這些額外的硬體需求的確會增加生產該設備所負擔的成本。

要符合這些需求並不代表你需要一個專屬的JVM，或是一個在設備上運作的完整JDK。因為JVM可以在任何形式的微核心程式上執行，甚至可以直接在硬體上執行。此外，JDK其中有一大部分對設備本身來說並不需要，如繪圖以及和使用者介面相關的部份，這些都是目前JDK版本中的一大部份，其中也有另一些部份可以因應需求來進行刪減，進而形成一個瘦身過後的JDK來提供Jini設備使用。這種將JDK真正所需的部份找出來的工作式相當值得的，因為這樣可以顯著的調整整個元件的大小，同時這樣的技術也和內嵌式Java技術(Embedded Java)的定義很接近，只是要再加上對RMI的支援即可。

這樣的做法重點是在設備可以下載任何由Java所撰寫的程式碼，並使用RMI來當作溝通的橋樑，以應付一個一般用途虛擬機器的需求。若是設備可以支援一個標準的JVM，則該設備便可以再Jini合作環境中發揮完整的功能，且在設備之間的相互合作溝通方面也可以具有完全的彈性。

2.使用自訂虛擬機器的設備

如果生產設備的廠商願意犧牲一些在Jini分散式架構下的彈性的話，要加入Jini合作環境的門檻就可以降低一些。也就是說，我們可以設計自己特殊用途的虛擬機器，使它只擁有加入Jini合作環境中最基本的發覺以及查詢服務協定即可。這樣一來，該設備仍然可以成為Jini系統中的一份子。要達到這樣的目的，首先設備廠商必須為該設備實作出Jini發覺服務以及Jini查詢服務的相關介面，包括和租約相關的部份，以及如何在Jini環境中更新租約等等。其次必須要有足夠的方式來讓其他成員下載並使用你所提供的服務代理人。舉例來說，這樣特殊的虛擬機器可能不需要使用到安全管理的功能(Security Manager)，但這在標準的JVM中卻是必需的。(圖二)表示了這種方法的形式，和第一種方法的差別只在虛擬機器的部份。

《圖二　使用自訂虛擬機器設備的組態》

間單來說，這樣的設備就是包含了特別用來在Jini環境中運作的JVM，其中允許了Jini的發覺以及查詢服務運作，並設計了特別的租約形式以供使用。這樣做法的缺點，就是它會限制了該設備的能力，不但將來的軟體更新較為困難，同時對代理人在協定的修正上也會有諸多不便之處。而特別的租約形式也會對設備造成限制，因為只有特別實作出來的查詢服務才能夠使用到它。但是無論如何，這種在服務設計上的負擔也不會比簡化整個設備要來得複雜。

3.數種設備共用一個虛擬機器(實體連接形式)

第三種方法是使用一個完整的JVM，但是將該JVM的成本(包括硬體及軟體部份)分散到數個不同的設備上。如果是使用這樣的做法，則一群設備便可以共同使用一個JVM來當作在設備和Jini系統之間的值中介層。每個設備都可以把Java程式碼載入到它們所屬的虛擬機器中，並允許該虛擬機器和設備本身溝通，並將那些和Jini查詢服務、發覺服務以及租約溝通的部份加入JVM中。這樣的做法和第一種方式相當類似，不同之處在於JVM是由一群設備共同使用的。它仍然是個完整的JVM，也就是說，它允許程式碼的下載，以及一切Java平台所應具有的功能。但無論如何，對這樣的實作設備來說，必須要能夠允許數個不同型態的實體設備連接到一個大的設備上，共同分享一個Java應用程式環境。

這樣一個大的設備，我們可以想像成是一個Jini設備船塢(Jini device bay)。這個船塢可以提供電源、網路連接、以及執行JVM的微處理器，並包括一個合適版本的JDK。而那些提供特殊用途Jini服務的設備則可以連接到這個船塢上，並讓設備船塢知道它們的存在。這部份的溝通可以使用自己的內部協定(也就是說，允許廠商生產自己的設備以及容納那些設備的設備船塢)，或是其他工業標準來識別自己的設備。而由於有這樣的關係，一個新加入的設備會告訴設備船塢如何針對特定的服務取出相對應的Java程式碼，或是如何找出和該設備溝通的程式。這樣一來，便允許設備本身攜帶自己的「驅動程式」，以利自己的機器或是網路來使用。

而當設備船塢偵測到一個新的設備時，它會運用Jini查詢服務來註冊該設備所提供的服務，在這裡，設備船塢則是負擔著在Jini查詢服務中更新租約的責任，並處理任何已經移除的設備，就如同該設備的代理者一樣。而設備船塢也會將設備的程式碼提供給Jini查詢服務，以便所有使用該服務的客戶端能夠下載執行。在使用設備服務的客戶端眼中，它會相信它正和在Jini查詢服務中所登記的設備做溝通，但是實際上它是透過了設備船塢來進行運作。而該設備船塢則是扮演這對不同服務所分派動作的角色，就如同代理者一般，將服務代理人的網路協定，經過轉換之後，透果設備船塢和真正設備之間的協定來作通知。這樣的架構我們以(圖三)來表示其運作模式。

《圖三　數種設備共用一個虛擬機器「實體連接形式」的組態》

這樣的做法對設備廠商來說，可以使用同一個設備船塢來連接許多個實體設備，的確可以降低成本，而這樣的船塢也可以具備一些智慧、記憶、以及其他單元(如電源等)。而透過這樣的方式在多個設備之間共享資源，和Jini系統環境溝通所需要的額外成本和工程負擔就可以適當的分散到這些設備上。這樣的方式對廠商來說，會負擔的成本主要是在於讓設備船塢扮演Jini設備的角色，並且實際運作的設備必須事先定義且無法更新。在這裡必須要再強調一次，Jini設備船塢本身就是一個Jini設備，也就是說，它提供了它所包含在其中的設備所擁有的所有服務。也就是因為如此，它對於自身內部的控制就具有極大的彈性，包括內部溝通的協定，甚至是硬體匯流排得規格等等。

4.數種設備共用一個虛擬機器(網路連接形式)

另一個使用設備船塢的方法，就是透過網路來和設備進行溝通，而不是使用實體的連接方式。在這種方式下，一個讓數種設備當作代理者的JVM就存在於網路環境中，提供服務的設備可以加入該網路，發覺現有的代理者設備，然後對該代理者進行註冊。而這個註冊動作除了是將自己所提供的服務的Java程式碼做登錄之外，還會將如何和設備本身溝通的程式碼也一併做登錄。而當一個設備替自己註冊了之後，該代理者便會將這個設備所提供的服務，向Jini查詢服務進行真正的註冊動作。這樣一來，設備所提供的服務便正式成為Jini合作環境中的一部份。而針對那些服務所發出的請求，則會先送到該服務的代理者，然後再將請求轉交給實際負責的設備上。此外，該代理者必須要能夠處理和Jini相關的工作，如租約的更新等等。這樣的方式在(圖四)中有清楚的說明。

《圖四　數種設備共用一個虛擬機器「網路連接形式」的組態》

這樣的方式對個別設備來說，是需要一些額外硬體設備支援，也就是要有所謂的代理者。這樣的代理者必須具有網路連線，並且具有自己的電源。但即使如此，各個設備仍不需要有自己的CPU、記憶體、或是儲存媒介，因為這些都由在網路上的Jini設備代理者來提供了。

使用這種方式的設備，和網路代理者之間必須要有特定的通訊協定，也就是說，要有特別的網路程式碼，以便提供該設備在網路上的識別功用，但這仍然只是代理者和設備之間的特殊溝通方式。而且，這樣的協定一旦確定下來之後，也就不容易在進行修正了。此外，這樣的方式和前一種Jini設備船塢比起來個別設備的設計上會比較複雜一些，但是設備的數量就不會因為硬體的限制而有所謂的上限，而且設備也不必一定要和代理者放在一起，這在前一種方式是不可能做到的。這樣的方式也可以當成為Jini設備和其他網路設備之間建立所謂的閘道(Gateway)。針對那些原先使用特定通訊協定的設備，我們去建立Jini代理者來連接它們，進而加入Jini合作環境之中。這種做法可以用在消費性電子設備、工廠自動控制設備、以及其他家用控制設備上，來共同組成Jini系統運作環境。

後記

本文介紹了在一個Jini系統環境中，硬體的實作有哪些可能性，同時也說明了這些實作方式所會面臨的取捨問題。這些取捨問題分別出現在各階層的成本問題上，包括硬體設計、軟體工程、網路組態等部份。本文也提供了有心發展Jini系統的讀者可以採取的系統架構形態，希望能讓讀者在花費最少的精神，來達到進入Jini世界的大門之中。