大家都知道C/S(Client/Server),那您知道B/S嗎?    C/S結構，即Client/Server(客戶機/伺服器)結構，是大家熟知的軟體系統體系結構，通過將任務合理分配到Client端和Server端，降低了系統的通訊開銷，可以充分利用兩端硬體環境的優勢。     B/S結構，即Browser/Server(瀏覽器/伺服器)結構，是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶介面完全通過WWW瀏覽器實現，一部分事務邏輯在前端實現，但是主要事務邏輯在伺服器端實現，形成所謂3-tier結構。B/S結構利用不斷成熟和普及的瀏覽器技術實現原來需要複雜專用軟體才能實現的強大功能，並節約了開發成本，是一種全新的軟體系統構造技術。這種結構更成為當今應用軟體的首選體系結構，microsoft.net也是在這樣一種背景下被提出來的架構，但微軟的方案只是一種構想，要成為現實還需要幾年，而JAVA技術已經是很成熟的應用了... 請詳見:http://delphi.ktop.com.tw/topic.php?topic_id=24337    以下有一個小小的B/S架構的展示畫面(採用ASP寫的,功能寫得還很少)    請進入體驗一下看看,http://weboa.51reg.net/system/Member/Login.asp?account=test&password=test&qydh=10006    站長列出畫面給大家參考看看! ～～～Delphi K.Top討論區站長～～～

------
～～～Delphi K.Top討論區站長～～～

請問天使:   Browser/Server跟WebService有何不同?是相同的東西嗎?    網路志工聯盟----Visita網站http://www.vista.org.tw ---[ 發問前請先找找舊文章 ]---

[本篇屬於轉貼文章，僅共參考！]    編者按: 為了更貼近軟體開發人員，為他們提供一個技術交流的平台，從本期開始，實用技術欄目更名為應用沙龍，下設軟體開發工具及技術、資料庫、網路管理和知識窗四個子欄目。雖然欄目的設置和名稱變化了，但不變的是我們的讀者定位，是關注我國程式員的成長、為軟體專案師服務的宗旨，是為我國的軟體人員提供一個交流園地的目的，因此我希望您對我們的關注和支持也一如既往。今年，在新的欄目安排下，我們將特別加強與讀者的交流和互動，就一些主流的軟體開發工具的最新近展和軟體開發的熱點技術進行探討，對資料庫技術和網路管理進行研究，對程式員的職業規劃進行交流，我希望在您軟體技術水平的點滴提升中，在您人生經歷的每一次成功中，都有我們相伴左右。      本期除了常規的知識窗外，我為您奉上四篇文章：《C/S、B/S及三層結構》（上）這篇文章是作者為所在公司的軟體開發人員進行培訓時的講稿，雖然作者不是一位專家，對一些問題的看法也未必準確，其內容也不是當前最熱門的話題，但是它是第一線軟體專案師的切身體會，是作者本人的實踐經驗總結，言之切切，所以我選中了它；《漫漫J2EE學習路》是一位網友的帖子，有讀者向我推薦了它，他告訴我，在Java論壇、計算機世界網和CSDN等不少知名網站的Java頻道都有轉載，因此我也就將這篇文章推薦給了各位Java愛好者，這篇文章給那些Java愛好者指出了一條學習的道路，相信Java愛好者不會失望；《Henry的VB.NET之旅》是本欄目所做的一次嘗試，此次一改過去傳統的技術講座形式，用一個個故事來講述VB.NET的知識點，我們希望讀者在輕鬆幽默的學習程序中，掌握VB.NET; 《XML和資料庫》揭示的是當前熱點XML和資料庫的關係，關注XML技術的人不妨一讀。      對一名軟體開發人員而言，計算機語言只是手段，開發平台是工具，而技術才是真正的實現。所以任何一位在軟體開發領域奮鬥的朋友，都應努力把握目前軟體開發的主流技術與知識，才能在這個領域中立於不敗之地。     多層模式（N Tier） 從事過Windows下MIS程式開發的人，都很清楚C/S是怎樣實現的，在此筆者並不是要拋棄兩層模式，只是希望通過筆者的描述幫助大家建立概念及瞭解三層結構帶給我們的是什麼空間。 誤解一：C/S退出歷史舞台了 筆者以為，C/S並沒有到這麼慘的地步，任何一個項目或任何一種方案，都要分析一下它實現的是什麼東西，並且它將要面對的最終用戶是什麼性質。比如開發一個在Windows下執行的程式，或開發一個在局域網內並且只針對少量用戶的程式，或者一個管理程式、後台執行程式，未必一定強求使用多層模式，因為它並不能給你帶來什麼，反而會增加你的工作量與維護量。 我們不應該單純追求技術的先進性，而要追求實用技術，當你要實現一個方案時，你要分析項目的性質及最終用戶，然後再尋找能解決你問題的最實用手段。因為用戶並不關心你採用多麼先進的技術，用戶關心的是可靠（Reliable）、快速（Rapid）、方便（Convenient）。 誤解二：多層模式只適用於大型項目 這是常見的一種誤區，包括筆者自己，在進入N Tier領域之前都是這種想法。但隨著對N Tier瞭解的不斷深入，才發現這種理解是錯誤的。具體的選擇應根據項目的特點及面向的最終用戶群性質來決定。 如果你的項目執行在廣域網，就必須考慮資料的安全以及帶寬問題，或者當你面對的是普通用戶，他們不可能完成複雜的程式設置、安裝等工作，或者簡單地講，如果你要實現一種零成本或者最小成本的最終用戶維護，你就必須考慮採用N Tier的B/S模式來開發該系統。 我們習慣把N Tier模式稱作三層結構體系，因為N Tier實際上是三層結構的變體。正確理解三層結構對於程式員而言非常重要，因為這裡面包含著許許多多的理論和技術背景，融合了多少天才式人物的奮鬥，才有了我們今天成熟的N Tier開發基礎。 三層結構的技術實現手段 要開發一個三層結構，這些技術是必不可少: 中間件、通信協議以及交易模式。 中間件 中間件是構造應用服務器不可缺少的。目前在Window平台下通用的三層結構中間件有下面幾種: Midas、CORBA、COM/DCOM/COM 以及Asta。 Midas是Borland公司從Delphi 3開始達到應用級的產品，功能強大，也是Borland公司的旗艇產品，可應用在Windows及Linux下; CORBA是OMG（物件管理組織）推出的產品，有強大的跨平台能力; COM/COM 是Microsoft的拳頭產品，也是每次Microsoft都要宣傳的理念之一，目前已整合到操作系統中。它的結構非常龐大，如果把Midas比喻成一隻野馬，那COM 就像是一頭獅子。獅子看起來比野馬強壯很多，但要馴服它卻很不容易。最後一個是Asta中間件，可能大家不太熟悉，實際上從1997年開始Asta公司就致力於發展這個產品。它內嵌了Socket連接，有強大的“消息"開發機制。 通信協議（或連接方式） 通用的中間件連接模式有TCP/IP（如Socket）、DCOM、CORBA等。程式員經常會把DCOM與COM混淆，實際是有區別的，COM只是一種服務提供，而DCOM才能使COM真正發揮它的魅力，DCOM在COM的基礎上增加了分佈的概念。目前，微軟又新推出了.NET，對DCOM進行了發展和完善。 Midas既可使用DCOM連接，也可使用Socket連接，Borland公司在Delphi 5中對Midas進行了核心性的改造，所以要使用Midas，一定要看Delphi 5以上版本的書籍。 COM/COM 只能使用DCOM連接，CORBA使用自己的連接協議。這裡筆者還想提一下DCOM，DCOM連接雖然優點很多，但設置過於複雜，所以連Microsoft也承認其缺陷。Microsoft在.NET平台中將首推SOAP連接協議，SOAP是建立在HTTP上層的協議，主要為了適應XML的發展，目前已得到許多大公司的支持（如IBM、Oracle等）。 交易模式 最著名的是MTS，它的英文全稱是Microsoft Transaction Server，交易模式實現的功能非常多，比如，多段提交模式，其Pooling技術，也就是緩衝池技術，讓資料提交更加安全、快速。很難想像，如果沒有交易模式，三層結構要做什麼：你要自己動手寫大量的程式碼實現事務機制，如果解決得不好，還降低了程式的可靠性與速度。而MTS是建立在系統層的，可以幫助你解決許多本應在程式裡解決的東西。還有一點要記住，目前市面上Windows開發平台上，只有Delphi與VC才能真正發揮MTS的功能。 三層結構編程要點 對此筆者不想講太多理論，只給大家一句經典名言，這句話每個程式員都應該牢牢記住：All business logic in the Middle Tier（所有的商業邏輯處在中間層上）。如果不這樣，你開發的三層結構程式就不專業，或者只是C/S模式的翻版產品。這句話雖然很簡單，要達到這一境界卻需要大量的經驗積累。 另一個要領是: 一定要盡量減少應用服務器與前台程式的資料傳遞量以及Round Trip。因為如果你的三層結構存在頻繁的Round Trip，那麼你開發的應用服務器效率一定非常低下，當同時進入10個連接時，你就會發現應用服務器接近癱瘓。 在開發三層結構的系統時，應該養成一種好習慣，就是在系統分析或者設計報告中，較為詳細地描述如何解決商業邏輯、如何有效降低資料傳遞量，以及只使用必要的Round Trip。只有這樣，別人才能與你一起探討你的解決方案是否合理，是否有更有效的實現方式。同時，經過不斷歸納，提高自己的系統分析能力。 在開發大量用戶連接的應用服務器時，多多執行緒技術是必要的，否則當應用服務器在處理一個用戶的請求時，另一用戶只能等待，如果這種等待的時間太長了，用戶就會對軟體失去信心。還有一個是分佈式的概念，你可以根據商業邏輯來切分，開發並發佈多個應用服務器解決不同的商業邏輯；或者你可以將執行應用服務器的多個進程分佈在不同的服務器中，並根據訪問流程自動引導用戶到合理的應用服務器中。 正是因為三層結構比C/S複雜，所以你要成為三層結構的高手，一定要經過一段較長的時間和大量項目的鍛練。但三層結構體現了一個開發人員與系統人員的專業素質，因為它涉及太多東西: 技術工具的選型、模塊化和元件化思想、前後台功能的分割等等。從真正意義上來講，只有三層結構的項目才能完整反映軟體項目的每個程序。 B/S模式與發展 主流的軟體架構B/S與N Tier模式都有一些缺點，所以現在出現了許多B－N Tier的系統，就是基於Web瀏覽器的多層結構開發模式，它吸收了兩者的優點。 我們知道單純的B/S方式，雖然很令人興奮，並且最終用戶使用成本幾乎為零，但它存在許多不足，它的功能較弱，無法非常容易地實現你的理念。比如你要實現一種商業模型，你會發現實際上Web方式是不安全、不可靠的，比如，用戶可通過頁面回退或前進來改變你所有希望的結果、報表製作能力不足等。 為什麼Web會造成邏輯實現上的困難？因為它是基於Stateless（無狀態）的。打個比方，Stateless就是這樣一種情形：你與你的用戶中間有一道牆，你並不知道牆另一邊的用戶長得什麼樣子，甚至是男是女你都不知道，然後你通過牆上的一個小窗遞給他一件禮物，至於禮物最終的流向，你也一無所知，這就是Stateless。所有基於HTTP的東西都是Stateless的。而Socket的魅力就在於它是有狀態的。 筆者以為現在發展起來的ASP、JSP、Java技術，都是在彌補HTTP協議存在的無狀態缺陷，但即使有了這些工具，仍會覺得網頁編程無法隨心所欲，因為這些技術再先進，也無法解決HTTP協議基於Stateless的事實。 也許有人會問，這些動態網頁開發技術是如何在一定程度上避免了Stateless的弊端的？以基於IIS的ASP技術來說，它使用Session變數來實現State。但是不管什麼技術，最終都落在了COOKIE上，也就是使用COOKIE來保留客戶端狀態。 這裡還要提一下Socket。Socket目前應用十分廣泛，ICQ、QQ等即時通訊軟體，還有許多網路工具，大都基於Socket，因為Socket協議是有狀態的，所以才能做到這一點。可以這麼說，是Socket讓網路生活更精彩！ 目前基於Web的多層結構採用的底層技術主要有SOAP State類協議或者HTTP State類協議。這裡有一個Delphi程式員的好消息，從Delphi 6開始引入WebSnap包（一種Web Provider產品），它的設計者被Borland公司稱為Borland歷史上最偉大的專案師之一。它同時支持HTTP與SOAP協議，也採用了一種類似Session變數的模式來實現有狀態(State)。它可以說是目前市面上最強大的基於平台的Browse/Server開發工具之一，其不足是它還不能稱為完全的RAD工具，而且門檻較高。為什麼不是ASP或者ASP.NET呢？筆者認為ASP不是基於平台的，它是基於腳本語言的，它的執行效率不高，而且它的調試困難。在Delphi 7中還引入了IntraWeb元件包，筆者以為它是一種真正意義上的網頁RAD開發工具，與WebSnap配合更會如虎添翼。 Web Provider、邏輯元件、多多執行緒處理、交易機制、消息流轉等組合在一起是N Tier開發的最高境界，筆者以為是大型商業軟體架構的首選。筆者在前面很少提到消息機制，主要是怕大家混淆了概念，消息機制並不一定在所有的多層結構中都存在，而且，如果要實現消息機制，必須尋找實現手段（比如使用Socket），否則，如果在程式中強制實施大量消息流轉（比如使用定時器監控和消息資料表方式），無論是效率還是實現的複雜性來講都是要考慮的問題。 軟體開發人員的選擇 筆者願意把軟體設計看成音樂藝術，它有許多流派，也有主流，但並不意味著別的思想被徹底拋棄。比如單層結構或C/S方式，許多人仍然在用，而且很擅長。筆者不鼓勵讀者拋棄這些傳統的東西，筆者的意思是要擴大眼界，開放思想。而多層反映的是一種集成的思想，以安全、高效、圖形方式整合系統，以元件思想逐步構架整個公司的商業邏輯，並降低最終用戶使用成本。其最核心的思想是集中，所有中間層是集中的，可以在不同的服務器上執行不同的商業邏輯元件（比如.NET），但這個邏輯元件一定是提供給所有前端程式使用的。現在許多企業都在走系統集中的道路，集中可以帶來無限的好處，但沒有軟體平台的支撐，集中是非常膚淺的。我們追求的不單純是機器的集中，機器的集中會同時帶來網路帶寬的壓力，只有應用集中了，才能最終達到合理配置資源的目的，這也是為什麼我們要用多層體系、要用分佈式思想來構建企業應用的真正原因。 筆者以為，在軟體開發的今天，作為一名專業人員，如果總在單層或C/S構架下，永遠形成不了系統思想，只有多層體系才能真正體會軟體生命週期的理念，從需求分析形成商業邏輯到系統設計、資料庫結構設計、元件化程式編寫、測試、推廣，一個好的N Tier系統一定要踏實地做好各個階段的工作。這不像程式語言的變化或者開發環境的簡單變換，因為它是一種開發思想與開發模式的完全變革，所以它也一定是一個程序，不可能要求自己在一兩個月內就能真正體會並開始駕馭N Tier模式，但商業模式變了，開發思想也要變，你必須也只能讓自己去適應新的思想，才能成為一名更加專業的開發人員。一旦你進入了N Tier的殿堂，並熟練掌握了這種開發模式，就會發現你開始逐漸形成了軟體開發的系統思想，並且在這個領域上越走越在前面，開發也會越來越有激情。 善用「注意力」，就是善於掌握「優先次序」—分清那些是重要的及不重要的。 「捨」才會「得」，集中焦距，才能發揮核心優勢。

引言: 請問天使: Browser/Server跟WebService有何不同?是相同的東西嗎?

這就功能面來看好像一樣吧! 都同樣在Web Server上執行的程式, 但WebService的定義應該是更廣的, WebService所提供的服務不一定要在Browser上流覽吧! ～～～Delphi K.Top討論區站長～～～

引言:

引言: 請問天使: Browser/Server跟WebService有何不同?是相同的東西嗎?

這就功能面來看好像一樣吧! 都同樣在Web Server上執行的程式, 但WebService的定義應該是更廣的, WebService所提供的服務不一定要在Browser上流覽吧! ～～～Delphi K.Top討論區站長～～～

恩,web service的應用可以將模組放在網路上的任一位置,提供不同平台的client來取用..就好像如果需要一股票看板的模組..只要網路上有提供這web service..就可以將其嵌在自己的程式中....以後程式需要執行此模組時..再到網路上取得web service...對使用者來說..只要他能上網....程式裡面的功能是誰提供的...他根本不用知道......不知有沒有錯誤 永遠追不上技術更新的速度~~