Jini 技術面向網路與分散式運算特性，決定其在許多方面與傳統單機系統有觀念與實際應用差異：網路延遲、失敗、設備突然撤出導致資訊無序遺失；資源獲取、保存、維護、回收更複雜；實體間通訊協調可靠性與效率不如單機系統易保證。因此 Jini 以 Java 為基礎引入分散式程式設計模式，特別是租約、分散式交易與分散式事件。
資源只能被使用一段時間，由租約持有者與授權者協商決定。目標為分散式系統提供特殊程式設計風格：物件首次存取資源時，雙方先協商，再授權某段時間使用。
非分散式系統中，資源/服務授權至明確釋放或放棄。此模式在分散式系統注定失敗：無法保證放棄資源/系統使用必定成功，導致系統部分資源永不釋放。引入租約避免此問題：授權基於時間，期滿服務結束、資源釋放。期限首次授權時由雙方以請求/回應方式協商。租約可在期滿前續約或取消。期滿時雙方視服務/資源已回收。
持續運作分散式系統傾向累積過時與不必要資訊，傳統解法為系統管理員手動清理。租用資源時，資訊僅在租約續約時保留於系統中，被遺忘資訊經有限時間後自動刪除，無需手動清理。
定義一組介面、慣例與協定，使不同 JVM 透過協商產生各類資源使用租約。協議類型：物件存取（參考）協議、未來行動（事件通知）協議、長久儲存協議等。租約機制需與並發機制結合：資源可有多個並發租約持有者。
交易行為在分散式運算極重要：提供讓一或多遠端參與者對一系列操作結果保持一致的方法。Jini 將實現交易語義交由交易中個別物件處理。系統首要提供：物件間確認交易時交換資訊的合作機制，目標提供最小協定與介面集合讓物件實現交易語義。
Jini 描述的完成協定由分散式系統兩階段提交協定組成。定義分散式物件資源通訊模式，需一管理者保證操作集決議一致性——所有參與者最終知曉應提交或放棄操作。
TransactionFactory）創建語義物件ready（準備提交）、unchanged（唯讀）、abort（應放棄）兩階段提交設計目標使物件提供 ACID 特性：
依賴參與者實現 ACID 是兩階段提交與傳統交易處理系統最大不同。三主要類型：
TransactionManager：創建新交易、協調參與者行動NestableTransactionManager：支援巢狀交易的管理者TransactionParticipant：操作在交易下進行時，參與者必須加入交易，提供 TransactionParticipant 參考供管理者表決用因網路延遲與失敗可能，遠端物件事件通知順序可能因客戶不同而異、或根本未送達。通知送達時間可能很長，接收方不總希望立即收到、而是在其決定的確定時間收到。甚至註冊興趣的物件並非事件通知應發送對象。
在產生通知物件與希望接收通知的其他物件間加入第三方物件。它們可從物件卸下通知、實現多種傳遞保證、儲存通知、過濾與重新路由通知。
Jini 分散式事件介面定義一協定：一 JVM 物件可在其他 JVM 物件上註冊感興趣事件，事件發生時獲通知。介面規定通知必含資訊。協定未體現通知可靠性與時限，此保證非協定一部分，涉及不同物件實作。
RemoteEventListener)，主要功能：接收其他物件事件發生通知RemoteEvent：從產生者傳遞至監聽者指示特定事件發生的物件EventRegistration：封裝註冊者所需資訊、標識通知、維護註冊請求的物件，為遠端事件註冊呼叫返回值EventRegistration 實例含：事件類型識別、當前事件類型序列號、註冊的 Lease 物件。
MarshalledObject，使事件通知含任意資訊；註冊呼叫應含 MarshalledObject 作為 RemoteEvent 一部分傳送RemoteEventListener 為 RemoteEvent 接收者。由單一方法 notify 定義，返回註冊時導入資訊，允許註冊者將任意資訊/動作與通知關聯。需由希望從其他物件收到 RemoteEvent 通知的物件實現。註冊呼叫需接收目標參數指明通知送達物件。繼承 Remote（方法為遠端方法、支援 RMI 傳遞參考）與 java.util.EventListener（指明為事件通知接收者）。
基本形式含：事件發生物件參考、長整數事件類型識別、長整數序列號（判定事件先後順序）、回呼 MarshalledObject（註冊者註冊一部分）。事件類型識別與事件發生者參考組合應唯一確定事件類型。非註冊興趣類型時 notify 拋出 UnknownEventException。序列號為遞增值，判定遠端事件發生先後順序。
封裝客戶所需資訊、標識註冊請求應答通知、維護註冊請求。允許事件註冊的方法不一定返回 EventRegistration 型別物件，但此類確實包含事件模型中需返回的資訊類型。
