企業電子業務集成技術ebusinessFramew_第1頁
企業電子業務集成技術ebusinessFramew_第2頁
企業電子業務集成技術ebusinessFramew_第3頁
企業電子業務集成技術ebusinessFramew_第4頁
企業電子業務集成技術ebusinessFramew_第5頁
已閱讀5頁,還剩241頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

企業電子業務集成技術浙江大學計算機學院施敏華smh@2003年10月北京能生存下來的既不是那些最強壯的,也不是那些最有智慧的,而是最能適應變化的物種。-達爾文《物種起源》主要內容基礎設施技術架構開發模型開發經驗商務模型功能模型客戶模型資源模型商務過程要素客戶行為模型功能結構導航IT體系結構和設備商務視角技術視角內部因素外部因素 這個參考模型由四層組成,分成兩個主要單元。上層單元集中于商務的特性提供服務的過程。下層單元集中于客戶對基礎設施資源提出的要求。參考模型的每一層都與兩大類用于提供這一層定量描述的描述符與規格相聯系。電子商務時代的挑戰應用軟件通過Internet或WAN分布在世界范圍。用戶和應用程序間的連接是非持久性的和低速的。應用程序所需的數據可能分布在不同的機器上。數以百萬/千萬計的用戶,可能存在的突發事件千差萬別的數據表示設備全球化的協同工作企業電子商務面臨的挑戰保護已有的投資將來的不確定性價值鏈的集成技術的整合重用和團隊的開發多種技術的需求有限的經驗對于上千萬用戶的可擴展性電子商務技術的變化數據集成DB+HTML動態電子商務發布HTMLWebServices應用集成什么是動態電子商務?

IBM曾為動態電子商務下了一個簡單定義是:“著重于B2B的綜合性和基礎設施組成上的下一代電子商務,通過調節因特網標準和通用基礎設施為內部和外部企業計算創造最佳效益?!眲討B電子商務預想了這樣一個因特網,商業實體能在其自身的域內以及在貿易合伙人之間有步驟地管理交互作用。從發現新的合伙人到與另一商務實體的集成,動態電子商務著重程序對程序的交互作用,而不是早期B2C電子商務階段占主導地位的客戶對程序的交互作用。動態電子商務實現的關鍵是WebServices。WebServices就是原來的組件技術思想在Internet時代中的進一步發展,它集成了CORBA、COM/DCOM等各種組件模型技術,是原有各種組件技術的繼承和發展。它不僅已作為動態電子商務的基礎,也是“電子商務隨需應變”技術發展的基礎。新的使用Web的模式目前人們使用Web的模式瀏覽互相鏈接的文檔通過手工操作處理采購等商業事務下載文件通過瀏覽器手工操作B2BP2P(PersonToPerson)(BusinessToBusiness)新的模式WebService是使用Web的嶄新模式通過程序自動啟動和處理商務事務,而并非使用瀏覽器能夠在一個分布式的計算環境中動態地描述、發布、發現和調用許多基于WebService的新型應用將出現完全基于XML以及其他相關的Internet標準電子商務面臨的問題IT產業/.COM的“瘋狂投資”的實驗年代已經逝去當前的務實氛圍:傳統企業的電子商務化技術?商務?電子商務?技術必須為商務服務脫離商務需求的“新技術”很難被廣泛接受切合商業需求的技術是最“佳”技術對應用的影響從對內部用戶到對外部用戶的轉變FrombackofficetofrontofficeFromreducingcosttoincreasingrevenue應用服務提供商的出現‘Appsontap’新的面向客戶的應用同已有應用的結合The‘composite’application面向客戶的應用銷售制造支付整合任務任務任務任務任務任務SAPFinancialsThe

CustomerThe

Happy

Customer任務任務任務Stand-

alone

WindowsNT

packageCustom-built0S/390企業需要什么?為企業帶來直接的經濟收益削減掉某方面的開支成本優化資源使用何謂切合商業需求?滿足商業的本質需求:獲取更多的利潤不拘泥,但又不脫離現有的商業運作模式創新,不斷地創新!當今最有價值的電子商務應用企業門戶(Portal)網上連鎖商店(Storefront)集團內聯網(Intranet)供應鏈(SupplyChain)管理客戶服務(CustomerService)分銷(Distribution)管理提供ASP服務門戶:面向企業的最終用戶/合作伙伴/員工,安全地,以個性化的方式提供內部信息資源和應用訪問服務,而唯一所需要的客戶端軟件是瀏覽器(PC,PDA,手機)!對于企業,擴大市場影響力,提高客戶服務水平,降低企業IT運行成本!今天的門戶服務市場今天的門戶市場被來自于不同的軟件供應商的方案劃分成為獨立的,部分功能/目的的門戶:元門戶“MegaPortal”企業信息門戶“EnterpriseInformationPortal”消費者門戶“ConsumerPortal”商務智能/分析門戶“BusinessAnalytics/IntelligencePortal”知識管理門戶“KnowledgeManagementPortal”垂直行業門戶“(IndustryVertical)Portal”適用于任何客戶端設備,無需客戶端單獨安裝程序從任何設備訪問基于角色的社區用戶管理應用無關性集成任何資源支持各種門戶應用模式B2B,B2E,B2C擴充性,穩健,快速市場的關鍵需求OnlineOfflineAwayBusy電子商務應用實施的特點經常會增加新的電子商務應用,這常常會每幾個星期或每幾個月發生一次;經常會對電子商務的流程進行更改,這常常每周或每幾天發生一次;經常應用戶的需求而進行更改,這甚至每個小時都會發生,尤其是當需要為每個客戶、每個合作伙伴或每個企業員工都定制其首選的電子商務應用的時候。電子商務的屬性典型的e-business都需要一種解決方案,這種方案能夠:跨越很遠的距離連接異構的系統操縱并完成多重并發交易維護數據的完整性維護系統的完整性易于管理和控制該解決方案的類別是由e-business的模式來決定的,這些模式包括:供應整合,CRM,交易,工作流,數據管理解決方案?企業解決方案的需求互聯網技術的特征和標準HTML,XML,Java,EJB,LDAP,SMTP/POP3可擴展性安全性同遺留系統的整合適應團隊的開發基于中央倉庫基于組件和模型驅動建模,構造,整合

尋求解決方案INTERNETINTRANETEXTRANET電子商務ERP整合應用定制DominoWebSphereLinuxWindows2000MQseriesTCP/IPVPNSNACICS商業集成的需要公司收購您的供應商您的公司您的客戶全球化電子商務成本及周期公司間的競爭1.合并&收購2.打包的應用集成(ERP)4.供應鏈5.直接交易處理6.Web集成3.客戶關系管理非常重要完全無關根本不知54321“應用集成對您的電子商務的影響有多重要”52%12%20%4%10%2%

Source:ForresterResearch,Inc.Sept.2000巨大的市場機會不恰當的解決方案:應用的復雜連接對于每個應用,程序員都為每個需要的企業資源或外部資源編寫連接代碼,以使得應用得以運行。程序員還需要編寫更多的代碼以使得大量的用戶能夠訪問每個應用。應用與應用之間的集成同樣需要編寫大量的代碼不恰當的解決方案:應用的復雜連接第一個應用,企業的為之付出的總的費用應該是該應用的開發和部署費用、以及運營時態的維護和更新費用。第二個應用,應用的開發和部署費用是一樣的,但是企業需要為之花費額外的集成費用,同時由于整個企業應用環境變得更加復雜,其運營時態的維護和更新費用可能呈指數形式增加。同樣,當第三個、第四個應用被部署后,企業所支出的費用可能是高得驚人。正確的解決方案:

WebService和BusinessWeb由程序員主導的由里向外的開發模式應當被由用戶主導的由外向里的開發模式取代冗長的串行的開發循環應當被即時的,快速的應用裝配所取代應用應當天生就具備高可定制性商業技術概念:“即時制造”以及“規??缮炜s”正確的解決方案:

WebService和BusinessWeb各種WebService分別實現了一定的電子商務功能將各種電子商務的WebService進行組合和集成以創建動態電子商務應用充分地跨越所有系統平臺通過在企業間進行WebService的集成,實現BusinessWebAutomatedBusinessProcessesProcessServer原材料制造業運輸供應鏈管理SalesForceAutomation記費原材料制造業配送銷售自動控

制BuenaVistaCorpBVC001949332BuenaVistaCorp6A6A6700QuebecSt.3409374874,000100800AF0800互聯網將全球的企業聯系起來,同時面臨應用整合的挑戰:不同平臺的集成不同的網絡的集成不同的數據表示的集成全球化協同計算

為集成而設計

可連接的應用程序松耦合可編排基于標準跨平臺LouGerstner:關于計算技術基礎架構沒有哪個公司的系統是孤立的。它們都是一個嶄新的、日益凸現的、全球性基礎架構的一部分。這種架構隨著Internet的出現成為可能,同時沒有任何一個企業可以(或企圖)去擁有它。它屬于我們全體,由大家一起管理、訪問,并依賴于商業、政府、學校、醫院以及我們身邊的一切。計算技術基礎架構正迅速地成為我們這個世界中重要的一份子,就象其它我們已經習以為常的基礎架構(如電話系統、高速公路、電力系統)。為了這一天的到來已經經歷了很長的時間。“Nocompany'ssystemsareanisland.They'repartofanew,emerging,globalinfrastructurethatismadepossiblebytheemergenceoftheInternet,andthatnooneenterprisecan–orwantsto–own.It'scollectivelyowned,accessed,andrelieduponbyeverybusiness,government,school,hospital,andneighborhood.Inthatrespect,computinginfrastructureisrapidlybecominglikealltheotherkindsofinfrastructurewetakeforgrantedintheworld–thetelephonesystem,thehighways,thepowergrid.Thishasbeenalongtimecoming."何謂電子商務基礎設施電子商務基礎設施是企業用于實現向電子商務轉型的完整IT基礎架構,它為用戶提供一個整合的環境,包括硬件、軟件以及服務等組成部分,通過全面的系統管理,支持用戶的多種應用。企業的每一項核心業務如SCM、ERP、SCM、商業智能、電子交易等,都可借助于電子商務基礎設施的支持獲得最佳效果。

電子商務基礎設施是企業用于實現向電子商務轉型的完整IT基礎架構,它為用戶提供一個整合的環境,包括硬件、軟件以及服務等組成部分,通過全面的系統管理,支持用戶的多種應用。電子商務整合服務電子商務基礎設施是成敗的關鍵成功者的共同之處在于對競爭環境和自身能力的充分了解、對電子商務前景的強烈渴望和對企業戰略的清晰把握、以及對快速實現業務革新的追求。然而最根本的還在于,這些企業都擁有一個強有力的電子商務基礎設施,這一基礎設施支持企業更好地開展現有業務,并持續實現業務創新,從而使科技成為一種能夠取得不斷成功和創造源源利潤的手段。在企業的電子商務環境中,電子商務基礎設施無處不在。它支撐著企業的全部業務系統,貫穿于企業運營的每一環節。IT系統是電子商務不可分割的一部分,但是規劃和建設電子商務基礎設施絕對不能被認為只是一個技術問題--企業應當同時考慮到業務管理和技術實現兩個方面,并選擇最合理的方式來實現。電子商務基礎設施的考量因素成功的電子商務依賴于能夠在下面三個考量因素上有出色表現的電子商務基礎設施:安全可靠性、可擴展性、靈活性。一個合格的電子商務基礎設施應該能夠確保業務運作的安全性和連續性,以及電子商務應用程序對于最終用戶的可用性。一份市場調查顯示,90%的CIO把網絡交易的安全性列為衡量電子商務的首要指標。企業一旦將自身與網絡世界對接,將面臨迅速增長的海量數據,以及極有可能因此導致的不可預知的客戶需求和用戶工作量的激增。統計表明平均每個企業在一年中對系統應用的更改超過3000次,許多企業內部存在著不同廠商提供的服務器、操作系統、數據庫和各類應用軟件。同時,企業還需要考慮與客戶、商業合作伙伴和供貨商的系統之間進行溝通和整合的問題,并促進電子商務模式的迅速擴展。IBM針對e-business的軟件策略該策略由以下內容組成基礎及其規則業務伙伴的應用用戶底層架構的職責框架的變化通常勾畫出了架構的組成方式內部和外部的文檔都總在不斷地更新策略或框架中出現的名稱或交替使用的名詞的參考資料標準框架在任何環境下,管理信息技術都是一種挑戰。構建一個良好的電子商務基礎設施的最大挑戰,是將企業現有的應用程序和基于Web和Internet的應用程序結合。創建和管理成功的電子商務架構需要謹慎的遠見、充足的時間、強大的金融實力和良好的資源為保證。現實中存在著眾多異構平臺并存的情況,而用戶通常都希望各類軟硬件設備之間能夠協同工作。事實上,由于當今巨大的電子商務系統中所涉及的組件太多,企業已經無法辨別哪一家供應商的產品更適合其本身的業務發展,或是它與其它一項產品的兼容性如何。所以要迅速地開發越來越多的電子商務應用程序,唯一可行的途徑就是采用基于開放工業標準的開發框架。下圖就是IBM提出的電子商務應用程序框架。

框架體系結構的特性客戶端網絡架構訪問控制安全性控制應用服務器軟件提供處理請求的平臺包含業務流程應用集成使異構的系統之間相互通信使Web能夠訪問到數據特性(continued)一種Web應用編程環境用以創建動態的應用e-business應用服務使e-business服務的創建更加容易系統管理功能管理系統中的多種組件開發工具

創建、組裝、部署以及管理應用程序特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具客戶端客戶端(continued)瘦客戶端幾乎沒有或者完全沒有應用邏輯幾乎不需要安裝軟件能夠發送請求能夠接受應答最小化的應用邏輯基本上只用于展現支持開放標準特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具應用服務器軟件應用服務器軟件(continued)提供核心業務流程功能HTTP服務器郵件及虛擬社區服務(聊天,新聞,等等)群件服務,可以支持業務工作流數據庫服務交易服務消息服務特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具業務流程的整合集成(continued)使異構的應用之間能夠相互通信WebServices連接器通過與應用相關的協議進行連接應用消息服務在應用之間基于消息機制的通信業務流程的集成和工作流服務組件集成服務可以利用現有的應用邏輯按不同的目標進行打包封裝特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具Web應用編程環境編程環境(continued)基于JavaServletsJavaServerPages(JSP)EnterpriseJavaservices(JDBC,JNDI…)EnterpriseJavaBeans為以下特性提供環境動態地編寫互動的方式在Web應用服務器上可以保證應用的安全實現并提高分隔開業務和表示層邏輯的功能特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具e-business應用服務適用于e-business的服務或應用構建支撐平臺,使e-business解決方案的建立更加容易面向高層次應用的組件構建在底層基礎架構之上并對其進行擴展特定類型應用所需要的功能特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具系統管理vs.網絡管理提供端到端的管理能夠跨越網絡、系統、中間件和應用包含工具和服務以對管理提供支持始終貫穿交易的整個周期實現一種以協作性和程序性為基礎的管理方式特性(continued)客戶端網絡基礎架構應用服務器軟件應用集成Web應用編程環境e-business應用服務系統管理功能開發工具開發工具開發工具(continued)支持廣泛的工具創建部署管理支持集成的第三方工具支持出現在開發中的不同技術組合工具以實現這些特定的技術組合為目標在開發團隊內部實現協作開發工具的選擇用戶界面

(10%)復雜計算

(0-15%)實現業務需求

(75-90%)策略(continued)基礎及其規則規則(continued)規則(continued)

策略以及產品的投入必須構建在行業認可的、基于開放標準的技術之上協議(TCP/IP,HTTP,WAP,802.11,LDAP…)語言(Java,XML,SQL,…)操作系統(Linux,PalmOS,…)多數廠商認可的標準(SOAP,Bluetooth,...)多數廠商認可的技術(Windows,…)開放標準組織的積極貢獻者(WorldWideWebConsortium——W3C)開放標準技術的積極開發者規則(continued)規則(continued)基于開放的編程模式J2EEJDBCJINIJNDIJNIEJBs.NET(jurystillout)…其它行業合作伙伴業務,應用,運行環境,…實踐實踐(continued)IBM的e-business模式IBM軟件部和IBM全球服務部的結合確定e-business解決方案中出現的通用業務、應用和運行時模式并進行分類提供一份實現的規劃圖重用這些模式以減小技術上的風險允許定制和客戶化資源的獲得資源集中傳送的途徑這一切是否已經提前做好了?實踐(continued)軟件策略實踐IBM的e-business最佳實踐實踐(continued)軟件策略實踐IBM最佳實踐IBMRedbooks為開發人員提供詳細的開發和管理指導快速入門指南Fasttracksolutiondeliveryforcommonengagements可供參考的架構e-businessreferencearchitectureV3.0WirelessReferencearchitecture實踐(continued)避免慣性思維——靈活并大膽革新“我總是以這種方式來做”設計一個系統時要充分考慮它將面臨的周邊環境就像房間位于房中,房子在街道上,而街道…自上而下的方法需求總是無法完全確定技術不能確定自底向上的方法需求很完全并明確清楚采用什么技術實踐(continued)利用模塊化的方式打破設計的復雜性找尋模式的適用性找尋框架的適用性在子系統之間是松散的耦合關系但是卻是緊密地結合從一開始就控制好系統的質量將您的決策歸檔,并使用標準建模語言UML,以及可操作的模型實踐(continued)技術評估IBM產品最好的選擇可以依賴的技術對改變現有或您所期望的技術保持敏感在前沿技術上領先往往導致損傷慘重充分估計風險和實用性不要因為您熟悉某種技術就犧牲整個解決方案去配合它實踐(continued)使技術決策始終在整個項目管理的過程中充分考慮到成本和預算方面的問題對一個方面的改變會直接影響到另外兩個底層架構的職責底層架構的職責(continued)底層架構的職責(continued)四個關鍵品牌WebSphereWeb服務器,應用服務器,MQSeries,WirelessSuite,CommerceSuite,應用開發(超過64種產品)Lotus知識管理,協作(Collaboration)Tivoli超過60種的企業管理系統DB2數據庫、數據和內容的管理合作伙伴選擇什么樣的合作伙伴呢?真正出色的解決方案決不僅僅依賴于純技術。在做出最終選擇之前,企業有必要事先向對方提出以下問題:*你們了解我這個行業嗎?--成功的電子商務意味著經過整合的電子商務基礎設施促進了企業核心業務的創新。合格的伙伴能夠充分理解企業的核心業務和競爭優勢,知曉企業外部環境和內部模式,并能夠合理地預見企業所在行業的未來發展趨勢。*你們以前有足夠豐富的實踐經驗嗎?--電子商務的成功只分階段,而沒有大小和種類的區別。優秀的合作伙伴具有在各種企業中的成功案例,既了解不同行業的企業,也了解不同規模的企業。*選擇你們能否讓我的投資回報最佳而風險降至最低?--設計良好的電子商務架構必然要考慮盡量實現最佳的投資回報率,并盡可能降低總體擁有成本。企業因此需要一個具備業務咨詢、熟悉各種體系結構及其長短處、并深諳實現手段的合作伙伴來指點迷津。*你們的技術力量是第一流的嗎?--一套完整的基于開放標準的開發平臺和工具,才能使企業的電子商務在保持安全可靠的同時具備高度靈活性。富有責任心的合作伙伴擁有訓練有素的技術工程師和高品質的產品,通過邏輯嚴密的方法論幫助企業建設符合要求的電子商務基礎設施。你們的服務質量和技術力量一樣出色嗎?--擁有第一流產品的公司并不意味著它就一定是合作伙伴的最佳人選,整合能力才是最重要的。杰出的合作伙伴是一個集中了業務顧問和技術專家的復合型團隊,依照一套行之有效的實施規范來確保電子商務基礎設施與企業核心業務的整合。這些問題最終都歸結為一點,即整合能力。合作伙伴(continued)合作伙伴

(continued)InternetOS/400OS/400OS/400LinuxLinuxIntranet內置網卡內置網卡WebServerWebSphere核心業務ERPCRMSCM數據庫防火墻防火墻HypervisorI/O處理器Linux應用LinuxforiSeries的架構CDROMMapperLANMapperDiskMapperConsoleMapperCDROMDDLANDDDiskDDComsoleDDDisk處理器GNURuntimeOS/400AS/400應用SLICLinuxKernelRAID磁盤陣列NAS-NetworkAttachedStorageSAN存儲區域網絡RouterFirewall業務單位RouterFirewall業務單位iSeriesvs.SANx.25/DDN/FROS/400LinuxWindows2000磁盤柜RouterFirewallCallCenter銀行計算中心儲蓄所業務單位iSeries的部署x.25/DDN/FRRouterFirewall業務單位OS/400LinuxWindows2000IFS(集成文件系統)金融內部網絡RouterFirewall業務單位iSeries作為前置機x.25/DDN/FR網絡基礎架構網絡基礎架構提供全面的訪問環境TCP/IP以及網絡服務(例如DHCP)安全服務,基于:公共秘鑰技術訪問控制機密性數據完整性交易的不可拒絕性目錄服務,用于在網絡中定位用戶、服務以及資源文件以及打印服務VPN:安全、可靠、低成本的網絡分支機構協作企業集團公司總部POPPOPPOPWebServerswitchfirewallrouterModemPOPInternet遠程終端什么是目錄?目錄是一種分類條目。目錄有:日常目錄:如電話目錄、電視目錄、圖書館目錄、書的目錄等。在線目錄:在計算機中的目錄,是一種分層式的數據庫。主要有LDAP目錄。目錄服務目錄服務:提供目錄搜索。目錄服務系統:是軟件、硬件、策略等資源的定位集合體。包括:目錄中的信息目錄服務端硬、軟件目錄客務端硬、軟件客戶端到服務端、服務端之間的網絡基礎設施策略等目錄服務的需求對計算機資源定位的需要在海量數據中進行查詢(主要為讀操作)關系數據庫的低效率LDAP目錄服務X.500是一種CCITT(ITU)針對已經被國際標準化組織(ISO)接受的目錄服務系統的建議。是目錄服務的一種國際標準。但其在數據表示、編碼和傳輸方面都顯得比較笨重。什么是LDAP?

LDAP的全稱是LightweightDirectoryAccessProtocol,即:輕量級目錄存取服務。它是基于X.500標準的,但簡化了,所以稱為輕量級。另外,與X.500不同,LDAP支持TCP/IP,這對訪問Internet是必須的。傳統方法的劣勢(1)對于大規模數據,系統整體的性能降低,因為關系數據庫需要不斷的進行數據類型的驗證和事務的完整性的確認。(2)擴充問題,任意的擴充會導致索引的爆炸性變化。LDAP的優勢(1)可以在任何計算機平臺上,訪問LDAP目錄。(2)LDAP目錄可放在任何服務器上,因為LDAP是一個跨平臺的協議。(3)有較好的安全和訪問控制,如:給予用戶改變他們自己的電話號碼和家庭地址的權限,但是限制他們對其它數據(如,職務名稱,經理的登錄名,等等)只有“只讀”權限。給予“HR-admins"組中的所有人權限以改變下面這些用戶的信息:經理、工作名稱、員工號、部門名稱和部門號。但是對其它域沒有寫權限。禁止任何人查詢LDAP服務器上的用戶口令,但是可以允許用戶改變他或她自己的口令。給予經理訪問他們上級的家庭電話的只讀權限,但是禁止其他人有這個權限。給予“host-admins"組中的任何人創建、刪除和編輯所有保存在LDAP服務器中的與計算機主機有關的信息通過Web,允許組的所有者刪除或添加他們擁有的組的成員。LDAP的優勢(continued)(4)能夠進行目錄的復制

LDAP服務器可以復制部分或全部數據,例如:可以把數據復制到遠程的辦公室,以增加數據的安全性,也可為多個用戶所用。(5)可使目錄分布在網絡內的多臺計算機上。(6)為了保存大的對象,能夠將目錄分為多個分區進行存儲。什么時候使用LDAP存儲數據?(1)需要在任何平臺上都能讀取數據(2)每一個單獨的記錄項都只有很少的改變(3)可以把數據存在平面數據庫(flatdatabase:文本性質的數據庫),而不是關系型數據庫中。電子郵件地址郵件路由信息人力資源數據公用密匙聯系人列表等等LDAP存儲各種類型的數據LDAP的結構LDAP結構是一個目錄樹結構LDAP用目錄記錄的標識名(DistinguishedName,簡稱DN)來讀取單個記錄。標識名規范:DC域元素OU組織單元CN通用名DCDCouCNDomainOU1ComputersComputer1UsersUser1UsersUser2OU2PrintersPrinter1張三AttributesValues姓名大樓樓層張三1171LDAP的層次結構Contoso.ibmFinanceSalesSuzanFineLDAP://CN=SuzanFine,OU=Sales,OU=Finance,DC=contoso,DC=ibmCN=SuzanFine,OU=Sales,OU=Finance,DC=contoso,DC=ibmLDAP的層次結構(continued)一個實例用標識名來訪問打印機:的寫法是:LDAP://CN=P1,OU=Printers,DC=finance,DC=hz,DC=zj,DC=govDNSvs.目錄服務DNS主要目的是把主機名轉換成IP地址而目錄有更普遍的作用DNS有一套專門的、固定的計劃,而目錄允許擴展DNS不充許更新它的信息,而目錄可以。如何在企業集成中使用?

使用DNS域名空間,定義和命名根域。確定是一棵樹還是一個森林。參考你的組織結構。EAI軟件應當具有的技術層面業務處理過程的支持傳輸服務接口轉換單層應用模型兩層客戶/服務器模型三層應用程序模型WebService應用開發架構應用系統架構的變遷多層結構Client/Server終端方式數據的集中分布合理化集中n-Tier多層應用系統架構業務邏輯處理層數據表示層數據存儲層業務規則存在于:服務器端數據庫中HTMLBrowserPresentation&

BusinesslogicData

AccessEtc.Java

ScriptHTMLASPEmbeddedHTMLBusinessLogicHTML傳統兩層架構的方案集成的關系數據庫:安全性-強大的安全機制擴展性-從幾萬到幾百萬美元全系列靈活性-與主機系統的天然聯系、集成文件系統、各種網絡開放性-支持OLEDB驅動iSeries提供的高可用性數據庫服務,使以PC為基礎的普通數據庫服務器黯然失色。

iSeries最合適的數據庫服務器考慮電子商務基礎設施建設中安全性、擴展性、靈活性的三個主要方面,iSeries是最合適的數據庫?!皵祿笔请娮由虅障到y的“生命”?。?/p>

EnterpriseJavaBeanEJB體系是JAVA平臺上的服務器端組件模型目標是最大限度地減輕分布式應用程序的開發工作。VisualageforJava+Websphere安全、事務處理盡可能不再由手工編碼的方式實現,而是通過使用JavaBean自身的標記實現。應用程序服務器Servlet/JSP引擎EJBServer客戶端Browse數據庫服務器HTTPJDBCDB2ModelControllerView

基于EJB的三層系統架構Web應用框架用于構建e-business應用的基礎一個全面的,可擴展的,與平臺無關的方法,它可以支持您開發和部署e-business解決方案所需要的所有服務目標加速開發可移植可擴展利用現有資源易用性功能Web應用的開發LHH易用+功能=生產率Model-drivenHTML-drivenJavaCICSR/3PeopleSoftTuxedoCustom統一集成框架EJBEJBServletRepositoryJMSMOMsJDBCRDBMSWebSphereApplicationServerWebSphere集成框架

EJB開發中的參與者(Role)提供者(Provider)-設計Bean安裝者(Deployer)-將EJB類安裝到EJB容器中應用程序開發者(ApplicationAssembler)容器提供者(ContainerProvider)-提供運行環境應用程序服務器Servlet/JSP引擎EJBServer客戶端Browse數據庫服務器HTTPJDBCDB2ModelControllerView

基于EJB的三層系統架構CCCCSSSSCCCCSTPmonitorS1000+傳統的事務處理CCCCCSSSSCTPMonitorC動態負載均衡和故障恢復CSSSS12Commit!組件往往是分布的TM(TransactionManager)TXTXXACSSSS資源管理(DBMSserver,Queuemanager)XA工業標準

EJB和事務管理在EJB環境中,EnterpriseJavaServerContainer提供事務和并發性管理服務。雖然EJB參與事務以及在事務上下文中自動管理EJB狀態的能力是使用EJB最大好處之一,但是它也是EJB編程模型中最棘手的部分之一。雖然WebSphere容器本身提供了一定程度的并發性管理,但是在給定資源級別上事務隔離的并發性方面卻由事務資源管理器處理,而不是完全由“容器”管理。換句話說,最終將與數據庫合作來一起管理對實體EJB表的并發訪問。因此,EJB應用程序開發者必須理解和參與該過程。如果沒有預防性步驟,針對同一實體bean的并發讀寫事務可能導致數據庫死鎖。甚至,用于分離不相關實體bean的并發只讀事務或并發事務可能死鎖。

EJB事務管理經驗應當盡可能地使用聲明的且由容器管理的事務,以使為事務管理服務API編寫代碼的開銷最小化。這不僅能減少程序員的工作量,而且還會減少最終代碼中出錯的可能性(例如,它將防止您意外地不提交事務或過早提交)并允許您不作編程更改就更改行為。分布式環境中的事務不應該跨越用戶思考時間。事務應該從接收到用戶請求開始,在返回響應時結束。當用戶使用響應中所包含的數據時,事務不應該保持活動。這樣做有幾個好處—最主要的好處是更短的事務減少了應用程序中的爭用,因為數據庫鎖定保持更短的時間周期。

EJB事務管理經驗應該將會話bean用作任何實體bean一個前端,以將多個相關的實體bean組合成一個事務。這樣,會話bean方法將代表單一工作單元。只有在例外情況下,會話bean才應該采取由bean劃分的的事務,其中,事務跨越多個更高級別的方法是有必要的(但是,您必須留意長期存活的事務)。準則應該是使用由容器劃分的事務。避免由客戶機劃分的事務。使用由客戶機劃分的事務不僅對同種錯誤(與由bean區分的事務所對應的錯誤相同)打開了系統,而且還通過將系統的關鍵功能(事務的管理)移至整個系統的前端層或GUI部分而違反了分層原則。數據庫訪問和并發管理

WebSphere在AdministrativeConsoleEJB頁面的General窗格中有一項設置,讓您將數據庫訪問設置成共享或互斥。聯機文檔沒有解釋該設置。它暗示了有關于如何以及何時從數據庫刷新已高速緩存的實體bean狀態。如果數據庫訪問是共享的,則容器假設它必須與其它應用程序共享對EJB表的訪問,并且在每一個事務的開始和/或結束刷新和更新該實體bean。WebSphere將事務隔離委托給數據庫。數據庫訪問和并發管理如果數據庫訪問是互斥的,則容器假設它對EJB表具有互斥權利,其它應用程序不能使用它們。這種方式減少了數據庫訪問并提高了性能,因為容器在事務之間保留高速緩存的實體bean,并且在每個事務開始時不從數據庫刷新。這有可能減少數據庫所放置的鎖的數量,并因此減少死鎖的風險和可能性。這還意味著,如果兩個WAS容器并發訪問EJB表(就象工作負載管理的情形那樣),則唯一可能的“數據庫訪問”設置是共享。即使在互斥方式中,WebSphere容器仍不提供事務隔離和并發性管理。在任何一種情況中,重要的是:雖然容器提供一些并發性管理,但是它將事務隔離方面的任務委托給數據庫。對于數據庫,EJS容器只是另一個多用戶應用程序。因此,EJB應用程序開發者必須理解容器如何使用數據庫以及應用程序需要做什么。為什么需要互操作性?

滿足客戶的需求異構已成為事實完全的中央控制不切實際大多數大企業擁有混合的系統企業合作,收購,兼并企業要求互操作性CIO已經把集成列入IT方面第一關注的事項誤區套牢(Lock-in)還是開放(Open)跨平臺還是互操作性互操作的目標保護現有的投資與新模塊無縫結合訪問到任何平臺上的業務邏輯通過標準接口訪問到數據層充分發揮平臺的優勢j2ee.net應用程序流程JSPsServletsServletsEJBsDB2ASP.NETServicedComponentsSQLServer客戶端Web層業務邏輯層數據庫層瀏覽器互操作–業務層集成EJB集成應用程序服務器考慮:事務處理錯誤處理可伸縮性,安全性,性能Web層業務邏輯數據層Web層業務邏輯數據層互操作-業務層

方案一RMI-.NETRemoting橋接優點接線層級的性能缺點緊耦合特定的廠商和版本Web層業務邏輯數據層Web層業務邏輯數據層j2ee.net互操作-業務層

方案二JSPsServletsServletsEJBsDB2ASP.NETServicedComponentsSQLServer客戶端Web層業務邏輯層數據庫層瀏覽器方案二:消息隊列互操作-業務層

方案二消息隊列(MQSeries)優點松耦合支持N到N的場景支持事務,安全性,可靠的消息傳遞缺點不能同步操作可能出現端口或防火墻問題消息隊列跨越互聯網?PresentationApplicationSessionTransportNetworkDatalinkPhysicalNetworkInterfaceIP,ARP,ICMPTCPApplicationUDPTCP/IPOSIOSIvs.TCP

和消息隊列消息隊列松耦合系統獨立系統相聯結獨立的基礎架構獨立地開發,部署,管理彼此之間沒有信任關系目標少數的,定義明確的連接點各系統實現沒有依賴性任何一端的修改都可以適度容忍j2ee.net互操作-業務層

方案三JSPsServletsServletsEJBsDB2ASP.NETServicedComponentsSQLServer客戶端Web層業務邏輯層數據庫層瀏覽器方案三:Web服務互操作-業務層

方案三Web服務優點松耦合同步(或異步)操作跨防火墻產業界推動可擴展缺點Web服務標準在事務處理,可靠消息傳遞方面缺少支持安全性如何?Web服務基本的標準(XML,XSD,SOAP,WSDL,UDDI)沒有涉及安全性現在可以使用點到點基于傳輸層的安全措施(比如,HTTPS)將來的版本將包含WS-Security對于其它互操作機制自己完成加密,數字簽名等互操作建議可能的情況下使用XMLWeb服務轉移到一個面向服務的體系結構使用XMLSchemaXMLWeb服務包含了XMLSchema也適用于消息傳遞,文檔交換,及其它情形只有在絕對必要時才可以不遵循這些約定集成調度員

超越點到點的連接.NET

Web服務

應用程序J2EEServer+

Web服務

實現應用程序應用程序應用程序WebSphere

服務器SOAP請求SOAP響應FTP請求SMTP請求轉換組合跟蹤分析業務流程

建模應用程序CICS調用HTTP請求SOAP問題是否系統需要大量的數據交換嗎–每秒鐘上千條信息?考慮在兩端使用相同的技術.這使你能使用高性能的二進制協議和一個緊耦合的模型,它更支持高吞吐量的事務處理.使用XMLWeb服務作為橋接協議.現有WebSphere系統中的程序可以修改嗎?包裝并顯示現有的程序為web服務.利用現有的WebSphere應用程序中的通信和遠程機制進行隱含橋接.需要保存并轉發或容忍網絡故障的功能嗎?使用消息中間件.使用簡單的傳輸方式,比如SMTP,FTP,HTTP.XMLWeb服務不適合或者不可行嗎?使用共享文件系統,消息中間件或共享數據庫.使用XMLWeb服務.有下面的情況出現嗎:一個復雜的過程流?多輸入輸出?需要消息轉換或協議轉換?消息必須被跟蹤,核查和分析?用MQInteger服務器來實現這些功能.直接的對等的XMLWeb服務.需要跨橋接的分布式事務處理嗎?重新構建系統以避免跨領域的緊耦合.或者,使用公用技術以允許分布事務處理.Web服務出現之前各種組件之間的“戰爭”各種編程語言之間的“戰爭”防火墻的阻擋沒有在互操作性上有任何一致協議在Internet應用集成中的問題不同組件模型的組件無法進行相互的無縫調用相同組件模型在Internet上也很難甚至無法相互調用EJBCORBACOMCORBAWeb服務定義了:范疇:“面向服務”(Service-oriented)的體系結構“裝配線”的概念“按需服務”的構想技術就是在(典型的是)HTTP之上使用XMLXML:因為商家對它一致認可HTTP:因為它可以穿過放火墻“Web服務”技術包含任何屬于“提供服務”范疇的技術典型的技術有:SOAP:XML/HTTPWSDL:用于描述服務UDDI:用于商業服務的注冊ebXML:用于商務數據交換,商業流程Web服務的“廣告”按需服務所使用的技術都得到業界商家的廣泛認可動態地發現銀彈Web服務的“真實現狀”按需服務?還沒有。所使用的技術都得到業界商家的廣泛認可?

還沒有。動態地發現?不。銀彈?不是。Web服務的“真實現狀”Web服務只是給一些老的技術帶了一頂有趣的新帽子你現在就已可以通過sockets來使用XML/HTTP;你現在就已可以使用IDL或接口來對服務進行描述;你現在就已可以通過“Java?NamingandDirectoryInterface?(/JNDI)”

來對服務進行注冊這里沒有任何新的東西;事實上,很多公司都早已開始、并一直在提供著Web服務;Web服務真正的優點在于:應用程序之間的松耦合相互獨立的應用程序的更新B2B—更加廉價,利用InternetEAI—無縫的集成“組件之間的戰爭”不會影響互操作性“編程語言之間的戰爭”不會影響互操作性應用環境和背景Web“過去”是面向人的;Web正在逐漸成為一個B2B的平臺A2A:應用程序到應用程序(application-to-application)B2B:是A2A中很流行的一種特殊應用Web服務是一個分布式計算平臺,在其上可以構造A2A的應用程序將現有的專用系統進行統一

(例如:信件

ú

傳真

ú

電子郵件

úHTML表單

úXML的傳遞)基于一堆新技術,包括:SOAP,WSDL,UDDI…什么是一個Web服務?Web服務中的術語WebServicesDescriptionLanguage(WSDL) [Web服務描述語言]SimpleObjectAccessProtocol(SOAP) [簡單對象訪問協議]UniversalDescription,DiscoveryandIntegration(UDDI) [統一的描述、發現和整合]一般的Web服務的特征傳遞(Delivery)與容器(Container)組件/服務的設計“Service”的粒度耦合度細小粗糙緊密松散“傳輸/接口(Transport/interface)”的特征延遲(Latency)帶寬(Bandwidth)

安全性(Security)

透明度(Transparency)...e-Business驅動了WebService的發展,而WebService的基石是Web技術、IT技術和對象技術的融合。高度可集成的、基于Web的對象通過SOAPMessage實施的面向對象編程能夠將你現有的企業應用使用SOAP包裝、WSDL描述,從而發布企業的商務功能或商務數據什么是XMLWebService?一個能夠使用XML消息通過網絡來訪問的Interface,這個Interface描述了一組可訪問的操作。由SOAP+WSDL包裝的Object適應松散耦合的網絡環境,可通過Web訪問,手段是SOAPMessage服務的行為、輸入/輸出都可使用WSDL描述WebServiceInterfaceInvocationSOAPWSDLDescriptionServiceRequestor什么是XMLWebService?什么是XMLWebService?通過標準的Web協議(HTTP)可編程訪問的WEB組件開放的

Internet

傳輸協議XMLWeb

serviceSOAPSOAP(簡單對象訪問協議)–用XML實現Webservice的標準協議WSDLXMLWebservices

DescriptionLanguageWSDL–描述Webservice的語言規范,相當于訪問Webservice的接口基于開放的Internet協議XMLandHTTPUDDIUniversalDescription,

DiscoveryandIntegrationUDDI-Webservice的黃頁WebService

層次結構Internet:IPv4,IPv6Transport:HTTP,FTP,SMTPMessaging:SOAPServiceDescription:WSDLServiceDiscovery,Integration:UDDIWorkflow:WSFLRouting,ReliabilityandTransaction:??????ManagementQualityofServiceSecurityWebService架構演化緊松耦合度GranularityScopeXML/HTTPMOMORBB2BMarket,

GlobalEnterpriseEcosystemsHomogeneous

ApplicationProgramTypicalaccessvia:WebServicesServicesComponentsObjectsSimpleObjectAccessProtocolSOAP1.0:Userland,Microsoft,DeveloperMentorSpecifictoCOMandHTTPSOAP1.1:Userland,Microsoft,IBM,Lotus,DeveloperMentor

自由的傳輸綁定(不僅僅是HTTP)自由的語言綁定(比如Java,C#)可插入的數據格式(當然必須基于XML)完全的中立(中立、公開的標準)獨立于任何編程語言、對象模型、操作系統、平臺SOAP消息結構Request/ResponseMessageRequest調用遠端對象的某個方法Response返回該方法運行后的輸出結果User

SOAPRequestSOAPResponseServiceProvider

WebServiceSOAP消息結構SOAP定義了一個“envelope”對象使用“envelope”包裝消息自身消息可以采用自身特定的XML詞匯使用namespace來區分彼此MessageEnvelopeSOAP詞匯集自定義詞匯ASOAPRequest消息<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://{soaporg}/envelope/"

SOAP-ENV:encodingStyle=

"http://{soaporg}/encoding/"><SOAP-ENV:Body><m:QuoteStockPricexmlns:m="Some-URI"><Symbol>MSFT</Symbol></m:QuoteStockPrice></SOAP-ENV:Body></SOAP-ENV:Envelope>ASOAPResponse消息<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://{soaporg}/envelope/"

SOAP-ENV:encodingStyle=

"http://{soaporg}/encoding/"><SOAP-ENV:Body><m:QuoteStockPriceResponse

xmlns:m="Some-URI"><Price>66.13</Price></m:QuoteStockPriceResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>SOAP隱藏了實現細節User

SOAPRequestSOAPResponseServiceProvider

HTTP

Server?SOAP

Processor用戶只需要了解SOAP消息的格式,而對底層實現的細節可以無需關心EJB?Corba?DCOM?為什么SOAP會成功?Internet環境下實現技術的多樣性使得早期的分布式技術無法實現普遍的互相連接DCOM–需要每個連接點都使用WindowsCORBA–需要每個連接點都有ORBRMI–需要每個連接點都使用JavaSOAP是基于平臺獨立的選擇簡單的XML格式可以在任意平臺采用任意技術可以使用開放源代碼資源WebServicesDescriptionLanguage使用XML進行描述類似IDL,不過是使用XML格式描述了服務的操縱信息ServiceInterfaceImplementationDetailsAccessProtocolContactEndpointWSDL是早先技術的綜合IBM'sNASSLMicrosoft'sSDLWSDL元素types:描述將會使用的數據類型message:定義傳入傳出的消息格式portType:定義了一個入口的類型(使用了怎樣的request/response消息對)binding:確定portType將會使用何種傳輸協議(SOAP/HTTP-POST/…)port:定義了一個關聯某個binding的服務入口service:一組port組成的WebService什么是UDDI?為加速WebService的推廣、加強WebService的互操作能力而推出的一個計劃基于標準的服務描述和發現的規范(specification)以資源共享的方式由多個運作者一起以WebService的形式運作UDDI商業注冊中心IT業界和商業界的領導者的合作UniversalDescription,DiscoveryandIntegration為什么UDDI會成功?UDDI商業注冊中心存儲全球商家的信息切合當前商業需要電子商務的全球化需要技術平臺的支持UDDI和WebService正是核心和基礎在現有技術上的技術規范使用SOAP作為底層技術由各大IT業領導者一起制定技術規范UDDI角色和操作ServiceProvider提供e-BusinessService通過ServiceRegistry發布(Publish)其提供的可用的ServiceServiceProviderServiceRegistryServiceRequestorPublishUDDI角色和操作ServiceRegistry為Service的發布和定位提供支持類似電話黃頁ServiceProviderServiceRegistryServiceRequestorPublishUDDI角色和操作ServiceRequestor通過ServiceRegistry發現(Find)需要的Service綁定(Bind)ServiceProvider提供的Service,并實施調用ServiceProviderServiceRegistryServiceRequestorPublishBindFindWhereisSOAPandWSDL?WSDLPublish的內容、Find的返回結果和Bind的信息都是WSDL描述的服務信息SOAPServiceRegistry的訪問(Publish/Find)、Service的訪問都是通過SOAPMessage實現ServiceProviderServiceRegistryServiceRequestorPublishBindFindUDDI解決了什么問題?一個中等規模的制造型企業需要和大約400個合作伙伴架構在線的交易關系,而每一個交易關系的連接可能都有其自身的標準和協議更廣泛的B2B中國的一家花店想要將他能提供的服務加入到全球所有合適的e-Marketplace中去,但卻不知道該如何尋找這些e-Marketplace更智能地搜索一家B2B的e-Marketplace無法順利地獲取行業內及行業外的相關供應商的供應目錄數據,對于行業內的承運商等也同樣如此。更容易的資源匯聚描述服務發現服務互相集成UDDI版本和進展從現有的標準(standard)開始TCP/IP,HTTP,XMLIndustry-specificschemasSharedvisionofopenprotocols2.通過WebService的形式實施和拓展Commonwebservices“stack”SharedimplementationtoavoidconfusingcustomersPublicspecs,openservice,inclusiveprocess3.將轉變為一個標準實體組織Managedesignprocessfor3revsLicensecontrolandIPtoa3rdparty注冊數據商業實體注冊其自身的發布信息標準實體,程序員,商業實體注冊他們提供或所有的ServiceType信息White

PagesYellow

PagesGreen

PagesServiceTypeRegistrationsWhitePages商業實體的名字描述文本可以包含一系列的多種語言版本的描述聯絡信息names,phonenumbers,faxnumbers,websites…已知的商業標識符listofidentifiersthatabusinessmaybeknownby-DUNS,Thomas,otherYellowPages商業分類在v1中支持3個標準分類法Industry:NAICS(Industrycodes-USGovt.)Product/Services:UN/SPSC(ECMA)Location:GeographicalTaxonomy通過name-valuepair的方式實現分類描述,這樣使得在businesswhitepage中可以包含所有合法的分類法標識符。(NAICS,02417)GreenPages如何與ServiceProvider實施技術綁定提供了一整套的技術注冊信息來描述其他企業如何與注冊者“doe-commerce”WebService的技術規范的引用對基于文件/URL的發現機制的支持NestedmodelBusinessprocessesServicedescriptionsBindinginformationProgramming/platform/implementationagnosticService可以通過標準分類法分類Registry運作IBMMicrosoftHPotherotherUDDI.orgqueries對等結點(websites)商業實體可以在任意結點注冊不同的結點將會每天定期同步復制數據在所有結點都會包含注冊數據的全集所有的結點都支持UDDI規范中定義的整套SOAPAPI由商業合同保證彼此的協作關系UDDI和SOAPUser/Client

UDDI

SOAPRequestUDDI

SOAPResponseUDDIRegistry

Node

HTTP

ServerSOAP

ProcessorUDDI

RegistryServiceB2B

DirectoryCreate,View,

Update,andDelete

registrationsImplementation-

neutral

WebServices:

業務革命“doinge-busines”革命性的方式全球商務產品和服務的數碼黃頁使得新型e-Business應用以及動態服務集成能夠迅速發展機遇:第三方的增值服務的出現基于UDDI的BusinessSearch全球性的行業Marketplace給予如此豐富集中的高價值的商業數據,事實上可能出現的服務的范圍將異常地廣泛WebServices:軟件革新NOTasoftwarerevolution基于現有標準是現有系統的一個延展并不需要一個新的編程語言SOAPmodelisnotnew與20年前的RPC具有同樣的目的WebServices:軟件革新What’snew:為調用遠端的對象提供了一整套的Internet規范,而使遠程調用輕便非凡使用了實現中立的消息格式UDDI:一個可用service的通用統一的目錄為商業聚合提供了不同層次的服務電子商務隨需應變 “電子商務隨需應變”(e—businessondemand)。簡單地說,就是企業用戶在需要企業管理程序、商業數據庫資料時,不必再獨立投資建立內部的全套軟件和程序,只需到IBM提供的網上企業電子商務應用軟件庫里去調一

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論