① 如何構建高可用的分布式系統
開源軟體已經成為許多大型網站的基本組成部分，隨著這些網站的逐步壯大，他們的網站架構和一些指導原則也出現在開發者們的面前，給予切實有用的指導和幫助。本文旨在介紹一些核心問題以及通過構建模塊來製作大型網站，實現最終目標。 這篇文章主要側重於Web系統，並且也適用於其他分布式系統。 Web分布式系統設計的原則 構建並運營一個可伸縮的Web站點或應用程序到底指的是什麼?在最初，僅是通過互聯網連接用戶和訪問遠程資源。 和大多數事情一樣，當構建一個Web服務時，需要提前抽出時間進行規劃。了解大型網站創建背後的注意事項以及權衡可能會給你帶來更加明智的決策，當你在創建小網站時。下面是設計大型Web系統時，需要注意的一些核心原則： 1.可用性 2.性能 3.可靠性 4.可擴展 5.易管理 6.成本 上面的這些原則給設計分布式Web架構提供了一定的基礎和理論指導。然而，它們也可能彼此相左，例如實現這個目標的代價是犧牲成本。一個簡單的例子：選擇地址容量，僅通過添加更多的伺服器(可伸縮性)，這個可能以易管理(你不得不操作額外的伺服器)和成本作為代價(伺服器價格)。 無論你想設計哪種類型的Web應用程序，這些原則都是非常重要的，甚至這些原則之間也會互相羈絆，做好它們之間的權衡也非常重要。 基礎 當涉及到系統架構問題時，這幾件事情是必須要考慮清楚的：什麼樣的模塊比較合適?如何把它們組合在一起?如何進行恰當地權衡?在擴大投資之前，它通常需要的並不是一個精明的商業命題，然而，一些深謀遠慮的設計可以幫你在未來節省大量的時間和資源。 討論的重點幾乎是構建所有大型Web應用程序的核心：服務、冗餘、分區和故障處理能力。這里的每個因素都會涉及到選擇和妥協，特別是前面所討論的那些原則。解釋這些核心的最佳辦法就是舉例子。 圖片託管應用程序 有時，你會在線上傳圖片，而一些大型網站需要託管和傳送大量的圖片，這對於構建一個具有成本效益、高可用性並具有低延時(快速檢索)的架構是一項挑戰。 在一個圖片系統中，用戶可以上傳圖片到一個中央伺服器里，通過網路連接或API對這些圖片進行請求，就像Flickr或者Picasa。簡單點，我們就假設這個應用程序只包含兩個核心部分：上傳(寫)圖片和檢索圖片。圖片上傳時最好能夠做到高效，傳輸速度也是我們最關心的，當有人向圖片發出請求時(例如是一個Web頁面或其他應用程序)。這是非常相似的功能，提供Web服務或內容分發網路(一個CDN伺服器可以在許多地方存儲內容，所以無論是在地理上還是物理上都更加接近用戶，從而導致更快的性能)邊緣伺服器。 該系統需要考慮的其他重要方面： 1.圖片存儲的數量是沒有限制的，所以存儲應具備可伸縮，另外圖片計算也需要考慮 2.下載/請求需要做到低延遲 3.用戶上傳一張圖片，那麼圖片就應該始終在那裡(圖片數據的可靠性) 4.系統應該易於維護(易管理) 5.由於圖片託管不會有太高的利潤空間，所以系統需要具備成本效益 圖1是個簡化的功能圖 圖1 圖片託管系統的簡化結構圖 在這個例子中，系統必須具備快速、數據存儲必須做到可靠和高度可擴展。構建一個小型的應用程序就微不足道了，一台伺服器即可實現託管。如果這樣，這篇文章就毫無興趣和吸引力了。假設我們要做的應用程序會逐漸成長成Flickr那麼大。 服務 當我們考慮構建可伸縮的系統時，它應有助於解耦功能，系統的每個部分都可以作為自己的服務並且擁有清晰的介面定義。在實踐中，這種系統設計被稱作面向服務的體系結構(SOA)。對於此類系統，每個服務都有它自己的獨特功能，通過一個抽象介面可以與外面的任何內容進行互動，通常是面向公眾的另一個服務 API。 把系統分解成一組互補性的服務，在互相解耦這些操作塊。這種抽象有助於在服務、基本環境和消費者服務之間建立非常清晰的關系。這種分解可以有效地隔離問題，每個塊也可以互相伸縮。這種面向服務的系統設計與面向對象設計非常相似。 在我們的例子中，所有上傳和檢索請求都在同一台伺服器上處理。然而，因為系統需要具備可伸縮性，所以把這兩個功能打破並集成到自己的服務中是有意義的。 快進並假設服務正在大量使用;在這種情況下，很容易看到寫圖片的時間對讀圖片時間有多大影響(他們兩個功能在彼此競爭共享資源)。根據各自體系，這種影響會是巨大的。即使上傳和下載速度相同(這是不可能的，對於大多數的IP網路來說，下載速度：上傳速度至少是3:1)，通常，文件可以從緩存中讀取，而寫入，最終是寫到磁碟中(也許在最終一致的情況下，可以被多寫幾次)。即使是從緩存或者磁碟(類似SSD)中讀取，數據寫入都會比讀慢(Pole Position，一個開源DB基準的開源工具和結果)。 這種設計的另一個潛在問題是像Apache或者Lighttpd這些Web伺服器通常都會有一個並發連接數上限(默認是500，但也可以更多)，這可能會花費高流量，寫可能會迅速消掉所有。既然讀可以非同步或利用其他性能優化，比如gzip壓縮或分塊傳輸代碼，Web服務可以快速切換讀取和客戶端來服務於更多的請求，超過每秒的最大連接數(Apache的最大連接數設置為500，這種情況並不常見，每秒可以服務幾千個讀取請求)。另一方面，寫通常傾向於保持一個開放的鏈接進行持續上傳，所以，使用家庭網路上傳一個1 MB的文件花費的時間可能會超過1秒，所以，這樣的伺服器只能同時滿足500個寫請求。 圖2：讀取分離 規劃這種瓶頸的一個非常好的做法是把讀和寫進行分離，如圖2所示。這樣我們就可以對它們單獨進行擴展(一直以來讀都比寫多)但也有助於弄明白每個點的意思。這種分離更易於排除故障和解決規模方面問題，如慢讀。 這種方法的優點就是我們能夠彼此獨立解決問題——在同種情況下，無需寫入和檢索操作。這兩種服務仍然利用全球語料庫的圖像，但是他們可以自由地優化性能和服務方法(例如排隊請求或者緩存流行圖片——下面會介紹更多)。從維護和成本角度來看，每一個服務都可以根據需要獨立進行擴展，但如果把它們進行合並或交織在一起，那麼有可能無意中就會對另一個性能產生影響，如上面討論的情景。 當然，如果你有兩個不同的端點，上面的例子可能會運行的很好(事實上，這非常類似於幾個雲存儲供應商之間的實現和內容分發網路)。雖然有很多種方法可以解決這些瓶頸，但每個人都會有不同的權衡，所以採用適合你的方法才是最重要的。 例如，Flickr解決這個讀/寫問題是通過分發用戶跨越不同的碎片，每個碎片只能處理一組用戶，但是隨著用戶數的增加，更多的碎片也會相應的添加到群集里(請參閱Flickr的擴展介紹)。在第一個例子中，它更容易基於硬體的實際用量進行擴展(在整個系統中的讀/寫數量)，而Flickr是基於其用戶群進行擴展(but forces the assumption of equal usage across users so there can be extra capacity)。而前面的那個例子，任何一個中斷或者問題都會降低整個系統功能(例如任何人都沒辦法執行寫操作)，而Flickr的一個中斷只會影響到其所在碎片的用戶數。在第一個例子中，它更容易通過整個數據集進行操作——例如，更新寫服務，包括新的元數據或者通過所有的圖片元數據進行搜索——而 Flickr架構的每個碎片都需要被更新或搜索(或者需要創建一個搜索服務來收集元數據——事實上，他們就是這樣做的)。 當談到這些系統時，其實並沒有非常正確的答案，但有助於我們回到文章開始處的原則上看問題。確定系統需求(大量的讀或寫或者兩個都進行、級別並發、跨數據查詢、范圍、種類等等)，選擇不同的基準、理解系統是如何出錯的並且對以後的故障發生情況做些扎實的計劃。 冗餘 為了可以正確處理錯誤，一個Web架構的服務和數據必須具備適當的冗餘。例如，如果只有一個副本文件存儲在這台單獨的伺服器上，那麼如果這台伺服器出現問題或丟失，那麼該文件也隨即一起丟失。丟失數據並不是什麼好事情，避免數據丟失的常用方法就是多創建幾個文件或副本或冗餘。 同樣也適用於伺服器。如果一個應用程序有個核心功能，應確保有多個副本或版本在同時運行，這樣可以避免單節點失敗。 在系統中創建冗餘，當系統發生危機時，如果需要，可以消除單點故障並提供備份或備用功能。例如，這里有兩個相同的服務示例在生產環境中運行，如果其中一個發生故障或者降低，那麼該系統容錯轉移至那個健康的副本上。容錯轉移可以自動發生也可以手動干預。 服務冗餘的另一重要組成部分是創建一個無共享架構。在這種體系結構中，每個節點都能相互獨立運行，並且沒有所謂的中央“大腦”管理狀態或協調活動其他節點。這對系統的可擴展幫助很大，因為新節點在沒有特殊要求或知識的前提下被添加。然而，最重要的是，這些系統是沒有單點故障的，所以失敗的彈性就更大。 例如在我們的圖片伺服器應用程序中，所有的圖片在另一個硬體上都有冗餘副本(理想情況下是在不同的地理位置，避免在數據中心發生一些火災、地震等自然事故)，服務去訪問圖片將被冗餘，所有潛在的服務請求。(參見圖3：採用負載均衡是實現這點的最好方法，在下面還會介紹更多方法) 圖3 圖片託管應用程序冗餘 分區 數據集有可能非常大，無法安裝在一台伺服器上。也有可能這樣，某操作需要太多的計算資源、性能降低並且有必要增加容量。在這兩種情況下，你有兩種選擇：縱向擴展或橫向擴展。 縱向擴展意味著在單個伺服器上添加更多的資源。所以，對於一個非常大的數據集來說，這可能意味著添加更多(或更大)的硬體設備，來使一台伺服器能容下整個數據集。在計算操作下，這可能意味著移動計算到一個更大的伺服器上，擁有更快的CPU或更大的內存。在各種情況下，縱向擴展可以通過提升單個資源的處理能力來完成。 橫向擴展在另一方面是添加更多的節點，在大數據集下，這可能會使用第二伺服器來存儲部分數據集，對於計算資源來說，這意味著分割操作或跨節點載入。為了充分利用橫向擴展，它應作為一種內在的系統架構設計原則，否則修改或拆分操作將會非常麻煩。 當談到橫向擴展時，最常見的做法是把服務進行分區或碎片。分區可以被派發，這樣每個邏輯組的功能就是獨立的。可以通過地理界限或其他標准，如非付費與付費用戶來完成分區。這些方案的優點是他們會隨著容量的增加提供一個服務或數據存儲。 在我們的圖片伺服器案例中，用來存儲圖片的單個文件伺服器可能被多個文件伺服器取代，每個裡面都會包含一套自己獨特的圖像。(見圖4)這種架構將允許系統來填充每一個文件/圖片伺服器，當磁碟填滿時會添加額外的伺服器。這樣的設計需要一個命名方案，用來捆綁圖片文件名到其相應的伺服器上。圖像名字可以形成一個一致的哈希方案並映射到整個伺服器上;或者給每張圖片分配一個增量ID，當客戶端對圖片發出請求時，圖片檢索服務只需要檢索映射到每個伺服器上(例如索引)的ID。 圖4 圖片託管應用程序冗餘和分區 當然，跨越多個伺服器對數據或功能進行分區還是有許多挑戰的。其中的關鍵問題是數據本地化。在分布式系統中，數據操作或計算點越接近，系統性能就會越好。因此，它也可能是個潛在問題，當數據分散在多個伺服器上時。有時數據不是在本地，那麼就要迫使伺服器通過網路來獲取所需的信息，這個獲取的過程就會設計到成本。 另一潛在問題是不一致。當這里有多個服務對一個共享資源執行讀寫操作時，潛在可能會有另一個伺服器或數據存儲參與進來，作為競選條件——一些數據需要更新，但是讀的優先順序高於更新——在這種情況下，數據就是不一致的。例如在圖片託管方案中，有可能出現的不一致是：如果一個客戶端發送更新“狗”圖片請求，進行重新命名，把“Dog”改成“Gizmo”，但同時，另一個客戶端正在讀這張圖片。在這種情況下，標題就是不清楚的。“Dog”或“Gizmo” 應該被第二個客戶端接收。 當然，在進行數據分區時會產生一些障礙，但是分區允許把每個問題拆分到管理群里——通過數據、負載、使用模式等。這樣對可擴展和易管理都是有幫助的，但也不是沒有風險的。這里有很多方式來降低風險和故障處理;然而，為了簡便起見，並未在本文中詳細說明，如果你有興趣，可以訪問我的博客。 總結 以上介紹的都是設計分布式系統需要考慮的核心要素。可用性、性能、可靠性、可擴展、易管理、成本這幾個原則非常重要，但在實際應用中可能會以犧牲某個原則來實現另外一個原則，在這個過程中就要做好權衡工作，做到因時制宜。 在下面的構建分布式系統實戰中，我們將會深入介紹如何設計可擴展的數據訪問，包括負載均衡、代理、全局緩存、分布式緩存等。 英文地址：Dr.Dobb's 文：CSDN
② web後台框架包括哪些
給大家總結介紹主流的web後端開發框架。一、Laravel
當我們談到後端web開發框架時，laravel會出現在前面。自2011年成立以來，Laravel為開發者展示了一條光明的道路。Laravel是一個免費的開源PHP web框架，旨在按照模型-視圖-控制器(MVC)架構模式構建最先進的web應用程序。
Laravel的一些特性是具有專用依賴管理器的模塊化打包系統、有助於應用程序部署和維護的實用工具、訪問關系資料庫的許多方法，以及它面向語法的方向。這就是為什麼它被認為是最好的PHP框架，並促使企業為他們的下一個項目僱傭Laravel開發人員的原因。
二、ThinkPHP
ThinkPHP是一個快速、兼容而且簡單的輕量級國產PHP開發框架，誕生於2006年初，原名FCS，2007年元旦正式更名為ThinkPHP，遵循Apache2開源協議發布，從Struts結構移植過來並做了改進和完善，同時也借鑒了國外很多優秀的框架和模式，使用面向對象的開發結構和MVC模式，融合了Struts的思想和TagLib（標簽庫）、RoR的ORM映射和ActiveRecord模式。
ThinkPHP可以支持windows/Unix/Linux等伺服器環境，正式版需要PHP5.0以上版本支持，支持MySql、PgSQL、Sqlite多種資料庫以及PDO擴展，ThinkPHP框架本身沒有什麼特別模塊要求，具體的應用系統運行環境要求視開發所涉及的模塊。
三、Yii
Yii與Asp.net非常相似，也是PHP中非常出色的開源web開發框架之一。Yii框架最適合為需要執行重復任務的系統開發應用程序。這個web開發框架具有內置的基於組件的模型、資料庫抽象層、事件驅動的編程特性和模塊化應用程序體系結構。Yii編碼器遵循快速應用開發(RAD)。
換句話說，Yii允許您在非常短的時間內啟動和運行web應用程序。此外，使用Yii框架，您還可以方便地根據不斷變化的業務需求定製應用程序。使用簡單的數據遷移實用程序，您可以方便地在不同的安裝上升級/降級應用程序版本。因此，您也可以考慮為您的web開發項目僱傭Yii開發人員。
四、Symfony
symfony是一個PHP框架，非常適合大型或復雜的企業級項目。這是一個非常穩定的框架。Symfony 3.1(當前版本)幫助全棧開發人員創建可伸縮的網站，以靈活地更改業務需求。
Symfony可以使用一些最大的開源平台，如PHPBB、Piwik和Drupal。Symfony由一組PHP組件、一個應用程序框架、一個社區和一種哲學組成，所有這些組件協同工作，幫助實現web上的一個共同目標。這些原因使得Symfony成為web開發的高級框架。
五、CakePHP
cakephpCakePHP是一個用PHP編寫的開源web開發框架，從一開始就在市場上非常流行。它基於模型-控制器-視圖和關聯數據映射的概念。通過使用CakePHP, processionals可以輕松地以結構化和快速的方式開發web應用程序。使用CakePHP的最大優勢之一是它提供了詳細的文檔和實用指南，以及非常容易編寫代碼的框架。
因此，開發人員可以使用這個框架輕松地創建web應用程序。如果您選擇這個框架進行開發，那麼通過編寫相對較少的代碼，您將能夠實現更多的功能。您甚至可以通過這個框架重用舊項目的代碼，從而使CakePHP web應用程序開發速度更快。
③ Java EE主要是用來做網站/Web應用的嗎
是的
Java EE（Java Platform，Enterprise Edition）是sun公司（2009年4月20日甲骨文將其收購）推出的企業級應用程序版本。這個版本以前稱為 J2EE。能夠幫助我們開發和部署可移植、健壯、可伸縮且安全的伺服器端 Java應用程序。Java EE 是在 Java SE 的基礎上構建的，它提供Web 服務、組件模型、管理和通信 API，可以用來實現企業級的面向服務體系結構（service-oriented architecture，SOA）和 Web 2.0應用程序。
Java，是由Sun Microsystems公司於1995年5月推出的Java程序設計語言和Java平台的總稱。用Java實現的HotJava瀏覽器（支持Java applet）顯示了Java的魅力：跨平台、動態的Web、Internet計算。從此，Java被廣泛接受並推動了Web的迅速發展，常用的瀏覽器現在均支持Java applet。
④ 如何構建可伸縮和可用的雲計算多租戶架構
雲計算到目前為止架構主要可分為四層，
首先：顯示層，多數據中心雲計算架構這層主要是用於以友好的方式展現用戶所需的內容，並會利用到下面中間件層提供的多種服務，主要有五種技術：
HTML：標準的Web頁面技術，現在主要以HTML4為主，但是將要推出的HTML5會在很多方面推動Web頁面的發展，比如視頻[1]和本地存儲等方面。
JavaScript：一種用於Web頁面的動態語言，通過JavaScript，能夠極大地豐富Web頁面的功能。
CSS：主要用於控制Web頁面的外觀，而且能使頁面的內容與其表現形式之間進行優雅地分離。
Flash[2]：業界最常用的RIA(Rich Internet Applications)技術，能夠在現階段提供HTML等技術所無法提供的基於Web的富應用，而且在用戶體驗[3]方面，非常不錯。
Silverlight：來自業界巨擎微軟[4]的RIA技術，雖然其現在市場佔有率稍遜於Flash，但由於其可以使用C#[5]來進行編程，所以對開發者非常友好。
其次：中間層這層是承上啟下的，它在下面的基礎設施層所提供資源的基礎上提供了多種服務，比如緩存服務和REST服務等，而且這些服務即可用於支撐顯示層，也可以直接讓戶調用，並主要有五種技術；
REST：通過REST技術，能夠非常方便和優雅地將中間件層所支撐的部分服務提供給調用者。
多租戶：就是能讓一個單獨的應用實例可以為多個組織服務，而且保持良好的隔離性和安全性，並且通過這種技術，能有效地降低應用的購置和維護成本。
並行處理：為了處理海量的數據，需要利用龐大的X86集群進行規模巨大的並行處理，Google的MapRece是這方面的代表之作。
應用伺服器：在原有的應用伺服器的基礎上為雲計算做了一定程度的優化，比如用於Google App Engine的Jetty應用伺服器。
分布式緩存：通過分布式緩存技術，不僅能有效地降低對後台伺服器的壓力，而且還能加快相應的反應速度，最著名的分布式緩存例子莫過於Memcached。
⑤ web應用系統開發
1.漸進式Web應用程序（PWA）
通過利用技術進步參與開發移動站點和本機應用程序的企業可以從漸進式Web應用程序中受益。到目前為止，這是2019年最熱門的Web開發趨勢。它鼓勵萬維網為用戶提供更好的瀏覽體驗。
漸進式Web應用程序是一般的Web應用程序，在用戶看來像移動應用程序，但實際上它們是行為類似於移動應用程序的網頁和網站。PWA致力於為所有設備上所有平台的用戶提供類似本機的體驗。
根據最近的一項研究，就互聯網使用和網站瀏覽而言，移動技術在其他設備上占據主導地位。不僅如此，使用移動應用程序和移動瀏覽器之間的差距還很大。可以估算一下，我們可以說移動應用程序佔用戶在其小工具上花費的總時間的70％以上。
實施PWA的一些知名公司包括阿里巴巴，Twitter，維珍美國航空，福布斯等。使用PWA的顯著優勢是，您的品牌對於具有更強身份的受眾更加可見。PWA中使用的流行技術是Angular，Polymer和React。
2.人工智慧與機器人
如您所知，企業跨不同時區工作並在各個大洲提供代表，這使得客戶支持服務既復雜又昂貴，尤其是考慮到24x7模式時。但是，隨著最近的發展，企業已轉向自動化的即時客戶端支持。
你們大多數人可能已經發現，聊天機器人可以使用人工智慧和機器學習的概念。在未來的幾年中，聊天機器人和機器學習的概念將比以往更加全面，尤其是對於Web設計和開發行業。
有多項調查表明，聊天機器人用於為客戶查詢提供快速響應和解決方案。AI執行人類的認知功能，例如學習，分析信息，收集數據，理解情緒以及解決具有挑戰性的問題的能力，這使聊天機器人成為Web開發的完美補充。
Facebook，Microsoft，Twitter，Google和Amazon等主要供應商都在人工智慧以及機器學習方面進行了大量投資。以下可用於為您的網站構建機器人的技術包括Facebook Bot Engine，Microsoft Bot Framework和Dialog flow。
3.加速的移動頁面（AMP）
Google不斷採用新技術來改善用戶的移動瀏覽體驗。Google在2015年向公眾推出了加速的移動頁面項目，該項目現已發展成為自己的新技術。
AWP的目的是減少網頁的載入時間或構建可在所有設備上快速載入且完美運行的網站。AMP頁面的載入時間被認為是兩秒鍾，而常規網頁可能需要長達22秒的載入時間。
與標准網頁相比，加速的網頁具有明顯的優勢，因為當您的網頁載入速度更快時，用戶將很高興瀏覽您的網站。此外，它將有助於提高您的Web應用程序的搜索引擎排名。
要將AMP技術引入您的網站，您將必須使用AMP HTML開放源代碼框架。Google首次提出這個概念時，就提供了有關如何構建AMP網頁的詳細文檔。
4.單頁申請
單頁應用程序完全基於JavaScript，是可在所有設備上正常運行的Web應用程序。它們不僅可以提高網站性能，還可以通過使用JavaScript載入所有內容來消除重新載入頁面的需要。
大多數公司使用單頁應用程序，因為與載入多頁相關的額外等待時間。誠然，與多頁Web應用程序相比，該頁面可能需要花費更多的時間來載入，但是，如果考慮到用戶在網站上的整個旅程的總時間，那麼放棄渲染多個頁面所節省的時間就變得很重要。這也使構建響應式網站變得更加容易。
SPA的示例包括Gmail，Facebook和GitHub。SPA中使用的技術包括React和Angular框架，使其成為混合應用程序的理想選擇。
5.語音搜索優化
語音搜索已經對Web開發產生了重大影響，使其成為2019年成功的趨勢之一，因此我們簡直不能忽略它。根據Gartner的報告，由於智能揚聲器的興起，到2020年，將有20％以上的搜索完成而無需在屏幕上鍵入任何內容。
即使在2019年，我們也會獲得帶有Google助手按鈕的設備，從而使用戶更輕松地在其設備上打開語音識別。因此，語音搜索在Web開發中達到頂峰還為時不遠。到2020年，我們可以假設英國的語音商務銷售額可以增長到50億美元，在美國達到400億美元。
考慮到多個研究報告和市場的實際情況，我們可以說語音搜索優化是不斷增長的Web開發趨勢之一，不容忽視。有可能，它將盡快成為您的SEO或技術策略的一部分。
要對您的站點實施語音搜索優化，可以使用Web搜索API，該API分為兩個部分-語音識別和語音合成。語音識別使您的網站能夠識別用戶的聲音，然後響應他們的查詢，而語音合成使腳本能夠讀取文本內容。
6.運動界面
Motion UI是為互動式Web設計提供動態圖形和動畫的東西。簡而言之，通過提供優雅的界面，即使使用簡約的網站，它也可以使您的Web應用程序設計與眾不同。而且，如果您進行適當的研究和實施，它可以為您的網站的轉化率帶來奇跡。
Motion UI是2019年最好的網路趨勢之一，因為它為您提供了一種吸引訪問者注意力的簡單解決方案。使用Motion UI庫，您可以合並動畫圖表，背景動畫，懸停和醒目的標題。
使用Motion UI元素不僅可以使您的網站脫穎而出，還可以通過鼓勵積極的用戶互動和改善網站可用性來增強用戶參與度。對於開發人員來說，這是一個額外的優勢，因為他們有多種選擇來製作功能強大的出色站點。
7.自動化測試
我們知道自動化測試已經存在了幾年，但是其中的最新創新使其再次進入了趨勢列表。從單元測試到Web應用程序的跨瀏覽器測試，Web開發測試中發生了許多變化。例如，以前您必須在系統上設置一個環境來執行Web應用程序的測試，但是現在不一樣了。
市場上提供了用於Web應用程序測試的多種擴展程序和API，使開發人員可以輕松地測試其網站。例如，Chrome，WordPress擴展程序和Screenshot API附帶的LambdaTest，使用戶無需編寫任何外部腳本即可測試其網頁。
最大，最受信任的自動化測試平台是LambdaTest，BrowserStack或跨瀏覽器測試，甚至一些大型企業都在使用它們。
8. JavaScript
JavaScript是最流行的編程語言之一，隨著時間的推移不斷發展，並為開發人員提供了新的功能。JavaScript的高級框架，設計和庫已經證明，它在市場上可以提供很多東西。
這就是為什麼它仍處於Web開發的十大趨勢之列的原因。曾經有一段時間人們因為JavaScript與某些瀏覽器不兼容而放棄使用JavaScript並改用純HTML和CSS。但是，隨著對JS的瀏覽器支持的趕超，越來越多的Web開發人員正在使用基於JS的框架和庫來構建其網站。
JavaScript用於開發動態Web應用程序。它為開發人員構建網站提供了靈活性，挑戰性和強大功能的全新體驗。藉助JavaScript，開發人員能夠構建精確，健壯和響應迅速的網站。使它在其他語言中脫穎而出的一些廣泛功能是回調和閉包。
不僅如此，基於JavaScript的框架和庫，尤其是Angular和React，為Web開發人員提供了更多功能。因此，可以說在未來幾年中，基於JavaScript的框架將推動Web開發。
9.區塊鏈技術
隨著整個2019年比特幣的流行，你們中的許多人可能已經對區塊鏈及其對整個Web開發行業的影響有所了解。
據信，到2020年，區塊鏈將給網路行業帶來根本性的變化。區塊鏈是一種開放式分布式賬本，以消除聯絡需求而提供安全和受保護的在線交易而聞名。它使用普通數據存儲來幫助個人將數據存儲在世界各地。
由於保護水平高，許多跨國銀行和組織都計劃投資於區塊鏈。此外，它還有助於降低金融業務成本，降低交易結算的頻率並改善由透明記錄支持的現金流。
10.物聯網
根據Statista的報告，相信2025年已連接設備的數量將超過300億。物聯網設備的巨大增長將直接影響Web開發，因為公司將從台式機或筆記本電腦控制此類設備。
物聯網將為企業帶來多種機遇，並使他們能夠以高精度提高效率。而且，為了向客戶提供更好的服務，將設備與網站集成已經變得至關重要。開發這些設備的不僅是開發人員，還包括開發人員。我們還將平等參與開發使用，分析和顯示設備數據的應用程序。
物聯網還將帶來很多挑戰，尤其是在數據安全方面，因此開發人員將面臨很多挑戰。盡管只有少數網站或Web應用程序正在使用IoT集成，但在未來幾天中，幾乎每個網站都將開始集成它以改善客戶體驗。
結論
Web開發是一個永遠不會淘汰的領域。實際上，隨著新技術的出現，它將隨著時間的推移不斷發展和變化。同樣，開發人員在使用這些技術方面也越來越先進，因為它允許他們以更好的方式構建應用程序或網站。
⑥ web伺服器
WEB伺服器
編輯本段什麼是WEB伺服器
WEB伺服器也稱為WWW(WORLD WIDE WEB)伺服器，主要功能是提供網上信息瀏覽服務。
(1)應用層使用HTTP協議。
(2)HTML文檔格式。
(3)瀏覽器統一資源定位器(URL)。
WWW代表萬維網的意思
WWW 是 Internet 的多媒體信息查詢工具，是 Internet 上近年才發展起來的服務，也是發展最快和目前用的最廣泛的服務。正是因為有了WWW工具，才使得近年來 Internet 迅速發展，且用戶數量飛速增長。
1、WWW簡介
WWW 是 World Wide Web （環球信息網）的縮寫，也可以簡稱為 Web，中文名字為「萬維網」。它起源於1989年3月，由歐洲量子物理實驗室 CERN（the European Laboratory for Particle Physics）所發展出來的主從結構分布式超媒體系統。通過萬維網，人們只要通過使用簡單的方法，就可以很迅速方便地取得豐富的信息資料。 由於用戶在通過 Web 瀏覽器訪問信息資源的過程中，無需再關心一些技術性的細節，而且界面非常友好，因而 Web 在Internet 上一推出就受到了熱烈的歡迎，走紅全球，並迅速得到了爆炸性的發展。
2、WWW的發展和特點
長期以來，人們只是通過傳統的媒體（如電視、報紙、雜志和廣播等）獲得信息。但隨著計算機網路的發展，人們想要獲取信息，已不再滿足於傳統媒體那種單方面傳輸和獲取的方式，而希望有一種主觀的選擇性。現在，網路上提供各種類別的資料庫系統，如文獻期刊、產業信息、氣象信息、論文檢索等等。由於計算機網路的發展，信息的獲取變得非常及時、迅速和便捷。
到了1993年，WWW 的技術有了突破性的進展，它解決了遠程信息服務中的文字顯示、數據連接以及圖像傳遞的問題，使得 WWW 成為 Internet 上最為流行的信息傳播方式。 現在，Web 伺服器成為 Internet 上最大的計算機群，Web 文檔之多、鏈接的網路之廣，令人難以想像。可以說，Web 為 Internet 的普及邁出了開創性的一步，是近年來 Internet 上取得的最激動人心的成就。
WWW 採用的是客戶/伺服器結構，其作用是整理和儲存各種WWW資源，並響應客戶端軟體的請求，把客戶所需的資源傳送到 Windows 95（或Windows98）、Windows NT、UNIX 或 Linux 等平台上。
使用最多的 web server 伺服器軟體 有兩個：微軟的信息伺服器（iis），和Apache。
通俗的講，Web伺服器傳送(serves)頁面使瀏覽器可以瀏覽，然而應用程序伺服器提供的是客戶端應用程序可以調用(call)的方法(methods)。確切一點，你可以說：Web伺服器專門處理HTTP請求(request)，但是應用程序伺服器是通過很多協議來為應用程序提供(serves)商業邏輯(business logic)。
Web伺服器可以解析(handles)HTTP協議。當Web伺服器接收到一個HTTP請求(request)，會返回一個HTTP響應(response)，例如送回一個HTML頁面。為了處理一個請求(request)，Web伺服器可以響應(response)一個靜態頁面或圖片，進行頁面跳轉(redirect)，或者把動態響應(dynamic response)的產生委託(delegate)給一些其它的程序例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本，伺服器端(server-side)JavaScript，或者一些其它的伺服器端(server-side)技術。無論它們(譯者註：腳本)的目的如何，這些伺服器端(server-side)的程序通常產生一個HTML的響應(response)來讓瀏覽器可以瀏覽。
要知道，Web伺服器的代理模型(delegation model)非常簡單。當一個請求(request)被送到Web伺服器里來時，它只單純的把請求(request)傳遞給可以很好的處理請求(request)的程序(譯者註：伺服器端腳本)。Web伺服器僅僅提供一個可以執行伺服器端(server-side)程序和返回(程序所產生的)響應(response)的環境，而不會超出職能范圍。伺服器端(server-side)程序通常具有事務處理(transaction processing)，資料庫連接(database connectivity)和消息(messaging)等功能。
雖然Web伺服器不支持事務處理或資料庫連接池，但它可以配置(employ)各種策略(strategies)來實現容錯性(fault tolerance)和可擴展性(scalability)，例如負載平衡(load balancing)，緩沖(caching)。集群特徵(clustering—features)經常被誤認為僅僅是應用程序伺服器專有的特徵。
應用程序伺服器(The Application Server)
根據我們的定義，作為應用程序伺服器，它通過各種協議，可以包括HTTP，把商業邏輯暴露給(expose)客戶端應用程序。Web伺服器主要是處理向瀏覽器發送HTML以供瀏覽，而應用程序伺服器提供訪問商業邏輯的途徑以供客戶端應用程序使用。應用程序使用此商業邏輯就象你調用對象的一個方法(或過程語言中的一個函數)一樣。
應用程序伺服器的客戶端(包含有圖形用戶界面(GUI)的)可能會運行在一台PC、一個Web伺服器或者甚至是其它的應用程序伺服器上。在應用程序伺服器與其客戶端之間來回穿梭(traveling)的信息不僅僅局限於簡單的顯示標記。相反，這種信息就是程序邏輯(program logic)。 正是由於這種邏輯取得了(takes)數據和方法調用(calls)的形式而不是靜態HTML，所以客戶端才可以隨心所欲的使用這種被暴露的商業邏輯。
在大多數情形下，應用程序伺服器是通過組件(component)的應用程序介面(API)把商業邏輯暴露(expose)(給客戶端應用程序)的，例如基於J2EE(Java 2 Platform, Enterprise Edition)應用程序伺服器的EJB(Enterprise JavaBean)組件模型。此外，應用程序伺服器可以管理自己的資源，例如看大門的工作(gate-keeping ties)包括安全(security)，事務處理(transaction processing)，資源池(resource pooling)， 和消息(messaging)。就象Web伺服器一樣，應用程序伺服器配置了多種可擴展(scalability)和容錯(fault tolerance)技術。
例如，設想一個在線商店(網站)提供實時定價(real-time pricing)和有效性(availability)信息。這個站點(site)很可能會提供一個表單(form)讓你來選擇產品。當你提交查詢(query)後，網站會進行查找(lookup)並把結果內嵌在HTML頁面中返回。網站可以有很多種方式來實現這種功能。我要介紹一個不使用應用程序伺服器的情景和一個使用應用程序伺服器的情景。觀察一下這兩中情景的不同會有助於你了解應用程序伺服器的功能。
情景1：不帶應用程序伺服器的Web伺服器
在此種情景下，一個Web伺服器獨立提供在線商店的功能。Web伺服器獲得你的請求(request)，然後發送給伺服器端(server-side)可以處理請求(request)的程序。此程序從資料庫或文本文件(flat file，譯者註：flat file是指沒有特殊格式的非二進制的文件，如properties和XML文件等)中查找定價信息。一旦找到，伺服器端(server-side)程序把結果信息表示成(formulate)HTML形式，最後Web伺服器把會它發送到你的Web瀏覽器。
簡而言之，Web伺服器只是簡單的通過響應(response)HTML頁面來處理HTTP請求(request)。
情景2：帶應用程序伺服器的Web伺服器
情景2和情景1相同的是Web伺服器還是把響應(response)的產生委託(delegates)給腳本(譯者註：伺服器端(server-side)程序)。然而，你可以把查找定價的商業邏輯(business logic)放到應用程序伺服器上。由於這種變化，此腳本只是簡單的調用應用程序伺服器的查找服務(lookup service)，而不是已經知道如何查找數據然後表示為(formulate)一個響應(response)。 這時當該腳本程序產生HTML響應(response)時就可以使用該服務的返回結果了。
在此情景中，應用程序伺服器提供(serves)了用於查詢產品的定價信息的商業邏輯。(伺服器的)這種功能(functionality)沒有指出有關顯示和客戶端如何使用此信息的細節，相反客戶端和應用程序伺服器只是來回傳送數據。當有客戶端調用應用程序伺服器的查找服務(lookup service)時，此服務只是簡單的查找並返回結果給客戶端。
通過從響應產生(response-generating)HTML的代碼中分離出來，在應用程序之中該定價(查找)邏輯的可重用性更強了。其他的客戶端，例如收款機，也可以調用同樣的服務(service)來作為一個店員給客戶結帳。相反，在情景1中的定價查找服務是不可重用的因為信息內嵌在HTML頁中了。
總而言之，在情景2的模型中，在Web伺服器通過回應HTML頁面來處理HTTP請求(request)，而應用程序伺服器則是通過處理定價和有效性(availability)請求(request)來提供應用程序邏輯的。
警告(Caveats)
現在，XML Web Services已經使應用程序伺服器和Web伺服器的界線混淆了。通過傳送一個XML有效載荷(payload)給伺服器，Web伺服器現在可以處理數據和響應(response)的能力與以前的應用程序伺服器同樣多了。
另外，現在大多數應用程序伺服器也包含了Web伺服器，這就意味著可以把Web伺服器當作是應用程序伺服器的一個子集(subset)。雖然應用程序伺服器包含了Web伺服器的功能，但是開發者很少把應用程序伺服器部署(deploy)成這種功能(capacity)(譯者註：這種功能是指既有應用程序伺服器的功能又有Web伺服器的功能)。相反，如果需要，他們通常會把Web伺服器獨立配置，和應用程序伺服器一前一後。這種功能的分離有助於提高性能(簡單的Web請求(request)就不會影響應用程序伺服器了)，分開配置(專門的Web伺服器，集群(clustering)等等)，而且給最佳產品的選取留有餘地。
編輯本段大型WEB伺服器
在UNIX和LINUX平台下使用最廣泛的免費HTTP伺服器是W3C、NCSA和APACHE伺服器，而Windows平台NT/2000/2003使用IIS的WEB伺服器。在選擇使用WEB伺服器應考慮的本身特性因素有：性能、安全性、日誌和統計、虛擬主機、代理伺服器、緩沖服務和集成應用程序等，下面介紹幾種常用的WEB伺服器。
Microsoft IIS
Microsoft的Web伺服器產品為Internet Information Server (IIS)， IIS 是允許在公共Intranet或Internet上發布信息的Web伺服器。IIS是目前最流行的Web伺服器產品之一，很多著名的網站都是建立在IIS的平台上。IIS提供了一個圖形界面的管理工具，稱為 Internet服務管理器，可用於監視配置和控制Internet服務。
IIS是一種Web服務組件，其中包括Web伺服器、FTP伺服器、NNTP伺服器和SMTP伺服器，分別用於網頁瀏覽、文件傳輸、新聞服務和郵件發送等方面，它使得在網路(包括互聯網和區域網)上發布信息成了一件很容易的事。它提供ISAPI(Intranet Server API)作為擴展Web伺服器功能的編程介面;同時，它還提供一個Internet資料庫連接器，可以實現對資料庫的查詢和更新。
IBM WebSphere
WebSphere Application Server 是 一 種功能完善、開放的Web應用程序伺服器，是IBM電子商務計劃的核心部分，它是基於 Java 的應用環境，用於建立、部署和管理 Internet 和 Intranet Web 應用程序。 這一整套產品進行了擴展，以適應 Web 應用程序伺服器的需要，范圍從簡單到高級直到企業級。
WebSphere 針對以 Web 為中心的開發人員，他們都是在基本 HTTP伺服器和 CGI 編程技術上成長起來的。IBM 將提供 WebSphere 產品系列，通過提供綜合資源、可重復使用的組件、功能強大並易於使用的工具、以及支持 HTTP 和 IIOP 通信的可伸縮運行時環境，來幫助這些用戶從簡單的 Web 應用程序轉移到電子商務世界。
BEA WebLogic
BEA WebLogic Server 是一種多功能、基於標準的web應用伺服器，為企業構建自己的應用提供了堅實的基礎。各種應用開發、部署所有關鍵性的任務，無論是集成各種系統和資料庫，還是提交服務、跨 Internet 協作，起始點都是 BEA WebLogic Server。由於 它具有全面的功能、對開放標準的遵從性、多層架構、支持基於組件的開發，基於 Internet 的企業都選擇它來開發、部署最佳的應用。
BEA WebLogic Server 在使應用伺服器成為企業應用架構的基礎方面繼續處於領先地位。BEA WebLogic Server 為構建集成化的企業級應用提供了穩固的基礎，它們以 Internet 的容量和速度，在連網的企業之間共享信息、提交服務，實現協作自動化。
APACHE
apache仍然是世界上用的最多的Web伺服器，市場佔有率達60%左右。它源於NCSAhttpd伺服器，當NCSA WWW伺服器項目停止後，那些使用NCSA WWW伺服器的人們開始交換用於此伺服器的補丁，這也是apache名稱的由來(pache 補丁)。世界上很多著名的網站都是Apache的產物，它的成功之處主要在於它的源代碼開放、有一支開放的開發隊伍、支持跨平台的應用(可以運行在幾乎所有的Unix、Windows、Linux系統平台上)以及它的可移植性等方面。
Tomcat
Tomcat是一個開放源代碼、運行servlet和JSP Web應用軟體的基於Java的Web應用軟體容器。Tomcat Server是根據servlet和JSP規范進行執行的，因此我們就可以說Tomcat Server也實行了Apache-Jakarta規范且比絕大多數商業應用軟體伺服器要好。
Tomcat是Java Servlet 2.2和JavaServer Pages 1.1技術的標准實現，是基於Apache許可證下開發的自由軟體。Tomcat是完全重寫的Servlet API 2.2和JSP 1.1兼容的Servlet/JSP容器。Tomcat使用了JServ的一些代碼，特別是Apache服務適配器。隨著Catalina Servlet引擎的出現，Tomcat第四版號的性能得到提升，使得它成為一個值得考慮的Servlet/JSP容器，因此目前許多WEB伺服器都是採用Tomcat。
編輯本段小型WEB伺服器
【 micro_httpd - really small HTTP server】
特點：
* 支持安全的 .. 上級目錄過濾
* 支持通用的MIME類型
* 支持簡單的目錄
* 支持目錄列表
* 支持使用 index.html 作為首頁
* Trailing-slash redirection
* 程序總共代碼才200多行
這個httpd適合學習簡單的Web Server編寫學習，因為它只有一個簡單的框架，只能夠處理簡單的靜態頁，可以考慮用來放靜態頁。
官方地址：http://www.acme.com/software/micro_httpd/
下載地址：http://www.acme.com/software/micro_httpd/micro_httpd_12dec2005.tar.gz
【 mini_httpd - small HTTP server 】
特點：
* 支持GET、HEAD、POST方法
* 支持CGI功能
* 支持基本的驗證功能
* 支持安全 .. 上級目錄功能
* 支持通用的MIME類型
* 支持目錄列表功能
* 支持使用 index.html, index.htm, index.cgi 作為首頁
* 支持多個根目錄的虛擬主機
* 支持標准日誌記錄
* 支持自定義錯誤頁
* Trailing-slash redirection
mini_httpd 也是相對比較適合學習使用，大體實現了一個Web Server的功能，支持靜態頁和CGI，能夠用來放置一些個人簡單的東西，不適宜投入生產使用。
官方地址：http://www.acme.com/software/thttpd/
下載地址：http://www.acme.com/software/mini_httpd/mini_httpd-1.19.tar.gz
【 thttpd - tiny/turbo/throttling HTTP server 】
thttpd中是一個簡單,小型,輕便,快速和安全的http伺服器.
簡單：它能夠支持HTTP/1.1協議標准，或者超過了最低水平
小巧：它具有非常少的運行時間，因為它不fork子進程來接受新請求，並且非常謹慎的分配內存（性能對比表：http://www.acme.com/software/thttpd/benchmarks.html）
便攜：它能夠在大部分的類Unix系統上運行，包括FreeBSD, SunOS 4, Solaris 2, BSD/OS, Linux, OSF等等
快速：它的速度要超過主流的Web伺服器（Apache, NCSA, Netscape），在高負載情況下，它要快的多
安全：它努力的保護主機不受到攻擊，不中斷伺服器
thttpd 類似於lighttpd，對於並發請求不使用fork()來派生子進程處理，而是採用多路復用(Multiplex)技術來實現。因此效能很好。同時它還有一個特點就是基於URL的文件流量限制，這對於下載的流量控制而言是非常方便的。象Apache就必須使用插件實現，效率較thttpd低。
thttpd跟lighttpd類似，適合靜態資源類的服務，比如圖片、資源文件、靜態HTML等等的應用，性能應該比較好，同時也適合簡單的CGI應用的場合。
官方地址：http://www.acme.com/software/thttpd/
下載地址：http://www.acme.com/software/thttpd/thttpd-2.25b.tar.gz
【 lighttpd - light footprint + httpd = LightTPD 】
Lighttpd是一個德國人領導的開源軟體，其根本的目的是提供一個專門針對高性能網站，安全、快速、兼容性好並且靈活的web server環境。具有非常低的內存開銷，cpu佔用率低，效能好，以及豐富的模塊等特點。
lighttpd 是眾多OpenSource輕量級的web server中較為優秀的一個。支持FastCGI, CGI, Auth, 輸出壓縮(output compress), URL重寫, Alias等重要功能，而Apache之所以流行，很大程度也是因為功能豐富，在lighttpd上很多功能都有相應的實現了，這點對於apache的用戶是非常重要的，因為遷移到lighttpd就必須面對這些問題。
實用起來lighttpd確實非常不錯，apache主要的問題是密集並發下，不斷的fork()和切換，以及較高（相對於 lighttpd而言）的內存佔用，使系統的資源幾盡枯竭。而lighttpd採用了Multiplex技術，代碼經過優化，體積非常小，資源佔用很低，而且反應速度相當快。
利用apache的rewrite技術，將繁重的cgi/fastcgi任務交給lighttpd來完成，充分利用兩者的優點，現在那台伺服器的負載下降了一個數量級，而且反應速度也提高了一個甚至是2個數量級！
lighttpd 適合靜態資源類的服務，比如圖片、資源文件、靜態HTML等等的應用，性能應該比較好，同時也適合簡單的CGI應用的場合。
官方地址：http://www.lighttpd.net/
下載地址：http://www.lighttpd.net/download/lighttpd-1.4.16.tar.gz
【 SHTTPD - Simple HTTPD 】
Shttpd是另一個輕量級的web server，具有比thttpd更豐富的功能特性，支持CGI, SSL, cookie, MD5認證, 還能嵌入(embedded)到現有的軟體里。最有意思的是不需要配置文件！ 由於shttpd可以嵌入其他軟體，因此可以非常容易的開發嵌入式系統的web server，官方網站上稱shttpd如果使用uclibc/dielibc(libc的簡化子集)則開銷將非常非常低。
特點：
* 小巧、快速、不膨脹、無需安裝、簡單的40KB的exe文件，隨意運行
* 支持GET, POST, HEAD, PUT, DELETE 等方法
* 支持CGI, SSL, SSI, MD5驗證, resumed download, aliases, inetd模式運行
* 標准日誌格式
* 非常簡單整潔的嵌入式API
* dietlibc friendly. NOT that friendly to the uClibc (*)
* 容易定製運行在任意平台：Windows, QNX, RTEMS, UNIX (*BSD, Solaris, Linux)
由於shttpd可以輕松嵌入其他程序里，因此shttpd是較為理想的web server開發原形，開發人員可以基於shttpd開發出自己的webserver！
官方網站：http://shttpd.sourceforge.net/
下載地址：http://jaist.dl.sourceforge.net/sourceforge/shttpd/shttpd-1.38.tar.gz
⑦ 中軟國際有限公司的產品與服務
中軟國際在業界率先提出「總、分、總」的項目建設模式：是指大型應用系統的建設可以分為系統總體咨詢 / 設計、系統各分應用分別開發、系統總體集成三個階段。其中，系統總體咨詢 / 設計和系統總體集成以選擇同一家公司完成為佳，各應用系統開發可以選擇多家公司在遵循相關規范的條件下分別開發，最終統一集成。該模式已在國家金審工程（一期），國家煙草專賣局生產經營決策管理系統建設中得以成功實施。
利用在電子政務領域已被證明的優秀的產品集群能力及服務實施能力，積極拓展電子商務及行業集成領域，中軟國際能夠為企業的電子商務建設提供成熟的軟體產品和解決方案，幫助企業利用互聯網設計自己的電子商務運行模式；提供包括咨詢、設計、集成、開發、實施、測試、培訓、售後服務在內的一條龍服務。作為電子政務及電子商務領域的先導者，中軟國際核心戰略之一，是通過技術創新來開發新產品與新解決方案，依靠自身強大的研發能力保持和鞏固在業界的領先地位。貼進市場需求是中軟國際產品的顯著特點，產品研發的原動力來自於我們與客戶充分的溝通以及我們對市場需求的及時、深刻理解，嚴格的產品開發流程管理確保了產品能夠成分（充分）實現這種需求。中軟國際先後承擔了多項國家重點科技攻關項目，申請並獲得了 10 余項軟體著作權和專利技術，形成了一系列應用廣泛的軟體產品和全套系統解決方案。成功研發了以應用支撐平台產品 ResourceOne為核心的產品系列，形成了包括平台產品、工具產品、應用產品在內的成熟產品架構，充分利用成熟技術將降低招標方的項目開發成本和開發風險。ResourceOne 被 CCID 評定為 2002 -2006年度中國電子政務應用支撐平台產品第一品牌。
中國軟體以服務社會、振興自主軟體產業為己任，在國家信息化「金」字系列工程中發揮了重要作用。經過多年努力，中國軟體形成了較為完善的自主基礎軟體發展體系，打造了一個從操作系統、資料庫、中間件、安全產品到應用系統的產業發展鏈條；先後承擔了數千項國家重大工程項目，在全國稅務、信訪、安監、應急、政法、審計、煙草、交通、金融、物流、能源、工商等國民經濟重要領域擁有上萬家客戶群體；同時積極推動移動增值、智慧城市、軟體外包等新型服務業務的發展。時至今日，中國軟體已經成為國內領先的綜合IT服務提供商，擁有立足國內、輻射海外的三十餘家控參股公司和境內外分支機構，與眾多合作夥伴一起形成了龐大的客戶服務網路。
同時，中軟國際在自身產品體系基礎上，通過積極的策略聯盟合作關系，引進、集成第三方產品和技術，從而極大地豐富、完善我們的解決方案。先進的專業化管理模式為中軟國際開展業務提供管理保障，其管理結構的設計參考了國際上最新的 IT 行業管理體系，其項目管理採用了國際上最先進的軟體工程的技術，務求做到與客戶的充分溝通與業務組織的有序，形成了以項目管理為核心的客戶服務水平保障機制，確保企業站在客戶的角度，理解客戶需求，規劃解決方案，實施客戶服務，降低客戶風險。領先的項目管理能力成為中軟國際核心競爭力的重要方面。公司已通過 ISO質量體系認證，並正在進行 CMM 咨詢、過程改進及評估相關程序，並謀求 CMM3 資質。
典型客戶包括天津泰達經濟技術開發區、北京經濟技術開發區、哈爾濱開發區、廣州開發區、大連經濟技術開發區、審計署、交通部、農業部、民政部、國家煙草專賣局、中國聯通、中國網通、 IBM 、 HP 、 Motorola 等。 ResourceOne（簡稱R1）是基於構件及服務技術的開發、整合、項目工程化管理的支撐平台，是集支撐快速應用開發、應用整合及分發管理、業務流程式控制制及管理、信息集成交換及業務協同於一體的完整信息化支撐平台，於2008年發布的V4第四代創新產品線包括：多年來，中軟國際精準把握客戶需求，憑借自主研發的應用整合和業務支撐中間件產品ResourceOne，幫助用戶實現信息化工程建設全生命周期的最佳操控，並一向致力於實現企業級信息系統的業務應用創建支撐、集成、管理、運維服務及業務優化，並在製造業（煙草工業及整個行業）、零售業（煙草銷售）、電子政務工程（多個國家金字型大小工程、政府機關、經濟技術開發區）中都已有廣泛的應用和大量成功案例。ResourceOne平台產品在中軟國際多年的行業經驗和技術積累基礎上，從工程建設角度提供了項目開發、整合、管理三位一體的配套支撐環境，保障和提升大型軟體工程項目成功交付能力：
一、R1提供IT整合支撐的環境 1、以R1構件和服務模型為核心，提供支撐R1構件及服務的基礎架構； 2、以R1 DE-Integration為核心的R1交換集成平台，遵循面向服務的技術架構（SOA），提供更為豐富的企業級支撐能力，以及提供對整個企業IT系統服務消息處理調度中樞的能力； 3、R1 StarFlow業務流程管理平台，提供跨應用的業務服務協同和流程管理的能力，幫助客戶實現業務流程的集成； 4、R1 Portal/Framework集成門戶，基於構件技術，提供構件注冊、裝配功能和資產化管理能力，並提供各類Web應用系統的統一訪問集成，構建具有高度可伸縮性的企業級應用集成門戶 5、R1 Adapter Framework，提供統一的適配框架，幫助客戶實現對異構、遺留系統的連接集成。
二、R1提供快速開發業務應用的工具與支撐平台1、ResourceOne 提供以構件方式快速實現應用封裝與應用裝配管理的工具，通過實現應用及服務鬆散耦合集成，幫助客戶有效的管理、重組、更新應用和對新系統的再造；2、R1 StarFlow結合R1Studio提供快速定製開發流程化業務應用的能力，業務應用中的數據和服務可與R1 DE-I及其他企業服務匯流排進行交互；3、基於Eclipse的全生命周期集成化設計開發工具 R1 Studio，提供應用快速輔助開發及部署、R1工程資源管理、團隊協作、集成場景的可視化設計編排、調試、模擬等功能。
三、提供項目過程管理及質量控制環境ResourceOne是中軟國際基於平台進行項目開發與管理的基礎，並且在Studio中內置集成了對R1工程建設方法的多項支持。
ResourceOne DE-Integration
ResourceOne DE-Integration（簡稱R1 DE-I）是ResourceOne家族中提供面向服務（SOA）技術支撐能力的基礎設施，提供企業服務匯流排（ESB）所需的核心功能，同時完全兼容和保留傳統的企業應用集成(EAI），擁有強大的企業級的信息交換、應用及服務集成能力，是實現企業面向服務(SOA）的服務調度、交換中樞和業務協同的重要產品。R1 DE-I是集多種功能於一體的集成骨架，實現基於SOA的企業應用集成，連接器/適配器接入；擁有企業服務匯流排ESB的強大功能，支持各種通訊協議轉換、消息格式轉換以及服務中介調用，用於在異構服務與應用系統之間連接、調節和管理交互。
1) 以信息交互、數據共享為切入點，構建應用系統間的集成中樞，整合IT環境中信息共享與管理；
2) 扮演企業服務匯流排（ESB）的角色，提供IT環境中應用/服務間的服務 ，幫助用戶構建面向服務（SOA）的IT架構；
3) 靈活的伸縮性和適應性，可以實現跨地域的信息或服務交互；提供可靠的信息傳輸架構；幫助用戶實現全國、甚至全球范圍內的信息整合；
4) 整合IT環境中應用間的相互交互關系，增強可擴展性、可管理性，增強IT環境對業務的適應性。ResourceOne額外提供適配器框架產品ResourceOne AdapterFramework（簡稱 R1 AF），為R1適配器提供一個鬆散耦合、標准、穩定、易於擴展、具有良好可管理能力的運行環境，在R1 SOA架構中，實現應用系統間非侵入式交互、連接。
ResourceOne GlobalRepository
ResourceOne GlobalRepository（簡稱：R1 GLR）是ResourceOne SOA架構中存儲和管理R1整合資源的元數據管理系統，提供了企業級的Web服務及其它資源注冊、存儲、發現、檢索及調用等服務。提供對資源依賴關系的清晰可見，促進重用，並且提供了與第三方同類產品和R1Studio的集成能力。
1) 通過使用各種管理控制、降低風險以及提高投資回報率的方法，使機構能夠更輕松地轉變到面向服務的架構；
2) 通過對IT資產的持續控制、分析來確保SOA始終有效提供業務價值，為整個面向服務架構生命周期的治理提供了堅實基礎；
3) 通過展現IT資產的可視性統一視圖來促進復用、消除冗餘和優化使用，從而保護已有的IT投資的價值；
4) 除Webservice之外，還提供更豐富的IT資產的管理，如R1適配器，並且可以通過標準的介面訪問。
ResourceOne StarFlow
ResourceOne Starflow（簡稱：R1 StarFlow）是ResourceOne業務流程管理基礎平台，可支持快速流程化應用開發與部署獨立流程管理BPM伺服器，以業務流程為核心，將參與流程活動的人員、信息、數據等實現整合管理，提高業務流程、組織及IT架構的靈活性和敏捷性，可與R1 DE-I或第三方ESB產品集成，提供完整的基於SOA的BPM解決方案。
1) 提供全生命周期的業務流程管理；
2) 提供快速構建流程化業務應用的能力；
3) 「流程即服務」輕松實現基於SOA的BMP解決方案；
4) 完備的多層次的許可權控制體系。
ResourceOne Portal/Framework
ResourceOne Portal/Framework（簡稱R1 Portal/Framework）通過整合人員、業務應用和服務，其採用多種先進技術帶來前所未有的用戶體驗。
1) 「融合」的設計理念，融信息門戶和應用集成門戶於一體，快速集成不同資源，為用戶提供差異化服務與體驗；
2) 融入中軟國際多年行業項目經驗，為用戶提供即插即用的實用功能，幫助用戶有效解決系統建設中的問題；
3) 彈性靈活，能夠根據實際業務場景和變化快速定製優化，緊跟業務步伐。 ResourceOne Studio（簡稱：R1 Studio）是ResourceOne的統一設計開發工具平台，提供對項目整個交付生命周期的全面支持，包括工程資源與Team協作統一管理，快速應用構件設計開發，中介服務、信息交換、業務流程、數據主題、映射的可視化設計，流程調試及模擬模擬，快速部署及多國語言支持等，為集成商、開發商提供了一個快速而強大的工具環境。
1) 基於ResourceOne工程建設方法論，對項目的設計、開發、集成等各個階段提供支持，幫助設計人員、應用開發人員、系統集成人員、質量管理人員等從不同層面對項目進行開發與管理；
2) 結合中軟國際項目管理辦法（如QA規范制度），針對在項目開發過程中各階段，提供項目Review管理，實現對Review結果管理、Review協作溝通，保障軟體項目設計、開發質量；
3) 提供流程模板復用、表單模板復用、代碼段復用等復用機制，通過復用機制可以迅速開發設計應用組件，隨著項目可重用資源不斷提煉積累，能為新項目提供復用資源和快速解決方案，從而提高企業核心競爭力；
4) 提供以腦圖方式對原始需求進行功能分解的功能，能夠形成功能分解圖，根據功能分解圖，基於R1工程建設方法論進行應用構件切分、功能設計、應用角色設計、菜單項設計；支持基於R1應用開發框架進行面向MVC模式的J2EE應用開發。
⑧ 在什麼上提供了集成、可靠，可伸縮的web伺服器
在Internet上提供了。
Web伺服器一般指網站伺服器，是指駐留於網際網路上某種類型計算機的程序，可以向瀏覽器等Web客戶端提供文檔，也可以放置網站文件，讓全世界瀏覽。可以放置數據文件，讓全世界下載。目前最主流的三個Web伺服器是ApacheNginxIIS。
⑨ Microsoft SOAP Toolkit Version 3 的問題
使用 Microsoft SOAP Toolkit 2.0 建立安全 Web 服務
Kirill Gavrylyuk
測試組長，Web 數據 SOAP 組
Microsoft Corporation
2001年7月
摘要： Microsoft SOAP Toolkit 2.0 提供一個靈活的框架，可以為各種 Intranet 和 Internet 解決方案構建可伸縮的 Web 服務。在這兩種方案中，安全性都是建立可靠服務的重要因素。SOAP Toolkit 2.0 支持基於 IIS 安全基礎結構的 Internet 安全性。本文介紹了如何使用 Microsoft SOAP Toolkit 2.0 建立安全解決方案。
目錄
簡介
重要規則
身份驗證
代理支持和身份驗證
SSL 和客戶端證書
身份驗證問題
疑難解答
其它信息
簡介
與任何分布式協議相同，成功的 SOAP 應用程序的關鍵在於獲得安全性許可權。SOAP 標准不指定任何安全性機制，而是將安全處理委派給傳輸層。對 SOAP Toolkit 2.0 而言，傳輸層是 HTTP。在 HTTP 上運行的 SOAP 基本上是一個 Web 應用程序，與其它在 IIS 上運行的 ASP 或 ISAPI 應用程序很相似。SOAP 的身份驗證、授權和加密機制與您通常使用的 Web 應用程序完全相同。如果熟悉 Web 安全性，也就了解了 SOAP 安全性。如果對 Web 應用程序不夠熟悉，本文將為您提供充分的入門知識背景。每個主題都介紹的非常詳細。如果需要更詳細的信息，請參見 MSDN Library 或由 Michael Howard、Marc Levy 和 Richard Waymire 編著的《設計 Microsoft Windows 2000 基於 Web 的安全應用程序》。
重要規則
根據《設計 Microsoft Windows 2000 基於 Web 的安全應用程序》中闡述的觀點，我們首先從概述建立安全 Web 服務應遵守的重要規則開始。安全 Web 服務可歸納為以下七類：
身份驗證
授權
審核
保密
完整性
可用性
認可
身份驗證是一個實體（也稱為主題）驗證另一個實體是否符合它所聲稱的身份的過程。SOAP Toolkit 2.0 支持以下身份驗證方法：
基本
摘要式
Kerberos
Windows NTLM
SSL 客戶端證書
基於 SOAP 頭的身份驗證
代理身份驗證
本文檔介紹如何配置伺服器端和客戶端使用上述身份驗證方法。
授權是為經過身份驗證的用戶提供資源訪問許可權的機制。只要使用 SOAP Toolkit 建立的 Web 服務基於 IIS，這些服務就可以利用 IIS 支持的授權機制。本文檔也將講述用戶應注意的一些問題。
審核的目的是為了收集有關對 Web 服務的成功和失敗請求的信息。可以使用 IIS 審核功能和 SOAP Toolkit 跟蹤功能實現這一目的。本文檔沒有介紹這方面的內容，您可以參考 IIS 文檔、netmon 日誌和 SoapServer 對象的 SOAP Toolkit 幫助。
保密是指確保攻擊者看不到客戶端與伺服器之間的通信信息。完整性是指保護數據不被刪除或更改（不管是惡意還是不慎）的能力。為了實現保密和完整性，SOAP Toolkit 允許使用安全套接字層 (SSL) 加密數據。本文檔將介紹如何啟用 IIS 上的 SSL 支持以及如何將其用於客戶端。
可用性確保不會拒絕合法用戶對請求的資源的訪問。可用性技術的示例包括負載平衡以及硬體和軟體的故障轉移。SOAP Toolkit 已成功通過了 Microsoft Application Center 負載平衡軟體的測試。
認可是一種技術，為發生的操作提供證據以防止客戶端在事務處理中欺詐或否認。SOAP Toolkit 採用 IIS 提供的認可功能。本文檔不對認可進行介紹。
身份驗證
本節介紹了 SOAP Toolkit 支持的身份驗證方法，包括其優點和缺點，以及如何對其進行設置。還介紹了 SOAP Toolkit 在支持平台上的已知局限性，以及伺服器具有多個可用身份驗證方案時 SOAP Toolkit HTTP 連接器的行為。
身份驗證握手是如何進行的？每個身份驗證握手都是如下開始：
客戶端發出頁面請求。
伺服器返回狀態 401「拒絕訪問」和一組 HTTP 頭。
WWW 驗證它支持的每一個身份驗證方法。
如何使用 SoapClient 驗證自身？如果 Web 服務要求身份驗證（基本、摘要式、NTLM 或 Kerberos），需要為 SoapClient 提供用戶名和密碼，以將其傳遞到 Web 服務。也可以使用 SoapClient.ConnectorProperty 包完成此操作：
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://your-server/webservice/service.wsdl ")
SoapClient.ConnectorProperty("AuthName") = "username"
SoapClient.ConnectorProperty("AuthPassword") = "userpwd"
Quote = SoapClient.GetQuote()
注意：使用 SOAP Toolkit 2.0 時，只有在調用遠程方法時才必須設置 SoapClient 上的 ConnectorProperties。
如果包含服務描述的 wsdl 文件所在的虛擬目錄也要求身份驗證，可以在 URL 內傳遞用戶名和密碼：
SoapClient.mssoapinit
("http:// username:userpwd@your-server/webservice/service.wsdl ")
人們往往錯誤地認為將用戶名和密碼放入 URL 是不安全的。事實並非如此。在發送 HTTP 請求之前，客戶端 HTTP 代碼將分析 URL，移出用戶名和密碼，並在身份驗證握手時使用此用戶名和密碼。事實上，代碼：
SoapClient.ConnectorProperty("AuthName") = "username"
SoapClient.ConnectorProperty("AuthPassword") = "userpwd"
Quote = SoapClient.GetQuote()
與下列代碼的功能相同（假設 WSDL 文件 service.wsdl 指向自身）：
SoapClient.ConnectorProperty("EndPointURL")=
"http:// username:userpwd@your-server/webservice/service.wsdl"
Quote = SoapClient.GetQuote()
虛擬目錄設置如何要求身份驗證？若要在伺服器上更改特定虛擬目錄的身份驗證設置，請執行下列操作：
在 IIS 4.0 和 IIS 5.0 上，用滑鼠右鍵單擊虛擬目錄，單擊「屬性」，然後單擊「目錄安全性」選項卡。
在「匿名訪問和身份驗證控制」之下，單擊「編輯」。將出現以下兩個選項：
匿名訪問
匿名訪問不是身份驗證方法。Windows 2000 和 NT4 要求用戶在訪問任何資源之前驗證自身，這種情況下，IIS 使用一個特殊帳戶作為匿名 Web 用戶（默認為 IUSR_machinename）。可以單擊「匿名訪問編輯」按鈕更改此默認匿名 Web 用戶的帳戶或其密碼。
注意：小心不要將特權帳戶用作匿名 Web 用戶帳戶。若要將虛擬目錄設置為要求身份驗證，需要清除「匿名訪問」標記。
基本身份驗證
若要將虛擬目錄設置為要求基本身份驗證，需要：
轉至「屬性」/「目錄安全性」/「編輯匿名訪問驗證控制」菜單。
取消選中「匿名訪問」。
啟用「基本身份驗證」。將顯示一條警告消息。如果要繼續使用基本身份驗證，請單擊「確定」。
單擊「基本身份驗證編輯」按鈕。輸入域名。如果要使用默認域名，請輸入「\」（不加引號）。
缺點：基本身份驗證是非常不安全的。用戶名和密碼以不加密的 Base64 編碼形式通過線路傳輸。問題不僅在於攻擊者能訪問基本身份驗證保護的資源，他們還能夠獲取您的用戶名和密碼的實際值，並用來訪問其它更安全的資源。使用 SSL 連接會更安全一些，因為 SSL 握手在身份驗證握手之前發生。這樣，可以通過安全連接傳送用戶名和密碼。
優點：基本身份驗證是 HTTP 1.0 協議的一部分，是得到最廣泛支持的身份驗證方案。
結論：基本身份驗僅當與 SSL 功能共同使用時才是一個好的解決方案。如果希望您的服務具有安全性和高互操作性，請使用本方法。
摘要式身份驗證
這是一個相對較新的方法，是 HTTP1.1 協議的一部分，但沒有被 Web 伺服器廣泛採用。對於 Windows，它只在出現 Windows 2000 之後才被採用。若要在 IIS 5.0 上設置摘要式身份驗證，請執行下列步驟：
轉至「屬性」/「目錄安全性」/「編輯匿名訪問」和「身份驗證控制」菜單。
取消選中「匿名訪問」。
啟用「摘要式身份驗證」。將顯示一條警告消息。如果要繼續使用摘要式身份驗證，請單擊「確定」。
使用摘要式身份驗證具有以下要求：
運行 Windows 2000 Server 的系統位於 Active Directory 域。
在域控制器上安裝 iissuba.dll 文件。該 DLL 在匿名訪問和摘要式身份驗證期間發揮作用。
在 Active Directory 設置中使用摘要式身份驗證的所有帳戶的日誌記錄都啟用「使用可逆加密存儲密碼」選項。這是對 Active Directory 中帳戶密碼的純文本副本進行摘要式身份驗證訪問時所必需的。這樣，可確保存儲這些密碼的伺服器是非常安全的。
缺點：如果摘要式身份驗證不與 SSL 一起使用，將不能保護資源免於重復攻擊。目前尚未在其它 HTTP 客戶端和伺服器中被廣泛採用。在 IIS 5.0 上的實現具有局限性，如果通過摘要式身份驗證登錄到伺服器，標識將無法委派到其它伺服器。這就將伺服器限制為伺服器方案。
優點：摘要式身份驗證簡單，可能會越來越普及。它比基本身份驗證更安全，因為盡管仍可能遭到重復攻擊，但攻擊者無法獲得訪問其它資源所要求的用戶名和密碼的實際值。
結論：摘要式身份驗證可以用於保護通過 Web 服務公開到 Internet 的低價值資源。在 SSL 上使用基本身份驗證可以獲得更好的性能，因為 SSL 速度慢，但不會象基本身份驗證那樣將用戶名和密碼暴露給攻擊者。
Windows 集成身份驗證 (NTLM)
Windows 集成身份驗證（IIS 4 中的 Windows 請求/響應身份驗證）在 Windows 2000 和 NT4 上表現為不同的方法。在具有 IIS 4 的 NT 4 下，它描述為 NTLM 身份驗證。若要將 IIS 伺服器設置為要求 Windows 集成身份驗證（在 IIS 5 上）或 NTLM（在 IIS 4 上），請完成基本或摘要式身份驗證步驟 1 和 2，並在步驟 3 中選擇相應的復選框。
NTLM 身份驗證（NT LAN Manager 或 Windows 請求/響應身份驗證）是本機 Windows 身份驗證方案。如果未指定用戶名/密碼，將使用當前登錄用戶憑據。通過 Intranet 訪問時，如果用戶已經登錄的域與 Web 伺服器的域相同，而且使用自己的憑據，則這些用戶不必重新進行身份驗證。在 NTLM 握手過程中，客戶端用伺服器（請求）發送的隨機值散列密碼，然後將此散列（響應）發送給伺服器。這意味著密碼不會通過線路顯式發送。人們通常錯誤地認為 NTLM 只能用於 Intranet 解決方案，不應用於 Internet。實際上，NTLM 可以用於 Internet，只不過用於 Intranet 時速度更快，因為它依賴於 Windows 登錄過程。若要同時傳送域名和登錄名稱，請使用 SAM 帳戶名稱：
SoapClient.ConnectorProperty("AuthName") = "DOMAIN\username"
缺點：NTLM 只能用於 Windows。與基本和摘要式身份驗證方案一樣，它只對客戶端進行身份驗證。使用 NTLM 時，伺服器上的模擬線程無法將自己的許可權委派給另一台伺服器。這限制了 NTLM 身份驗證在「伺服器至伺服器」方案中的使用；但仍可以在這種方案中使用基本和摘要式身份驗證。NTLM 不能通過代理工作。
優點：NTLM 比基本和摘要式身份驗證更安全，因為它不容易受到重復攻擊。由於依賴 Windows 登錄過程，因此在 Intranet 方案中速度很快。
結論：推薦將 NTLM 用於「客戶端至伺服器」Intranet 解決方案。也可用於限制為 Windows 體系結構的公司 Internet 解決方案。
Kerberos 身份驗證
Kerberos 身份驗證是在 Windows 2000 中出現的。當指定 IIS 5 使用 Windows 集成身份驗證時，IIS 5 和 SoapClient HTTP 連接器通過協商協議確定是使用 NTLM 還是使用 Kerberos。如果在 Windows 2000 上運行 SoapClient，則使用 Kerberos，否則使用 NTLM。指定 SoapClient 上用戶憑據時所應用的規則與 NTLM 相同。
缺點：僅 Windows 2000 平台支持 Kerberos。Kerberos 要求具有一個可向其請求服務票證的 KDC 伺服器。通常，人們不想將自己的 KDC 伺服器公開於 Internet。因此，Kerberos 通常只限於 Intranet 應用。默認情況下，只有伺服器的 NetBIOS 名稱在 Kerberos KDC 中進行了注冊。如果您希望請求票證時使用 IIS 伺服器的 DNS 名稱，則必須在 KDC 中注冊 DNS 名稱。
優點：與 NTLM 相比，Kerberos 速度更快、更安全，而且同時對伺服器和客戶端進行身份驗證。Kerberos 不是 Windows 專有的身份驗證方案，也可以由其它平台實現。很重要的一點在於它允許將標識委派給另一台計算機，因此可以在「伺服器至伺服器」方案中使用。
結論：推薦在基於 Windows 2000 的 Intranet 解決方案中使用 Kerberos。
有時，需要伺服器支持多種身份驗證方案（以便允許對多種類型的客戶端進行身份驗證）。這種情況下，IIS 將發送多個 WWW 身份驗證頭，詳細說明它支持的身份驗證方案，客戶端將選擇它支持的第一個身份驗證方案。了解 SoapClient 在特定情況下選擇哪種身份驗證方案非常重要。請參考表 1，其中描述了 SOAP Toolkit 2.0（更准確的說是 HttpConnector）在各種平台上的行為。
表 1：SOAP Toolkit 2.0 HttpConnector 與 IIS 5.0 的比較
基本 摘要式 Windows 集成 Windows 98 Windows Me Windows NT 4.0 Windows 2000
X X 基本 基本 基本 摘要式
X X NTLM NTLM NTLM Kerberos
X X NTLM NTLM NTLM Kerberos
X X X NTLM NTLM NTLM Kerberos
左邊的三列代表伺服器提供的身份驗證方案。每一行都代表伺服器允許的身份驗證方案集的一個不同組合。右邊的四列顯示了可以運行 SOAP Toolkit Client (HttpConnector) 的平台。例如，如果伺服器既允許基本身份驗證也允許摘要式身份驗證，SOAP 將在除 Windows 2000 之外的所有平台上選擇基本身份驗證。
表 2 顯示了 Microsoft SOAP 行為與 IIS 4.0 伺服器的比較。
表 2：SOAP Toolkit 2.0 HttpConnector 與 IIS 4.0 的比較
基本 Windows 集成 Windows 98 Windows Me Winodws NT 4.0 Windows 2000
X X NTLM NTLM NTLM NTLM
身份驗證支持中的已知局限性：SOAP Toolkit 2.0 使用 NTLM/Kerberos 同時發送域名和帳戶名時具有某種局限性。但已經在 SP2 中進行了修正。
代理支持和身份驗證
SOAP Toolkit 廣泛支持通過代理伺服器進行通信，包括在代理伺服器上進行身份驗證。我們將具體說明以下方案，講述如何通過代理伺服器使用 Web 服務。
直接訪問
默認情況下，SOAP Toolkit HttpConnector 嘗試對 Web 服務進行直接調用。如果您不具有 Web 服務的直接訪問許可權（例如，Web 服務位於您的 Intranet 之外，必須通過代理才能訪問），以下腳本將失敗：
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://services.xmethods.net/soap/urn:xmethods-CurrencyExchange.wsdl")
Quote = SoapClient.GetQuote()
通過默認代理訪問
試圖訪問 Intranet 之外的網站時，Internet Explorer Web 瀏覽器將通過在 IE 設置中指定的默認代理伺服器。您可以通過 IE/「工具」/「選項」/「連接」/「區域網設置」對話框查看這些設置。若要使 Microsoft SOAP Toolkit (HTTPConnecter) 使用這些設置，應將 UseProxy 屬性設置為 TRUE。示例：
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://services.xmethods.net/soap/urn:xmethods-CurrencyExchange.wsdl")
SoapClient.ConnectorProperty("UseProxy") = true
Quote = SoapClient.GetQuote()
繞過代理伺服器列表。請注意，IE 代理設置中有一個主機列表，您可以連接這些主機來繞過代理伺服器。
轉至 IE/「工具」/「選項」/「連接」/「區域網設置」對話框。
若要繞過本地伺服器，請啟用設置「對於本地地址不使用代理伺服器」。
若要在連接到其它特定伺服器時繞過代理，請單擊「高級」按鈕。可以在「例外」編輯控制項中列出要繞過的伺服器，各個伺服器名稱之間用分號隔開。可以使用通配符「*.soap-company.com」繞過名稱中含有 .soap-company.com 的所有伺服器。
需要代理伺服器來允許繞過本地 Intranet 之外的任何伺服器。請注意，用於 HTTP 和用於通過 SSL (HTTPS) 連接的代理伺服器不同。代理應允許使用任一協議，以便 SSL 正常工作。
局限性：使用默認代理時，在 Windows 2000 和 Windows NT4 上使用 Microsoft SOAP Toolkit 2.0 HttpConnector 有一個已知問題：它不理解默認 IE 代理設置的「繞過代理」列表。如果選中了「對於本地地址不使用代理伺服器」並且在 URL 中指定的主機名不包含「.」，它將繞過代理伺服器。但它不理解在 IE 代理設置「高級」菜單中的「例外」文本框中指定的復雜模板。
通過指定代理連接
可以指定哪個代理使用 ProxyServer 和 ProxyPort 連接器屬性：
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://services.xmethods.net/soap/urn:xmethods-CurrencyExchange.wsdl")
SoapClient.ConnectorProperty("UseProxy") = true
SoapClient.ConnectorProperty("ProxyServer") = "yourproxy"
SoapClient.ConnectorProperty("ProxyPort") = 80
Quote = SoapClient.GetQuote()
請注意，如果使用 ProxyServer 屬性，則不必將 UseProxy 設置為 True，它將自動設置。
代理身份驗證
代理伺服器可以在允許連接之前要求您對自身進行身份驗證。例如，可以使用它限制在公司 Intranet 內使用 Internet。代理伺服器可使用上述所有身份驗證方案。Microsoft SOAP Toolkit 2.0 允許您指定代理身份驗證的用戶名和密碼：
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.ConnectorProperty("UseProxy") = true
SoapClient.mssoapinit("http://services.xmethods.net/soap/urn:xmethods-CurrencyExchange.wsdl")
SoapClient.ConnectorProperty("ProxyServer") = "secureproxy"
SoapClient.ConnectorProperty("ProxyPort") = 80
SoapClient.ConnectorProperty("ProxyUser") = "username"
SoapClient.ConnectorProperty("ProxyPassword") = "password"
Quote = SoapClient.GetQuote()
如果代理要求 NTLM 身份驗證，可以省略用戶名和密碼，這是將使用當前登錄憑據。如果需要指定代理 NTLM 身份驗證的域名，請添加「DOMAIN\username」進行伺服器身份驗證。
局限性。Microsoft SOAP Toolkit 2.0 不支持通過要求身份驗證的代理連接到也要求身份驗證的伺服器。另外，通過要求身份驗證的代理的 SSL 連接在 Windows 2000 和 Windows NT4 上不能正常工作。
SSL 和客戶端證書
在本節中，我們將具體討論如何通過安全套接字層 (SSL) 和客戶端證書支持進行連接。我們還將討論 Microsoft SOAP Toolkit 2.0 在使用客戶端證書支持的支持平台上的已知局限性。
通常認為 SSL 只是一種加密機制，其實它還提供身份驗證。若要使 IIS 4.0/IIS 5.0 支持 SSL 連接，需要獲取 X.509 證書，並將其安裝在伺服器上。
何謂 X.509 證書？
證書是一種結構，其中包含主題、頒發者名稱、有效期和其它特徵等信息。（有關證書的詳細信息，請參閱由 Michael Howard 編著的《設計 Microsoft Windows 2000 基於 Web 的安全應用程序》。） 每個證書都與用於 SSL 加密的一對私有和公用密鑰相關。SSL 始終使用 X.509 證書對 Web 伺服器進行身份驗證。
若要獲得證書，需要向證書頒發機構發出證書請求。證書頒發機構 (CA) 是頒發證書的單位。當 CA 向主題（發出請求的實體）頒發證書時，它驗證該主題是否與它所聲稱的相符，並簽發新證書和私有密鑰。這樣，主題可以信任 CA。如果信任頒發證書的 CA，則表示信任向您提供此證書的主題。根目錄證書保證 CA 的可信性。多個 CA 可以形成一條信任鏈：如果信任根 CA，就信任具有根 CA 頒發的證書的中間 CA，因此將信任具有中間 CA 頒發的證書的所有主題。
「信任」的實際意義是什麼？可以將 CA 的證書放入「受信任的根目錄證書頒發機構」存儲區來表示信任該 CA。所有證書都存儲在所謂的證書存儲區中。有多個默認存儲區，例如：
CURRENT_USER\MY\，個人證書存儲區，用於當前登錄的用戶，對其它登錄用戶不可見
LOCAL_MACHINE\MY\，個人證書存儲區，用於所有用戶
CURRENT_USER\Root\，受信任的根目錄證書頒發機構，包含當前用戶信任的根 CA 的證書，如果證書具有到根 CA 證書的證書路徑，則當前用戶信任該證書的有效性。
LOCAL_MACHINE\Root\，相同，但被所有用戶信任
具有被默認信任的根 CA，例如 Verisign。盡管我們的示例將使用一個試用版的 Verisign 證書，但是它們是由不被默認信任的 Verisign 測試機構頒發的。
在伺服器上啟用 SSL
本節介紹如何創建證書請求、從 Verisign 站點獲得試用版的測試伺服器端證書，並將其安裝在 Web 伺服器上。
使用 IIS 4.0 啟用伺服器上的 SSL
用滑鼠右鍵單擊要啟用 SSL 的網站，並選擇「屬性」。
在「目錄安全性」選項卡上，單擊「編輯安全通信」。
在對話框中，單擊「密鑰管理器」。
展開樹狀視圖中的「本地計算機」節點。用滑鼠右鍵單擊 WWW 葉，並選擇「新建密鑰」。這將啟動稱為「密鑰管理器」的密鑰請求向導。
選擇「將請求放入要發送到頒發機構的文件中」和一個文件名。單擊「下一步」。
輸入一個易記的密鑰名稱。輸入密碼，當獲取由頒發機構頒發的證書時需要此密碼。對於加密密鑰位元組長度，請選擇 1024（1024 為推薦長度，某些頒發機構不頒發小於此長度的證書）。單擊「下一步」。
輸入您的組織和部門名稱。輸入等同於完整站點名稱的公用名稱，例如 www.yoursite.com。在啟動 SSL 連接之前，客戶端將檢查站點名稱是否與證書的公用名稱相同。單擊「下一步」。
輸入國家（地區）、省/自治區、市/縣所在地。證書頒發機構可能檢查這些信息是否一致，以確保輸入的信息有效。輸入省時，請輸入完整的省名稱。
輸入管理伺服器的人員的姓名、電子郵件地址和電話號碼。這些信息不包含在證書中，但證書頒發機構需要這些信息。
包含您的請求的文件已經創建。該文件為 Base64 編碼格式。在此過程中，IIS 還將為該證書請求創建一個私有密鑰和一個公用密鑰。私有密鑰將保存在您的計算機上，而公用密鑰將隨請求一起發往 Verisign，並用以加密證書數據。
轉至 www.verisign.com（英文），並單擊「Get Trial SSL ID」。注冊證書時，會要求您提供 CSR（證書簽名請求）。復制並粘貼您的請求文件中自行「BEGIN NEW CERTIFICATE REQUEST;」之後的內容，否則，將會出錯。Verisign 以郵件形式將測試伺服器端證書發送給您。該過程同樣適用於商業證書，不同之處在於它收費並仔細驗證提交的信息。
確保從證書頒發機構獲得的證書是 Base64 編碼的。如果證書頒發機構是 Verisign，則您可以通過電子郵件獲得證書。創建一個擴展名為 .cer 的空文件，復制行「BEGIN CERTIFICATE」和「END CERTIFICATE」之間（包含這兩行）的所有內容並粘貼到該文件。
轉至要啟用 SSL 的站點的「屬性」/「目錄安全性」選項卡。單擊「編輯安全通信」，然後單擊「密鑰管理器」。
在對話框中，展開樹狀視圖中的「本地計算機」節點，再展開 WWW 葉，將顯示您的證書請求的密鑰。由於該證書尚未安裝，它標記為紅色。用滑鼠右鍵單擊該證書，並選擇「安裝密鑰證書」。選擇具有要安裝的證書的文件。將提示您提供以前設置的密碼。輸入密碼。現在，您的證書已安裝。
使用 IIS 5.0 啟用伺服器上的 SSL
用滑鼠右鍵單擊要啟用 SSL 的網站，並選擇「屬性」。
在「目錄安全性」選項卡上，單擊「編輯安全通信」。
單擊「伺服器證書」打開伺服器證書向導。該向導將記憶網站的當前狀態，例如您是否已擁有伺服器證書。（現在假設您沒有證書。）
在證書向導中，單擊「下一步」，選擇「創建一個新證書」，然後單擊「下一步」。
選擇「現在准備請求，但稍後發送」，並單擊「下一步」。
輸入證書的友好名稱。該名稱不會在證書結構中使用，但作為區分請求和證書的一種方法。選擇公用密鑰長度。推薦密鑰長度不小於 1024 位元組。單擊「下一步」。
輸入可以由頒發機構驗證的組織名稱和部門名稱，如果您請求用於商業目的的真實證書，請輸入有效名稱。輸入要被認證的計算機的名稱。注意：它必須等同於您的完整站點名稱，例如 www.yoursite.com。單擊「下一步」。
輸入國家（地區）、省/自治區、市/縣所在地。請輸入有效信息，證書頒發機構將檢查這些信息是否一致。輸入省時，請輸入完整的省名稱。單擊「下一步」。
輸入用於保存請求的請求文件名稱。單擊「下一步」。
將摘要顯示您輸入的內容。確認內容正確，並單擊「下一步」完成向導。包含請求的文件將以 Base 64 格式保存。
包含您的請求的文件已經創建。該文件為 Base64 編碼格式。在此過程中，IIS 還將為該證書請求創建一個私有密鑰和一個公用密鑰。私有密鑰將保存在您的計算機上，而公用密鑰將隨請求一起發往 Verisign，並用以加密證書數據。
轉至 www.verisign.com（英文），並單擊「Get Trial SSL ID」。注冊證書時，會要求您提供 CSR（證書簽名請求）。復制並粘貼您的請求文件中自行「BEGIN NEW CERTIFICATE REQUEST;」之後的內容，否則，將會出錯。Verisign 以郵件形式將測試伺服器端證書發送給您。該過程同樣適用於商業證書，不同之處在於它收費並仔細驗證提交的信息。
確保從證書頒發機構獲得的證書是 Base64 編碼的。如果證