1、為什么說(shuō)SOA是軟件技術(shù)發(fā)展到一定階段的產(chǎn)物？

a）、我們不再能一致化系統(tǒng)，維持對(duì)系統(tǒng)的控制，需要一個(gè)新的方法——個(gè)接受異質(zhì)、帶來(lái)

分散的方法；

b）、需要一個(gè)解決“業(yè)務(wù)/IT”鴻溝的方法

2、在何種情況我應(yīng)當(dāng)一方面考慮采用SOA架構(gòu)？

大型分布式系統(tǒng)中優(yōu)先使用SOA架構(gòu)。

3、從計(jì)算環(huán)境演變中，我可以發(fā)現(xiàn)何種規(guī)律？

計(jì)算環(huán)境的演變過(guò)程：

1）主機(jī)時(shí)代。2）客戶/服務(wù)器計(jì)算環(huán)境。3）基于多層架構(gòu)和中間件的分布式計(jì)算環(huán)境。4）面向

服務(wù)的計(jì)算環(huán)境。

計(jì)算環(huán)境的演變過(guò)程是逐漸解耦的過(guò)程。

4、SOA是一種具體技術(shù)嗎？

SOA不是一種具體的技術(shù)，SOA是一種架構(gòu)風(fēng)格。

廣義上認(rèn)為SOA是包含運(yùn)營(yíng)環(huán)境、編程模型、架構(gòu)風(fēng)格和相關(guān)方法論在內(nèi)的一整套新的的分布

式軟件系統(tǒng)構(gòu)造方法和環(huán)境，涵蓋服務(wù)的整個(gè)生命周期：建模-開(kāi)發(fā)-整合-部署-運(yùn)營(yíng)-管理.

5、請(qǐng)描述一下現(xiàn)實(shí)世界中的服務(wù)模型

6、傳統(tǒng)的大型分布式軟件有哪些局限性？

1）復(fù)雜性不一致

2）業(yè)務(wù)與IT的不一致

3）已存在的遺產(chǎn)軟件

4）異構(gòu)問(wèn)題

5）生命周期的問(wèn)題

6）參與者（所有者）的問(wèn)題

7）靈活性問(wèn)題

8）冗余問(wèn)題

7、SOA是銀彈嗎？為什么？

不是，SOA對(duì)特定的環(huán)境（具有不同所有者的異質(zhì)分布式系統(tǒng)）而言是抱負(fù)的解決方案，對(duì)其

它系統(tǒng)而言也許不是一個(gè)好的方法，采用SOA是需要付出一定的代價(jià)的。

8、為什么SOA架構(gòu)可以幫助解決IT與業(yè)務(wù)的不一致？

基于服務(wù)可在業(yè)務(wù)層進(jìn)行建模，從而支持頂層設(shè)計(jì)。并且，在服務(wù)實(shí)現(xiàn)之前就可對(duì)頂層架構(gòu)進(jìn)

行驗(yàn)證

9、什么是服務(wù)，抱負(fù)中的服務(wù)應(yīng)包含哪些特性？

服務(wù)是整個(gè)SOA實(shí)現(xiàn)的核心。一項(xiàng)“服務(wù)”（抱負(fù)中）是一個(gè)自足的，無(wú)狀態(tài)的業(yè)務(wù)功能，通

過(guò)定義良好的標(biāo)準(zhǔn)接口，它接受一個(gè)或多個(gè)請(qǐng)求，返回一個(gè)或多個(gè)應(yīng)答。服務(wù)能執(zhí)行離散的工

作單元，服務(wù)不應(yīng)依賴于其它功能或過(guò)程

a）自足性

b）粗粒度

c）可見(jiàn)、可發(fā)現(xiàn)

d）無(wú)狀態(tài)

e）幕等性

f）重用性

g）服務(wù)質(zhì)量與服務(wù)等級(jí)

h）前提和后置條件

i）供應(yīng)商分散

j）可互操作址。

10、在S0A的架構(gòu)中我重點(diǎn)關(guān)注的是服務(wù)接口還是服務(wù)實(shí)現(xiàn)？

服務(wù)接口

11、服務(wù)的設(shè)計(jì)中應(yīng)當(dāng)一方面考慮服務(wù)的重用性，還是要一方面保證和業(yè)務(wù)功能相應(yīng)?

一方面保證和業(yè)務(wù)功能相應(yīng)

12、SOA中服務(wù)設(shè)計(jì)中，我們希望采用業(yè)務(wù)驅(qū)動(dòng)接口還是技術(shù)驅(qū)動(dòng)接口？

服務(wù)自身體現(xiàn)了業(yè)務(wù)功能，因此傾向業(yè)務(wù)驅(qū)動(dòng)的接口

13、如何把技術(shù)驅(qū)動(dòng)接口改寫(xiě)為技術(shù)驅(qū)動(dòng)接口

舉例：設(shè)計(jì)一個(gè)服務(wù)實(shí)現(xiàn)算數(shù)運(yùn)算業(yè)務(wù)功能

技術(shù)驅(qū)動(dòng)接口

Operation(type,parami,param2)〃其中type：1代表+；2代表-；3代表*;4代表、

業(yè)務(wù)驅(qū)動(dòng)接口：

Add(paraml,param2)

multiply(paraml,param2)

divide(paraml,param2)

subtract(paraml,param2)

14、什么是服務(wù)契約？

必須有一些機(jī)制準(zhǔn)確并具體地說(shuō)明服務(wù)向其消費(fèi)者提供的內(nèi)容，以及規(guī)定消費(fèi)者提供的內(nèi)容

(輸入、規(guī)定的操作調(diào)用順序等)。服務(wù)提供者和服務(wù)消費(fèi)者之間的雙向協(xié)議稱為服務(wù)契約

15、服務(wù)可分為哪幾種類型？它們的粒度粗細(xì)如何？重用性如何？

基本服務(wù)：提供一個(gè)基本的業(yè)務(wù)功能

組合服務(wù)：組合服務(wù)由基本服務(wù)或其它組合服務(wù)組合而成。組合服務(wù)的運(yùn)營(yíng)層次比基本服務(wù)高,

然而它們?nèi)匀皇嵌唐趫?zhí)行的(微流)，并視無(wú)狀態(tài).

流程服務(wù)：和組合服務(wù)不同，流程服務(wù)有狀態(tài)，該狀態(tài)在多個(gè)調(diào)用之間保持穩(wěn)定。流程服務(wù)可

代表長(zhǎng)期的業(yè)務(wù)流程(宏流)以判斷是否滿足業(yè)務(wù)功能需要為準(zhǔn)則，決定使用組合服務(wù)還是基

本服務(wù)

16、基本服務(wù)和組合服務(wù)那個(gè)需要滿足ACID特性？為什么？

基本數(shù)據(jù)服務(wù)要具有ACID特性由于基本數(shù)據(jù)服務(wù)其也是服務(wù)所以也要包含最低限度的業(yè)務(wù)功

能。從從消費(fèi)者的觀點(diǎn)來(lái)看組合服務(wù)也要遵循ACID。

17、什么是“補(bǔ)償”機(jī)制，SOA中為什么在事務(wù)解決方面重要采用補(bǔ)償機(jī)制

補(bǔ)償與事務(wù)相關(guān)。補(bǔ)償不同于“兩階段提交"（2PC）。補(bǔ)償采用“偽回滾”，即采用操作倒退

回來(lái)的方法。補(bǔ)償?shù)膬?yōu)點(diǎn)是更新不必同步，缺陷是必須顯示提供和調(diào)用服務(wù)。由于SOA基本數(shù)

據(jù)服務(wù)是原子性并且是無(wú)狀態(tài)的，所以必須采用補(bǔ)償機(jī)制。

18、SOA中松耦合的目的？典型的松耦合形式？

松耦合的目的是最小化依賴。當(dāng)彼此的依賴更少時(shí)，一個(gè)系統(tǒng)修改或發(fā)生錯(cuò)誤會(huì)更少地影響其

他系統(tǒng)。

典型的松耦合形式：異步通信，補(bǔ)償，異質(zhì)數(shù)據(jù)類型，中介，弱類型檢查

19、ESB是什么？為什么SOA中要引入ESB

公司服務(wù)總線（EnterpriseServiceBus）,是過(guò)去消息中間件的發(fā)展。ESB采用了“總線”這

樣一種模式來(lái)管理和簡(jiǎn)化應(yīng)用之間的集成拓?fù)浣Y(jié)構(gòu)，以廣為接受的開(kāi)放標(biāo)準(zhǔn)為基礎(chǔ)來(lái)支持應(yīng)用

之間在消息、事件和服務(wù)的級(jí)別上動(dòng)態(tài)的互連互通。ESB可以說(shuō)是搭建SOA架構(gòu)所必須實(shí)現(xiàn)

的核心功能組件。

引入ESB因素：

1）服務(wù)總線幫助服務(wù)消費(fèi)者穿越網(wǎng)絡(luò)找到服務(wù)的提供者，使得各類服務(wù)得以協(xié)同工作。

2）應(yīng)用程序隔離了內(nèi)部的具體實(shí)現(xiàn)，被包裝成一個(gè)服務(wù)加到服務(wù)總線上

3）總線的修改和替換不影響已經(jīng)存在各類應(yīng)用程序

20、ESB的職責(zé)有哪些？

a數(shù)據(jù)映射

b智能路由

以上為最基本的兩項(xiàng)職責(zé)

a解決安全

b解決可靠性

c服務(wù)管理

d監(jiān)測(cè)和日記

e業(yè)務(wù)活動(dòng)監(jiān)測(cè)

21、比較一下ESB的協(xié)議驅(qū)動(dòng)和API驅(qū)動(dòng)

協(xié)議驅(qū)動(dòng)：通過(guò)定義一個(gè)協(xié)議，服務(wù)提供者和消費(fèi)者根據(jù)該協(xié)議進(jìn)行發(fā)送和接受消息。例如：

SOAP

API驅(qū)動(dòng)：ESB定義平臺(tái)相關(guān)的API,服務(wù)提供者和消費(fèi)者通過(guò)這些API來(lái)進(jìn)行服務(wù)實(shí)現(xiàn)和服

務(wù)調(diào)用。

基于協(xié)議的驅(qū)動(dòng)：

如何進(jìn)行消費(fèi)和供應(yīng)問(wèn)題由服務(wù)開(kāi)發(fā)團(tuán)隊(duì)考慮，ESB不負(fù)責(zé)解決該類問(wèn)題。例如：每個(gè)服務(wù)的

開(kāi)發(fā)者必須滿足ESB定義的協(xié)議，如SOAPo

基于API的驅(qū)動(dòng)：

ESB考慮如何消費(fèi)和供應(yīng)問(wèn)題。服務(wù)開(kāi)發(fā)團(tuán)隊(duì)只需要考慮業(yè)務(wù)功能。ESB為相應(yīng)的API提供解

決方案（代碼生成器和程序庫(kù)）。Eg:Java接口

22、什么是BPM?為什么要引入BPM?

23、請(qǐng)結(jié)合宏流和微流討論一下BPM和工作流

24、請(qǐng)討論一下服務(wù)的編排和編制，及兩者的耦合性

25、請(qǐng)談?wù)劮植际綄?duì)象的發(fā)展歷程？

CORBA->DC0M->RMI(EJB)->S0A

26、CORBA的運(yùn)營(yíng)機(jī)制是什么？

27、什么是IDL?為什么要有IDL?

OMGIDL是一種獨(dú)立于編程語(yǔ)言、下層網(wǎng)絡(luò)和具體實(shí)現(xiàn)的數(shù)據(jù)類型和服務(wù)接口描述語(yǔ).

CORBA通過(guò)OMGIDL來(lái)區(qū)分接口和實(shí)現(xiàn)

IDL語(yǔ)言完全是一種描述性語(yǔ)言，這在異質(zhì)分布式環(huán)境中是非常重要的，由于不同的平臺(tái)上不

也許支持所有的編程語(yǔ)言。通過(guò)把IDL的特性可以映射為具體語(yǔ)言的實(shí)現(xiàn)，這就是語(yǔ)言映射的

任務(wù)

28、為什么CORBA要引入STUB和SKELETON?

為什么要有存根：

存根為客戶提供了一種機(jī)制，使得客戶可以不關(guān)心ORB的存在，而把請(qǐng)求交給存根，由存根負(fù)

責(zé)對(duì)請(qǐng)求參數(shù)的封裝和發(fā)送，以及對(duì)返回結(jié)果的接受和解封裝

為什么要有骨架：

IDL骨架是IDL存根在服務(wù)器端的相應(yīng)，提供與存根類似的服務(wù)。當(dāng)ORB接受到請(qǐng)求時(shí)，由骨

架將請(qǐng)求參數(shù)解封裝，辨認(rèn)客戶所請(qǐng)求的服務(wù)，（向上）調(diào)用服務(wù)器中的對(duì)象實(shí)現(xiàn)，當(dāng)服務(wù)器完

畢了對(duì)請(qǐng)求的解決后，骨架把執(zhí)行結(jié)果封裝，并將結(jié)果返回給客戶程序

29、基于ORB的開(kāi)發(fā)過(guò)程是什么?

基本的開(kāi)發(fā)過(guò)程：

1）定義IDL

2）將IDL映射為具體語(yǔ)言的Stub/Skeleton

3）編寫(xiě)實(shí)現(xiàn)具體服務(wù)功能的代碼

4）編譯，連接，產(chǎn)生服務(wù)器程序

5）編寫(xiě)調(diào)用品體服務(wù)功能的代碼

6）編譯，連接，產(chǎn)生客戶程序

30、請(qǐng)談?wù)勎④浐蚃AVA陣營(yíng)的分布式組件技術(shù)的發(fā)展。

Java:JavaRMI->javaBean->EJB

31、DCOM及其相關(guān)技術(shù)的演化過(guò)程

演化過(guò)程見(jiàn)上圖

32、DCOM的重要優(yōu)點(diǎn)：

1）擁有高質(zhì)量的開(kāi)發(fā)工具及方便的向?qū)В╓izard）；

2）有大量的商品化ActiveX組件可供選用；

3）具有靜態(tài)或動(dòng)態(tài)接口支持；

4）支持多線程服務(wù)。

DCOM有兩大缺陷：

1）由單一開(kāi)發(fā)者（微軟）定義并控制，這大大限制了DCOM使用者的選擇范圍（比方說(shuō)開(kāi)發(fā)工具

和風(fēng)格）。

2）缺少眾多的平臺(tái)支持，這極大限度地制約了代碼的可重用性和DCOM應(yīng)用的可擴(kuò)展性

33、請(qǐng)比較CORBA、DCOM、EJB

軟

支

支

件

公

事

持

持

產(chǎn)

開(kāi)

共

消

安

網(wǎng)

可

日

務(wù)

跨

跨

品

集

容

可

發(fā)

服

息

絡(luò)

全

隸

擴(kuò)

處

語(yǔ)

平

成

錯(cuò)

成

用

通

服

務(wù)

服

服

商

展

理

性

性

性

言

臺(tái)

熟

訊

務(wù)

務(wù)

務(wù)

性

組

支

性

操

操

件

持

作

作

度

一

一

一

一

好

好

好

好

好

好

好

好

好

CORBA好

般

般

般

般

/ORB

一

一

一

一

一

一

一

一

好

好

DCOM/好

般

般

般

般

般

般

般

般

般

股

般

ActiveX

一

一

一

一

一

一

一

好

好

好

好好

好

EJB/好

般

般

般

般

般

般

般

RMI

34、在SOA中為什么要討論MEP?

由于消息的傳遞和互換模式會(huì)影響消費(fèi)者與服務(wù)者具體實(shí)現(xiàn)

35、常見(jiàn)的幾種MEP模式，各自有什么特點(diǎn)？

1）請(qǐng)求/應(yīng)答模式：消費(fèi)者向供應(yīng)者發(fā)出一個(gè)請(qǐng)求消息，等待供應(yīng)者發(fā)出應(yīng)答消息。類似RPC.

優(yōu)點(diǎn)：實(shí)現(xiàn)較為容易和簡(jiǎn)樸，返回到同一實(shí)例

缺陷：出現(xiàn)阻塞，無(wú)法在應(yīng)答期間解決其它事情

2）單程模式：消費(fèi)者向供應(yīng)者發(fā)出一個(gè)請(qǐng)求消息，無(wú)需等待應(yīng)答

缺陷：實(shí)現(xiàn)較為復(fù)雜?？

優(yōu)點(diǎn)：異步，無(wú)阻塞

3）請(qǐng)求/回調(diào)模式：消費(fèi)者向供應(yīng)者發(fā)出一個(gè)請(qǐng)求消息，在等待應(yīng)答時(shí)不必被阻塞

優(yōu)點(diǎn)：非阻塞請(qǐng)求/應(yīng)答

4）發(fā)布/訂閱模式：。觀測(cè)者模式定義了一種一對(duì)多地依賴模式，讓多個(gè)觀測(cè)者同時(shí)監(jiān)聽(tīng)某一

個(gè)主題對(duì)象。這個(gè)主題對(duì)象在狀態(tài)發(fā)生變化時(shí)，會(huì)告知所有的觀測(cè)者對(duì)象，使它們可以自動(dòng)更

新自己。這里的主題對(duì)象就是指告知者，又叫做發(fā)布者。觀測(cè)者又叫訂閱者。

5）可靠性與錯(cuò)誤

36、如何構(gòu)造健壯的單程消息？

通過(guò)雙重確認(rèn)

ConsumerProvider

Sendrequest

Confrmsreceptionofrequest

Confirmsreceptionofcofifirmadon

Process

request

37、能否在不可靠協(xié)議上實(shí)現(xiàn)可靠的消息互換？

可以。

38、請(qǐng)求/應(yīng)答可以用兩個(gè)單程消息的組合來(lái)實(shí)現(xiàn)嗎?

可以。

39、如何判斷同步請(qǐng)求應(yīng)答和異步單程消息構(gòu)成的請(qǐng)求應(yīng)答？

根據(jù)應(yīng)答是否應(yīng)當(dāng)提交給最初的進(jìn)程/線程實(shí)例，假如是，則是同步請(qǐng)求應(yīng)答。否則是異步單

程消息

40、請(qǐng)比較EDA與S0A

EDA與S0A

S0A通常更適合請(qǐng)求/響應(yīng)互換環(huán)境，但EDA引入了一些長(zhǎng)時(shí)間運(yùn)營(yíng)的異步進(jìn)程功能。并且，

EDA節(jié)點(diǎn)可發(fā)布事件，且并不依賴于所發(fā)布的服務(wù)的可用性。它真正地實(shí)現(xiàn)了同其他節(jié)點(diǎn)的分

離。EDA并不會(huì)完全取代S0A,而會(huì)對(duì)S0A形成補(bǔ)充

通過(guò)事件所帶數(shù)據(jù)看S0A與EDA

粗粒度數(shù)據(jù)？S0A

細(xì)粒度數(shù)據(jù)？EDA

誰(shuí)的耦合性更高？

EDA的業(yè)務(wù)流程

S0A把基本服務(wù)組合成流程服務(wù)，EDA通過(guò)事件來(lái)解決流程。每個(gè)系統(tǒng)扮演特定的角色，并且

將自己解決過(guò)程的結(jié)束標(biāo)志為一個(gè)事件

41、有工作量的版本劃分和無(wú)工作量的版本劃分各自的含義。各有何優(yōu)缺陷？

無(wú)工作量版本劃分：當(dāng)業(yè)務(wù)變化時(shí)使用，用新服務(wù)來(lái)實(shí)現(xiàn)業(yè)務(wù)改變，不用修訂已有老的服務(wù)。

優(yōu)點(diǎn)：無(wú)需對(duì)已有服務(wù)進(jìn)行修改，只關(guān)注變化的部分。

缺陷：版本越來(lái)越多，最后難以管理。

有工作量版本劃分：當(dāng)業(yè)務(wù)變化時(shí)，需要關(guān)注已有老的服務(wù)。

42、服務(wù)為什么會(huì)發(fā)生變化？版本劃分重要討論的是什么問(wèn)題？

設(shè)計(jì)局限性和需求變化會(huì)導(dǎo)致服務(wù)的版本變化。當(dāng)版本變化時(shí)，需要考慮兩方面：1.開(kāi)發(fā)新版

本，使得運(yùn)營(yíng)中多個(gè)版本并行；修訂新版本，替換老的版本。

43、有工作量的版本劃分的解決方法有哪些？

1）提供機(jī)制保證向前兼容

2）通過(guò)技術(shù)手段擴(kuò)展服務(wù)

3）通過(guò)間接方法，如中介

44、不同版本用不同類型需要考慮哪些問(wèn)題？

1）導(dǎo)致的多個(gè)關(guān)聯(lián)類型也要做修改

2）在強(qiáng)類型語(yǔ)言中，需要做類型映射

3）在關(guān)聯(lián)類型和服務(wù)增長(zhǎng)時(shí)，工作量會(huì)大大增長(zhǎng)

4）也許要升級(jí)所有關(guān)聯(lián)服務(wù)

45、不同版本用相同類型要考慮哪些問(wèn)題？

1）要記錄屬性與版本的關(guān)系

2）當(dāng)數(shù)據(jù)類型因新服務(wù)而發(fā)生變化時(shí)，需要編譯所有現(xiàn)存代碼

3）根據(jù)自己的標(biāo)準(zhǔn)驗(yàn)證數(shù)據(jù)

46、SOA中可否使用泛型來(lái)解決數(shù)據(jù)類型版本的劃分問(wèn)題

可以，但是要考慮到分布式SOA環(huán)境中是否支持泛型，現(xiàn)實(shí)中很難所有平臺(tái)都支持。

47、當(dāng)碰到版本劃分問(wèn)題時(shí)，我們?cè)撊绾稳∩幔?/p>

沒(méi)有銀彈可以解決所有版本問(wèn)題，需要根據(jù)實(shí)際情況來(lái)擬定如何調(diào)整。從消費(fèi)者和提供者兩個(gè)

角度來(lái)考量版本劃分所帶來(lái)的工作量問(wèn)題。建議從如下兩個(gè)方式解決：

1）服務(wù)提供者一般建議采用無(wú)工作量的版本劃分，不同版本采用不同的數(shù)據(jù)類型

2）消費(fèi)者，采用映射層的方法解決版本不一致問(wèn)題

48、何為開(kāi)發(fā)中的服務(wù)？何為生產(chǎn)中的服務(wù)？

開(kāi)發(fā)中的服務(wù)指在設(shè)計(jì)或?qū)崿F(xiàn)的服務(wù)

生產(chǎn)中的服務(wù)指正在部署后的服務(wù)

49、IBM的SOA方法論中服務(wù)被劃分為幾個(gè)階段，各階段的重要工作有哪些？

Model:收集需求、建模、設(shè)計(jì)

Assemble:實(shí)現(xiàn)和測(cè)試

Depoy:發(fā)布

Manager：管理和監(jiān)控

50、Webservice與S0A的關(guān)系

51、Webservice的架構(gòu)與特點(diǎn)

三個(gè)參與者:

1)服務(wù)提供者(ServiceProvider)

2)服務(wù)請(qǐng)求者(ServiceRequester)

3)服務(wù)代理(ServiceBroker)

三個(gè)基本操作：

1)發(fā)布(Publish)

2）查找（Find）

3）綁定/調(diào)用（Bind/Invoke）

WebService的特點(diǎn)

a完好的封裝性b松散耦合c使用標(biāo)準(zhǔn)協(xié)議規(guī)范d高度可互操作性e高度可集成能力f動(dòng)態(tài)

性

52、什么是SOAP協(xié)議，它有何特點(diǎn)

SOAP是一個(gè)簡(jiǎn)樸的用于在Web上互換結(jié)構(gòu)信息的XML協(xié)議

SOAP1.1的特性：

a）自由的傳輸綁定（不僅僅是HTTP）

b）自由的語(yǔ)言綁定（比如Java,C#）

c）可插入的數(shù)據(jù)格式（當(dāng)然必須基于XML）

d）完全的中立（中立、公開(kāi)的標(biāo)準(zhǔn)）

e）獨(dú)立于任何編程語(yǔ)言、對(duì)象模型、操作系統(tǒng)、平臺(tái)、協(xié)議

53、SOAPMessage的結(jié)構(gòu)

SOAP定義了一個(gè)"envelope”對(duì)象，使用“envelope”包裝消息自身，消息可以采用自身特定

的XML詞匯，使用namespace來(lái)區(qū)分彼

<?xmlversion="i.o"?>

<soap：Envelopexmlns：soap="http:〃/2o23/12/soap-envelope”

soap：encodingStyle="http：//www./2023/12/soap-encoding">

<soap：Header>

</soap：Header>

<soap：Body>

<soap：fault>

</soap：Fault>

</soap：Body>

</soap：Envelope>

54、SOAP與Http的關(guān)系

55、什么是WSDL?WSDLL1版本包含哪些組成部分？每個(gè)部分的內(nèi)容及含義

WSDL:WebService描述語(yǔ)言

1)types元素中描述消息中復(fù)雜數(shù)據(jù)類型的使用。

2)message元素指定XML數(shù)據(jù)類型組成消息的各個(gè)部分。操作的輸入或輸出(參數(shù))被定義

為message元素。

3)portType元素中定義了Web服務(wù)的操作。操作定義了輸入和輸出數(shù)據(jù)流中可以出現(xiàn)的XML

消息。

4)binding元素描述特定服務(wù)接口的協(xié)議、數(shù)據(jù)格式、安全性和其它屬性。

5)service元素。服務(wù)元素包含一組port元素。端口將端點(diǎn)與來(lái)自服務(wù)接口定義的binding元

素關(guān)聯(lián)起來(lái)。

56、什么是XMLSchemaDataTypes的基類型和復(fù)合類型？

基本類型：基本的數(shù)據(jù)類型

復(fù)合類型：由多個(gè)基本數(shù)據(jù)類型組合而成的類型，類似于C語(yǔ)言中的結(jié)構(gòu)體

57、Java中的數(shù)據(jù)結(jié)構(gòu)能否所有映射到XSD?Class將被映射為什么類型？

可以；Class被映射成復(fù)雜類型

58、請(qǐng)比較RPC模式與DOCUMENT模式？在SOA中我們?cè)摬捎媚姆N模式，為什么？

RPC(RemoteProcedureCall)本質(zhì)上就是遠(yuǎn)程方法的調(diào)用。盡管Webservice是基于XML的

但是你仍然可以使用遠(yuǎn)程方法調(diào)用這種模式來(lái)進(jìn)行Webservice的實(shí)現(xiàn)，特別是在那種簡(jiǎn)樸的

請(qǐng)求相應(yīng)的模型中。在這個(gè)過(guò)程中，傳輸中的XML文獻(xiàn)所描述的更多是有關(guān)遠(yuǎn)程方法的信息,

比如方法名，方法參數(shù)等等。

DOCTUMNET

即文檔互換方式.與RPC相比較在XML文獻(xiàn)中不是做遠(yuǎn)程方法的映射，而是一份完整的自包含

的業(yè)務(wù)文檔，當(dāng)Service端收到這份文檔后，先進(jìn)行預(yù)解決(比如詞匯的翻譯和映射)，然后

再構(gòu)造出返回消息。這個(gè)構(gòu)造返回消息的過(guò)程中，往往不再是簡(jiǎn)簡(jiǎn)樸單的一個(gè)方法調(diào)用，而是

多個(gè)對(duì)象協(xié)同完畢一個(gè)事務(wù)的解決，再將結(jié)果返回

SOA中我們?cè)摬捎肈OCUMENT模式

59、WSDL支持的消息互換方式？

WSDL支持4種消息互換方式，來(lái)訪問(wèn)服務(wù)端點(diǎn)。

1)單向(One-way。服務(wù)訪問(wèn)端點(diǎn)接受消息;

2)請(qǐng)求響應(yīng)(Request-response)：服務(wù)訪問(wèn)端點(diǎn)接受請(qǐng)求消息，然后發(fā)送響應(yīng)消息；

3)規(guī)定應(yīng)答(Solicit-response)：服務(wù)訪問(wèn)端點(diǎn)發(fā)送規(guī)定消息，然后接受應(yīng)答消息；

4)告知(Notification)：服務(wù)訪問(wèn)端點(diǎn)發(fā)送告知消息。

60、在WSDL中能否有多個(gè)porttype、bingding^prot?

不可以

61、Java提供的java2wsdl■和wsdl2java工具有何作用？

Java2wsdl:根據(jù)java代碼生成wsdl

Wsdl2java:根據(jù)wsdl生成客戶端以及服務(wù)器端java代碼

62、UDDI是什么，它有什么作用？

UDDI是一個(gè)獨(dú)立于平臺(tái)的框架，用于通過(guò)使用Internet來(lái)描述服務(wù)，發(fā)現(xiàn)公司，并對(duì)公司

服務(wù)進(jìn)行集成。

63、什么是BPM?為什么要引入BPM?

64、請(qǐng)結(jié)合宏流和微流討論一下BPM和工作流

65、請(qǐng)討論一下服務(wù)的編排和編制，及兩者的耦合性

66、采用S0A架構(gòu)，性能問(wèn)題重要由那些方面引起？

1).通過(guò)ESB發(fā)送請(qǐng)求或應(yīng)答；2).反序列化請(qǐng)求或應(yīng)答；3).解決請(qǐng)求。

67、S0A常見(jiàn)的幾種解決性能問(wèn)題的思緒

1.何時(shí)采用粗粒度服務(wù)2.何時(shí)采用細(xì)粒度服務(wù)3.調(diào)用約束4.定制服務(wù)

68、粗粒度的服務(wù)性能一定好于細(xì)粒度嗎？

不一定。采用粗粒度服務(wù)時(shí)(注意不是調(diào)用基本服務(wù)的粗粒度服務(wù))，并且不考慮返回?cái)?shù)據(jù)被

使用的情況時(shí)。當(dāng)采用粗粒度服務(wù)時(shí)返回的數(shù)據(jù)量大，但所用到的數(shù)據(jù)卻很少時(shí)可考慮細(xì)粒度

服務(wù)。

69、采用“調(diào)用約束”來(lái)解決性能問(wèn)題對(duì)耦合、內(nèi)聚的影響

也許會(huì)使得問(wèn)題變得更加復(fù)雜

70、采用“定制服務(wù)”來(lái)提高性能會(huì)破壞服務(wù)所包的業(yè)務(wù)功能嗎？

1.定制服務(wù)也許會(huì)破壞了重用性

2.考慮定制服務(wù)也許會(huì)破壞業(yè)務(wù)流程和系統(tǒng)設(shè)計(jì)

71、S0A有哪些特殊安全需求？

互操作性安全、異質(zhì)和安全、分布式過(guò)程和多層抽象、多客戶端能力

72、在SOA中性能是第一位的嗎？如何取舍

1）性能問(wèn)題在需求階段必須考慮

2）性能問(wèn)題盡量不要破壞系統(tǒng)的整體設(shè)計(jì)，

取舍：

1）當(dāng)發(fā)生沖突時(shí)應(yīng)盡量考慮不破壞整體設(shè)計(jì)的解決方案，例如硬件的升級(jí)

2）當(dāng)性能是第一要素且無(wú)法通過(guò)其它方法獲得好的解決辦法是，可參考上述討論的方法

73、請(qǐng)梳理一下現(xiàn)實(shí)中實(shí)行SOA時(shí)的解決思緒。

1）確認(rèn)安全需求

2）擬定所用的SOA安全規(guī)范

3）選擇為你提供核心SOA安全功能的產(chǎn)品

4）配置及集成產(chǎn)品，以便協(xié)同工作

5）用框架填補(bǔ)漏洞

6）可以考慮把安全作為服務(wù)

7.）安全也許會(huì)帶來(lái)性能方面的影響

74、什么是BPEL?SOA中運(yùn)用BPEL的好處

BPEL：即業(yè)務(wù)解決執(zhí)行語(yǔ)言，是一種使用XML編寫(xiě)的編程語(yǔ)言，是專為整合WebServices而

制定的一項(xiàng)規(guī)范標(biāo)準(zhǔn)。BPEL的作用是將一組現(xiàn)有的服務(wù)組合起來(lái)，從而定義一個(gè)新的Web服

務(wù)

75、BPEL中同步與異步的概念以及具體應(yīng)用

76、BPEL基本結(jié)構(gòu)涉及哪些部分？

<processname="BusinessTravelProcess"...>

<partnerLinks>

<!-Thedeclarationofpartnerlinks->

</partnerlinks>

<variables>

<!-Thedeclrartionofvariables->

</variables>

<sequence>

<!-ThedefinitionoftheBPELbusinessprocessmainbody->

</sequence>

</process>

71、BPEL基本語(yǔ)法與活動(dòng)

78、BPEL開(kāi)發(fā)過(guò)程是如何的？

1）熟悉相關(guān)的Web服務(wù)

2）為此BPEL流程定義WSDL

3）定義合作伙伴鏈接類型

4）開(kāi)發(fā)此BPEL流程：

5）定義合作伙伴鏈接

6）聲明變量

7）編寫(xiě)流程邏輯定義。

79、什么是JBI?JBI的組成？

JBI(JavaBusinessIntegration)是Java業(yè)務(wù)集成，是SUN發(fā)布的一個(gè)用于Java組件進(jìn)

行集成的一個(gè)標(biāo)準(zhǔn)。JBI的本質(zhì)是一種服務(wù)總線思想。JBI的目的是創(chuàng)建一個(gè)用于各種Java

組件服務(wù)集成的運(yùn)營(yíng)環(huán)境

1)綁定組件

2)服務(wù)引擎組件

3)NMR

80、BC組件和SE組件的特點(diǎn)

BC：BindingComponents,JBI通過(guò)實(shí)現(xiàn)了不同協(xié)議的綁定組件來(lái)接受不同傳輸協(xié)議的請(qǐng)求，

綁定組件可分為接受BC和發(fā)送BC

SE：ServiceEngines是服務(wù)引擎組件，該組件負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)邏輯和其他服務(wù)。這類組件只解

決JBI容器內(nèi)部的消息。

81、什么是NMR?BC,SE和NMR如何進(jìn)行通信？

NMR是，JBI的規(guī)格化消息路由器：是JBI內(nèi)部消息系統(tǒng)的核心，所有的組件之間不能互換消

息，只能通過(guò)NMR來(lái)傳遞

在JBI容器內(nèi)部，只有一種標(biāo)準(zhǔn)的規(guī)格化消息(