A. Web應用的測試內容都包括哪些方面
1、通用指標
指Web應用伺服器、資料庫伺服器必需測試項，包括：處理器時間：指伺服器CPU佔用率，一般平均達到70%時，服務就接近飽和。可用內存數：如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重。物理磁碟讀寫時間。
2、Web伺服器指標
平均每秒響應次數為總請求時間與秒數之比。平均每秒業務腳本的迭代次數。成功的請求和失敗的請求。成功的點擊次數和失敗的點擊次數。每秒點擊次數、每秒成功的點擊次數和每秒失敗的點擊次數。嘗試連接數。
3、資料庫伺服器指標
用戶連接數，也就是資料庫的連接數量。資料庫死鎖量。資料庫緩存的命中情況。
(1)構建實時web應用擴展閱讀
對被測的Web應用程序進行需求分析，即對所做的測試作一個簡要的介紹，包括描述測試的目標和范圍，所測試的目標要實現一個什麼樣的功能，總結基本文檔、主要活動。
寫出測試策略和方法，這里包括測試開始的條件、測試的類型、測試開始的標准以及所測試的功能、測試通過或失敗的標准、結束測試的條件、測試過程中遇到什麼樣的情況終止和怎麼處理後恢復等。
一個Web應用程序由完成特定任務的各種Web組件（web components)構成的並通過Web將服務展示給外界。在實際應用中，Web應用程序由多個Servlet、JSP頁面、HTML文件以及圖像文件等組成。所有這些組件相互協調為用戶提供一組完整的服務。
B. 做Web應用需要了解哪些事情
今天小編要跟大家分享的文章是關於做Web應用需要了解哪些事情?如果你是Web前端工程師，如果你正在做Web應用程序，就來看一看這篇文章吧，文章中會告訴你做Web應用需要了解哪些事情，下面讓我們一起來學習一下吧~
一、安全性
§確認郵件：
當用戶注冊時，應向他們發送帶有點擊確認郵箱的鏈接的郵件。如果用戶更新他們的郵箱地址，則要再次重復這個工作流程。
§身份管理：
當存儲密碼時，首先對它們進行加鹽和散列操作，然後再用現在廣泛使用的crypto庫。如果你不這樣做的話，把身份管理轉由給Facebook/
GitHub/Twitter/等，用OAuth就能做到。
§加密：
所有證書問題，還有什麼比SSL更好。使用它吧。還可以使用HSTS。
§憑證：
不要把伺服器身份信息(API密鑰、資料庫密碼等)放到版本控制里，否則就泄密了。
二、工程：動畫
所有的愛，都是神聖的。但別為應用里的所有元素添加動畫。因為大多數CSS動畫都會觸發布局重繪;最好盡可能地限制自己使用transform和
opacity。
避免進行緩慢的過渡運算，如果非要使用，那麼確保它是針對某個屬性的(如，」transition:opacity250msease-in」，而不是
」transition:all250msease-in」)。
三、用戶體驗(UX)
§表單：
當提交一個表單後，用戶應收到提交後的反饋。如果提交後不向用戶發送一個不同的頁面，那麼就應該有彈框或alert
一些信息，以便讓用戶知道這次提交是否成功。
§登錄重定向：
如果用戶打算在你的網站打開一個頁面，但並沒有登錄，那麼他們應該首先接收到一個能登錄的頁面，並在登錄後重定向到一個他們原本想打開的一個頁面(當然，前提是已得到授權)。
如果他們嘗試登錄，但提供了一個錯誤的密碼，這時，用戶有可能是忘記了密碼，那我們就應該提供一個視覺線索來提醒他們，要有一個重置密碼的選項。
四、電子郵件
訂閱設置：
任何發送到用戶的email
，都應該至少包含一個鏈接，能鏈接到修改他們的郵箱設置的應用程序頁面，並且最好每個郵件都有一個單獨的鏈接，能取消訂閱。
千萬別讓用戶為了取消訂閱而向你發送郵件。
五、移動端
雖然你不必開發移動端但不管你是否做，你都應該確保這是一個積極的決定，因為這會對你的應用程序設計和工程有實質性影響。
下面的注意事項是假設你已選擇移動端作為你的平台之一。我碰巧選用Grunt作為我的構建工具，所以我得使用一些Grunt-specific
插件，但你可能使用類似的JavaScript構建工具。
六、工程
單頁面應用：
現今單頁面(SPA)是王道。它的主要優勢是很少載入整個頁面_只需載入所需資源，並且無須反復重載相同的資源。如果你才剛剛開始開發一個新的web
應用，那它很可能是SPA。
七、用戶界面(UI)
解析度：
當你開發MVP(MinimumViableProct_最簡化可實行產品)時，不用先急著兼容各種尺寸的UI
，那是等你的產品一下子火了之後才需要去做的事情，但要確保支持主流設備(尺寸)。
八、UX：寬頻
相對於桌面端，移動端的一個大主題是帶寬，它是非常珍貴的資源。因此，不應該放過任何能減少請求的機會，讓它們盡可能地採用非同步請求，並減少請求資源的大小。
JS&CSS_合並與壓縮：把面向具體應用的JavaScript和CSS合並到單獨文件里(一個JS，一個
CSS)，並進行壓縮。Grunt-contrib-concat、Grunt-contrib-cssmin和Grunt-contrib-uglify
都是你的好朋友。
所有資源-使用CDN：它有兩個主要的優勢。第一個是適用託管所有資源，並本地化。CDN
確保資源服務都位於一個區域，而該區域在地理位置上是靠近用戶請求資源的位置，從而減少載入時間。
第二個優勢是更適用於你的依賴文件(比如，非面向特定應用的樣式和JS代碼)。為你所依賴的文件使用CDN能極大地減少載入時間。比如，很多網站依賴
Angular.js，使用CDN鏈接Angular代碼會觸發緩存命中，那麼移動設備會從設備緩存里檢索，而不是額外新建一個HTTP請求。
CSS_減少佔用空間：大多數開發者在初始時階段，很可能使用某些UI框架(如Bootstrap、Foundation
等)。這些框架可以很大，其壓縮版通常可以常用的CDN上獲得，但你不太可能使用它包含的所有樣式。因此，類似uncss工具(一般配對的有
processhtml)能令你難以置信地移除最終未被使用的樣式。
注意這點很重要：uncss解析器不能提取動態樣式(即通過JavaScript
事件添加的樣式)，所以你必須在瀏覽器進行嚴格的測試，以確保不會去除應用程序實際用到的樣式。
CSS_將關鍵的文件放在頭部：因為樣式需要在應用完成載入前看到;次要的樣式能在載入完後提供。
JS_減少佔用空間：因為應用一旦上線，程序員就不需要考慮JavaScript代碼里內部變數的可讀性，因此可以將所有如user.name
變數重命名為u.e，從而減少文件大小。因此，有一個工具為此而生_上面提及到的uglify，雖然它會使JS
代碼完全看不懂，但極大地減小文件大小。
九、用戶體驗：表單
這是一個很好的建議：保持表單和工作流程的簡易性，當你針對移動設備作為部署平台時，這點尤其重要。因為沒有人願意在手機上填滿5頁的表單。
我希望這列表對於剛開始開發第一款Web
應用的你有所幫助，甚至對那些之前不熟悉前端的一些優化技巧的後端或設計師。如果你有其它建議或記起某些東西，那麼請讓我知道，我會考慮將它添加到該列表。
以上就是小編今天為大家分享的關於做web應用需要了解哪些事情?的文章，希望本篇文章能夠對正在從事web前端開發工作的小夥伴們有所幫助。想要了解更多web前端方面的知識記得關注北大青鳥web前端培訓官網哦~
本文來源：伯樂在線@劉健超-J.c
*聲明：內容與圖片均來源於網路(部分內容有修改)，版權歸原作者所有，如來源信息有誤或侵犯權益，請聯系我們刪除或授權事宜。
C. java消息推送，一個實時數據的web顯示該怎麼做
javaweb消息實時推送可以使用GoEasy平台。1、操作如下：到goeasy官網上注冊一個賬號，並創建一個應用，應用創建好後系統會默認為它生成兩個key: publish key和subscribe key。
2、前台實時訂閱及接收：需要引入goeasy.js,然後調用goeasy的subscribe方法訂閱一個channel即可，訂閱時無論是用publish key還是subscribe key都可以。
3、通過subscribe的參數 onMessage的回調函數可以實時接收到消息。
4、前台實時推送：需要引入goeasy.js（如果該頁面已經引入了可不在引入）,然後調用goeasy的publish方法向已訂閱的channel上推送消息即可，推送時只能用publish key。
5、後台實時推送：調用GoEasy Restful API， 用post方式訪問。
6、 同時還需要帶上三個必要參數：appkey: publish key。channel: 訂閱了的channel。content: 推送內容GoEasy的實現原理很簡單，就是推送消息的一端只負責推送，而需要接收的頁面需要預先訂閱。
7、往 某個channel上推送消息，客戶端就訂閱相同的channel,這樣就可以確保准確接收。
8、通過channel可以自己指定哪些頁面或哪些用戶可以 接收到從這個channel上推送出來的消息。
消息推送推薦極光。極光iAudience依託自身海量移動終端數據，對用戶線上和線下行為進行分析，構建多維、准確、及時的全息畫像體系，並以開放介面的形式為全行業提供服務。
D. 簡述動態web應用系統的實現原理和工作流程
webwork工作流程與原理
關鍵字: webwork
首先瀏覽器按照web.xml中指定的格式（比如：以.do結尾的請求）發起請求，servlet接收請求後從url中解析出action名稱，同時遍歷HttpServletRequest、HttpSession、ServletContext 中的數據，並將其復制到
Webwork的Map實現中，至此之後，所有數據操作均在此Map結構中進行，從而將內部結構與Servlet API相分離。
接著ActionProxyFactory創建對應的ActionProxy實例。ActionProxyFactory 將根據Xwork 配置文件（xwork.xml）中的設定，創建ActionProxy實例，ActionProxy中包含了Action的配置信息（包括Action名稱，
對應實現類等等）。ActionProxy創建對應的Action實例，並根據配置進行一系列的處理程序。包括執行相應的預處理程序（如通過Interceptor 將Map 中的請求數據轉換為Action所需要的Java 輸入數據對象等），以及對Action 運行結果進行後處理
是不是這個？
E. java消息推送，一個實時數據的web顯示該怎麼做
javaweb消息實時推送可以使用極光平台進行實現。具體操作如下：1、首先先到到極光官網上注冊一個賬號，並創建一個應用；
2、前台進行實時訂閱及接收；
3、前台進行實時推送；
4、後台也進行實時推送；
5、極光的實現原理很簡單，就是推送消息的一端只負責推送，而需要接收的頁面需要預先訂閱。
消息推送軟體，選擇極光是個不錯的選擇，而且安全性和穩定性都不錯。極光作為合作夥伴，體現了以映客為代表的頭部互動娛樂及社交平台對極光服務能力的認可及技術實力的信賴。
極光將始終堅持「助力開發者運營、增長和變現，邁向成功」的使命，還用更專業、高效、安全、穩定、智能的開發者服務及出色的機器學習數據分析能力，為更多合作夥伴的智能化用戶運營「錦上添花」。
F. 如何構建一個每天數十億次請求級別的web應用
1、程序和資料庫部署在同一台伺服器上
2.多學習一些相關的書籍比如：構建高性能Web站點，大規模Web服務開發技術 構建可擴展的Web站點 ， Web容量規劃的技術，分布式資料庫系統及其應用。 掌握其原理和結構 。
G. Web工程師你知道如何構建單頁Web應用嗎
今天小編要跟大家分享的文章是關於Web工程師你知道如何構建單頁Web應用嗎?正在從事web相關工作的小夥伴們你們是否知道什麼是單頁面應用，是否知道該如何構建單頁面web應用?下面
就來和小編一起來看一看吧!
首先我們來看一看單頁應用是什麼?
所謂單頁應用，指的是在一個頁面上集成多種功能，甚至整個系統就只有一個頁面，所有的業務功能都是它的子模塊，通過特定的方式掛接到主界面上。它是AJAX技術的進一步升華，把AJAX的無刷新機制發揮到極致，因此能造就與桌面程序媲美的流暢用戶體驗。
其實單頁應用我們並不陌生，很多人寫過ExtJS的項目，用它實現的系統，很天然的就已經是單頁的了，也有人用jQuery或者其他框架實現過類似的東西。用各種JS框架，甚至不用框架，都是可以實現單頁應用的，它只是一種理念。有些框架適用於開發這種系統，如果使用它們，可以得到很多便利。
一、開發框架
ExtJS可以稱為第一代單頁應用框架的典型，它封裝了各種UI組件，用戶主要使用JavaScript來完成整個前端部分，甚至包括布局。隨著功能逐漸增加，ExtJS的體積也逐漸增大，即使用於內部系統的開發，有時候也顯得笨重了，更不用說開發以上這類運行在互聯網上的系統。
jQuery由於偏重DOM操作，它的插件體系又比較鬆散，所以比ExtJS這個體系更適合開發在公網運行的單頁系統，整個解決方案會相對比較輕量、靈活。
但由於jQuery主要面向上層操作，它對代碼的組織是缺乏約束的。如何在代碼急劇膨脹的情況下控制每個模塊的內聚性，並且適當在模塊之間產生數據傳遞與共享，就成為了一種有挑戰的事情。
為了解決單頁應用規模增大時候的代碼邏輯問題，出現了不少MV*框架，他們的基本思路都是在JS層創建模塊分層和通信機制。有的是MVC，有的是MVP，有的是MVVM，而且，它們幾乎都在這些模式上產生了變異，以適應前端開發的特點。
這類框架包括Backbone，Knockout，AngularJS，Avalon等。
二、組件化
這些在前端做分層的框架推動了代碼的組件化，所謂組件化，在傳統的Web產品中，更多的指UI組件，但其實組件是一個廣泛概念，傳統Web產品中UI組件佔比高的原因是它的厚度不足，隨著客戶端代碼比例的增加，相當一部分的業務邏輯也前端化，由此催生了很多非界面型組件的出現。
分層帶來的一個優勢是，每層的職責更專一了，由此，可以對其作單元測試的覆蓋，以保證其質量。傳統UI層測試最頭疼的問題是UI層和邏輯混雜在一起，比如往往會在遠程請求的回調中更改DOM，當引入分層之後，這些東西都可以分別被測試，然後再通過場景測試來保證整體流程。
三、代碼隔離
與開發傳統頁面型網站相比，實現單頁應用的過程中，有一些比較值得特別關注的點。
從單頁應用的特點來看，它比頁面型網站更加依賴於JavaScript，而由於頁面的單頁化，各種子功能的JavaScript代碼聚集到了同一個作用域，所以代碼的隔離、模塊化變得很重要。
在單頁應用中，頁面模板的使用是很普遍的。很多框架內置了特定的模板，也有的框架需要引入第三方的模板。這種模板是界面片段，我們可以把它們類比成JavaScript模塊，它們是另一種類型的組件。
模板也一樣有隔離的需要。不隔離模板，會造成什麼問題呢?模板間的沖突主要存在於id屬性上，如果一個模板中包含固定的id，當它被批量渲染的時候，會造成同一個頁面的作用域中出現多個相同id的元素，產生不可預測的後果。因此，我們需要在模板中避免使用id，如果有對DOM的訪問需求，應當通過其他選擇器來完成。如果一個單頁應用的組件化程度非常高，很可能整個應用中都沒有元素id的使用。
四、代碼合並與載入策略
人們對於單頁系統的載入時間容忍度與Web頁面不同，如果說他們願意為購物頁面的載入等待3秒，有可能會願意為單頁應用的首次載入等待5-10秒，但在此之後，各種功能的使用應當都比較流暢，所有子功能頁面盡量要在1-2秒時間內切換成功，否則他們就會感覺這個系統很慢。
從這些特點來看，我們可以把更多的公共功能放到首次載入，以減小每次載入的載入量，有一些站點甚至把所有的界面和邏輯全部放到首頁載入，每次業務界面切換的時候，只產生數據請求，因此它的響應是非常迅速的，比如青雲的控制台就是這么做的。
通常在單頁應用中，無需像網站型產品一樣，為了防止文件載入阻塞渲染，把js放到html後面載入，因為它的界面基本都是動態生成的。
當切換功能的時候，除了產生數據請求，還需要渲染界面，這個新渲染的界面部件一般是界面模板，它從哪裡來呢?來源無非是兩種，一種是即時請求，像請求數據那樣通過AJAX獲取過來，另一種是內置於主界面的某些位置，比如script標簽或者不可見的textarea中，後者在切換功能的時候速度有優勢，但是加重了主頁面的負擔。
在傳統的頁面型網站中，頁面之間是互相隔離的，因此，如果在頁面間存在可復用的代碼，一般是提取成單獨的文件，並且可能會需要按照每個頁面的需求去進行合並。
單頁應用中，如果總的代碼量不大，可以整體打包一次在首頁載入，如果大到一定規模，再作運行時載入，載入的粒度可以搞得比較大，不同的塊之間沒有重復部分。
五、路由與狀態的管理
我們最開始看到的幾個在線應用，有的是對路由作了管理的，有的沒有。
管理路由的目的是什麼呢?是為了能減少用戶的導航成本。比如說我們有一個功能，經歷過多次導航菜單的點擊，才呈現出來。
如果用戶想要把這個功能地址分享給別人，他怎麼才能做到呢?
傳統的頁面型產品是不存在這個問題的，因為它就是以頁面為單位的，也有的時候，服務端路由處理了這一切。
但是在單頁應用中，這成為了問題，因為我們只有一個頁面，界面上的各種功能區塊是動態生成的。所以我們要通過對路由的管理，來實現這樣的功能。
具體的做法就是把產品功能劃分為若干狀態，每個狀態映射到相應的路由，然後通過pushState這樣的機制，動態解析路由，使之與功能界面匹配。
有了路由之後，我們的單頁面產品就可以前進後退，就像是在不同頁面之間一樣。
其實在Web產品之外，早就有了管理路由的技術方案，Adobe
Flex中，就會把比如TabNavigator，甚至下拉框的選中狀態對應到url上，因為它也是單「頁面」的產品模式，需要面對同樣的問題。
當產品狀態復雜到一定程度的時候，路由又變得很難應用了，因為狀態的管理極其麻煩，比如開始的時候我們演示的c9.io在線IDE，它就沒法把狀態對應到url上。
六、緩存與本地存儲
在單頁應用的運作機制中，緩存是一個很重要的環節。
由於這類系統的前端部分幾乎全是靜態文件，所以它能夠有機會利用瀏覽器的緩存機制，而比如動態載入的界面模板，也完全可以做一些自定義的緩存機制，在非首次的請求中直接取緩存的版本，以加快載入速度。
甚至，也出現了一些方案，在動態載入JavaScript代碼的同時，把它們也緩存起來。比如Addy
Osmani的這個basket.js，就利用了HTML5localStorage作了js和css文件的緩存。
在單頁產品中，業務代碼也常常會需要跟本地存儲打交道，存儲一些臨時數據，可以使用localStorage或者localStorageDB來簡化自己的業務代碼。
七、服務端通信
傳統的Web產品通常使用JSONP或者AJAX這樣的方式與服務端通信，但在單頁Web應用中，有很大一部分採用WebSocket這樣的實時通訊方式。
WebSocket與傳統基於HTTP的通信機制相比，有很大的優勢。它可以讓服務端很便利地使用反向推送，前端只響應確實產生業務數據的事件，減少一遍又一遍無意義的AJAX輪詢。
由於WebSocket只在比較先進的瀏覽器上被支持，有一些庫提供了在不同瀏覽器中的兼容方案，比如socket.io，它在不支持WebSocket的瀏覽器上會降級成使用AJAX或JSONP等方式，對業務代碼完全透明、兼容。
八、內存管理
傳統的Web頁面一般是不需要考慮內存的管理的，因為用戶的停留時間相對少，即使出現內存泄漏，可能很快就被刷新頁面之類的操作沖掉了，但單頁應用是不同的，它的用戶很可能會把它開一整天，因此，我們需要對其中的DOM操作、網路連接等部分格外小心。
九、樣式的規劃
在單頁應用中，因為頁面的集成度高，所有頁面聚集到同一作用域，樣式的規劃也變得重要了。
樣式規劃主要是幾個方面：
1、基準樣式的分離
這裡面主要包括瀏覽器樣式的重設、全局字體的設置、布局的基本約定和響應式支持。
2、組件樣式的劃分
這裡面是兩個層面的規劃，首先是各種界面組件及其子元素的樣式，其次是一些修飾樣式。組件樣式應當盡量減少互相依賴，各組件的樣式允許冗餘。
3、堆疊次序的管理
傳統Web頁面的特點是元素多，但是層次少，單頁應用會有些不同。
在單頁應用中，需要提前為各種UI組件規劃堆疊次序，也就是z-index，比如說，我們可能會有各種彈出對話框，浮動層，它們可能組合成各種堆疊狀態。新的對話框的z-index需要比舊的高，才能確保蓋在它上面。諸如此類，都需要我們對這些可能的遮蓋作規劃，那麼，怎樣去規劃呢?
了解通信知識的人，應當會知道，不同的頻率段被劃分給不同的通信方式使用，在一些國家，領空的使用也是有劃分的，我們也可以用同樣的方式來預先分段，不同類型的組件的z-index落到各自的區間，以避免它們的沖突。
十、單頁應用的產品形態
我們在開始的時候提到，存在著很多新型Web產品，使用單頁應用的方式構建，但實際上，這類產品不僅僅存在於Web上。點開Chrome商店，我們會發現很多離線應用，這些產品都可以算是單頁應用的體現。
除了各種瀏覽器插件，藉助node-webkit這樣的外殼平台，我們可以使用Web技術來構建本地應用，產品的主要部分仍然是我們熟悉的單頁應用。
單頁應用的流行程度正在逐漸增加，大家如果關注了一些初創型互聯網企業，會發現其中很大一部分的產品模式是單頁化的。這種模式能帶給用戶流暢的體驗，在開發階段，對JavaScript技能水平要求較高。
單頁應用開發過程中，前後端是天然分離的，雙方以API為分界。前端作為服務的消費者，後端作為服務的提供者。
在此模式下，前端將會推動後端的服務化。當後端不再承擔模板渲染、輸出頁面這樣工作的情況下，它可以更專注於所提供的API的實現，而在這樣的情況下，Web前端與各種移動終端的地位對等，也逐漸使得後端API不必再為每個端作差異化設計了。
十一、部署模式的改變
在現在這個時代，我們已經可以看到一種產品的出現了，那就是「無後端」的Web應用。這是一種什麼東西呢?基於這種理念，你的產品很可能只需要自己編寫靜態Web頁面，在某種BaaS(Backend
asa
Service)雲平台上定製服務端API和雲存儲，集成這個平台提供的SDK，通過AJAX等方式與之打交道，實現注冊認證、社交、消息推送、實時通信、雲存儲等功能。
我們觀察一下這種模式，會發現前後端的部署已經完全分離了，前端代碼完全靜態化，這意味著可以把它們放置到CDN上，訪問將大大地加速，而服務端託管在BaaS雲上，開發者也不必去關注一些部署方面的繁瑣細節。
假設你是一名創業者，正在做的是一種實時協同的單頁產品，可以在雲平台上，快速定製後端服務，把絕大部分寶貴的時間花在開發產品本身上。
十二、單頁應用的缺陷
單頁應用最根本的缺陷就是不利於SEO，因為界面的絕大部分都是動態生成的，所以搜索引擎很不容易索引它。
十三、產品單頁化帶來的挑戰
一個產品想要單頁化，首先是它必須適合單頁的形態。其次，在這個過程中，對開發模式會產生一些變更，對開發技能也會有一些要求。
開發者的JavaScript技能必須過關，同時需要對組件化、設計模式有所認識，他所面對的不再是一個簡單的頁面，而是一個運行在瀏覽器環境中的桌面軟體。
以上就是小編今天為大家分享的關於Web工程師你知道如何構建單頁Web應用嗎?的文章，希望本篇文章能夠對正從事web前端工作的小夥伴們有所幫助。相信通過本篇文章的介紹大家已經對如何構建單頁面web應用有所了解了，想要了解更多web相關知識記得關注北大青鳥web培訓官網哦!
來源：https://github.com/xufei/blog/issues/5
*聲明：內容與圖片均來源於網路(部分內容有修改)，版權歸原作者所有，如來源信息有誤或侵犯權益，請聯系我們刪除或授權事宜。
H. 怎樣用PowerBuilder開發WEB應用
1powerbuilder中的web應用模塊
powerbuilder中含有開發web應用的模塊，通過這些模塊可以連接web伺服器與powerbuilder應用．該模塊包括以下及部分,web.pb:是幾個可以在web伺服器上執行的程序，被伺服器激活後，調用powerbuilder應用，完成客戶端任務和對資料庫的事務操作．plug_ins（插入件）：包括window plug_in和datawindow plug_in，此方式可將powerbuilder對象嵌入到頁面中，在瀏覽器端執行powerbuilder應用．window activex:此方式與window plug_in類似, 所不同在於該方式可以和html中的javascripts,vbscripts交互．本文主要討論利用web.pb開發web應用．
2用web.pb開發web應用
web.pb本身就是個cgi程序，它提供了從伺服器到powerbuilder應用的訪問．所以在web.pb之上，可以利用powerbuilder的強大功能開發復雜的web應用，如採用powerbuilder的powerscripts語言環境，數據窗口技
術等．powerbuilder的web應用構建前提是分布式應用體系．powerbuilder的客戶端應用分布到web伺服器上，可將web.pb看
作為客戶端應用．當客戶端應用web.pb被web伺服器激活後，調用powerbuilder的伺服器應用，執行在伺服器應用中定義的方法，實現業務邏
輯.
這種模式是真正的「廋」客戶機模式，客戶端不需要安裝其它軟體，只安裝瀏覽器軟體．所有的事務操作都在伺服器端完成，下面將結合實例詳細說明：
利
用powerbuilder開發一個網上購書應用．對於分布式powerbuilder應用，首先應向客戶web.pb指明powerbuilder服務
器應用在網路上的位置（location），其應用名，使用文件pbweb.ini來記錄伺服器應用信息．在此例中，取伺服器應用名為tutorial,
driver=winsock, application=10099/tcp, location=localhost.
建一個資料庫（book_dealing）其中有三個表，分別為：
「 book」： b_name， b_no， b_publisher， b_price，b_num
「customer」： c_name， c_tel，c_addr
「dealing」： b_name， c_name， d_num, d_time
建一個數據窗口dw_book，其sql語法為：
select 「book」.」b_name」,
「book」.」b_no」,
「book」.」b_publisher」,
「book」.」b_price」,
「book」.」b_num」
from 「book」
創建pb伺服器應用的用戶界面。在窗口w_server上有兩個按鈕cb_1,cb_2，再定義一個transport類型的實例變數mytransport，cb_1的clicked事件有關程序如下：
..........
mytransport = create transport
mytransport .driver = 「winsock」
mytransport.location = 「localhost」
mytransport.application = 「10099」
.........
創建一個不可視的用戶對象u_internet，定義一個transaction類型的全局變數mytransaction，在該用戶對象的constructor事件中定義連接到資料庫(book_dealing)的事務對象mytransaction和連接到資料庫(webpb)的事務對象sqlca，在該對象的destructor事件中分別取消這兩個事務對象。
在u_internet上定義兩個函數分別為f_book, f_book_dealing，這兩個函數的返回值都為字元類型。在f_book中，利用數據窗口dw_book作資料庫查詢，再利用數據窗口的屬性將查詢結果以html形式返回給web.pb，有關程序如下：
string return_html
datastore dd
dd = create datastore
dd.dataobject = 」dw_book」
dd.settransobject(mytransaction)
dd.retrieve()
.... .
return_html=return_html+dd.object.datawindow.data.htmltable
......
return return_html
在
函數f_dealing中，定義參數分別為：book_name, deal_num, custom_name, deal_time,
custom_tel,
custom_addr，用來接受form元素傳來的信息。再利用powerscripts語言對資料庫（book_dealing）進行修改。有關程序
如下：
string return_html
…………
connection using mytransaction;
insert into 「customer」
(「c_name」,
「c_tel」,
「c_addr」)
values( :custom_name, :custom_tel, :custom_addr);
insert into 「dealing」
(「b_name」,
」d_num」,
」d_time」,
」c_name」)
value(:book_name, :deal_num, :deal_time, :custom_name);
if mytransaction.sqlcacode>0 then
return_html=」定貨成功！」
else
return_html=」定貨失敗！」
endif
………..
return return_html
主頁上的「瀏覽書庫」的超連接為：
〈a herf=」/scripts/pbcgi60.exe/tutorial/u_internet/f_book」〉 瀏覽書庫</a>
定書信息頁上應有幾個單行編輯器,用來錄入用戶購書信息(例如:書名,用戶名,購書數量.,等等)其form元素的action為：
<form action= 「/scripts/pbcgi60.exe/tutorial/u_internet/f_book_dealing」method= 「get」>
以上程序可實現簡單的網上購書的功能，既用戶可瀏覽書庫，也可訂購所需的圖書。
I. java消息推送，一個實時數據的web顯示該怎麼做
javaweb消息實時推送可以使用GoEasy平台。
操作如下：
到goeasy官網上注冊一個賬號，並創建一個應用，應用創建好後系統會默認為它生成兩個key: publish key和subscribe key。
前台實時訂閱及接收：需要引入goeasy.js,然後調用goeasy的subscribe方法訂閱一個channel即可，訂閱時無論是用publish key還是subscribe key都可以。通過subscribe的參數 onMessage的回調函數可以實時接收到消息。
前台實時推送：需要引入goeasy.js（如果該頁面已經引入了可不在引入）,然後調用goeasy的publish方法向已訂閱的channel上推送消息即可，推送時只能用publish key。
後台實時推送：調用GoEasy Restful API， 用post方式訪問http://goeasy.io/goeasy/publish， 同時還需要帶上三個必要參數：
appkey: publish key
channel: 你訂閱了的channel
content: 推送內容
GoEasy的實現原理很簡單，就是推送消息的一端只負責推送，而需要接收的頁面需要預先訂閱。訂閱什麼呢？訂閱channel。往 某個channel上推送消息，客戶端就訂閱相同的channel,這樣就可以確保准確接收。通過channel我們可以自己指定哪些頁面或哪些用戶可以 接收到從這個channel上推送出來的消息。
J. 什麼是實時web應用
Meteor、Derby號稱新一代Web應用框架，可用來構建實時Web應用。這些框架由JavaScript編寫而成，開發者不必在客戶端和伺服器端分別編寫相同的邏輯程序。將JavaScript作為伺服器端編程語言，其好處在於可使數據架構和邏輯程序在前後端共享，而不必用兩種不同的語言再分別寫一遍。
這兩種新的框架也可實現資料庫的自動同步。換言之，伺服器和所有相連的客戶端可同時自動復制伺服器上的部分和全部信息。自動同步資料庫信息，可幫助你快速實現實時Web應用。