米布(8101690) 23:08:08
大家有沒有想把 axis 嵌到自己產品中去的?
我有一個理想(24332715) 23:08:13
如果SCA構件分布式的部署在多個應用服務器上,那么在裝配中
我有一個理想(24332715) 23:08:24
SCA的服務結構
我有一個理想(24332715) 23:08:35
接口
我有一個理想(24332715) 23:08:43
使用WS定義
我有一個理想(24332715) 23:08:57
那么裝配出來的應用效率是不是很低
david(172171) 23:09:12
可以認為SCA的容器是一個bean
我有一個理想(24332715) 23:09:47
沒懂
david(172171) 23:10:52
sca容器宿主在Tomcat上,通過sca可以引用其它分布的應用
david(172171) 23:11:40
SCA宿主:啟動SCA裝配過程的系統
米布
(8101690) 23:11:24
我能否用 bpel 流程來引用SCA呢?
david(172171) 23:11:42
可以
david(172171) 23:12:02
這個問題在那個群里已經討論過了
我有一個理想(24332715) 23:12:23
通過宿主進行的引用?
david(172171) 23:12:28
對
david(172171) 23:12:30
http://blog.csdn.net/teamlet/archive/2007/03/22/1537510.aspx
我有一個理想(24332715) 23:12:37
謝謝
david(172171) 23:12:56
從這個圖中可以看出 SCA中的component和bpel的關系
david(172171) 23:13:52
sca的component/(composite: cuiyi add)對外提供粗粒度的接口,bpel通過implementation提供細粒度的實現
david(172171) 23:14:09
sca是bpel更高層次的抽象(bpel is implement technology, sca is a component, compent is interfaces, one for expose, another for reference,就是下面的棍/坑說啦,cuiyi add)。
我有一個理想(24332715) 23:14:38
bpel是SCA的服務實現
我有一個理想(24332715) 23:14:45
是一種
我有一個理想(24332715) 23:14:50
這么理解對嗎?
david(172171) 23:15:10
是的,是其中的一種
david(172171) 23:14:57
component只不過是sca裝配模型中最基本的組件單元,上面還有composite,domain
david(172171) 23:15:36
想用bpel調用sca是可以的,但是大才小用了
david(172171) 23:16:45
實現包括 , C++, PHP, Java Script, BPEL, SQL, XQuery, Composite,ruby
david(172171) 23:17:12
當然還有java
我有一個理想(24332715) 23:49:42
SCA Component 它有一個殼,殼上Service,Reference,property,殼里邊包含的東西連接著Service,Reference,property,殼里邊的東西就是這個Component的implementation(not exactly, cuiyi add),implementation可以是很多東西,java,c++等等什么都行,這么理解對不對。
兩塊田(7739638) 23:52:39
很對
我有一個理想(24332715) 23:56:40
殼上的Service就是指出來的棍(凹進去的坑,引用找服務,就像棍插坑,cuiyi add),Reference就是凹進去的坑(凸出來的棍),棍插坑,坑插棍,幾個連一起,還有坑還有棍這時候是合成組件(Composite),對不?
兩塊田(7739638) 23:57:14
說得有點色了~:)
我有一個理想(24332715) 23:57:23
哈哈
我有一個理想(24332715) 23:58:33
再整幾個只有棍的,還有只有坑的,把Composite的棍和坑插滿,就是系統域(Domain)
兩塊田(7739638) 00:11:24
兄弟研究棍和坑研究得挺深啊.
我有一個理想(24332715) 00:11:38
兩塊田(7739638) 00:12:02
重要的是可以插進去,插出來又可以用到別的坑里~:)
我有一個理想(24332715) 00:13:48
嗯
the following add by cuiyi, 系引用



開-閉”原則(Open-Closed Principle)是面向對象的可復用設計(Object Oriented Design或OOD)的基石。其他設計原則(里氏代換原則、依賴倒轉原則、合成/聚合復用原則、迪米特法則、接口隔離原則)是實現“開-閉”原則的手段和工具。
“開-閉”原則的定義
定義:一個軟件實體應當對擴展開放,對修改關閉。
( Software entities should be open for extension,but closed for modification)。
在設計一個軟件系統模塊的時候,應該使這個模塊可以在不被修改的前提下被擴展,或者說,可以在不必修改原來代碼的情況下改變這個模塊的行為。
滿足“開-閉”原則的系統的優點
1)通過擴展已有的軟件系統,可以提供新的行為,以滿足對軟件的新需求,使變化中的軟件系統有一定的適應性和靈活性。
2)已有的軟件模塊,特別是最重要的抽象層模塊不能再修改,這就使變化中的軟件系統有一定的穩定性和延續性。
具有這樣兩個優點的系統是一個在高層次上實現了復用的系統,也是一個易于維護的系統。
“開-閉”原則的實現——抽象化
面向對象編程語言可以使用抽象的方法,為系統定義一個不再更改的抽象設計來作為系統的抽象層。這個抽象層覆蓋了所有未來可能擴展,因此在任何情況都不會改變。這樣使系統的抽象層保持不變,從而滿足了開閉原則的第二點:對修改關閉。
由于從抽象層導出的一個或多個具體類可以改變系統的行為,因為系統的設計對擴展是開放的,從而滿足了開閉原則的第一點:對擴展開放。
在SCA框架中,無論在commonj還是SPI;無論是composite還是component,都可以看到開閉原則的應用。
remark by cuiyi
I feel Component in SCA just a restriction according to DP, so exposed as interface or web service description language (XML), just made DP a restriction to developers, meanwile, the systems developed on it can be more extensice and integratable; 即:
SCA 提供一個以與技術無關的方式定義接口、實現和引用的模型,從而使技術人員能夠將這些元素綁定到所選擇的某一技術的特定實現。
例如,我們可以用 Java 定義我們的接口,將我們的實現作為 BPEL 流程加以應用,或者將接口作為一個 WSDL 文檔,而且我們的實現可以是一個 Java™ 類。下圖 演示了如何在 IBM WebSphere Process Server 中使用 SCA。
圖. WebSphere Process Server 中的 SCA

SCA的目的是使用戶在構建企業應用時有一個不再直接面對具體的技術細節的層次,而是通過服務組件的方式來構建應用。這種方式也使得客戶的企業應用具有良好的分層架構,能夠很好的分離應用的業務邏輯和IT邏輯,不但易于應用的構建,也易于應用的更改和部署。
○分離業務邏輯和技術實現邏輯
○業務過程由松散耦合、可重用的組件或服務組成
○組件或服務與平臺和實現無關
實際上呢,其就是對現有技術的再一次包裝,達到真正的屏蔽語言,我們來看看SOA規范理念,是如何達到屏蔽和包裝的:

SCA規范包括了Assemble Model和Client Model兩部分。
前者約定了如何將異種組件(Java類,BPEL,WebService)組裝并發布成SOA服務,這也是SCA
最大的特點和最核心的概念;
后者則約定了如何在異種語言環境中調用SOA服務。
那么,通過這兩部分的規范,就可以完全解決了服務從服務端到客戶端的跨語言、跨實現技術的問題。
其即將推出的DAS規范,也無非是我們現有技術的再次包裝,理念圖如下:

這樣,客戶端看到的只是DataGraph中的DataObject就是我們說的SDO,而不再需要去關注或者操作所謂的JDBC等連接數據庫的、以及JCA等連接手段獲得的數據入口了。
于是我們看到了,SOA通過SCA、SDO對現有技術進行了再次包裝或者屏蔽,從而達到了一個 大一統 的局面,但是尚未知對于大多的開發者來說這是否是一個好的消息。
不過通過如下,我們發現并不是如此的悲觀:

goCom SCA規范綜述
實施SOA不意味著要推翻既有的架構,比如MVC,而是要在現有架構上做更大的架構。

傳統的MVC對于單個應用來說非常成熟,這是實踐中證明的。對于大多數獨立的應用和系統來說MVC很勝任。然而,當企業中的應用規模不斷擴大,從幾個到幾十個甚至上百個的時候,靠若干MVC架構的不斷疊加能夠構造出一個適合企業級的架構么?所以才出現了Portal這樣的新技術來迎接這樣的挑戰,但是Portal的關注點更靠近與展現端,在底端通訊方面不能給出更好的答案。所謂架構是要一套整體解決方案,這樣的架構所要解決的問題簡而言之就是兩個特點:數目或規模大、異構應用交互。