JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Engineering  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 由 MVC 看軟體設計思維(2) [精華]
kenming





發文: 194
積分: 10
於 2004-11-07 22:34 user profilesend a private message to usersend email to kenmingreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
觀察 MVC 的設計思維,可以得知:畫面的設計並不是軟體設計的重心首在,畫面是手段,僅是為了表達展示給操作使用者來觀看的,若有更好的畫面呈現方式,系統可以整個抽離掉畫面而不致影響核心,就好比樹葉會代謝再長出新葉也是為了讓整棵樹能呈現更茂盛的一面。

同樣地,資料庫也是手段,是資料儲存的倉庫。若因為分散及負荷的因素,則需考慮配置多個資料庫,甚至,有效能更好、更便宜的資料庫,則隨時可更換之。

畫面(View)與資料庫都是手段,目的即是為了要能維護軟體的主幹–來自專業領域(Problem Domain)上的概念(Domain Concepts),概念往往成為軟體設計內的企業元件(Business Component)。

為了要能維護企業元件不因外在環境的變動而牽動,進而提升系統的彈性度及增進再利用的價值,軟體開發人員,要能考慮:

變與不變的相對性。
虛與實的相依性。

同時,又要能兼顧系統的效率與問題與使用者的便利性,也要能瞭解:

Stateless 與 Stateful 物件相互的配合。


★變與不變

“變” 與 “不變” 是一種相對性的關係,不是絕對的“變”或絕對的“不變”。觀察:

◆Presentation -> 易變 ; Database -> 變動幅度較小 ; Middleware -> 較穩定。

◆子系統(SubSystem) or 模組(Module)元件 -> 善變 ; 本質性(Entity)元件(Component) -> 穩定。

◆企業流程 -> 善變 ; Domain Concept -> 穩定。

◆View -> 易變 ; Control -> 變動幅度較小 ; Model -> 最具穩定性。

◆Boundary -> 易變 ; Control -> 變動幅度較小 ; Entity -> 最具穩定性。

◆屬性(Attributes) -> 善變 ; 物件(Object) -> 穩定

◆介面(Interface) -> 穩定 ; "Realize" 該介面的物件 -> 易變


★虛與實

容易變動的部分,宜採用 “虛” 的設計,也就是說,不直接落實企業邏輯的責任於易變的部分。觀察:

◆畫面與資料庫是易變動的部分,所以不負責處理企業邏輯 ; 可以這麼說,為了要能履行畫面上所呈現的功能(Function),該功能的落實,不會寫在畫面或資料庫上。

誘l系統是善變的,所以,子系統與子系統間所溝通的介面是不穩定,要以“虛”的設計來承擔其變動,也就是說,該介面僅是訊息溝通的管道(Request、Response),而由穩定的元件來落實。

◆由上點推論,擔任子系統溝通的介面的 Web Service 物件,就不宜以“實”的方式來設計。

◆控制物件接收至 View 所傳送過來的需求,它是屬於流程物件(Process Object)或功能物件(Function Object)並將該需求協調及轉派給適當的企業物件(Business Object)來處理,所以,它也是“虛”的物件。

◆由使用者的需求所構成的“流程”,宜由最具穩定來自於領域概念上的企業物件來落實,才能快速的“組裝”動態多變的流程。所以,企業物件或稱之為企業元件(Business Component),來擔任“實”的設計。


Stateless 與 Stateful

從 State + “less” or “ful” 的字義來看,顯然的,主要是以 “狀態(state)” 來作區分。不保存狀態,就為 “stateless” ; 而可以保存 Client 與 Server 之間的狀態,就稱為 “stateful”。

會因狀態的保留與否而區分為 Stateless 或 Stateful 物件,最主要就是考量到 Server 可利用的資源(Resource)有限。

傳統的OO物件大多著重於stateful物件,像UML也不著重stateless物件的探討與表達。然而,在今天的middleware(如EJB或COM+/MTS)裡stateless 物件卻大放異采,甚至掩蓋過傳統OO所青睞的stateful物件呢!

尤其,在EJB架構裡,有非常重要的用途。如R. Monson-Haefel [Mon99, p.175]所說:

“Stateless session beans require few server resources because they are neither persistent nor dedicateed to one client. Because they aren‘t not dedicated to one client, many EJB objects can use just a few instances of a stateless bean.”
(stateless 的session元件不須要長存其狀態值,也不專屬於特定的client,所以其佔用server的資源較少。也由於不隸屬於特定的client,所以許多EJB物件可共用少數的stateless 元件 。)

Stateless物件就像計程車,並不是專為某位顧客服務,只要少數的計程車就可為極多數的客人服務。 至於stateful元件則像自用轎車,每部只服務特定的顧客,常需要較多的停車場(即佔用server資源較多)。
當您呼叫計程車時,並不會指明要上次所搭那一輛計程車。同理,client使用stateless物件時,心裡必須明白stateless物件與stateful物件的不同假設,就如R. Monson-Haefel [Mon99, p.176]所說:

“A client can‘t assume that the same bean instance will service it every time.”
(client物件不能認為每次叫用時,都是由同一個物件個體來為其服務。)

因之,stateless物件的特性為:就client而言,在意的是server物件的外在行為,而行為又跟物件的狀態無關,所以client物件不必在意物件狀態的變化,而不是此種物件真的沒有狀態。就如R. Monson-Haefel [Mon99, p.175]所說:

“These restrictions don‘t mean that a stateless session bean can’t have instance variables and therefore some kind of internal state. .... However, it‘s important to remember that this state can never be visible to a client.”
(這些限制並不意謂著stateless 的session bean 不能有屬性變數,因此意謂著可以有其內部狀態。然而重要的是,client不會看到這些內部狀態。)

然而,像前面已經談過,stateless物件像計程車,stateful物件像自用轎車。stateless物件馬不停蹄地轉檯,為不同的client服務,所以stateless的再用性(reusability)非常高,而stateful物件專屬於特定顧客,常出現「佔在毛坑不拉屎」的情形,因為再用率低而造成資源的浪費。所以R. Monson-Haefel [Mon99, p.175]說:

“A stateless session bean is relatively easy to develop, and also very efficient. Stateless session beans require few server resources .... In short, they are lightweight and fast!”
(無狀態的session bean比較容易開發,也比較有效率。無狀態的session bean需節省server的資源 .... 簡而言之,它們輕盈而快速。)


在Internet時代裡,資訊系統的延展性(scalability)卻是重要無比,而高度延展性的前提必須有效運用server的資源,使得stateless物件的輕盈快速,成為極為亮麗而有價值的特性。在開發N-tier系統時,活用stateless物件成為系統設計師的必備技能。

*** 所有文章均收錄於個人的部落格(BLOG) 網站 ***
*** 本文版權為作者個人擁有,歡迎轉載,但請註明出處 ***
*** 矇矇的秘密基地(http://www.kenming.idv.tw) ***


kenming edited on 2004-11-07 22:44
reply to postreply to post
=$∼寸心千里∼$=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息 http://www.hsdc.com.tw/
作者 Re:由 MVC 看軟體設計思維(2) [Re:kenming]
saijone

Web Services

版主

發文: 470
積分: 24
於 2004-11-16 08:11 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
kenming wrote: ...
◆由上點推論,擔任子系統溝通的介面的 Web Service 物件,就不宜以“實”的方式來設計。
...


It depends on how you define “Web Services”. 目前Web Services較被廣為接受的定義, 大多是指以WSDL為界面, 以SOAP為溝通方式之應用程式功能集合. 基於這樣的定義, 您指的實與虛可能有兩種應用:

1. WSDL 為應用程式之間或Services的界面, 設計上應傾向穩定. 但WSDL後頭的 endpoint implementation就可以相當有彈性: JAVA Class, EJB,或是個透過IIOP溝通的CORBA Object, 甚至可以是dynamic的(for example, 根據QoS). WebServices所”decouple”的是service endpoint implementation 與client之間的耦合. 將client application對”services” 的 dependency 上移至更抽像或更高層次的WSDL上.

2. 事實上不論是WSDL1.1或未來的WSDL2.0, 在一個WSDL裡所定義的components(artifacts) 也有abstract與concrete的差別. for example, message is abstract, binding is concrete. 理由是 WSDL specs 並不是單為 SOAP 及 HTTP 設計的. 以 XML Schema 所定義出來的 “abstract message” 可以使用 SOAP 以外的格式, 也可以使用HTTP以外的傳輸方式.

kenming wrote: ...
...在Internet時代裡,資訊系統的延展性(scalability)卻是重要無比,而高度延展性的前提必須有效運用server的資源,使得stateless物件的輕盈快速,成為極為亮麗而有價值的特性。在開發N-tier系統時,活用stateless物件成為系統設計師的必備技能。

  
你的私人轎車idle時也可拿來出租吧? 雖然我不知道EJB的 passivate 與 activate 是不是真有用, 但至少在理論上以及其用意都是好的. 單以scalability為由, 就斷定 stateless 比 stateful 好可能不很妥當… 一個元件該不該 cache conversational states, 可能要以該元件的 responsibility 乃至於在整體 architecture上的配置來決定. 該 stateful 時還是得 stateful.

最近有個很 hot 的東西叫 SOA, 提到 Service 很多人都將它定義為 stateless. 個人認為這樣的”曲解”可能來自於一般對於”Service”的定義常會提到什麼 Service is self-contained, and does not need to depend on the context or state of other services 之類的. 這樣的定義可能會有些問題: 最直接的就幾忽把 transaction 在 WebServices上的可能性排除了, 一般認為 WebServices 最大的應用之一在於 Workflow 或是 business process 之間的整合, 但你如何避免一個 Service 將 transaction 給 propagate 到令一個 Service上或多個 Services 牽扯到同一個transaction 裡呢? 當多個Services牽扯到同一個transaction 裡時, 事實上一個stateful session已經存在.

另外在舉一個較極端的例子: 如果你可以完全不用到”非static的member variable”(也就是說你可以幾乎只寫static method), 而設計出一個優雅的東西, 那或可證明stateless可以是唯一的選擇.


reply to postreply to post
You don't need a reason to help people
作者 Re:由 MVC 看軟體設計思維(2) [Re:saijone]
joeyli





發文: 105
積分: 5
於 2004-11-17 00:53 user profilesend a private message to usersend email to joeylireply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
kenming wrote:
由上點推論,擔任子系統溝通的介面的 Web Service 物件,就不宜以“實”的方式來設計。
...

嗯...........小弟拙見.........
是否要將"擔任子系統溝通介面"的Web Services物件設計成"虛"的, 那要看WSDL的地位是否在business logic及工程考量上都被視為相對穩定.

若,
kenming大只是將WSDL定位為protocol, 且所指的"虛", "實"若是以"是否實作business logic"作為分界點的話, 那的確是應當將Web Services介面寫成虛的, 因為雖然WSDL可以定義出很廣泛的結構, 但以business logic的觀點來說, 就算是提供同樣的service, 若這次的定義與上次的定義有所不同, 例如: 多了, 或少了參數; 或者是多傳了什麼資訊, 亦或是取消了什麼資訊. 那WSDL不過是個定義溝通語意的protocol, 沒有辦法吸收這樣的變動, 所以需要再一層的介面來擋住變動.
就像JDBC一樣, JDBC雖然提供了一個與database溝通的標準, 但仍需要DAO去吸收變動.
這時候, 所站的立場在於只是將WSDL定位成protocol, 它定義出來的介面是會變動的.

這又對應到saijone大所說的:
saijone wrote:
WSDL 為應用程式之間或Services的界面, 設計上應傾向穩定. 但WSDL後頭的 endpoint implementation就可以相當有彈性

躲在endpoint後面負責處理WebServices的chain可以非常的有彈性, 以保持WSDL的穩定, 這時候整個chain的結構就等於是"虛"的, 因為它必須吸收變動以維持WSDL定義出來的interface完整. 但此處的"虛"並不代表endpoint implementation就完全不涉及business logic, 而是它應當會是一組結構, 而該結構是活動的.
所以kenming大所說的"Web Services物件"與saijone大所說的"endpoint implementation"在角色上是很雷同的.

另一方面,
在工程面的考量上, 就要看WSDL所定義出來的彈性與其標準化的程度.
若它的彈性不足, 或者標準化程度不夠, 那的確需要再一層的介面去吸收掉這樣的變動, 這時候對外服務的Web Services物件就盡量要做成"虛"的, 不涉及"business logic"的實作.
但倘若WSDL本身定義出來的彈性足夠, 且標準化, 那變動就自然會被WSDL與其配套機制所吸收掉, 就像saijone大所說:
saijone wrote:
理由是 WSDL specs 並不是單為 SOAP 及 HTTP 設計的. 以 XML Schema 所定義出來的 “abstract message” 可以使用 SOAP 以外的格式, 也可以使用HTTP以外的傳輸方式.

以這時候的觀點, 對外提供Web Services的物件就沒必要做成"虛"的.

總之, 變動總是要有人吸收掉的, 吸收變動的成員一般來說就是"虛"的一方.

小弟個人基本上同意WSDL所定義出來的interface應當要維持相對穩定, 但往往事與願違, 故, 作為service的consumer仍必須要將provider可能會將其變動的風險考量在內, 這時候最好還是要有一層緩衝.
另,
就工程面的考量來說, 雖然目前的實作仍是著重在HTTP與SOAP上, 但小弟認為已經足堪使用, 重點仍是在標準的維持, 只要不要再過度的發散, 那也沒必要因為工程上的問題太過顧慮WSDL背後的虛實問題.

saijone wrote:
你的私人轎車idle時也可拿來出租吧? 雖然我不知道EJB的 passivate 與 activate 是不是真有用, 但至少在理論上以及其用意都是好的. 單以scalability為由, 就斷定 stateless 比 stateful 好可能不很妥當… 一個元件該不該 cache conversational states, 可能要以該元件的 responsibility 乃至於在整體 architecture上的配置來決定. 該 stateful 時還是得 stateful.

針對實作面來說, 小弟覺得元件的stateful或stateless分界好像滿模糊的, 若今天我們將所謂的conversational states存放在其他地方, 直到叫用原本"工程上"的stateless元件時, 將這些conversational states灌注到它的身上, 那它事實上也算是domain local上的stateful元件, 但倘若它沒有使用到這些states就能夠進行運作時(例如: 找不到states時用預設值run), 那它又活脫脫是個標準的stateless元件.

當然, 大家談的應當都是physical上的定義, 就像saijone大所說: 它的instance是否有cache conversational states.
但, 就像上面所描述的, 當我們將states在執行時期灌注到原本的stateless元件中, 也能有stateful的效果時, 是否就成為了大家後來比較愛用stateless元件的原因呢? 就像session一樣, 我們把states帶著跑就好了啊!?

這點是小弟比較有疑問的地方, 若觀念不清, 還煩請眾大大不吝更正解惑...............

saijone wrote:
最近有個很 hot 的東西叫 SOA, 提到 Service 很多人都將它定義為 stateless. 個人認為這樣的”曲解”可能來自於一般對於”Service”的定義常會提到什麼 Service is self-contained, and does not need to depend on the context or state of other services 之類的. 這樣的定義可能會有些問題: 最直接的就幾忽把 transaction 在 WebServices上的可能性排除了, 一般認為 WebServices 最大的應用之一在於 Workflow 或是 business process 之間的整合, 但你如何避免一個 Service 將 transaction 給 propagate 到令一個 Service上或多個 Services 牽扯到同一個transaction 裡呢? 當多個Services牽扯到同一個transaction 裡時, 事實上一個stateful session已經存在.
.....

關於這點, 小弟完全贊同saijone大的說法, 就算以Service的角度來說, 也沒辦法完全排除transaction串聯的可能性, 若將目前的SOA中的Services誤解成是stateless的話, 那是完全背離現實的說法.
試想, 公司內兩個系統要利用WebServices進行整合, 以SOA的架構來說, 各系統均會提出個別的服務, 但最後我們的整合系統取用兩個服務時不保證transaction的一致性, 這是沒辦法使用的.
至於目前多數應用於Workflow中, 那是因為workflow取用每一次的service都存在比較獨立的特性, 且workflow process大部分適用來與人員協同作業, 人工介入深, 所以也比較容易處理錯誤.

小弟個人認為, 真正的SOA不只應當能夠做到stateful與transaction串聯, 而且最後決定是否stateful的人至少有一半的狀況下不會是service provider, 而應當是service consumer, 由consumer就process或business的考量, 在利用services時或需要組合出新的整合性servcie時, 才決定兩個services之間是否存在transaction或stateful的關係. 而provider所提出的service應當要能夠提供這樣的彈性.
這時候, 兩個異質系統才能真正因為SOA而有完全被視為component來使用的可能性.

這一點, 可以從WebLogic這些廠商所提出的SOA平台中看出來, 它們除了WebServices外, 還與各大ERP廠商合作包裝了其專屬的adapter, 力求以它們的平台為中心(並不是以WebServices為中心), 做到所有異質系統皆為component的可能性.


joeyli edited on 2004-11-17 01:28
reply to postreply to post
跨平台是個夢!
» JWorld@TW »  Software Engineering

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8