公有云的出現(xiàn)無疑為眾多的企業(yè)用戶在應(yīng)用選擇方面打了一劑強(qiáng)心劑，大型企業(yè)可以通過公有云服務(wù)來省去自身的數(shù)據(jù)中心升級改造工作，而中小企業(yè)可以打消自身信息化成本的壁壘。

    作為公有云的代表，SaaS服務(wù)被眾多的企業(yè)級用戶所關(guān)注，但是，人們對于SaaS的疑問和顧慮制約了SaaS的發(fā)展。用戶之所以產(chǎn)生顧慮，是因?yàn)槟壳癝aaS并沒有一個(gè)自身的標(biāo)準(zhǔn)，由于SaaS是一種在線的應(yīng)用系統(tǒng)服務(wù)的提供，所以不同的應(yīng)用會產(chǎn)生不同的標(biāo)準(zhǔn)。所以從某種意義上說，SaaS也很難產(chǎn)生一個(gè)通用的標(biāo)準(zhǔn)。

    沒有標(biāo)準(zhǔn)并不等同于SaaS不能被用戶接受。我們可以從某些常見的應(yīng)用中以點(diǎn)帶面，看一看SaaS服務(wù)應(yīng)該具有什么樣的標(biāo)準(zhǔn)。

    我們今天以企業(yè)用戶常用的CRM系統(tǒng)，來看一看標(biāo)準(zhǔn)的SaaS CRM應(yīng)該是一個(gè)什么樣子。

    實(shí)際上，很多用戶對于CRM并不陌生，早在2000年的時(shí)候，有一些企業(yè)就已經(jīng)開始嘗試CRM系統(tǒng)。在很多人眼中，CRM就是一套C/S或者B/S的應(yīng)用系統(tǒng)。

    而當(dāng)CRM進(jìn)入了SaaS，他在架構(gòu)上會是一個(gè)什么樣子呢？我們以中科軟科技股份有限公司新推出的361CRM為例，來看一下SaaS CRM的架構(gòu)。

    361CRM 系統(tǒng)采用分布式架構(gòu)。采用企業(yè)級的多層次、多應(yīng)用的系統(tǒng)結(jié)構(gòu)的SaaS在線CRM平臺平臺架構(gòu)從大的層次上來分主要為四層，根據(jù)調(diào)用關(guān)系依次為應(yīng)用層、緩沖層、服務(wù)層以及存儲層，如下圖所示：

應(yīng)用層

    從瀏覽器發(fā)送過來的請求，直接由應(yīng)用層來進(jìn)行直接響應(yīng)；

    平臺是多租賃用戶的在線多應(yīng)用來實(shí)現(xiàn)的，由于每個(gè)用戶的具體業(yè)務(wù)需求不同，因此每個(gè)租賃用戶的應(yīng)用是相互隔離的，但應(yīng)用層的結(jié)構(gòu)卻都是相同，從上到下主要分為業(yè)務(wù)展現(xiàn)層、業(yè)務(wù)邏輯層、業(yè)務(wù)模型層、實(shí)體訪問層；

    業(yè)務(wù)展現(xiàn)層主要為用戶數(shù)據(jù)的不同視圖表現(xiàn)，為用戶呈現(xiàn)各種易于瀏覽、便于理解的各種數(shù)據(jù)表現(xiàn)方式，如表單、表格、報(bào)表、圖表等；

    業(yè)務(wù)邏輯層主要是業(yè)務(wù)邏輯的具體實(shí)現(xiàn)層，對于用戶動作、觸發(fā)事件以及工作流程等由業(yè)務(wù)邏輯層來實(shí)現(xiàn)業(yè)務(wù)的處理以及響應(yīng)，通過業(yè)務(wù)邏輯層對下層業(yè)務(wù)模型的訪問來實(shí)現(xiàn)具體的邏輯處理；

    業(yè)務(wù)模型層主要是業(yè)務(wù)對象的具體定義與封裝，是對于現(xiàn)實(shí)中業(yè)務(wù)在平臺中的最直接的映射；

    實(shí)體訪問層是對于業(yè)務(wù)邏輯層對于業(yè)務(wù)模型操作的封裝，業(yè)務(wù)模型的實(shí)體狀態(tài)的更新、刪除、查詢等都是通過實(shí)體訪問層來實(shí)現(xiàn)。

緩沖層

    緩沖層主要對于靜態(tài)資源以及動態(tài)數(shù)據(jù)的緩存。靜態(tài)資源主要是指應(yīng)用層中展現(xiàn)層中所要使用到的靜態(tài)資源文件，以及由用戶在業(yè)務(wù)操作中產(chǎn)生的文件等，如圖片、上傳的文件等；

    而動態(tài)數(shù)據(jù)是指用戶在使用平臺的過程中所產(chǎn)生的業(yè)務(wù)數(shù)據(jù)，在實(shí)現(xiàn)業(yè)務(wù)中，這部分?jǐn)?shù)據(jù)大部分都是讀操作比較多，而寫操作比較少，因此可以針對這部分?jǐn)?shù)據(jù)根據(jù)特定的緩存失效策略機(jī)制來進(jìn)行相應(yīng)的緩存；

    緩沖層的緩存針對應(yīng)用層是透明的，而且針對多應(yīng)用也是透明的，因此緩沖層具有更大的彈性與靈活性。

服務(wù)層

    服務(wù)主要是指平臺的核心服務(wù)，核心服務(wù)分為業(yè)務(wù)共通服務(wù)以及平臺共通服務(wù)，平臺共通服務(wù)是指與業(yè)務(wù)無關(guān)且是平臺最基礎(chǔ)的服務(wù)，如任務(wù)調(diào)度、消息隊(duì)列、郵件服務(wù)、圖片處理、工作流引擎等；而業(yè)務(wù)共通服務(wù)指基于平臺共通服務(wù)，而對于所有業(yè)務(wù)具有共通性的服務(wù)，如日志審核、操作回滾、數(shù)據(jù)安全、全文檢索、權(quán)限角色等；

    服務(wù)層是對于平臺運(yùn)營、維護(hù)最核心的服務(wù)實(shí)現(xiàn)，是平臺正常運(yùn)行的基礎(chǔ)。

存儲層

    存儲主要分為兩部分：分布式文件存儲以及分布式的數(shù)據(jù)存儲；

    由于是多應(yīng)用的平臺，因此隨著平臺的運(yùn)營，會產(chǎn)生海量的業(yè)務(wù)數(shù)據(jù)以及資源文件，因此伴隨著海量的數(shù)據(jù)而來的問題就是存儲、檢索、分析以及統(tǒng)計(jì)等問題；

    針對上述問題，361CRM平臺采用了分布式的存儲系統(tǒng)，基于Map-Reduce來進(jìn)行相應(yīng)的檢索、分析以及統(tǒng)計(jì)，實(shí)現(xiàn)了對于海量數(shù)據(jù)的統(tǒng)一操作。

    這種結(jié)構(gòu)能做到真正的分布式網(wǎng)絡(luò)計(jì)算，有效降低網(wǎng)絡(luò)流量，減輕客戶端負(fù)擔(dān)，還能安全、方便地與互聯(lián)網(wǎng)接口。另外公司員工或客戶分布或行走于全國各地，通常都有移動辦公需求。

REST 架構(gòu)

    REST是基于HTTP的，因此天生就有在互聯(lián)網(wǎng)上穿透防火墻的能力，REST可以簡單地認(rèn)為它是輕量級的Web Service，但是它具有自己的一些顯著特點(diǎn)：

    所有的資源通過統(tǒng)一的接口訪問(HTTP/HTTPS GET、POST、PUT、ELETE)，而且接口比較統(tǒng)一，便于與第三方的集成；

    因?yàn)槭腔�于HTTP/HTTPS的，因此可以將資源（響應(yīng)）分為可緩存的和不可緩存的，以及采用瀏覽器的標(biāo)準(zhǔn)壓縮方式，有效地提升網(wǎng)絡(luò)效能。也可以在客戶和資源之間插入不同的中間組件來提升性能和安全等，如，代理服務(wù)，緩存服務(wù)，網(wǎng)關(guān)服務(wù)等；

    因?yàn)槭腔�于HTTP/HTTPS的資源請求，因此本次連接和下一次到服務(wù)器的連接之間沒有狀態(tài)。由于361CRM平臺采用了REST架構(gòu)，因此也就決定了361CRM平臺天然就具備以下幾方面的優(yōu)勢：

    由于REST本身無狀態(tài)的特性，361CRM平臺天然就是分布式的，決定了后臺通過根據(jù)業(yè)務(wù)量而彈性地增加服務(wù)器就可以實(shí)現(xiàn)平臺計(jì)算能力的線性增加；

    所有的請求都是統(tǒng)一通過REST API進(jìn)行相應(yīng)的資源與服務(wù)的請求，這樣就能夠保證系統(tǒng)提供的服務(wù)都是解耦的，極大的簡化了系統(tǒng)，從而改善了系統(tǒng)的交互性和可重用性，同時(shí)也能夠根據(jù)業(yè)務(wù)進(jìn)行相應(yīng)統(tǒng)一且透明的內(nèi)存緩存

    客戶端瀏覽器能夠輕松通過Ajax實(shí)現(xiàn)REST資源的異步調(diào)用處理，同時(shí)也可以有效地減少應(yīng)用服務(wù)器地壓力

    通過提供開放的REST API，能夠輕松實(shí)現(xiàn)與第三方的集成

平臺服務(wù)

    平臺服務(wù)層的調(diào)用是通過REST API進(jìn)行的，由于REST的特點(diǎn)，通過在URI中添加資源路徑以及版本信息，很方便地能夠?qū)崿F(xiàn)平臺的平滑升級以及數(shù)據(jù)兼容性問題。

    平臺服務(wù)層實(shí)現(xiàn)的都是共通的服務(wù)，服務(wù)之間是獨(dú)立的，而且是插件式的方式來實(shí)現(xiàn)的，平臺選用了面向分布式計(jì)算的Erlang語言來實(shí)現(xiàn)的，因此保證了這些插件式的服務(wù)能夠熱拔插地部署，實(shí)現(xiàn)真正地不宕機(jī)地部署與更新。

    平臺服務(wù)層的插件式架構(gòu)，決定了平臺的無限擴(kuò)展能力，能夠根據(jù)不斷變化地用戶需求而進(jìn)行平臺的不斷地在線迭代與更新，與用戶的需求形成一個(gè)良性的循環(huán)。配置定制平臺通過服務(wù)器(Apache)的自定義開發(fā)，實(shí)現(xiàn)了企業(yè)用戶應(yīng)用的透明隔離，因此平臺具有面向不同企業(yè)用戶根據(jù)不同需求進(jìn)行個(gè)性化定制的能力。不同的企業(yè)用戶，一般主要有幾方面的自定義需求：業(yè)務(wù)對象、工作流程、報(bào)表、布局等，而361CRM平臺的平臺框架就決定著能夠很好地滿足用戶的自定義需求，主要分為以下幾個(gè)方面：

    由于用戶使用的是文檔數(shù)據(jù)庫，有著松散的數(shù)據(jù)結(jié)構(gòu)，因此用戶根據(jù)需求，而可以隨意自定義自己的業(yè)務(wù)對象；

    361CRM平臺后臺的平臺服務(wù)層，有相應(yīng)的實(shí)時(shí)的工作流引擎，提供給用戶強(qiáng)大的自定義工作流程功能；

    361CRM平臺有業(yè)內(nèi)是豐富的報(bào)表模板，用戶只需要根據(jù)自己的需要來選擇即可，針對一些自定義的動態(tài)數(shù)據(jù)，還提供模板的再定義功能，能夠很好地滿足用戶的報(bào)表需求；

    由于平臺是應(yīng)用隔離的，因此針對著頁面的布局，可以很容易地實(shí)現(xiàn)個(gè)性化地定制；

    361CRM平臺的配置功能的強(qiáng)大，并不以損失平臺應(yīng)用的易用性為基礎(chǔ)，361CRM平臺在操作上采用引導(dǎo)式操作，以及提供方便易用的在線幫助，大大地降低了系統(tǒng)使用的復(fù)雜度，使系統(tǒng)更加地人性化、簡易化。

實(shí)時(shí)即時(shí)

    361CRM平臺的平臺服務(wù)層與通常的應(yīng)用服務(wù)不同，它是實(shí)時(shí)運(yùn)行的服務(wù)，平臺服務(wù)層有相應(yīng)的任務(wù)調(diào)度機(jī)制，郵件服務(wù)、消息隊(duì)列以及實(shí)時(shí)的工作流引擎等，這些服務(wù)都是實(shí)時(shí)運(yùn)行的，因此當(dāng)企業(yè)用戶的業(yè)務(wù)對象或者業(yè)務(wù)流程發(fā)生變化時(shí)，通過這些平臺服務(wù)就可以把即時(shí)的狀態(tài)消息(通過郵件、短信或者其它的IM工具)推送給用戶，讓用戶真正了解到業(yè)務(wù)的即時(shí)與實(shí)時(shí)的狀態(tài)信息。

    而通常的應(yīng)用服務(wù)是靜態(tài)的，只有當(dāng)用戶登錄時(shí)，才會進(jìn)行相應(yīng)的業(yè)務(wù)狀態(tài)的檢查，這樣就嚴(yán)重影響了業(yè)務(wù)處理的速度，對于即時(shí)性業(yè)務(wù)，就會帶來很大的損失。

多級負(fù)載

    平臺是一個(gè)多租賃用戶的在線SaaS系統(tǒng)，因此會給平臺帶來大量的高并發(fā)的請求，361CRM平臺是一個(gè)多層次的結(jié)構(gòu)，而且采用了REST架構(gòu)，REST天生就是分布式，因此通過物理部署就可以實(shí)現(xiàn)高并發(fā)帶的負(fù)載均衡。

    四層負(fù)載在鏈路層解決來自互聯(lián)網(wǎng)的并發(fā)請求壓力，使用LVS+Heartbeat的主從雙備的架構(gòu)，保證不會出現(xiàn)單點(diǎn)故障；

    Web應(yīng)用的大部分壓力都來自于資源的請求，如圖片，靜態(tài)文件，樣式表等文件的請求，服務(wù)器壓力的70%都來自于這些資源的請求，因此對于這些靜態(tài)資源的請求，通過靜態(tài)資源緩沖層就能夠很好解決這些請求對于后臺造成的壓力；

    經(jīng)過實(shí)測，經(jīng)過一段時(shí)間穩(wěn)定運(yùn)行之后，靜態(tài)資源緩沖層能夠命中前臺請求的80%以上，有效地緩解了應(yīng)用服務(wù)器的壓力；

    七層負(fù)載層主要是做業(yè)務(wù)、以及資源的請求分流，把負(fù)載均衡到多臺文件服務(wù)器以及應(yīng)用服務(wù)器上；

    文件服務(wù)器與應(yīng)用服務(wù)器是分布式的，通過Map-Reduce進(jìn)行任務(wù)的拆分與結(jié)果的合并，充分利用多臺服務(wù)器的并行計(jì)算能力，提升整體平臺的運(yùn)行性能；

    文件緩存采用多級緩存策略，解決命中率高的文件的頻繁請求。而數(shù)據(jù)緩存則通過業(yè)務(wù)標(biāo)簽以及時(shí)效性策略進(jìn)行數(shù)據(jù)的緩存，并且進(jìn)行緩存的增量更新，有效地解決了對于后臺的
數(shù)據(jù)讀寫壓力；

    分布式的存儲系統(tǒng)有效地解決了海量數(shù)據(jù)的存儲、檢索、分析以及統(tǒng)計(jì)等問題。

    可見，當(dāng)傳統(tǒng)的CRM系統(tǒng)轉(zhuǎn)換為SaaS服務(wù)后，其架構(gòu)方面還是發(fā)生了不少的變動的，也只有這樣的變動，才使得CRM能夠在SaaS平臺上更好的為客戶所服務(wù)。

附：什么是REST 架構(gòu)

    REST軟件架構(gòu)是當(dāng)今世界上最成功的互聯(lián)網(wǎng)的超媒體分布式系統(tǒng)。它讓人們真正理解我們的網(wǎng)絡(luò)協(xié)議HTTP本來面貌。它正在成為網(wǎng)絡(luò)服務(wù)的主流技術(shù)，同時(shí)也正在改變互聯(lián)網(wǎng)的網(wǎng)絡(luò)軟件開發(fā)的全新思維方式。AJAX技術(shù)和Rails框架把REST軟件架構(gòu)思想真正地在實(shí)際中很好表現(xiàn)出來。今天微軟也已經(jīng)應(yīng)用REST并且提出把我們現(xiàn)有的網(wǎng)絡(luò)變成為一個(gè)語義網(wǎng)，這種網(wǎng)絡(luò)將會使得搜索更加智能化。

    REST與HTTP協(xié)議

    REST軟件架構(gòu)是由Roy Thomas Fielding博士在2000年首次提出的。他為我們描繪了開發(fā)基于互聯(lián)網(wǎng)的網(wǎng)絡(luò)軟件的藍(lán)圖。REST軟件架構(gòu)是一個(gè)抽象的概念，是一種為了實(shí)現(xiàn)這一互聯(lián)網(wǎng)的超媒體分布式系統(tǒng)的行動指南。利用任何的技術(shù)都可以實(shí)現(xiàn)這種理念。而實(shí)現(xiàn)這一軟件架構(gòu)最著名的就是HTTP協(xié)議。通常我們把REST也寫作為REST/HTTP，在實(shí)際中往往把REST理解為基于HTTP的REST軟件架構(gòu)，或者更進(jìn)一步把REST和HTTP看作為等同的概念。

    今天，HTTP是互聯(lián)網(wǎng)上應(yīng)用最廣泛的計(jì)算機(jī)協(xié)議。HTTP不是一個(gè)簡單的運(yùn)載數(shù)據(jù)的協(xié)議，而是一個(gè)具有豐富內(nèi)涵的網(wǎng)絡(luò)軟件的協(xié)議。它不僅僅能夠?qū)τ诨ヂ?lián)網(wǎng)資源進(jìn)行唯一定位，而且還能告訴我們對于該資源進(jìn)行怎樣運(yùn)作。這也是REST軟件架構(gòu)當(dāng)中最重要的兩個(gè)理念。而REST軟件架構(gòu)理念是真正理解HTTP協(xié)議而形成的。有了REST軟件架構(gòu)理念出現(xiàn)，才使得軟件業(yè)避免了對HTTP協(xié)議的片面理解。只有正確的理論指導(dǎo)，才能避免在軟件開發(fā)的實(shí)際工作過程中少走彎路。

    REST與URI（資源定位）

    REST軟件架構(gòu)之所以是一個(gè)超媒體系統(tǒng)，是因?yàn)樗�可以把網(wǎng)絡(luò)上所有資源進(jìn)行唯一的定位，不管你的文件是圖片、文件Word還是視頻文件，也不管你的文件是txt文件格式、xml文件格式還是其它文本文件格式。它利用支持HTTP的TCP/IP協(xié)議來確定互聯(lián)網(wǎng)上的資源。

    REST與CRUD原則

    REST軟件架構(gòu)遵循了CRUD原則，該原則告訴我們對于資源（包括網(wǎng)絡(luò)資源）只需要四種行為：創(chuàng)建（Create）、獲�。≧ead）、更新（Update）和銷毀（DELETE）就可以完成對其操作和處理了。其實(shí)世界萬物都是遵循這一規(guī)律：生、變、見、滅。所以計(jì)算機(jī)世界也不例外。這個(gè)原則是源自于我們對于數(shù)據(jù)庫表的數(shù)據(jù)操作：insert（生）、select（見）、update（變）和delete（滅），所以有時(shí)候CRUD也寫作為RUDI，其中的I就是insert。這四個(gè)操作是一種原子操作，即一種無法再分的操作，通過它們可以構(gòu)造復(fù)雜的操作過程，正如數(shù)學(xué)上四則運(yùn)算是數(shù)字的最基本的運(yùn)算一樣。

    REST與網(wǎng)絡(luò)服務(wù)

    盡管在Java語言世界中網(wǎng)絡(luò)服務(wù)目前是以SOAP技術(shù)為主，但是REST將是是網(wǎng)絡(luò)服務(wù)的另一選擇，并且是真正意義上的網(wǎng)絡(luò)服務(wù)�；�于REST思想的網(wǎng)絡(luò)服務(wù)不久的將來也會成為是網(wǎng)絡(luò)服務(wù)的主流技術(shù)。REST不僅僅把HTTP作為自己的數(shù)據(jù)運(yùn)輸協(xié)議，而且也作為直接進(jìn)行數(shù)據(jù)處理的工具。而當(dāng)前的網(wǎng)絡(luò)服務(wù)技術(shù)都需要使用其它手段來完成數(shù)據(jù)處理工作，它們完全獨(dú)立于HTTP協(xié)議來進(jìn)行的，這樣增加了大量的復(fù)雜軟件架構(gòu)設(shè)計(jì)工作。REST的思想充分利用了現(xiàn)有的HTTP技術(shù)的網(wǎng)絡(luò)能力。在德國電視臺上曾經(jīng)出現(xiàn)過一個(gè)這樣的五十萬歐元智力題：如何實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)才能充分利用現(xiàn)有的HTTP協(xié)議？該問題給出了四個(gè)答案：去問微軟；WSDL2.0/SOAP1.2；WS-Transfer；根本沒有。這個(gè)問題告訴我們HTTP并不是一個(gè)簡單的數(shù)據(jù)傳來傳去的協(xié)議，而是一個(gè)聰明的會表現(xiàn)自己的協(xié)議，這也許是REST = Representational State Transfer的真正含義。

    實(shí)際上目前很多大公司已經(jīng)采用了REST技術(shù)作為網(wǎng)絡(luò)服務(wù)，如Google、Amazon等。在Java語言中重要的兩個(gè)以SOAP技術(shù)開始的網(wǎng)絡(luò)服務(wù)框架XFire和Axis也把REST作為自己的另一種選擇。它們的新的項(xiàng)目分別是Apache CXF 和Axis2 。Java語言也制定關(guān)于REST網(wǎng)絡(luò)服務(wù)規(guī)范：JAX-RS: Java API for RESTful Web Services (JSR 311)。相信還會出現(xiàn)更多與REST相關(guān)的激動人心的信息。

    REST與AJAX技術(shù)

    盡管AJAX技術(shù)的出現(xiàn)才不到兩年時(shí)間，但是AJAX技術(shù)遵循了REST的一些重要原則。AJAX技術(shù)充分利用了HTTP來獲取網(wǎng)絡(luò)資源并且實(shí)現(xiàn)了HTTP沒有的對于異步數(shù)據(jù)進(jìn)行傳輸?shù)墓δ�。AJAX技術(shù)還使得軟件更好地實(shí)現(xiàn)分布性功能，在一個(gè)企業(yè)內(nèi)只要一個(gè)人下載了AJAX引擎，其它企業(yè)內(nèi)部的人員，就可以共享該資源了。AJAX技術(shù)遵守REST準(zhǔn)則的應(yīng)用程序中簡單和可伸縮的架構(gòu)，凡是采用AJAX技術(shù)的頁面簡潔而又豐富，一個(gè)頁面表現(xiàn)了豐富多彩的形態(tài)。

    AJAX技術(shù)還使用了一種不同于XML格式的JSON文件格式，這個(gè)意義在哪里呢？在REST軟件架構(gòu)下我們不能對于XML文件進(jìn)行序列化處理，這樣程序員必須要使用自己的XML綁定框架。而以序列化的JavaScript對象為基礎(chǔ)的JSON已經(jīng)獲得了廣泛認(rèn)可，它被認(rèn)為能以遠(yuǎn)比XML更好的方式來序列化和傳輸簡單數(shù)據(jù)結(jié)構(gòu)，而且它更簡潔。這對REST是一個(gè)極大貢獻(xiàn)和補(bǔ)充。

    當(dāng)前的網(wǎng)絡(luò)應(yīng)用軟件還違背了REST的“無狀態(tài)服務(wù)器”約束。REST服務(wù)器只知道自己的狀態(tài)。REST不關(guān)心客戶端的狀態(tài)，客戶端的狀態(tài)自己來管理，這是AJAX技術(shù)的應(yīng)用之地。通過AJAX技術(shù)，可以發(fā)揮有狀態(tài)網(wǎng)絡(luò)客戶機(jī)的優(yōu)勢。而REST的服務(wù)器關(guān)心的是從所有網(wǎng)絡(luò)客戶端發(fā)送到服務(wù)器操作的順序。這樣使得互聯(lián)網(wǎng)這樣一個(gè)巨大的網(wǎng)絡(luò)得到有序的管理。

    REST與Rails框架

    Ruby on Rails框架（簡稱Rails或者Rails框架）是一個(gè)基于Ruby語言的越來越流行的網(wǎng)絡(luò)應(yīng)用軟件開發(fā)框架。它提供了關(guān)于REST最好的支持，也是當(dāng)今應(yīng)用REST最成功的一個(gè)軟件開發(fā)框架。Rails框架（從版本1.2.x起）成為了第一個(gè)引入REST作為核心思想的主流網(wǎng)絡(luò)軟件開發(fā)框架。在Rails框架的充分利用了REST軟件架構(gòu)之后，人們更加堅(jiān)信REST的重要性和必要性。Rails利用REST軟件架構(gòu)思想對網(wǎng)絡(luò)服務(wù)也提供了一流的支持。從最直觀的角度看待REST，它是網(wǎng)絡(luò)服務(wù)最理想的手段，但是Rails框架把REST帶到了網(wǎng)絡(luò)應(yīng)用軟件開發(fā)框架。這是一次飛躍，讓REST的思想從網(wǎng)絡(luò)服務(wù)的應(yīng)用提升到了網(wǎng)絡(luò)應(yīng)用軟件開發(fā)。利用REST思想的simply_restful插件已經(jīng)成為了Rails框架的核心內(nèi)容。

    REST安全性

    我們把現(xiàn)有基于SOAP的網(wǎng)絡(luò)服務(wù)和基于REST/HTTP網(wǎng)絡(luò)服務(wù)作個(gè)比喻，前者是一種傳統(tǒng)的寄信方式，而后者是現(xiàn)代網(wǎng)絡(luò)的電子郵件方式。要是是寄信和電子郵件都有病毒存在的話，傳統(tǒng)的寄信被送到對方就很危險(xiǎn)，而電子郵件是開發(fā)的，電子郵件供應(yīng)商比如Google為我們檢查了電子郵件是否有病毒。這里并不是說明SOAP網(wǎng)絡(luò)服務(wù)消息包含義病毒，而是說明HTTP是無法處理SOAP信息包究竟好不好，需要額外的軟件工具解決這一問題，包括防火墻也用不上和管不了。

    REST/HTTP網(wǎng)絡(luò)服務(wù)的信息包可以被防火墻理解和控制。你可以按照操作和鏈接進(jìn)行過濾信息包，如你可以規(guī)定從外部來的只能讀�。℅ET操作）自己服務(wù)器的資源。這樣對于系統(tǒng)管理員而言使得軟件管理更為簡單。REST的安全性還可以利用傳輸安全協(xié)議SSL/TLS、基本和摘要式認(rèn)證（Basic und Digest Authentication）。除了這些REST自身的安全性功能外，還可以利用像基于信息的Web Services Security（JSR 155）作為REST不錯(cuò)的補(bǔ)充。

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：淺談CRM云技術(shù)架構(gòu)

本文網(wǎng)址：http://www.ezxoed.cn/html/solutions/1401862911.html