網閘，也稱邊界平台、內外網數據交換系統。
網閘將內網與外網實現了隔離，即內外網程序不能直接相互訪問。
那么，如何實現內外網即時數據交互呢？比如外網程序要訪問內網webservice服務？
就拿外網程序訪問內網的webservice服務為例，分析幾種數據交互方式的可行性。
大概有三種方式：
1、使用網閘的映射功能：即在網閘中配置指定ip段的外網機器，只能訪問內網指定ip、端口的機器所提供的指定服務。
評價：此種方式較為方便，但不是最安全的。
2、文件同步功能：此種方式需要一台外網服務器和一台內網服務器，在內外網服務器上分別部署webservice服務程序，並在內外網機器上分別建立共享文件夾，供網閘進行文件的同步（從內網到外網，從外網到內網）。
實現思路大致是：
（1）、外網服務器部署的webservice程序供外網用戶訪問，一旦接受請求，則將請求生成xml或者其他格式文件，放到外網服務器的共享請求目錄。
（2）、通過在網閘中配置內外網的共享請求目錄與共享響應目錄，網閘會定時（最低一分鍾）掃描內外網服務器的指定的若干目錄，看有無新增文件，有則同步過去。
（3）、內網服務器webservice程序內部定時掃描指定請求目錄，網閘將外網服務器的請求文件同步到內網服務器的請求目錄后，內網程序檢測到請求文件則立即觸發調用本地或者內網其他機器的webservice服務，並將結果生成響應文件放到響應目錄。
（4）、網閘檢測響應目錄的新增文件，將文件同步到外網服務器的響應目錄，外網服務器程序線程接受到請求后， 一直等待指定時間，掃描響應目錄下有無響應文件產生（請求文件與響應文件采取同名方式，以便區分），讀取到響應文件后，返回給外網用戶調用者。
評價：此種方式雖然較上種方式安全，但網閘掃描頻率最快一分鍾掃描一次的限制便將該種方式kill了（讓客戶等待至少2分鍾是完全不可行的）。
然而對於新的網閘內外網數據交換平台可以支持1s掃描一次，因此對於需要交換圖片、視頻等應用，則可考慮升級舊網閘數據交換系統；此時采取文件同步是比較理想的。
3、數據庫同步方式：
實現思路：
（1）、需要兩台服務器，內網服務器與外網服務器，兩台機器同時部署兩個程序（程序不完全相同），兩台服務器都要安裝數據庫，並建立相同的表結構（指需要通過網閘同步的表的結構相同，本例中需要響應表和請求表）
（2）、在網閘中配置數據庫同步，需要兩個庫的連接方式，及需要同步那些表；注意，同步的表字段不可有clob或者blob等類型（網閘不能同步，猜測是大字段類型不能導出的原因），基本類型最好。
（3）、外網webservice程序接收請求，將請求插入到請求表中，然后線程休眠指定時間后讀取響應表中的響應結果。
（4）、網閘將外網數據庫的請求表中的插入的數據，即時（可能采用觸發器，具體不知，相當於即時）同步到內網數據庫的請求表中。
（5）、對內網請求表預先建立行級觸發器，當請求表每插入一條數據時，即執行觸發器，在觸發器中調用內網的webservice程序。
（6）、可在觸發器中插入結果到響應表中，若是業務邏輯復雜，則可在webservice程序內部將結果插入到響應表中。
（7）、網閘將響應表中數據即時同步到外網服務器的響應表中。
（8）、(3) 中等待的線程在限定時間內每隔100ms（自己指定）查詢響應表，查詢到等待的結果則返回給客戶。
關鍵點：
1）、外網等待線程如何知道響應表中哪條記錄是它要的結果？ 外網請求表新增請求的id、內網請求表新增請求的id、內網響應表響應記錄的id、外網響應表響應記錄的id，這四個id為同一個id，都是外網請求表新增請求的id，即只有外網請求表新增請求的id是自動產生，其他三個均采取手動賦值。
2）、內網請求表的觸發器如何調用webservice？ 在觸發器中可通過utl_http、utl_dbws兩種方式訪問webservice，第一種方式稍簡單，第二種方式需要導入utl_dbws包到oracle數據庫，較麻煩。
3）、表中字段不可為大數據類型，最好為基本類型
4、總結：映射方式與數據庫同步方式最為靠譜，但若是對安全性要求非常高，則建議使用數據庫同步方式，否則使用映射方式最為便捷。
然而，此種方式不支持圖片數據，大字段類型、視頻的交換。