???電子商務系統的建設方式及技術選擇

1.1.1 電子商務系統的建設方式 電子商務系統的建設方式目前基本上有三類，第一種方式是整個系統由企業自己建設；第二種方式是委托專業的IT企業實施系統的集成和開發；第三種方式是企業和IT公司合作建設。 ??? 由于電子商務的核心是企業商務活動，所以，能否正確地理解企業的核心商務邏輯對于實現企業的商務系統至關重要。相對來講，企業的經營管理人員對業務需求最了解，所以如果企業自身具備開發電子商務系統的能力，那么由企業自己開發其商務系統比較好。 ??? 委托建設方式是指將電子商務系統的應用開發和系統集成委托給專業性的IT企業，這也是一種見效比較快的方式。目前，在Internet上提供服務的IT企業，除了Internet（接入）服務供應商ISP（Internet Service Provider）、Internet內容供應商ICP（Internet Content Provider）以外，還有一類就是所謂的Internet應用供應商ASP(Application Software Provider)，ASP專門提供電子商務系統開發與集成服務。 ??? 無論是企業獨立開發還是由ASP負責企業商務系統的開發集成，這兩種方式都需要大量的資金投入，而且存在系統投產后的維護問題。如果企業在這些方面有困難的話，目前還有一種方式也逐漸流行起來，這就是傳統的企業和ASP或者電子商務技術提供商之間合作開發企業電子商務系統。通常采取這種方式時，ASP無償地提供技術產品和應用開發，而企業以電子商務經營中的部分利潤作為回報。這種模式可能導致IT公司和傳統企業之間的聯營。例如，HP公司設計的所謂“車庫計劃”，就是這種方式的一個實例。還有，IBM公司和柯達公司的合作也是這種方式的一個特例。 ??? 以上三種方式各自有特點，比如第一種方案，企業能夠獲得電子商務系統的所有知識產權，在調整電子商務系統的結構、維護等方面有很多方便，但是對企業的技術素質要求很高。第二種方式，雖然對企業的技術力量沒有很高的要求，但是在系統的后期維護方面，企業需要付出很多精力。第三種方式，企業雖然不需要過多的初期資金投入，但需要和ASP分享系統運行后的收益。所以，無法評價哪一種是最佳的選擇。具體哪一種方案是企業建設電子商務系統時的最佳選擇，需要企業根據自身的情況進行充分地比選。 由于電子商務系統的構造技術涉及內容廣泛，可選擇的產品也各具特色，所以在實現?電子商務系統的過程中，如何選擇合適的產品或技術是一個比較復雜的問題。 1.1.2.1 選擇技術產品的主要依據 從目前的發展看，無論是傳統的IT巨人如IBM、HP、SUN、ORACLE，還是伴隨電子商務飛速發展而誕生的新興企業，如Ariba、BEA、Intervowen等，在電子商務系統的構造技術、產品方面均提出了很多不同方案。企業選擇這些技術產品的基本依據首先是考察這些產品能否滿足需要。除了這條最基本的原則外，還有一些因素會對整個系統產生全局性的影響，甚至制約系統未來的發展，所以是必須考慮的。這些需要遵循的依據包括： 1．符合各種主流的技術標準 候選產品是否符合各種主流的技術標準是最重要的一條評判依據。電子商務系統的很多技術領域已經制定了某些標準，例如TCP/IP協議。還有些領域盡管沒有統一的標準，但是存在事實性的工業標準，例如CORBA、COM等。如果候選的技術是符合這些標準的，那么所構造的電子商務系統就容易得到技術支持，而且其擴充性將會比較好。 ??? 2．符合企業信息化的整體技術戰略 ??? 某些情況下，企業為了提高生產和管理的需要，已經制定或者建立了信息技術政策，或者已經開發了相關的信息系統。在這種情況下，選擇技術產品時，就需要考慮到未來的電子商務系統是否符合企業的整體技術戰略。一般來講，企業支持不同的平臺、不同的應用系統比單純支持一個平臺要更多地在系統的移植、技術人員培訓、系統維護方面付出。例如，企業在制定整體技術策略時，已經選定以UNIX系統作為企業信息系統的主要操作系統環境，那么在建設電子商務系統時是否采用Windows平臺，就需要充分考慮企業在這一系統上的支持能力、維護成本等方面的開銷。 ??? 3．符合未來技術的發展方向 由于電子商務技術發展得很快，可能出現標準制定滯后于技術更新的情況，這可能導致選擇產品時無標準可依據。這時，需要考慮候選技術產品是否符合未來技術的發展方向。例如，考察一個產品是否易于集成、是否具有可重用的特征時，盡管沒有標準，但是可能會發現至少J2EE、CORBA和COM是比較流行的，被公認為未來產品發展的方向，這樣可以采取的策略就是盡可能地選擇主流的、有代表性的產品，以保證系統是有生命力的。 ??? 4．滿足開放、可擴充的要求 ??? 滿足開放性的要求，不僅意味著電子商務系統可以獨立于硬件、操作系統，系統開發建設中能夠獲得更多的技術支持，容易升級，而且開放的系統結構可以和企業已有的信息資源集成。 ??? 產品的可擴充性好，則意味著一旦我們的需求發生變化，系統能夠盡快的得到擴充，原有的投入得到有效的保護，從而在整體上得到良好的投入產出效益。例如，我們在選擇 Web服務器時，如果候選的產品支持服務器集群，那么當計算機的處理能力不能滿足業務增長的要求時，就可以僅僅擴充硬件資源，而不必重新開發Web上的應用程序，這樣可以減少應用升級的開銷。 ??? 5．與現行的應用具有良好的兼容性 ??? 兼容現行的應用表明電子商務系統可以有效地利用已有的信息資源，節約投資，實現信息的增值。??? 、 ??? 例如，企業內部通過Lotus Notes建立了工作流(Work Flows)系統，而在實現電子商務系統的過程中，需要將原有的基于工作流的應用擴充到Web平臺上，如果候選平臺和已有系統兼容并且能夠共享數據，這就可以減少數據轉換方面的開銷。 ??? 6. 具有成功的應用實例 ??? 一般來講，優秀的產品或者技術應用得更加廣泛。所以在選擇技術產品的過程中，應當盡可能地考察這一產品在相關的領域中的應用效果，通過考察候選技術產品的市場占有率、是否存在成功的案例為評價產品的先進性提供重要的參考依據。 所以，以上的一些原則可以作為選擇電子商務系統構造技術或者產品的基本依據。在選擇過程中(參見圖1-1)，將上述的一些依據作為一種過濾器，通過多層次的比較，可以得出綜合效果比較滿意的結果。 ????????????? ? 圖12－1 產品/技術的選擇 1.1.2.2 各個層次的主要技術標準 ??? 前面談到了判斷候選的技術產品是否滿足標準或者事實上的工業標準，這是選擇產品的一個主要依據。以下闡述構造電子商務系統時，在不同層次上應當遵循的主要技術標準或規范。 ??? 電子商務相關的標準或者規范基本上可分成兩大類，一類針對商務活動，另外一類針對支持商務活動的技術環境。 ??? 1．商務標準及規范 ??? 該部分主要涉及商務活動中的單據票證、數據自動識別、交易及支付、貿易數據安全等方面。目前這方面的技術規范體系不很完整，已有的一些標準規范主要包括： ??? (1)國際數字保證商務總則(GUIDEC：General Usage for International Digitally Ensured Commerce) 。該標準于1997年由國際商會在法國舉行的世界電子商務會議上確定。其主要內容包括電子商務在全球范圍內統一實施的規則和框架。 ??? (2)EDI標準UN／EDIFACT ??? 1987年，聯合國公布了EDI運作標準UN/EDIFACT(United Nations Rules for Electronic Data Interchange for Administration，Commerce and Transport)，并且每年進行修訂。1990年3月正式推出UN/EDIFACT標準，并被國際標準化組織正式接受為國際標準IS09735。 ??? UN/EDIFACT實際上定義了傳統EDI中關于國際貿易或者無紙貿易的有關標準。雖然這種方式有一定的局限性，但是該標準關于交易過程、電子數據交換的格式等方面的闡述對電子交易過程的標準化有很多借鑒意義。 ??? (3)Internet開放貿易標準協議IOTP ??? 1998年Internet協會成立了專門進行電子商務標準化的研究小組，并且給出了相關的 Internet開放貿易標準協議IOTP(Internet Open Trading Protocol)的建議標準。該建議的主要貢獻之一是提出了Internet商務的互操作框架。此外，該組織還提出了其他一些準則，其中有影響的包括： ●????????? IOTP的HTPP補充部分 ●????????? IOTP的數字簽名補充部分 ??? (4)聯機交易及在線支付方面的標準 ??? 這一領域的標準，主要針對聯機交易過程的安全、交易過程的不可抵賴性、數據的不可竊取及數據加密等方面。目前主要的標準規范有： ●????????? 安全超文本傳輸協議(S-HTTP)：依靠密鑰對的加密，保障Web站點間的交易信息傳輸的安全性。 ●????????? 安全套接層協議(SSL)：由Netscape公司提出的安全交易協議，提供加密、認證服務和報文的完整性。SSL被用于Netscape Communicator和Microsoft IE瀏覽器，以完成需要的安全交易操作。 ●????????? 安全交易技術協議(STT，Secure Transaction Technology)：由Microsoft公司提出，STT將認證和解密在瀏覽器中分離開，用以提高安全控制能力。Microsoft在Internet Explorer中采用這一技術。 ●?????????安全電子交易協議(SET，Secure Electronic Transaction) ??? 1996年6月，由IBM、Master Card International、Visa International、Microsoft、Netscape、 GTE、VeriSign、SAIC、Terisa就共同制定的標準SET發布公告，并于1997年5月底發布了SET Specification Version l.0，它涵蓋了信用卡在電子商務交易中的交易協定、信息保密、資料完整及數據認證、數據簽名等。SET 2.0中增加了——些附加的交易要求。SET規范明確的主要目標是保障付款安全，確定應用之互通性，并使全球市場接受。 ??? (5)電子支付的有關標準 ??? 電子支付標準主要定義的是支付手段和方式。主要的一些標準包括： ●????????? 聯合電子支付(JEPI) ??? JEPI(Joint Electronic Payment Interface)的主要定義支付過程中支付方式的選擇、自動支付的接口。JEPI的目標是為不同的支付協議，提供公共的支付平臺。 ●????????? 金融業務標記語言(FSML) ??? FSML目前主要定義的是電子支票的有關規范。該標準為美國財政部采用。FSML是標準通用標記語言SGML(Standard General Markup Language)中的一個子集。 ??? (6)數據自動識別技術標準 ??? 該部分的標準主要用于商業數據的自動識別方面，其中比較典型的代表是條形碼技術標準，例如二維條形碼的PDF標準等。 ??? 2．技術標準及規范 ??? 技術標準比商務標準制定得早，相對比較完整，大部分內容得到廣泛的認可，并融入技術產品當中。這些技術標準主要分成以下幾個層次： ??? (1)網絡技術標準 ??? 計算機網絡和數據通信方面技術標準最完整，對應于電子商務體系結構中的“基礎支持層”。可以分成以下幾個層次： ●????????? 計算機網絡體系結構標準(如ISOOSI/RM，TCP/IP協議族)。 ●????????? 網絡體系結構中各個層次的協議標準(例如物理層當中的RS232、數據鏈路層中的HDLC等)。 ●????????? 各種數據通信網的協議，例如公共分組交換網PSDN當中的X.25協議標準等。 ??? (2)計算機系統及設備標準 ??? 主要包括計算機主機系統、多媒體設備、計算機系統的外部環境、系統管理、接口等方面的標準。 ??? (3)信息安全標準 ??? 信息安全標準包括傳統的密碼學中有關規范和計算機數據安全的一些標準。例如DES、 RSA、PKI、PGP等。 ??? (4)應用軟件及開發標準 ??? 該部分主要用以規范用戶界面(例如OSF的GDE)、圖形圖像(例如GIF、JPG)、操作系統服務、數據管理、國際化／本地化等方面。例如X.Open組織的CDE(Common Desktop? Environment)等?！?/span> 1.2 電子商務系統的實現過程 電子商務系統的實現過程如圖1-2所示。 1.2.1應用表達層的實現 該層最終由多種客戶端構成，其硬件設備主要是各種客戶端應用程序運行的終端設備，例如計算機、移動通信設備等。 ??? 客戶端的應用程序分成兩大類，最常見的是通用的瀏覽器，也就是通常說的瘦客戶機。此外客戶端也可以是一些專用的應用程序，以支持專門的應用。 ??? 構造電子商務系統的客戶端的關鍵是要確定客戶端的類型并選擇合適的設備，使客戶端和電子商務系統的服務器之間具有良好的接口。 ??? 1.2.2 商務邏輯層的實現 ??? 商務邏輯層是電子商務系統的核心，也是系統建造過程中的難點和重點。商務邏輯層包括商務應用（程序）、支持平臺（包括商務服務層、商務支持層和基礎支持層三部分）。 ? 圖1-2? 電子商務系統的實現過程示意圖 ??? 支持平臺向上層(商務應用)提供的服務主要包括：表達、商務支持、運行支持、開發和集成服務。構成支持平臺的技術產品至少應當包括： ●????????? Web服務器 ●????????? 商務支持軟件 ●????????? 集成與開發工具 ●????????? 計算機主機 ●????????? 網絡 ●????????? 其他系統軟件(如操作系統、管理工具軟件等) ??? 通常以上內容中，Web服務器、商務支持軟件、部分集成開發工具被集中在一個稱之為“應用服務器”（在本章的后續章節中專門介紹）的軟件包中，所以商務邏輯層在物理上可以簡化為以下三個部分： ●????????? 應用軟件(實現商務邏輯) ●????????? 應用服務器(為應用軟件提供軟件支持平臺)和其他支持軟件 ●????????? 計算機主機及網絡(為應用軟件提供硬件支持平臺) ??? 構造商務邏輯層的任務基本上可以歸納為兩部分：選擇合適的應用服務器及其他支持軟件，開發實現商務邏輯的應用軟件系統。 ??? 1.2.3 數據層的實現 ??? 構造數據層的關鍵是開發電子商務系統與外部系統、內部信息資源的接口，完成系統集成。 ??? 數據層的數據源主要包括以下幾部分： ●????????? 系統既有信息系統(如ERP系統等)的數據和企業的數據庫； ●????????? 企業與協作伙伴(例如供應商等)之間交換的數據： ●????????? 企業與銀行之間交換的數據； ●????????? 企業與認證中心之間的認證數據： ●????????? 企業與其他商務中介交換的電子數據。 ??? 由于企業商務邏輯的處理過程是一個從市場、銷售、采購到客戶服務的整體，所以必須將商務邏輯處理過程所涉及到的數據集成在一起，因此構造數據層的任務是： ●????????? 實現電子商務系統與企業內部和外部信息系統之間的網絡互聯，并確保安全的網絡環境。 ●????????? 基于應用服務器平臺的商務應用系統與企業內部數據的共享。 ??? 通過以上的分析，可以將電子商務系統的實現過程的關鍵分為： ??? (1)技術支持平臺的選擇與構造 ??? (2)應用系統的開發 ??? (3)網絡系統集成 ??? (4)數據共享及應用的互操作 ??? (5)實施過程的合理組織 　 1.3 客戶端的實現方式 　　客戶端(Client)是電子商務系統的最終用戶接口。它包括兩層含義，首先指的是客戶端的應用程序(例如瀏覽器)：其次，這一概念也指運行客戶端應用程序的具體硬件設備(例如PC機、PDA設備等)。 ??? 1.3.1 客戶端的分類 ??? 　　從設備角度，可以將客戶端分成普通計算機(包括PC、工作站等)、移動終端(如手機、PDA、尋呼機等)、其他信息終端(例如通過無線或有線方式與電子商務系統連接的家用電器、ATM取款機等)。?　　從邏輯結構角度，可以將客戶端分成基于瀏覽器的瘦客戶端(Thin Client)、有數據處理功能的傳統客戶端(即所謂的胖客戶端：Fat Client)。?? 　　從應用角度可以將客戶端分為通用的客戶端(例如Netscape公司的Navigator、Microsoft公司的IE)、專用的客戶端(例如PointCast(http://www.pointcast.com)公司的專門服務于接收信息廣播的程序BroadCast，從網絡上接受數字語音的RealPlayer等)。 ??? 1.3.2客戶端的特點 ●????????? 通過Internet可以和電子商務系統連接，并進行交互。 ●????????? 一般具有圖形用戶界面GUI(Graphic User Interface)，如果無GUI界面，那么需要具有易于非專業用戶使用的特征。 ●????????? 客戶端一般需要支持電子商務系統表示層的各種格式化數據表達標準，例如HTML、XML、WML等。 ●????????? 如果客戶端是專用的，那么其一般支持HTML／WML的子集或者Java標準。 ??? 1.3.3 客戶端設備及要求 ??? 　　客戶端設備在技術上，應當滿足以下要求： ●????????? 支持標準協議(HTML、WML、XML)，最好具備GUI界面。 ●????????? 能夠從網絡上下載插件(例如Browser中的Plug-ins)。 ●????????? 支持聯機診斷或者在線升級(Online Update)。 ??? 1.3.4 客戶端的選擇 ??? 　　客戶端盡管不是電子商務系統最關鍵的部分，而且通常由客戶自己選擇，但它直接影響系統服務能否真實地再現，因此電子商務系統的建造者應當給客戶提供如何應用的建議。 　　一般來講，選擇客戶端時，應當注意以下問題： ??? (1)盡可能地選擇通用瀏覽器作為商務邏輯表達的客戶端，以減少維護及升級的開銷，并保證系統支持盡可能多的用戶。 ??? (2)在使用專門的客戶端應用軟件時，也盡量遵循以下原則： ●????????? 將專用的客戶端應用設計成可以嵌入到通用瀏覽器中的插件(Plug-ins)，這樣能夠保證應用得到最廣泛的支持。例如，Adobe(http://www.adobe.com)的Acrobat Reader，Microsoft的Word等就能夠作為插件在瀏覽器中使用，使用戶在瀏覽器中閱讀Word格式或者PDF格式的文件。 ●????????? 如果專用客戶端應用無法作為瀏覽器插件，那么應當盡量使客戶能夠通過Internet完成在線下載和升級。例如著名的防病毒程序Norton Antivirus就是一個典型例子。 1.4 商務表達平臺的實現 1.4.1 商務表達層的主要標準 商務表達層支持的標準主要是有關數據表達方式和形式的標準，主要包括： ●????????? 超文本傳輸協議：HTTP ●????????? 動態超文本傳輸協議：DHTML ●????????? 無線應用協議：WAP ●????????? 擴展超文本協議：XML ●????????? 多媒體函件類型擴展協議：MIME(Multimedia Internet Mail Extension) ●????????? 其他的一些數據表達協議，例如FSML、DOM、CSS等。 1.4.2 商務表達層的實現 商務表達層目前主要可以通過以下三種方式實現(參見圖1-3)。 (1)利用Web，支持以HTML為主的表達形式 ??? 這種方式是使用比較多的一種方案。它的特點是： ●????????? 結構簡單。只需要以Web服務器為基礎，不需要額外的配置或產品支持，容易實現。 ●????????? 只能夠支持HTML或XML的客戶端，不直接支持符合WML標準的移動設備。應用范圍稍窄。 ??? (2)在Web基礎上增加表達工具，擴展Web的既有表達功能 ??? 這種方式是在第一種方式的基礎上，增加支持多種客戶終端的軟件、硬件，使Web服務器不僅支持HTML，還支持其他數據表達方式，從而擴充了Web的功能。 這種方式的好處在于可以有針對性地擴充Web的功能，使商務處理結果能夠利用多種渠道由多種客戶端表達。但是由于需要在Web上增加獨立的產品，所以增加了系統集成的難度。 目前，很多產品可以通過這種方式擴展Web的功能，例如專門在無線信息服務領域拓展的Vignette（http://www.vignette.com）公司的V/5Deployment Server就是這樣一種有特色的產品。MediaBridge（http://www.mediabridge.net）公司的smartmedia.server除了支持WML外，還可以通過有線電視(CATV)實現數據的發布。 ??????????????????????????? ??????????????? 圖1-3? 客戶端及表達層實現方式示意圖 ??? (3)利用應用服務器的數據發布功能 ??? 由于應用服務器將數據表達層的功能和Web服務器緊密地結合在一起，所以可直接利用應用服務器來完成表達層的功能。 ??? 一般的，目前的應用服務器逐步走向支持多種客戶端設備(如計算機、PDA、移動通信設備)和多種協議標準(如HTML、WML和XML)。例如，Oracle公司的iExchange、 Microsoft的SiteSuite、SUN和AOL聯盟的i-Planet NAS等。 ??? 采用應用服務器來實現應用表達層的功能，好處在于集成難度小，表達部分和應用程序之間的接口比較容易實現。但是，由于目前各個IT廠商提供的應用服務器功能差異比較大，有些產品在表達層上有不足之處，但在其他方面可能功能比較強；有的則可能在表達層次上實現得很好，但是在商務服務層次則有缺點。所以開發者需要在這些方面進行取舍和選擇。 　 1.5 商務支持平臺與應用服務器 應用服務器是一個軟件包，它將一些通用的、與商務應用無關的軟件集成為一個整體。由于應用服務器預裝(pre-install)了部分功能，并提供了一些開發工具，所以在其基礎上開發應用軟件，能夠簡化用戶的接口，減少開發的難度。 從電子商務系統的體系結構上看，應用服務器是商務支持層、商務服務層和基礎服務層的某些功能的一個集合。 1.5.1 應用服務器基本結構 ??? 從本質上講，應用服務器仍然是支持商務應用的一個運行、支持和開發環境，它為商務系統的核心——應用軟件提供服務。 ??? 應用服務器為應用軟件提供的服務主要包括：首先是預安裝的部分商務功能(例如搜索引擎Search Engine、內容管理Content Manage)，減少了應用開發工作量。其次是系統管理部分，可提高系統的效率。還有就是提供集成與開發工具，便于與其他系統進行集成。 應用服務器的基本結構如圖1-4所示。 ? 圖12－4 Web服務器與應用服務器 ?? ?目前應用服務器的內容主要包括兩部分：一部分是增強型的Web服務器，另外一部分是專門為應用提供服務的部分。這兩個部分在某些產品中是合并在一起提供的，例如IBM Websphere、BEA的Weblogic。也有些公司將這兩部分作為兩個獨立的產品分開提供，例如 iPlanet。 ??? 1．增強型Web服務器 ??? 應用服務器軟件包中的WebServer盡管也以HTTPD為核心，但增強了很多功能，主要包括： ●????????? 靜態Web頁面(包括HTML和DHTML)發布 ●????????? 動態頁面腳本(如JSP、ASP、Servlet和Java Applet等) ●????????? 用戶自定義的MIME類型信息的發布 ●????????? Java虛擬機(JVM) ●????????? 傳統的HTTPD服務 ●????????? 服務器管理功能(例如頁面訪問控制、Web訪問統計、Web服務器配置等) ●????????? Web開發接口(例如NSAPI、ISAPI等) ??? 2．應用服務器(Application Server) ??? 從邏輯角度看，應用服務器與Web服務器相互配合共同完成商務邏輯。Web服務器向應用服務器提供用戶的請求，并表達處理的結果。而應用服務器及其上層的應用負責完成商務邏輯的處理，并反饋處理的結果。 ??? 應用服務器和Web服務器有很大的差別，體現在： ??? (1)Web服務器只能將應用程序處理結果以HTML頁面的形式發布給用戶。例如，如果應用程序需要和IBM的MainFrame（如3270）交互，從IBM3270這樣的專用系統中提取數據，那么Web服務器是無能為力的，而應用服務器則可能提供與IBM大型機的中間件接口，使應用程序可以很容易地存取數據。 ??? (2)應用服務器可為企業級應用提供一種可靠的、高性能的運行環境，而Web服務器是無法做到這一點的。 ??? (3)應用服務器可以提供很多預先安裝的(或者預置)服務，例如搜索引擎、內容管理等，這樣開發人員實現這些功能時，不再需要額外地開發，可以直接通過系統調用實現,這樣開發的工作量能夠減少。 ??? (4)由于很多應用服務器預先配置和快速構造商務模型的組件，企業可以迅速地建立商務邏輯。例如一個從事B2B的企業試圖建立虛擬電子市場，假如以Oracle的iExchange為平臺，企業僅需要通過定義角色，不再投入很多開發力量編寫復雜的應用程序，僅需要在此平臺上定義相關規則，就可以快速地建立起一個電子交易市場。 1.5.2 應用服務器功能 ??? 目前應用服務器的版本很多，其功能差異也較大，可以提供的服務主要包括： ??? 1．高性能的應用程序運行環境 ??? (1)內容緩存（Content Cache） ??? 當用戶訪問Web服務器，存取HTML頁面時，一般Web服務器需要從硬盤上讀取HTML文件，然后傳輸給用戶。每次用戶訪問，Web服務器都重復相同的處理過程。 ??? 內容緩存則將用戶經常訪問的HTML頁面或者Web處理結果存儲在服務器的內存當中，在用戶請求某一服務時，服務器首先從內存中檢索是否有相應的結果，如果存在，則不必重新處理，而直接將結果返給用戶。由于內存的存取速度遠比硬盤的存取速度快，所以服務器如果支持內容緩存功能，那么系統的響應時間可以縮短。 ??? (2)數據庫連接緩存（Connection Pool） ??? 通常用戶通過Web服務器訪問數據庫時，Web上的應用程序和數據庫服務器之間需要首先建立連接，然后才能存取數據，在處理結束后，這種連接被關閉。每次用戶訪問都需要重復這樣的步驟。由于數據庫連接過程比較消耗系統資源，而且時間開銷也比較大，尤其是利用公共網關接口CGI（Common Gateway Interface）進行連接時，效率尤其低，通常情況下連接過程對系統響應時間的影響是很大的。 ??? 數據庫連接緩存是指在Web服務器和數據庫服務器之間建立經常性的連接，當用戶需要訪問數據庫時，直接利用這些已經存在的連接，操作結束后，連接仍然保持而不被關閉，這樣一來，用戶訪問數據庫的步驟被簡化，進而提升系統的效率。 ??? (3)支持進程的多線程（multi-thread）執行：該功能是將一個進程分解成為多個可以獨立的線程并行運行，提高應用程序的運行效率，縮短運行時間。 ??? (4)大量用戶訪問情況下的負載均衡：該功能根據用戶訪問量及服務器的處理能力，動態調整每個服務器的負載，使服務器的處理能力和負載之間保持平衡，提高系統的可靠性和整個系統的性能。 ??? (5)支持分布式聯機事務處理（OLTP） ??? 2．為應用提供擴充性（scalability） ??? 由于電子商務系統在規劃設計階段難以精確預測未來服務的客戶數量，而且預測其客戶增長的速度也比較難，所以，電子商務應用系統應當具備良好的可擴展性能。應用服務器主要通過三種方式提高系統可擴充性，首先是利用服務器集群(詳見第6章)技術，將系統壓力分攤在集群服務器中的各個設備上去。其次，應用服務器大多支持多CPU系統，從而在系統訪問壓力增加時，通過增加服務器CPU來提高系統的處理能力。第三，一些優秀的應用服務器還提供應用的動態負荷均衡（Load Balancing），使服務器的性能和訪問壓力之間得到匹配。 ??? 3．會話管理（Session Management） ??? 用戶一般通過和電子商務系統進行對話來完成商務活動。以一次網絡購物過程為例，用戶經常要經過多次挑選才能夠確定購物清單，每次挑選貨物并將其放入購物車的過程就是一次會話過程。如果計算機系統無法記錄用戶的購物清單的話，那么必須要求用戶一邊在線挑選，一邊用紙筆記錄，否則在付款時可能發現難以回憶起整個購物過程中都買了些什么商品，這是一件時常發生但又令人尷尬的事情。 ??? 會話管理的作用是記錄和管理客戶的每次人機會話過程。應用服務器如果支持會話管理功能，那么如果用戶重復上述的購物過程，付款時，電子商務系統會自動地提供其購買清單。因此，如果一次商務活動必須經過多個復雜的步驟才能完成，會話管理是非常重要的。 ??? 4．支持多種應用編程模式 ??? 在應用服務器的基礎上開發應用程序，除了可以使用多種語言外，也可以采取多種編寫程序的方式。具體來講包括以下的內容： ??? (1)應用表達：JSP、Servlet、JAVA應用 ??? (2)商務邏輯：Java Beans、EJB等 ??? (3)數據庫存取：JDBC、ODBC等 ??? (4)應用集成：XML、CORBA等 ??? 5．目錄及內容管理 ??? 應用服務器——般提供目錄管理和內容管理工具。利用這些工具可以完成用戶訪問內容的控制、分層數據組織、目錄更新及控制等服務。 ??? 6．商務引擎 ??? 商務引擎主要是為商務系統提供業務支持，它所提供的服務主要包括：個性化服務（例如BEA的WebLogic Personal Server）、客戶關系管理CRM（例如BroadVision、Oracle公司的產品）、供應鏈管理、電子交易市場（如Oracle iExchange）等。但是不同的應用服務器產品在這一方面的差異很大。 ??? 7．系統管理 ??? 目前應用服務器都提供系統管理工具，具體功能包括： ??? (1)性能配置管理 ??? 性能管理主要圍繞為商務應用配置合適的系統資源。例如對服務進程數的調整、結果緩存（result cache）大小的調整等。 ??? (2)存取控制管理 ??? 存取控制管理也可以稱為訪問控制（Access Control），其目的是對系統資源的訪問權限進行限制，保護特定內容的安全。例如控制只有特定權限的用戶才能訪問系統當中的某些應用或者頁面等。 ??? (3)系統日志管理 ??? 這一功能對系統訪問、應用運行、存取失敗等情況進行記錄，從而為系統的故障診斷、分析和性能優化提供依據。 1.5.3 主流應用服務器產品 應用服務器產品很多，但是流行的應用服務器主要包括：BEA公司的WebLogic產品家族、IBM的Webshpere、AOL和SUN聯盟的iPlanet、Microsoft的IIS及SiteSuite。這些產品的基本特點如表12-1所示： 　 表12-1??? ?????????????????????????????????????????????? 主流應用服務器產品的比較 ??? 產品名稱??? ?????????????????????????????????????????????? 支?持??? ?????????????????????????????????????? 服?務 BEA WebLogic Server?? ??????????????????????? HTTP，HTML，XML,WML?????????? 靜態頁間 JSP，SEVELET??? ??????????????????????????????????????????????????? 動態頁面 SSL，X．509，ACL?? ??????????????????????????????????? 安全 J2EE, EJB??? ???????????????????????????????????????????????????????????????????????????????????????? ? Java2 Enterprise Edition CORBA，??? ????????????????????????????????????????????????????????????????????? ? Enterprise Java Bean TUXED/JOLT??? ??????????????????????????????????????????????????????? ? 組件標準 RMI??? ???????????????????????????????????????????????????????????????????????????????????????? ? 事務處理 JMS??? ??????????????????????????????????????????????????????????????????????????????????????? ? 遠程方法調用 BEA WebLogicPersonalServer?Personalized Service????????????????????????? ? 基于Java的可靠消息規則 ????????? 內容管理 BEA WebLogicCommerceServer?Busiffess Service ???????????????????????????????? 用戶和組管理 Collaboration Server??? ????????????????????????????????????????????????????? (含Session Management，??????????? Web頁面管理 Production Management，???????????? 會話管理、客戶管理、 CRM)??? ????????????????????????????????????????????????????????????????????????????????????? 購物指導，贈品管理、 ?????????? 定單管理、產品管理、 ?????????? 庫存管理、發票管理、 ?????????? 配送系統管理和客戶服務 IBM Websphere Standard，??? HTTP，HTML，XML，WML??? ?????????靜態頁面 WebSphere Advanced Server?? JSP，Servelet??? ???????????????????????????? 動態頁面 WebsphereEnterpriseServer?? HTTPS，SSL，X．509，ACL 安全 J2EE??? ?????????????????????????????? ??? ?????????????? ??????? Java2 Enterprise Edition EJB??? ????????????????????????????????????????? ??????? ?????????? Enterprise Java Bean CORBA??? ??????????????????????????????????? ??????? ?? 組件標準 XA??? ?????????????????????????????????????????? ??????? ?事務處理 MQSeries??? ????????????????????????????????????????????????????????????????????? 傳輸中間件 SUN和Netscape聯盟的i-Planet?HTTP，HTML，XML,WML?? ???????? ????????? 靜態頁面 ?????????????????????????????????????????????????????????????????????????? JSP，Servlet??????????????????????????????????????????????????????????????????????? 動態頁面 ?????????????????????????????????????????????????????????????????????????? SSL, X.509, ACL??????????????????????????????????????????????? 安全 ?????????????????????????????????????????????????????????????????????????? J2EE,???????????????????????????????????????????????????????????????????????????????????? Java2 Enterprise Edition ?????????????????????????????????????????????????????????????????????????? EJB????????????????????????????????????????????????????????????????????????????????????????????????????????? Enterprise Java Bean ?NetscapeApp Server ???????????????????????????? 應用集成 ?CORBA??? ???????????????????????????????????????????????????????????????????????? 組件標準 Netscape App. Server?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 應用集成 ?(NetDynamic) Calendar Server????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 消息處理 Directory Server?????????????????????????????????????? LDAP??????????????????????????????????????????????????????????????????????????????????????????????????????????????? 目錄管理/內容管理 TradingXpert & ECXpert?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 銷售、采購、庫存、市場等 ?????????? 商務活動支持、 Microsoft Internet ??????????????????????????????????? HTTP，HTML，XML,WML Information Server(IIS)??? SiteSuite??? ???????????????????????????????????????????? SSL，X.509，ACL ASP??? ??????????????????????????????????????????????????????????????????????????????????????? Active Server Page COM?????????????????????????????????????????????? ??????? ?Microsoft 組件模型 ISAPI???????????????????????????????????????????????????????????????????????????????????? 服務器開發接口

1.6 基礎支持平臺的實現 ??? 基礎支持層提供電子商務系統的運行環境、集成接口和開發環境。構造基礎支持平臺主要涉及到計算機網絡環境、計算機系統、系統集成及開發方面的有關標準以及產品的選擇。 1.6.1 網絡環境的構建 ??? 電子商務系統的網絡環境可以分成Internet、Intranet和Extranet三個組成部分。其基本的邏輯結構如圖1-5所示。 ??? 一個良好的電子商務系統的網絡環境應當滿足以下要求： ●????????? 支持網絡的互聯和應用的互操作 ●????????? 能夠隔離和控制不同用戶對系統的訪問，保證網絡設備的安全 ●????????? 網絡環境是可以管理的 ??? 電子商務系統的網絡環境的每個部分都有不同的要求，以下進行說明。 ??? 1．Internet部分 ?? ?Internet部分是企業電子商務系統的用戶訪問接口，是企業與客戶之間相互交流的通道。建設電子商務系統Internet部分的目的主要是實現企業Intranet和Internet之間的互聯，它的主要內容包括兩部分接口方式、接口規格的設計以及相互連接。 ??? 電子商務系統與Internet的互聯方式很多。目前常見的方式是通過公共電話網、數字數據網DDN(例如ChinaDDN)、分組交換網PSDN(如ChinaPAC)等方式將企業電子商務系統接入Internet。 ?? ?2．電子商務系統的局域網部分 ?? ?電子商務系統Web服務器、應用服務器等一般運行于局域網上（參考圖1-5、圖1-6）。該局域網一般需要滿足以下要求： (1)由于用戶通過Internet訪問服務器時，要求比較高的響應速度，因此，需要在局域網上配置高性能的服務器，而且要求網絡具備較高的帶寬，并且該局域網一般利用LAN Switch構造。圖1-6所示的就是這種交換式的局域網。 ? 圖12－5 電子商務系統網絡結構示意圖 圖1—6? 一個電子商務系統LAN配置示意圖 ??? (2)電子商務系統的局域網必須具備隔離措施，提供可靠的和安全的網絡環境。 電子商務系統的局域網不僅和Internet互聯，而且基本上還需要和企業的內部網絡連接。這種情況下，LAN上的主機設備、應用系統和企業內部信息系統在理論上都存在被非法用戶入侵的可能。如果商務應用系統一旦遭到惡意攻擊，那么企業的商務活動就可能受到影響，所以強化網絡的安全是非常必要的。一般可以采取以下的一些措施減少系統遭受破壞的可能： ●????????? 設置防火墻（Firewall），將網絡隔離成敏感程度不同的區域 ??? 將企業的電子商務系統LAN和Internet、LAN和企業內部網絡之間劃分為兩個信任程度不同的區域。可以設置兩道防火墻，分別隔離電子商務系統與Internet、電子商務系統與企業內部信息系統，允許Internet用戶訪問LAN上的應用系統，只允許得到授權的內部用戶訪問企業內部的信息資源。 ??? 值得指出的是：防火墻基本上都是通過對IP報文進行地址過濾，實現授權訪問，但是防火墻設置的層次越多，系統響應時間就越會延遲。因此，當設置防火墻時，究竟劃分多少個不同信任等級的區域，需要充分考慮這一點。 ●????????? 將網絡劃分為信任等級不同的網段，通過路由設備隔離 ??? 根據LAN上各類設備的服務對象不同，可以將這些設備分別設置在不同的IP網段。在不同網段之間設置路由設備，可以隔離不同安全級別的主機。例如Web服務器主要由用戶訪問，應用服務器、數據庫服務器則主要由系統用戶來訪問，于是，可以將必須直接面對用戶的設備作為一個網段，而將其他的設備配置在其他的網段。 ??? 3．Intranet和Extranet ??? 從電子商務系統體系結構來看，Intranet建設所包含的主要任務是完成內部信息系統和電子商務系統的互聯問題，而Extranet建設所要完成的任務則主要是電子商務系統如何和外部信息系統(例如銀行、CA等)的互聯問題。 ??? 從技術角度看，Intranet和Extranet建設涉及的主要是互聯問題，這種互聯是在兩個層次上實現的。 ??? (1)低層互聯 ??? 低層互聯是指企業內部信息系統或者外部信息系統與電子商務系統之間通信子網的連通。 ??? Extranet的通信子網是一個VPN(Virtual Private Network)，可以在多種數據通信網(如 DDN、PSDN、PSTN、F.R等)的基礎上構造。 ??? (2)高層互聯 ??? 高層互聯是指Intranet或Extranet上的應用程序和電子商務系統的應用程序之間能夠相互通信，交換數據。其目標是解決應用的互操作及數據共享問題。 ??? 對Extranet而言，高層互聯至少需要解決三個方面的問題： ●????????? 銀行支付網關(Payment Gateway)接口。利用該支付網關接口，電子商務系統完成在線支付請求。 ●????????? 認證中心(CA)接口。利用該接口，電子商務系統與認證中心間完成電子證書及認證結果的傳遞。 ●????????? 企業合作伙伴的接口。該接口主要實現電子商務系統的應用程序和企業重要客戶 (VIP)、企業供貨商等的電子數據交換。傳統的EDI部分也屬于這樣一類接口。 ??? 從實施的角度看，電子商務系統的網絡環境除了由用戶自己獨立建造外，還可以采取以下方式實現： ??? (1)主機托管：這是企業電子商務環境外包建設的最原始的形式。其主要特征是：電子商務系統的擁有者將主機系統安裝在數據通信網絡運營商提供的環境中，由網絡運營商提供高速網絡及維護接口，并由其負責進行硬件維護。 ??? (2)利用Internet數據中心IDC(Intelligent Data Center)建立電子商務系統的網絡環境。數據中心將寬帶網絡、高性能設備及系統運行管理軟件等集成在一起，為電子商務系統經營者提供一攬子服務。 1.6.2 服務器主機及操作系統選擇

1．服務器選擇 ??? 電子商務系統的服務器主機是應用系統運行的主要環境。對電子商務系統而言，它所面臨的是用戶對系統響應時間的苛刻要求、動態變化和難以預估的未來負荷、未知的升級周期等特殊的問題。所以在選擇服務器的主機時，除了遵循高性能、網絡吞吐量大、可靠性和可用性好這樣一些基本原則外，還應當注意以下問題： ??? (1)可靠性高、安全性好 ??? 電子商務系統所支持的企業商務活動要求7×24小時不間斷地工作，而且系統處理的數據很多是企業敏感的商務數據。為此，電子商務系統的服務器必須具備非常良好的安全性。所以，應當注意服務器是否支持諸如自動系統恢復（auto recover）、動態系統重新配置（dynamic? re-configuration）、模塊化結構、冗余或可熱更換關鍵部件、在線升級等特性。 ??? (2)可擴展性 ??? 當系統的負荷增大到一定程度時，需要對系統進行擴展。系統擴展方式主要有兩種：一種是增加系統的配置，例如增加內存、更換CPU、增加系統外部存儲設備等。另外一種是通過增加服務器，建立服務器集群來滿足需求增長的要求。不管是哪種方式都要求系統具有可擴展的體系結構（例如冗余插槽、托架、電源等）。 ??? (3)網絡吞吐量及網絡接口能力 ??? 服務器的計算能力和網絡吞吐量不一定呈線性關系，例如應用于計算機仿真領域的某些高性能計算機的CPU運算性能、圖形處理能力很強，但其網絡接口及網絡吞吐量卻非常有限。由于電子商務系統的服務器必須在大量用戶訪問的情況下仍然能夠具備良好的響應時間，所以相對來說，在選擇服務器時，應當首先考慮網絡吞吐能力是否滿足要求。 ??? 此外，服務器的網絡適配器類型及插槽的數量差別也很大，在選擇過程中，需要注意選擇網絡適配器類型和接口都較多的產品。 ??? (4)開放的體系結構 ??? 服務器是否具有開放的體系結構直接影響到系統日后的升級換代和維護問題。專用體系結構的計算機設備（例如IBM AS/400、Compaq Tandam系列）雖然有良好的整體性能，但在系統升級和維護方面有一定風險。 ??? 2．操作系統及系統管理軟件的選擇 ??? 除了服務器外，構成電子商務系統基礎環境的還包括操作系統、系統管理軟件。目前操作系統分成三大主流： ●????????? UNIX系統：主要包括IBM的AIX，SUN公司的Solaris，HP公司的HP-UX，COMPAQ公司的OSP/1等。 ●????????? Microsoft的Windows系列：主要包括WindowsNT，Windows2000Server等。 ●????????? Linux系統：Linux系統的核心和UNIX相似，但主要運行于Intel的芯片上。如RedHat Linux、Core Linux、Open Linux等。 ??? 這三大類操作系統各有特點。從企業級電子商務系統應用來看，UNIX系統所占的份額更大一些。Linux是一個免費的平臺，沒有專業的技術支持，所以盡管利用Linux可以節省費用，但是如果系統出現問題，那么只能由用戶自行解決，所以使用該平臺需要承擔一定風險。

1.7 電子商務系統的集成 ??? 　　電子商務系統是應用軟件、應用支持平臺、基礎環境等部分集成在一起的系統，它還需要與外部信息系統、企業內部信息系統發生數據交換，只有將這些部分集成在一個統一的商務邏輯處理流程中，才能使系統發揮整體的效益。 　　電子商務系統的集成主要涉及以下幾個層次（參見圖1-7）。 ??? 1．數據集成 ??? 　　數據集成是指應用系統能夠通過消息、網絡文件系統等方式存取外部數據。例如電子商務系統通過e-Link這樣的消息中間件產品訪問IBM ES9000大型機。 ??? 2．網絡集成 ??? 　　網絡集成是指通過網絡互聯將各種不同形式的數據通信網絡連接在一起，為應用之間的數據交換提供通信環境。 ??? 3．應用集成 ??? 　　應用集成有兩個含義，一個是指利用各種組件（component）搭建能夠進行商務邏輯處理的應用程序。另外一個是指應用之間的互操作。 圖1-7應用集成示意圖 ??? 4．企業商務流程集成 ??? 　　企業商務流程集成意味著將企業的業務流程統一到一個信息平臺上，它還指以信息技術為依托，整合企業的管理信息系統，使企業的生產過程能夠在一個新的平臺上更為有效地運轉。它和企業的商務過程再造類似，是一種商務邏輯集成。 1.7.1 網絡集成技術 ??? 　　網絡集成的主要內容是指將電子商務系統的企業內部網絡、電子商務系統的局域網、 Internet和企業外部網絡連接在一起，構成互聯的網絡。由于支持電子商務系統的各種數據通信網種類繁多，而且網絡協議類型也不相同，所以在集成過程中涉及到很多新的技術手段。一般而言，實現電子商務系統網絡集成的重點在于： ??? 1．規劃網絡集成方案 ??? 　　規劃網絡集成方案的目標是：在調查各互聯通信子網的基礎上，確定未來網絡的體系結構、協議體系、接口方式及互聯設備。其基本過程是： ??? (1)針對網絡集成的對象，調查各互聯子網的結構、協議等背景。 ??? (2)確定未來網絡的邊界以及各互聯子網的邊界。 ??? (3)分析各子網互聯的目的，確定各互聯子網的接口層次(例如明確是在網絡層、鏈路層還是物理層建立接口)。 ??? (4)根據商務系統的應用處理分布，分析未來網絡中各需要互聯的通信子網所要承擔的網絡流量，規劃接口帶寬要求。 ??? (5)確定未來互聯網絡的體系結構及協議標準。 ??? (6)確定各個互聯接口設備。 ??? 2．低層網絡互聯 ??? 　　網絡低層互聯是實現通信子網的連通，它包括物理層網絡的擴充、鏈路層和網絡層互聯，其目標是解決通信子網的連接、尋址及路由問題。 ??? 實現低層網絡互聯的方式基本上可以分成兩部分： ??? 　　第一部分是物理層互聯，基本上可以通過中繼設備實現，如中繼器、LAN Switch和各種集散器（如智能HUB、交換式HUB等）實現。物理層的連接可擴展網絡覆蓋范圍、改變網絡拓撲結構，但是無法解決尋址及路由的問題。所以如果電子商務系統網絡互聯只是實現網絡的連接與擴充，那么直接采用物理層互聯技術即可。 ??? 　　第二部分是鏈路層和網絡層的互聯，該層互聯一般可以通過各種路由設備來實現。 ??? 3．中、高層應用的互通及互操作 ??? 　　低層網絡的互聯實際上是通信子網的聯通，它為網絡應用提供了一個互聯的通信平臺，但是無法解決應用程序之間的互操作問題（例如虛擬終端、網絡文件系統等）。所以網絡系統集成除了解決低層網絡的可擴展性和互聯性之外，還需要從中高層解決數據傳輸和應用服務問題。 ??? 　　中高層網絡互聯主要通過應用網關（Application Gateway）實現。應用網關是一個邏輯概念，實際是一組應用程序，主要作用是在不同的高層服務協議之間進行轉換，例如轉換 Internet Mail和EDI系統的Mail格式，網絡上不同數據文件的格式轉換等。目前網絡體系結構中，中高層沒有標準的協議，所以中高層集成也沒有成熟的標準。因此，這一部分也是網絡集成的難點。 1.7.2 數據集成 ??? 　　數據集成的目標是使不同系統的、不同形式的數據集合能夠統一在一起，為電子商務系統提供支持，實現分布式的數據共享。例如利用SAP的ERP系統構造的企業內部生產管理系統要接受來自Web的訂單，Web讀取內部基于Lotus/Domino構造的辦公系統上的數據等。這些問題就涉及到所謂的數據集成。 ??? 　　數據集成方面目前的標準和規范并不完備。下面從實用角度闡述解決上述問題的一些基本方法。 ??? 1．異構數據庫的存取 ??? 　　目前數據庫系統的數據存取方式、接口方面的標準主要有： ??? (1)數據庫數據的存取標準SQL ??? 　　結構化查詢語言SQL（Structured Query Language）由ANSI制定，ISO選定其作為數據庫數據存取標準（ISO9079）。OSF和X/Open也都選擇了它作為產品標準。 ??? (2)應用訪問數據庫的接口標準ODBC、JDBC等應用程序訪問數據庫時，通常可以利用數據庫管理系統提供的應用程序接口API（Application Programming Interface）訪問數據庫中數據，但是各個數據庫產品生產商向程序員提供的API接口差異比較大（例如Sybase的DB-Library、Informix的E-SQL等）。數據庫應用程序接口標準就是試圖建立這種程序接口的規范，減少應用程序和數據庫管理系統之間的依賴性，使應用程序可以通過相同的方式訪問不同DBMS。目前主要有以下的一些數據庫應用程序接口標準： 1)開放數據庫互聯標準ODBC(Open Data Base Connectivity)：ODBC由Microsoft公司提供，它定義了數據庫訪問的應用程序接口，即API接口。ODBC的目的是屏蔽各種數據庫存取API接口的差異，為訪問數據庫的應用程序提供一致的接口。應用程序可以通過稱之為ODBC驅動程序（ODBC Driver）的數據庫引擎訪問不同的數據庫管理系統(參見圖1—8)。 圖1-8? 通過ODBC Drive訪問異構數據庫 ?? 2)Java數據庫連接標準JDBC(Java Data Base Connectivity)：JDBC和ODBC類似，它為Java應用程序提供統一的API接口。JDBC包括兩個基本部分，一部分是面向開發人員的JDBC API，其作用是為程序員提供不同的數據庫連接方式。另一部分是JDBC Driver，它可以建立在ODBC基礎上，即程序對JDBC的訪問先轉換成為對ODBC的調用，然后利用ODBC完成數據庫訪問：JDBC也可以直接與數據庫連接。 　　目前幾乎所有的應用服務器都為Java程序提供JDBC接口，如圖1-9所示。 圖1—9? 通過應用服務器的JDBC Driver訪問不同的數據庫 3)統一數據存取標準UDA(Universal Data Access)：UDA是Microsoft公司提出的一種標準，它也力圖為應用程序提供一個統一的API接口，但它所針對的數據源不僅僅局限于關系數據庫，可以是非關系型的數據文件、圖形圖像等。在UDA機制當中，應用程序通過ADO(Advanced Data Object)接口訪問數據，而ADO可通過OLE DB訪問非關系型的數據或者通過ODBC驅動程序訪問不同的數據庫，如圖1—10所示。 圖1-10 UDA結構示意圖 ??? UDA提供了對不同的數據源一致的存取方式，但是遺憾的是除了Microsoft公司外，其他IT廠商的產品對這一標準支持不夠充分。 ??? 2．異構數據的統一管理 ??? 　　異構數據的統一管理是指：利用統一的操作方式管理不同格式的數據，并且實現不同數據之間的相互轉換。利用該服務，應用程序的可移植性就會得到很大的提高。目前這一方面的標準和產品主要包括： ??? (1)Microsoft UDA：UDA實際上是將數據及其存儲、表達格式和存取方式集成在一起，形成可被統一操作的數據對象（ADO對象）。在對象當中，數據及其操作方法被封裝在一起，可以被透明地存取。 ??? (2)擴展標記語言XML：XML不僅可以定義數據表達的方式，而且可以描述數據的存取方法。使用XML語言，企業能夠使用統一的數據結構管理各種不同格式的數據，以統一的方式管理起來，而且向用戶提供統一的存取方法。 ??? 3．數據集成的中間件產品 ??? 　　除了上面闡述的標準外，很多中間件產品可以向開發人員提供比較完善的工具和接口，簡化了API接口及配置接口，幫助開發人員完成數據集成。 ??? 這些中間件產品主要包括以下幾類： ??? (1)基于遠程過程調用(RPC)的中間件 ??? 　　RPC機制使客戶可以采用與調用本地進程一樣的方式調用遠程服務。由于RPC采用阻塞(blocking)方式完成，所以它提供的是一種底層的同步服務，這種方式對于基于Internet的電子商務應用不見得非常實用，但是當電子商務系統與企業原來的信息系統連接，而原有系統支持RPC的話，這是一種可以選擇的方案。這種中間件產品比較有代表性的有Microsoft的DCOM機制、Inprise公司的Entera、NoblenetRPC。 ??? (2)基于應用消息隊列(message)的中間件 ??? 　　這類中間件是在IPC（Internal Process Communication）的消息隊列基礎上的經過擴充而實現的，它保證分布式應用可以在脫機情況下實現可靠的數據傳輸。消息型中間件也是目前數據集成中應用最為廣泛的中間件產品。 ??? 這類產品的代表是IBM的MQ Series，此外還包括BEA TUXEDO中的MessageQ、 Microsoft的Message Queue，國產化產品的代表是東方通的TongLINK／Q。 ??? (3)交易中間件 ??? 　　有的地方也將此類中間件稱為交易處理監視器。它本質上是對聯機事務處理提供服務的軟件工具。 ??? 　　該類中間件的典型代表是BEA公司的TUXEDO、IBM的CICS等。利用這些平臺可以比較好地構造OLTP（On Line Transaction Process）系統，同時對聯機事務處理的并發事務處理性能能夠有較大提高。 ??? 　　由于電子商務系統的實時性要求較高，而且很多商務活動過程就是事務處理過程，所以這種中間件在電子商務系統的數據集成中應用比較多，它比較適合于構造要求在Internet環境中進行并發事務處理（例如訂票、證券委托等）的電子商務系統。 ??? 　　除了以上這些比較通用的中間件可用以實現電子商務系統的數據集成外，還有一些具有特定功能的產品可實現數據集成。其中最有代表性的是用于電子商務系統和ERP系統數據集成的產品。這類產品側重于支持電子商務系統與ERP系統之間的連接、數據一致性及工作流協同。其目標是將ERP與電子商務系統聯系在一起，擴充和改善ERP系統原有的銷售、財務、生產管理功能，進而形成整個企業的價值鏈管理VCM(Value Chain Management)體系。一些大型的盯企業，例如Oracle、SAP、i2、Baan、Siebel和JDE等都有這一方面的產品。 1.7.3 基于組件的應用集成 ??? 　　從目前的發展來看，電子商務系統的應用構造方法趨向于采用應用總線方式構造。所謂應用總線是借用了計算機體系結構當中的“總線(bus)結構”的概念。應用總線與計算機體系結構中的總線概念類似，以一種通用的方式為各應用組件提供數據及控制邏輯，協調應用軟件各部分的通信，從而達到軟件各組成部分協同工作的目的。在這種指導思想下，組件技術伴隨電子商務的發展近些年來進展很快，已成為電子商務應用開發技術的一個主流方向。 ??? 　　組件或者構件技術是應用級別的集成技術，其基本思想是將應用軟件分解成為一個個獨立的單元，將軟件開發過程轉變成為類似于“搭積木”的搭建過程，通過組裝不同的軟件組件單元來實現軟件的集成。按照組件技術的觀點，應用軟件的開發就成為各種不同組件的集成過程。 ??? 　　電子商務系統是一種分布式的信息系統，伴隨電子商務系統的發展，分布式環境中面向對象的組件技術也得到充分地發展，這些技術中最具有代表性的包括：CORBA、Microsoft公司提出的DCOM、SUN公司提出的EJB和J2EE。 1.7.3.1 CORBA 　　CORBA是通用對象請求代理結構（Common Object Request Broker Architecture）的縮寫。通常提到的CORBA一般有兩層意思，一是指對象管理組織OMG（Object Management Group）提出的分布式對象體系結構標準(或稱規格)，另一層意思是按這種體系結構開發的中間件產品。CORBA作為一種應用級的互聯標準得到了廣泛的認同和應用，其主要特征是： ??? (1)在CORBA環境下應用系統間的互聯是以對象或程序的調用方式進行的，這樣就可以做到系統間實時互操作。這類環境有很強的互操作能力，原則上，一個系統內部能夠完成的操作，在系統之間通過CORBA都可以實現。 ??? (2)CORBA的面向對象的特點還保證了各種對象的封裝性和內部細節的隱蔽性。這不僅可以簡化各種功能(服務)的使用，還提高了系統的安全性。 ??? (3)CORBA比較適合于分層結構的應用集成，由于電子商務系統的體系結構本身就是一種多層次的結構，所以這一技術比較適合于核心業務邏輯的應用程序的集成。此外，由于目前應用服務器大多提供CORBA接口，這樣利用CORBA技術完成應用程序和平臺之間的無縫連接也比較容易。 1.7.3.2 EJB和J2EE ??? 1．EJB和J2EE ??? 　　EJB是SUN公司倡導的基于Java的組件構架。EJB定義了一個集成的編程模型和標準的API接口。EJB是實現服務器端應用服務的組件。 ??? 　　在EJB之后，SUN提出了J2EE（Java 2EnterpriseEdition），定義了一個一致的環境，以支持企業級別應用的集成，確保應用的可移植性。在SUN的J2EE規范（J2EE白皮書）當中，J2EE被定義成為一個多層次的服務、開發平臺，總共包括4個組成部分，其核心是J2EE應用開發模型和J2EE平臺。 ??? (1)J2EE應用編程模型（J2EE Application Programming Modal）：一個標準的開發多層結構、瘦客戶端（Thin Client）的開發標準。 ??? (2)J2EE平臺（J2EE Platform）：是J2EE應用的標準宿主（hosting）平臺，包括——系列的 API和策略的集合。 ??? (3)J2EE兼容性測試工具（J2EE Compatibility Test Suite）。 ??? (4)J2EE實施參考（J2EE Reference Implementation）。 ??? 2．J2EE應用編程模型（J2EE Application Programming Modal） J2EE應用編程模型如圖1-11所示。在該模型當中，商務邏輯處理被分成三個層次：客戶層（Client Tier）、中間層（middle Tier）和企業信息系統層（EIS Tier）。 圖1-11 J2EE應用編程模型 ??? 客戶層支持不同的客戶端，包括基于瀏覽器的瘦客戶端及其他客戶端。中間層能夠完成企業服務的存取。EIS層負責存儲企業內部的關鍵商務數據。在J2EE模型當中，應用服務被分為兩部分，一部分是商務及表達邏輯，由開發人員實現；另一部分是標準的系統服務，由J2EE平臺提供。 ??? 　　在J2EE模型當中，中間層的商務功能通過一系列的EJB組件實現。中間層使用JSP實現商務邏輯處理結果的動態發布，構成動態的HTML頁面，中間層也可以使用Servlet實現更為靈活一些的動態頁面。 ??? 　　在上述模型中，中間層可以通過以下方式訪問企業信息系統層(EIS Tier)中的信息資源： ●????????? JDBC：數據庫訪問接口API。 ●????????? Java名字及目錄接口JNDI（Java Naming and Directory Interface）。JNDI可以獲取名字服務和目錄服務，例如DNS、NDS、LDAP和CORBA的名字服務。 ●????????? Java消息服務JMS（Java Message Service）：JMS作為一個標準的API接口可以和企業基于消息的中間件系統（例如IBM MQSeries、BEA TUXEDO等）交互。 ●????????? Java Mail：基于Java的電子函件API接口。 ●????????? Java IDL．IDL(Interface Definition Language)是一種接口定義語言。JavaIDL可以通過建立遠程接口支持Java和CORBA應用的通信。利用Java IDL，應用系統可以調用CORBA的服務。 3．J2EE平臺(J2EE Platform) J2EE平臺是一個運行J2EE應用(EJB、JSP、Servlets等)的標準環境。它包括以下幾個部分： ●????????? J2EE(應用)分布規范(J2EE deployment specification)：該部分定義了在J2EE平臺上進行應用集成及分布的標準。 ●????????? J2EE平臺的Java技術標準：定義了J2EE平臺需要支持的標準集合。 ●????????? J2EE平臺的IETF標準：J2EE平臺需要支持的IETF標準的集合。 ●????????? J2EE平臺的CORBA標準：J2EE平臺的中間層(Middle Tier)需要支持的CORBA標準。對象管理組織OMG和SUN聯合制定了RMI-IIOP協議，該協議定義了CORBA的IIOP協議如何調用Java的RMI(Remote Method Invocation)。同時EJB標準中也定義了EJB如何和IIOP進行映射，所以通過RMI-IIOP協議，Java應用可以和CORBA應用之間進行互操作。 1.7.3.3 Microsoft DCOM及Windows DNA ?? 　　分布式公共對象模型DCOM(Distributed Common Object Modal)是微軟公司以其公共對象模型COM(Common Object Modal)為基礎提出的分布式應用集成框架，DCOM和 Windows DNA是Microsoft公司的組件集成標準，該標準支持基于數據總線和控制總線的組件集成。 ??? 　　Windows DNA(Windows Distributed InterNet Applications Architecture)是一種分布式的互聯網應用框架，它被Bill Gates成為“數字神經系統”。這種結構的基本出發點是為了改善傳統的客戶機/服務器兩層結構愈發表現出的明顯的局限性，以適應更快更復雜的事務處理任務和快速開發的需要。 　　Windows DNA與微軟的Windows操作系統緊密結合，它是在原來Microsoft的分布式對象服務(如COM、事務服務器MTS等)的基礎上構造的。Windows DNA的結構和SUN的J2EE標準相似，如圖1—12所示。 ?? 圖1-12? Microsoft Windows DNA結構示意圖 ? ??在Windows DNA結構中，分布式應用系統由表示層(Presentation)、事務邏輯層(Business? Logic)和數據服務層(Data)三個組成部分： ??? (1)表示層：用戶的界面部分。主要是通過在客戶端瀏覽器中運行HTML、DHTML、 Scripting、Java Applet、ActiveX(在IE5.0中還可運行XML)實現用戶與應用程序的通信。在Internet應用環境中，表示層的工作由瘦型客戶機來完成。 ??? (2)商務邏輯層：負責處理表示層的應用請求，完成商務邏輯的計算任務，并將處理結果返回給用戶。商務邏輯處理層是將原先置于客戶端的商務邏輯分離出來，集中置于服務器部分，為所有用戶共享。商務邏輯層是整個應用的核心部分，而組件對象模型COM則相當其心臟。商務邏輯層通過COM進行事務處理，并由IIS(Internet Information Server)和MTS (Microsoft Transaction Server)為各種應用組件提供完善的管理。 ??? (3)數據服務層：為應用提供數據來源。和以往的兩層體系結構不同，數據庫不再和每個活動客戶程序保持一個連接，而是若干個客戶程序通過應用邏輯組件共享數據庫的連接，從而減少了連接次數，提高了數據服務器的性能和安全性?？梢愿鶕枰x擇Microsoft SQL Server，Oracle或任何與OLEDB或ODBC兼容的數據源。 ??? 　　Windows DNA的技術思想使應用開發有了明確的分工。一部分人員專注于事務邏輯層COM組件的開發和測試工作，另一部分人員根據商務邏輯的需要選擇和使用COM組件，而不需要了解組件功能實現的內部細節，最終以精練的ASP腳本語言把組件集成到頁面之中，從而有效地降低了開發的難度。 ??? 　　將應用邏輯組件集中置于中間層，組件對象COM的可重用性減少了應用系統整體的管理和維護費用。商務邏輯改變時，不必改變整個頁面源代碼，只需調整或替換中間層相應的 COM組件，即可靈活適應商務邏輯的變化。而后，系統可以在更新后的商務邏輯處理環境下運作，減少了客戶端應用程序版本控制和更新的難度。在這樣的結構下，所有復雜的事務處理都在中間層進行，客戶端只需最基本的瀏覽器配置，就可以和服務器及其他客戶進行事務交流。 ??? 　　這種應用模式能夠提高系統的運營效率和安全性。在中間層，IIS負責應用邏輯層Web頁面的管理，MTS負責應用邏輯層COM組件的管理。MTS在多線程的支持下工作，實現對COM組件的分布式連接管理、線程自動管理及高性能事務處理的監視。應用程序使用組件可以共享與數據庫的連接，使數據庫不再和每個活動客戶保持一個連接，而是若干個客戶通過共享組件和數據庫連接，降低了數據庫的負擔，提高了系統性能。此外，客戶通過組件訪問數據庫時，MTS的安全管理可以按權限將特定組件授給不同的用戶組，使商務活動的安全性和系統結構有機地結合在一起。 　 　 下一節 1.8 實施及組織 ??? 電子商務系統的實施也是一個比較復雜的系統工程，系統的實施不僅涉及應用的開發與實現，而且需要有比較完整的項目組織，才能保證應用系統的品質能夠達到預期的目標。 1.8.1 電子商務系統開發集成的任務 ??? 電子商務系統開發及集成與傳統信息系統開發相比有一定的特殊性，主要表現在： ??? (1)電子商務系統的應用是基于Web的應用，應用是一種分布式的結構，所以開發工作可以分解成為客戶端和服務器端的應用開發兩部分。 ??? (2)由于電子商務系統的應用程序既包括編譯型的程序，也包括解釋型的腳本程序(例如Java Applet、Java Script、VBScript等)，而這些腳本程序基本上都是嵌入到HTML頁面中的。所以，應用程序的編寫就不僅局限于編碼，而且也包括HTML頁面的編寫。 ??? (3)借助于組件技術搭建應用日益成為未來電子商務應用開發與集成的主流方向。 ??? 根據以上的分析，可以將電子商務系統的主要設計開發任務歸納為以下內容： ??? (1)應用系統設計開發 ??? 應用系統開發設計的目標是完成應用系統結構設計，編寫服務器、客戶端應用程序，提供可嵌入頁面的腳本。具體包括： ●????????? 應用系統設計 ??? 包括應用系統的體系結構、數據流程、外部接口、數據結構、組件對象分析及定義等。其目標是清晰地描述應用系統的結構，以便為項目開發定義可分解的任務。 ●????????? 服務器端組件、應用編程 ??? 這部分任務的開發方式有兩種，一類是按商務邏輯的功能進行劃分，這樣一來每個不同的開發小組負責一個具體的商務邏輯，其特點是易于保證應用的完整性，但缺點是對開發者的技術素質要求比較高，小組中的人員必須正確理解前后臺應用的差異、不同的開發工具。另外一類開發組織方式是根據人員的知識及B／S結構的特點，將開發組織分成前、后臺兩個開發小組，其優點是可充分發揮兩部分人員的特長，但缺點在于接口和協調較之前者要復雜一些。盡管兩種開發組織各具特色，但是相對而言，后一種方式的可操作性更強一些。 ??? 服務器端的應用主要通過一般的高級語言、Java、PHP等來構造，也可以通過EJB或者CORBA等組件標準來開發。 ●????????? 客戶端應用或腳本編寫 ??? 客戶端的應用開發任務分成兩類，一類是針對瀏覽器編寫的瘦客戶應用，可以利用各種解釋性語言編寫，例如ActiveX、Java Applet等。另外一類是需要進行數據處理的所謂胖客戶程序，這類程序基本上用傳統的C／C++等高級語言編寫?？傮w來講兩類客戶端應用的目標是統一的，就是構造友好的圖形用戶界面。 ??? 客戶端應用腳本需要和HTML頁面配合起來，常見的問題是腳本如何在頁面當中被合理地安排、頁面更新后腳本的調整等。這些問題都是在腳本編寫過程中需要注意的。 ??? (2)內容設計與編輯 ??? 內容設計與編輯的目標是對電子商務系統中網站的整體風格、頁面組織結構進行設計，完成頁面內容組織與編寫。該部分的主要任務包括： ●????????? 站點設計與策劃 ??? 站點結構設計的目標是確定站點所要表達的內容如何能夠有效地被用戶理解。它的核心是對站點內容的組織、頁面/超連接、導航設計、站點風格等關鍵問題進行有效地決策。 ??? 由于站點的組織初始可能是一種網狀的結構，但從設計角度看，我們最終是需要將其抽象成為可以由各類靜態、動態頁面表示成為一個樹狀結構。這樣才能夠對站點的頁面內容進行分解，進而分配給不同的HTML編寫人員。 ??? 站點的風格直接影響到整個網絡站點的效率(例如網絡速度比較慢的情況下，用戶對Frame結構的頁面或者存在大量表(table)的頁面的忍耐力就會差一些)、客戶對站點的忠誠程度等方面。所以站點的結構與風格設計是非常重要的。 ??? 站點設計人員不僅需要對技術進行了解，而且對藝術、形象設計、客戶心理等需要有充分的理解，所以某些時候將站點的結構設計人員稱為站點設計師或者信息構建師 (Information Architect)。 ●????????? 頁面編程 ??? 頁面編程主要是利用HTML及其它圖形、圖像表達工具，建立能夠正確和準確表達商務服務的、對客戶視覺有沖擊力的頁面。 ??? 頁面編程的主要任務包括兩部分：一是界面行為的表達(類似于軟件工程中的界面設計)，該任務需要完成頁面布局(Layout)設計、素材搜集和HTML頁面編寫。另一任務是集成動態頁面當中需要嵌入的腳本。 ●????????? 內容創建或者信息采編 ??? 這一任務相對簡單一些，它主要包括頁面需要表達的文字內容的編輯和整理、非文字內容(如圖像、音樂等)的格式轉換及其他的一些輔助性工作。在某些時候，這部分工作也被稱之為信息采編。 ??? (3)軟、硬件系統集成 ??? 軟硬件系統集成的內容我們在前面談過了。涉及的技術領域包括：網絡、操作系統數據庫、系統軟件(應用服務器、安全管理軟件、系統管理軟件等)等。 1.8.2 開發集成人員 ??? 根據電子商務系統設計開發的主要任務，可以看到完成這項工作需要熟悉不同領域知識的專業人員。一般來講，這些人員主要包括： ●????????? 項目管理人員：負責系統開發的組織協調。 ●????????? 站點設計師：負責系統設計、策劃。 ●????????? 應用工程師：負責應用系統前、后臺應用的編寫、組件開發。 ●????????? 系統工程師：負責系統軟件(操作系統、數據庫等)維護。 ●????????? 網絡工程師：負責網絡集成。 ●????????? 硬件工程師：負責硬件設備安裝、調試與維護。 ●????????? 美術創意人員：負責站點藝術包裝，輔助頁面開發工程師開發。 ●????????? 頁面開發工程師：負責HTML頁面編寫和頁面內嵌腳本集成。 ●????????? 內容創建或信息采編人員：數據采集、整理和加工。 1.8.3 項目管理　　 由于電子商務系統的實施過程是一個復雜的系統工程，所以要保證系統在技術上可實現，實際運作中能夠實施，合理的項目管理是非常必要的。電子商務系統的項目管理主要追求以下目標： ●????????? 付出較低的開發成本 ●????????? 應用系統的品質能夠得到可靠保證 ●????????? 開發的應用易于移植 ●????????? 開發過程可控制、可管理 ●????????? 最終項目進度可保證 ●????????? 項目投產后易于維護 ??? 要實現以上目標，在從項目可行性立項開始到項目投產為止的項目管理生命周期內，需要對需求分析和管理、分析設計、編碼、測試和運行的各個階段都進行嚴格控制。具體的控制方式在IS09001軟件行業認證標準中有所定義。本節主要闡述項目管理中的人員組織。 ??? 為了實現良好的系統管理，建立合理的項目組織是非常必要的。在電子商務系統的項目管理中，項目管理組織可以包括以下部分： ??? (1)項目建設領導小組 ??? 項目建設領導小組負責整個電子商務系統實施項目的領導。這一小組應當是由企業的主要負責人員擔任組長，實踐證明，企業主要負責人員對項目的重視程度是影響項目成敗非常關鍵的因素。 ??? 在項目建設領導小組中，除了企業主要負責人外，其信息主管(CIO)、技術主管(CTO)業務負責人及項目負責人也應當參加。如果項目是采用外包方式進行，那么ASP負責人員也應當加入到領導小組中。 ??? 項目領導小組直接管理項目顧問、支持小組及項目負責人。 ??? (2)項目顧問與支持小組 ??? 項目顧問不直接參加項目實施，但是對項目的運作提供咨詢與建議。項目顧問由電子商務方面的技術、產品等方面的專家參加，同時應吸收相同領域具有成功電子商務應用的企業相關人員參加。 ??? 支持人員主要從法律、財務、行政等方面為項目的實施提供支持。 ??? (3)項目負責人 ???? 項目負責人對項目的具體操作起非常關鍵的作用。它對項目開發與實施中的各個部分進行協調及進度控制，負責發掘項目開發組的潛力，實現項目開發及實施中各相關單位的理解與溝通，進行沖突裁決。 ??? 項目負責人不一定是技術專家，但它需要有技術背景和管理經驗，能夠和客戶取得溝通。項目負責人負責直接管理項目實施小組、品質保證小組和開發小組。 ??? (4)項目實施小組 ??? 項目實施小組負責項目從開發環境到實際運行環境的遷移。該小組由企業業務人員、技術人員和第三方產品支持人員構成。其中，企業業務人員對遷移過程中業務的連續性負責，技術人員對系統負責。由于電子商務系統一般都是需要使用不同的技術產品集成構成的，所以第三方技術支持人員從產品角度負責降低實施過程中的風險。 ??? (5)項目品質保證小組 ??? 這一部分對整個項目的質量控制起監督作用。其主要任務有三個，一個是監督開發小組是否按系統設計性能要求完成任務，開發過程是否滿足項目開發計劃的要求。第二是在每個檢查點，對系統的性能和缺陷進行檢測，對應用系統進行測試，對項目開發小組提供改進建議。第三個作用就是完整地整理和保存項目生命周期中的各種文檔，為項目的后期維護提供幫助。 ??? (6)項目開發小組 ??? 項目開發組承擔項目的具體開發工作。如果項目比較大的話，那么可以將項目開發小組進一步細分，細分可以采取不同的方式，例如可以按前、后臺分工，也可以按功能分解成不同的小組。需要注意的是，項目小組之間應當有明確的分工，其接口關系在開發前必須確定，開發小組需要制定嚴格的版本控制規則。 ? 1.9 小?結 ??? 本章針對電子商務系統的實現問題，從技術選擇、集成技術和項目組織三個方面進行了闡述。 ??? 在本章中，探討了電子商務系統的建設方式。給出了電子商務系統技術選擇的基本依據，從商務和技術兩個方面闡述了有關的技術標準。 ??? 本章分析和介紹了電子商務系統的實現過程，著重說明了這一從邏輯到物理的實現過程。從這部分說明中，讀者應當了解到系統從規劃設計到實現的逐步透明過程。 ??? 針對系統的構造過程，我們從客戶；應用表達、支持平臺和基礎平臺這樣的幾個層次，分別說明了各層相關的技術選擇和產品特點。在分析的基礎上，進一步探討了如何實現各個層次的集成問題。 ??? 最后，本章還從系統實施組織的角度，介紹了電子商務系統實施中的任務、開發組織和項目管理問題。

總結

以上是生活随笔為你收集整理的电子商务系统的建设方式及技术选择的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。