WSDL (Web Services Description Language,Web服務描述語言)是一種XML Application,他將Web服務描述定義為一組服務訪問點,客戶端可以通過這些服務訪問點對包含面向文檔信息或面向過程調用的服務進行訪問(類似遠程過程調用)。WSDL首先對訪問的操作和訪問時使用的請求/響應消息進行抽象描述,然后將其綁定到具體的傳輸協議和消息格式上以最終定義具體部署的服務訪問點。相關的具體部署的服務訪問點通過組合就成為抽象的Web服務。 本文將詳細講解WSDL文檔的結構,并分析每個元素的作用。
一:WSDL定義
WSDL是一個用于精確描述Web服務的文檔,WSDL文檔是一個遵循WSDL XML模式的XML文檔。WSDL 文檔將Web服務定義為服務訪問點或端口的集合。在 WSDL 中,由于服務訪問點和消息的抽象定義已從具體的服務部署或數據格式綁定中分離出來,因此可以對抽象定義進行再次使用:消息,指對交換數據的抽象描述;而端口類型,指操作的抽象集合。用于特定端口類型的具體協議和數據格式規范構成了可以再次使用的綁定。將Web訪問地址與可再次使用的綁定相關聯,可以定義一個端口,而端口的集合則定義為服務。
一個WSDL文檔通常包含7個重要的元素,即types、import、message、portType、operation、binding、 service元素。這些元素嵌套在definitions元素中,definitions是WSDL文檔的根元素。文章的下一部分將會詳細介紹WSDL 的基本結構。
二:WSDL的基本結構--概述
如第一部分最后描述的那樣,一個基本的WSDL文檔包含7個重要的元素。下面將分別介紹這幾個元素以及他們的作用。
WSDL 文檔在Web服務的定義中使用下列元素:
Types - 數據類型定義的容器,它使用某種類型系統(一般地使用XML Schema中的類型系統)。
Message - 通信消息的數據結構的抽象類型化定義。使用Types所定義的類型來定義整個消息的數據結構。
Operation - 對服務中所支持的操作的抽象描述,一般單個Operation描述了一個訪問入口的請求/響應消息對。
PortType - 對于某個訪問入口點類型所支持的操作的抽象集合,這些操作可以由一個或多個服務訪問點來支持。
Binding - 特定端口類型的具體協議和數據格式規范的綁定。
Port - 定義為協議/數據格式綁定與具體Web訪問地址組合的單個服務訪問點。
Service- 相關服務訪問點的集合。
可以參考下圖來理解一下WSDL的文檔結構圖:
WSDL的xml schema可以參照如下網址:http://schemas.xmlsoap.org/wsdl/
三:WSDL的基本結構--詳述
本節將通過一個例子詳細描述WSDL文檔每個元素的作用。下面一個例子是一個簡單的WSDL文檔的內容,該文檔的產生可以參見我的另外一篇文章:xfire開發實例--HelloWorld篇 。
一個簡單的Web Service的WSDL文檔,該服務支持名為sayHello的唯一操作,該操作通過在http上運行SOAP協議來實現的。該請求接受一個字符串name,經過處理后返回一個簡單的字符串。文檔如下:
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions
targetNamespace=" xmlns:tns=" xmlns:wsdlsoap=" xmlns:soap12=" xmlns:xsd=" xmlns:soapenc11=" xmlns:soapenc12=" xmlns:soap11=" xmlns:wsdl=" <wsdl:types>
<xsd:schema xmlns:xsd=" attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace=" <xsd:element name="sayHello">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1"
name="name" nillable="true" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="sayHelloResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1"
name="out" nillable="true" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="sayHelloResponse">
<wsdl:part name="parameters" element="tns:sayHelloResponse" />
</wsdl:message>
<wsdl:message name="sayHelloRequest">
<wsdl:part name="parameters" element="tns:sayHello" />
</wsdl:message>
<wsdl:portType name="HelloServicePortType">
<wsdl:operation name="sayHello">
<wsdl:input name="sayHelloRequest"
message="tns:sayHelloRequest" />
<wsdl:output name="sayHelloResponse"
message="tns:sayHelloResponse" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="HelloServiceHttpBinding"
type="tns:HelloServicePortType">
<wsdlsoap:binding style="document"
transport=" <wsdl:operation name="sayHello">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="sayHelloRequest">
<wsdlsoap:body use="literal" />
</wsdl:input>
<wsdl:output name="sayHelloResponse">
<wsdlsoap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HelloService">
<wsdl:port name="HelloServiceHttpPort"
binding="tns:HelloServiceHttpBinding">
<wsdlsoap:address
location="http://localhost:8080/xfire/services/HelloService" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
♦ types元素使用XML模式語言聲明在WSDL文檔中的其他位置使用的復雜數據類型與元素;
♦ import元素類似于XML模式文檔中的import元素,用于從其他WSDL文檔中導入WSDL定義;
♦ message元素使用在WSDL文檔的type元素中定義或在import元素引用的外部WSDL文檔中定義的XML模式的內置類型、復雜類型或元素描述了消息的有效負載;
♦ portType元素和operation元素描述了Web服務的接口并定義了他的方法。portType元素和operation元素類似于 java接口和接口中定義的方法聲明。operation元素使用一個或者多個message類型來定義他的輸入和輸出的有效負載;
♦ Binding元素將portType元素和operation元素賦給一個特殊的協議和編碼樣式;
♦ service元素負責將Internet地址賦給一個具體的綁定;
1、definitions元素
所有的WSDL文檔的根元素均是definitions元素。該元素封裝了整個文檔,同時通過其name提供了一個WSDL文檔。除了提供一個命名空間外,該元素沒有其他作用,故不作詳細描述。
下面的代碼是一個definitions元素的結構:
<wsdl:definitions
targetNamespace=" xmlns:tns=" xmlns:wsdlsoap=" xmlns:soap12=" xmlns:xsd=" xmlns:soapenc11=" xmlns:soapenc12=" xmlns:soap11=" xmlns:wsdl="</wsdl:definitions>
2、types元素
WSDL采用了W3C XML模式內置類型作為其基本類型系統。types元素用作一個容器,用于定義XML模式內置類型中沒有描述的各種數據類型。當聲明消息部分的有效負載時,消息定義使用了在types元素中定義的數據類型和元素。在本文的WSDL文檔中的types定義:
<wsdl:types>
<xsd:schema xmlns:xsd=" attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace=" <xsd:element name="sayHello">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1"
name="name" nillable="true" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="sayHelloResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1"
name="out" nillable="true" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
上面是數據定義部分,該部分定義了兩個元素,一個是sayHello,一個是sayHelloResponse:
sayHello:定義了一個復雜類型,僅僅包含一個簡單的字符串,將來用來描述操作的參入傳入部分;
sayHelloResponse:定義了一個復雜類型,僅僅包含一個簡單的字符串,將來用來描述操作的返回值;
3、import元素
import元素使得可以在當前的WSDL文檔中使用其他WSDL文檔中指定的命名空間中的定義元素。本例子中沒有使用import元素。通常在用戶希望模塊化WSDL文檔的時候,該功能是非常有效果的。
import的格式如下:
<wsdl:import namespace=" <wsdl:part name="parameters" element="tns:sayHelloResponse" />
</wsdl:message>
<wsdl:message name="sayHelloRequest">
<wsdl:part name="parameters" element="tns:sayHello" />
</wsdl:message>
該部分是消息格式的抽象定義:定義了兩個消息sayHelloResponse和sayHelloRequest:
sayHelloRequest:sayHello操作的請求消息格式,由一個消息片斷組成,名字為parameters,元素是我們前面定義的types中的元素;
sayHelloResponse:sayHello操作的響應消息格式,由一個消息片斷組成,名字為parameters,元素是我們前面定義的types中的元素;
如果采用RPC樣式的消息傳遞,只需要將文檔中的element元素應以修改為type即可。
5、portType元素
portType元素定義了Web服務的抽象接口。該接口有點類似Java的接口,都是定義了一個抽象類型和方法,沒有定義實現。在WSDL中, portType元素是由binding和service元素來實現的,這兩個元素用來說明Web服務實現使用的Internet協議、編碼方案以及 Internet地址。
一個portType中可以定義多個operation,一個operation可以看作是一個方法,本文中WSDL文檔的定義:
<wsdl:portType name="HelloServicePortType">
<wsdl:operation name="sayHello">
<wsdl:input name="sayHelloRequest"
message="tns:sayHelloRequest" />
<wsdl:output name="sayHelloResponse"
message="tns:sayHelloResponse" />
</wsdl:operation>
</wsdl:portType>
portType定義了服務的調用模式的類型,這里包含一個操作sayHello方法,同時包含input和output表明該操作是一個請求/響應模式,請求消息是前面定義的sayHelloRequest,響應消息是前面定義的sayHelloResponse。input表示傳遞到Web服務的有效負載,output消息表示傳遞給客戶的有效負載。
6、binding
binding元素將一個抽象portType映射到一組具體協議(SOAO和HTTP)、消息傳遞樣式、編碼樣式。通常binding元素與協議專有的元素和在一起使用,本文中的例子:
<wsdl:binding name="HelloServiceHttpBinding"
type="tns:HelloServicePortType">
<wsdlsoap:binding style="document"
transport=" <wsdl:operation name="sayHello">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="sayHelloRequest">
<wsdlsoap:body use="literal" />
</wsdl:input>
<wsdl:output name="sayHelloResponse">
<wsdlsoap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
這部分將服務訪問點的抽象定義與SOAP HTTP綁定,描述如何通過SOAP/HTTP來訪問按照前面描述的訪問入口點類型部署的訪問入口。其中規定了在具體SOAP調用時,應當使用的soapAction是""。
具體的使用需要參考特定協議定義的元素。
7、service元素和port元素
service元素包含一個或者多個port元素,其中每個port元素表示一個不同的Web服務。port元素將URL賦給一個特定的binding,甚至可以使兩個或者多個port元素將不同的URL賦值給相同的binding。文檔中的例子:
<wsdl:service name="HelloService">
<wsdl:port name="HelloServiceHttpPort"
binding="tns:HelloServiceHttpBinding">
<wsdlsoap:address
location="http://localhost:8080/xfire/services/HelloService" />
</wsdl:port>
</wsdl:service>
這部分是具體的Web服務的定義,在這個名為HelloService的Web服務中,提供了一個服務訪問入口,訪問地址是http://localhost:8080/xfire/services/HelloService,使用的消息模式是由前面的binding所定義的。
本文簡單介紹了WSDL規范的用途,基本結構和使用方法,希望對大家學習WSDL有幫助。
本文來自CSDN博客,轉載請標明出處:http://blog.csdn.net/sunchaohuang/archive/2008/10/14/3076375.aspx
posted @
2009-11-05 12:24 黃劍父 閱讀(392) |
評論 (0) |
編輯 收藏
如題
posted @
2009-11-04 14:20 黃劍父 閱讀(374) |
評論 (0) |
編輯 收藏
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
我們通過身體力行和幫助他人來揭示更好的軟件開發方式。經由這項工作,我們形成了如下價值觀:
個體與交互 重于 過程和工具
可用的軟件 重于 完備的文檔
客戶協作 重于 合同談判
響應變化 重于 遵循計劃
在每對比對中,后者并非全無價值,但我們更看重前者。
|
|
|
Kent Beck |
James Grenning |
Robert C. Martin |
Mike Beedle |
Jim Highsmith |
Steve Mellor |
Arie van Bennekum |
Andrew Hunt |
Ken Schwaber |
Alistair Cockburn |
Ron Jeffries |
Jeff Sutherland |
Ward Cunningham |
Jon Kern |
Dave Thomas |
Martin Fowler |
Brian Marick |
posted @
2009-10-16 01:11 黃劍父 閱讀(314) |
評論 (0) |
編輯 收藏
Principles behind the Agile Manifesto
We follow these principles:
我們遵循以下準則:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我們的最高目標是,通過盡早和持續地交付有價值的軟件來滿足客戶。
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
歡迎對需求提出變更——即使是在項目開發后期。要善于利用需求變更,幫助客戶獲得競爭優勢。
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
要不斷交付可用的軟件,周期從幾周到幾個月不等,且越短越好。
Business people and developers must work together daily throughout the project.
項目過程中,業務人員與開發人員必須在一起工作。
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
要善于激勵項目人員,給他們以所需要的環境和支持,并相信他們能夠完成任務。
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
無論是團隊內還是團隊間,最有效的溝通方法是面對面的交談。
Working software is the primary measure of progress.
可用的軟件是衡量進度的主要指標。
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恒久穩定的進展速度。
Continuous attention to technical excellence and good design enhances agility.
對技術的精益求精以及對設計的不斷完善將提升敏捷性。
Simplicity--the art of maximizing the amount of work not done--is essential.
要做到簡潔,即盡最大可能減少不必要的工作。這是一門藝術。
The best architectures, requirements, and designs emerge from self-organizing teams.
最佳的架構、需求和設計出自于自組織的團隊。
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
團隊要定期反省如何能夠做到更有效,并相應地調整團隊的行為。
posted @
2009-10-16 01:10 黃劍父 閱讀(221) |
評論 (0) |
編輯 收藏
今天偶然在公司看到一本書《精通windows sockets網絡編程--基于Visual C++實現》。本人對于此類標著精通兩個字的書名比較反感,但還是看了一下目錄,看了一下目錄覺得在編排上還比較是在,再翻了一章講完成端口的看了下,覺得還比較實在,然后看了一下講基礎知識部分,雖然很多東西都是一筆帶過,但在實踐中遇到過的一些問題,確實還是講到了。
比如說從容關閉,今天在做一個文件下載的服務器時就遇到此問題,不知道為什么最后的一些字節客戶端接收不到,其實就是從容關閉的問題。
還有講sockets套接字,到底是個什么東西時,也有講到,但還是講得簡單了些,只是描述了一下,套接字,在tcp/ip中就是屬于應用層與傳輸層的一個接口,概念上雖然說明了是個什么東西,但原理和如何做的又一點都未介紹,這個又讓我有點失望。
今天也就看了下,沒仔細看,今晚又把此書的代碼從網站上down下來了,編譯了一下完成端口那個程序,還行,能一次編譯通過,說明作者不是在忽悠。
以后有時間還是有溫習,系統的看看網絡編程,此書不失為一本比較好的參考。
這也算是今天的收獲吧。
posted @
2009-10-13 22:14 黃劍父 閱讀(1693) |
評論 (2) |
編輯 收藏
要減少軟件中的錯誤數目,方法之一就是擁有一個專業的測試組,其工作就是盡一切可能使軟件崩潰。不幸的是,如果擁有測試組,那么即使是經驗豐富的開發人員,也會傾向于花費較少的時間來保證代碼的可靠性。
軟件界有一句俗語:“開發人員不應該測試他們自己的代碼”。這是因為開發人員對自己的代碼了如指掌,他們很清楚如何采用適當的方法對代碼進行測試。盡管這
句俗語很有道理,但卻忽略了非常重要的一點 - 如果開發人員不對自己的代碼進行測試,又如何知道代碼能否按照預期的方式運行?
簡單說來,他們根本無從得知。開發人員編寫那種運行不正常或只在某些情況下運行正常的代碼是一個嚴重的問題。他們通常只測試代碼能否在很少的情況下正常運行,而不是驗證代碼能夠在所有情況下均正常運行。
發現軟件錯誤的情況有很多:
1.由首次編寫代碼的開發人員發現。
2.由嘗試運行代碼的開發人員發現。
3.由組中的其他開發人員或測試人員發現。
4.作為產品大規模測試的一部分。
5.由最終用戶發現。
如果在第一種情況下發現軟件錯誤,則修復錯誤比較容易,成本也很低。情況越靠后,修復軟件錯誤的成本就越高;修復一個由最終用戶發現的軟件錯誤可能要耗費
100 或 1000 倍的成本。更不用說用戶通常因為軟件錯誤導致工作無法繼續,而一直等到下一個版本才能解決問題。
如果開發人員能夠在編寫代碼期間發現所有的軟件錯誤,那就再好不過了。為此,您必須編寫能在編寫代碼時運行的測試。
測試是軟件開發的重要環節之一。按照軟件開發的過程測試可分為:單元測試、功能測試、性能測試、性能測試、集成測試、系統測試、域測試(Field test)等。我們這里將主要研究的是面向程序員的單元測試。
什么是單元測試
單元測試是開發者編寫的一小段代碼,用于檢驗被測代碼中的一個很明確的功能是否正確。通常而言,一個單元測試是用于判斷某個特定條件(或者場景)下某個特
定函數的行為。例如,你可能把一個很大的值放入一個有序list 中去,然后確認該值出現在list
的尾部。或者,你可能會從字符串中刪除匹配某種模式的字符,然后確認字符串確實不再包含這些字符了。
單元測試是由程序員自己來完成,最終受益的也是程序員自己。可以這么說,程序員有責任編寫功能代碼,同時也就有責任為自己的代碼編寫單元測試。執行單元測試,就是為了證明這段代碼的行為和我們期望的一致。
為什么要使用單元測試
我們編寫代碼時,一定會反復調試保證它能夠編譯通過。如果是編譯沒有通過的代碼,沒有任何人會愿意交付給自己的客戶。但代碼通過編譯,只是說明了它的語法正確;我們卻無法保證它的語義也一定正確,沒有任何人可以輕易承諾這段代碼的行為一定是正確的。
幸運,單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。有了單元測試,我們可以自信的交付自己的代碼,而沒有任何的后顧之憂。
單元測試有下面的這些優點:
1、它是一種驗證行為。
程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發提供支緩。就算是開發后期,我們也可以輕松的增加功能或更改程序結構,而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣,我們就可以更自由的對程序進行改進。
2、它是一種設計行為。
編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試(test-first),迫使我們把程序設計成易于調用和可測試的,即迫使我們解除軟件中的耦合。
3、它是一種編寫文檔的行為。
單元測試是一種無價的文檔,它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的,并且它保持最新,永遠與代碼同步。
4、它具有回歸性。
自動化的單元測試避免了代碼出現回歸,編寫完成之后,可以隨時隨地的快速運行測試。
單元測試的范疇
如果要給單元測試定義一個明確的范疇,指出哪些功能是屬于單元測試,這似乎很難。但下面討論的四個問題,基本上可以說明單元測試的范疇,單元測試所要做的工作。
1、 它的行為和我期望的一致嗎?
這是單元測試最根本的目的,我們就是用單元測試的代碼來證明它所做的就是我們所期望的。
2、 它的行為一直和我期望的一致嗎?
編寫單元測試,如果只測試代碼的一條正確路徑,讓它正確走一遍,并不算是真正的完成。軟件開發是一個項復雜的工程,在測試某段代碼的行為是否和你的期望一
致時,你需要確認:在任何情況下,這段代碼是否都和你的期望一致;譬如參數很可疑、硬盤沒有剩余空間、緩沖區溢出、網絡掉線的時候。
3、 我可以依賴單元測試嗎?
不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性,那么單元測試也一定要值得依賴。
4、 單元測試說明我的意圖了嗎?
單元測試能夠幫我們充分了解代碼的用法,從效果上而言,單元測試就像是能執行的文檔,說明了在你用各種條件調用代碼時,你所能期望這段代碼完成的功能。
不寫測試的借口
到這里,我們已經知道了使用單元測試的種種理由。但目前的實際情況是大多數程序員不進行單元測試,或只進行簡單的單元測試。下面是一些他們常用的接口:
1、 編寫單元測試太花時間了。
我們知道,在開發時越早發現BUG,就能節省更多的時間,降低更多的風險。如果你仍然認為在編寫產品代碼的時候,還是沒有時間編寫測試代碼,那么請先考慮下面這些問題:
1)、對于所編寫的代碼,你在調試上面花了多少時間。
2)、對于以前你自認為正確的代碼,而實際上這些代碼卻存在重大的bug,你花了多少時間在重新確認這些代碼上面。
3)、對于一個別人報告的bug,你花了多少時間才找出導致這個bug 的源碼位置。
回答完這些問題,你一定不再以“太花時間”作為拒絕單元測試的借口。
2、 運行測試的時間太長了。
合適的測試是不會讓這種情況發生的。實際上,大多數測試的執行都是非常快的,因此你在幾秒之內就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間。這時,需要把這些耗時的測試和其他測試分開。通常可以每天運行這種測試一次,或者幾天一次。
3、 測試代碼并不是我的工作。
你的工作就是保證代碼能夠正確的完成你的行為,恰恰相反,測試代碼正是你不可缺少的工作。
4、 我并不清楚代碼的行為,所以也就無從測試。
如果你實在不清楚代碼的行為,那么估計現在并不是編碼的時候。如果你并不知道代碼的行為,那么你又如何知道你編寫的代碼是正確的呢?
5、 但是這些代碼都能夠編譯通過。
我們前面已經說過,代碼通過編譯只是驗證它的語法通過。但并不能保證它的行為就一定正確。
6、 公司請我來是為了寫代碼,而不是寫測試。
公司付給你薪水是為了讓你編寫產品代碼,而單元測試大體上是一個工具,是一個和編輯器、開發環境、編譯器等處于同一位置的工具。
7、 如果我讓測試員或者QA(Quality Assurance)人員沒有工作,那么我會覺得很內疚。
你并不需要擔心這些。請記住,我們在此只是談論單元測試,而它只是一種針對源碼的、低層次的,為程序員而設計的測試。在整個項目中,還有其他的很多測試需要這些人來完成,如:功能測試、驗收測試、性能測試、環境測試、有效性測試、正確性測試、正規分析等等。
8、 我的公司并不會讓我在真實系統中運行單元測試。
我們所討論的只是針對開發者的單元測試。也就是說,如果你可以在其他的環境下(例如在正式的產品系統中)運行這些測試的話,那么它們就不再是單元測試,而是其他類型的測試了。實際上,你可以在你的本機運行單元測試,使用你自己的數據庫。
總而言之,單元測試會讓我們的開發工作變得更加輕松,讓我們對自己的代碼更加自信。無論是大型項目還是小型項目,無論是時間緊迫的項目還是時間寬裕的項目,只要代碼不是一次寫完永不改動,編寫單元測試就一定超值,它已成為我們編碼不可缺少的一部分。
posted @
2009-07-15 21:19 黃劍父 閱讀(176) |
評論 (0) |
編輯 收藏
因公司的需要和安排,我由開發轉為測試。
理由有:
1、公司需要加強測試的力量。目前測試從人數和資源,以及經驗需要加強。
2、公司的產品質量的提升需要測試加強,加重測試在整個產品開發過程中的比重。
3、公司說與其從外面招人,不如從內部選拔一些人出來,而我又有開發經驗,又有逆向思維能力,又喜歡挑戰別人,思維周密,反正能說的好話都說了。
4、我個人認為,我自己喜歡挑戰,喜歡批評其他人和事物(其實是講真話,只是這年代講真話的人不太受別人喜歡,就說這個人只知道挑別人的錯,等等)。
5、希望能干下去,老老實實的干下去,只要不是因為我個人確實不能干測試,而只能做開發,那么就轉回來做開發,否則,就走下去。我個人為測試的前途這幾年要超過搞開發的前途。測試工作對目前待中國的軟件人員來講確實是不熟悉,好似門檻不高,實則想做得好,確實難。連一個測試用例在本科階段,看都未看過,更不要說怎么去培養測試方面的素質。
目前我給自己定的目標是,以一個完全新人的角度,大學應屆畢業生的姿態去向別人學習測試。拋開以前開發那種高高在上的心態,認認真真做好測試工作。我相信我會在半年內熟悉這項工作。
目前正在看《軟件測試的藝術》,個人認為還是一本不錯的書,是進入測試這行一個比較好的入門書,能產生非常大影響的一本書。因為此書,主要是讓人明白測試的本質問題是什么,以及一些測試方面要注意的原則問題,測試技術也講了一些,對我熟悉測試還是非常具有啟發性。
posted @
2009-06-14 22:01 黃劍父 閱讀(207) |
評論 (0) |
編輯 收藏
intel處理器實現了4個權限級別ring0-ring3。
windows使用了兩個ring0和ring3。
posted @
2009-06-11 09:43 黃劍父 閱讀(549) |
評論 (0) |
編輯 收藏
信息安全涉及到信息的保密性(Confidentiality)、完整性(Integrity)、可用性(Availability)、可控性(Controllability)和不可否認性(Non-Repudiation)。綜合起來說,就是要保障電子信息的有效性。保密性就是對抗對手的被動攻擊,保證信息不泄漏給未經授權的人。完整性就是對抗對手主動攻擊,防止信息被未經授權的人篡改。可用性就是保證信息及信息系統確實為授權使用者所用。可控性就是對信息及信息系統實施安全監控。
posted @
2009-06-10 16:11 黃劍父 閱讀(170) |
評論 (0) |
編輯 收藏
資料來源:
http://www.cnpaf.net/Class/Ethernet/200408/402.html,中國協議分析網
正如其名字所暗示的,Hub就是活動的中心。用網絡術語來說,Hub或 Concentrator,是基于星形拓撲的接線點。Arcnet、10Base-T、10Base-F及許多其它專用網絡都依靠集線器來連接各段電纜及把數據分發到各個網段。集線器的基本功能是信息分發,它把一個端口接收的所有信號向所有端口分發出去。一些集線器在分發之前將弱信號重新生成,一些集線器整理信號的時序以提供所有端口間的同步數據通信。具有多個10Base-F接口的集線器就象是使用鏡子來把光線分到各個端口。
圖1是基本的10Base-2網絡,注意機器間連接的方式和數據在源設備和目的設備間的各個設備的處理及傳遞。

圖2是與圖1相同的網絡,不過是10Base-T,可以看到拓撲的不同和集線器是如何嵌到此網中。

在 10Base-T網絡中,所有設備需要用非屏蔽雙絞線連接到一個或多個集線器,集線器應該有多個端口甚至多種類型的端口。有時需要把多個集線器連接起來,這時,你可能想用高速端口來建立網絡的主干,各集線器與服務器應直接連到高速主干上。因為多數LAN的主要通信是在工作站和主服務器之間的,主干對網絡的整體性能意義重大。
圖3是個較復雜的10Base-T網絡示意圖,注意主干是怎樣連接多個集線器和服務器的。主干應該是高速連接,如快速以太網或FDDI等。

令牌環網中也有可以稱作集線器的設備,MSAU(Multi-StationAccessUnit)就可以看作一種集線器,因為它的功能與以太網的集線器很類似,但是MSAU把包串行地路由到各個設備,不象以太網集線器是并行的。為了不發生混淆,令牌環網MSAU不作為集線器討論。
二、誰需要集線器?
判斷你的局域網是否需要集線器的方法很簡單:如果你想建立星形網絡且有不少于兩臺主機,那么就需要集線器。這個規則只有一個例外,那就是只有兩臺主機的 10Base-T網絡,可以直接將之相連,但是需要一條特殊發送端與接收端交叉連接的線纜,這種線纜很普通,如果你實在找不到,也可以自己做一個,很容易也很便宜,所需物品為一小段雙絞線、兩個RJ-45接頭和工具,按照下表連接就是了。
RJ-45接頭1 RJ-45接頭2
針號功能 針號功能
1發送+<-->3接收+
2發送-<-->6接收-
3接收+<-->1發送+
6接收-<-->2發送-
三、集線器的類型
我們知道,集線器在星形拓撲的網絡中起著重要作用。集線器有多種,各個種類具有特定的功能、提供不同等級的服務。下面講講多數集線器的一些標準特性和被動、主動、智能集線器的區別以及一些高性能集線器的附加特性。
1、基本規范
所有的集線器根據可連接的線纜類型都有一些基本特性。集線器可以給網絡提供除接口之外的附加服務,但也必須遵從IEEE對介質的規定。
多數集線器主要的連接是RJ-45插座,這是基于雙絞線的多種以太網的標準接頭類型,從10Base-T到100Base-T,局域網中的工作站、打印機等設備通常是以某種雙絞線連接到集線器的,其兩端為RJ-45連接頭。
注:RJ-45頭看起來有點象電話線的接頭,不過稍微寬點。它主要用于以太網,但也可用于令牌環網。
每種線纜到集線器的長度由使用的介質決定(見下表)。
以太網類型距離
10Base-2185米
10Base-5500米
10Base-T100米
10Base-F2公里
10broad-363,600米
上述是以太網規范的最大長度,其中多數可以用中繼器(repeater)來延長。當然還有其他的要求。
集線器是電子設備,因此需要電源,多數集線器還有指示多種狀態的LED指示燈,常見的兩種指示燈是電源和端口狀態指示燈,有的集線器還有監視端口通信狀態和沖突的指示燈。
2、被動集線器
顧名思義,被動集線器是相對靜止的。它們沒有專門的動作來提高網絡性能,也不能幫你檢測硬件錯誤或性能瓶頸,它們只是簡單地從一個端口接收數據并通過所有端口分發,這是集線器可以做的最簡單的事情。被動集線器是星形拓撲以太網的入門級設備。
被動集線器通常有一個10Base-2端口和一些RJ-45接頭。我們知道,10Base-5是使用粗纜的以太網,這個10Base-2接頭可以用于連接主干。有些集線器還有可連到收發器的AUI端口以建立主干。
3、主動集線器
主動集線器擁有被動集線器的所有性能,此外還能監視數據。它們是在以太網實現存貯轉發技術的重要角色,它們在轉發之前檢查數據,它們并不區分優先次序,而是糾正損壞的分組并調整時序。
如果信號比較弱但仍然可讀,主動集線器在轉發前將其恢復到較強的狀態。這使得一些性能不是特別理想的設備也可正常使用。如果某設備發出的信號不夠強,使得被動集線器無法識別,那么主動集線器的信號放大器可以使該設備繼續正常使用。此外,主動集線器還可以報知那些設備失效,從而提供了一定的診斷能力。
有些線纜可能有電磁干擾使分組不能按正常時序到達集線器,主動集線器可以將轉發的分組重新同步。有時數據根本就到不了目的地,主動集線器通過在單個端口重發分組來彌補數據的丟失。主動集線器可以調整時序以適應較慢的、錯誤率較高的連接。當然,這樣做會降低連接到該集線器上設備的整體網絡速度,但是,有時這比丟失數據要好。此外時序調整實際上可以減少局域網中的沖突次數,數據不需要重復廣播,局域網就可以傳輸新的數據。
主動集線器提供一定的優化性能和一些診斷能力,它們比簡單的被動集線器貴,可以配以多個、多種端口。
4、智能集線器
智能集線器比前兩種提供更多的好處,可以使用戶更有效地共享資源。其技術近些年才出現,很多地方還沒有機會享受到它的好處。除了主動集線器的特性外,智能集線器提供了集中管理功能。如果連接到智能集線器上的設備出了問題,你可以很容易的識別、診斷和修補。這是極大的提高,在一個大型網絡里,如果沒有集中的管理工具,那么你常常需要一個一個線盒地跑,尋找出問題的設備。
智能集線器的另一個出色的特性是可以為不同設備提供靈活的傳輸速率。除了上連到高速主干的端口外,智能集線器還支持到桌面的10、16和100Mbps的速率,即以太網、令牌環和FDDI。
5、高級特性
高端集線器還提供其它一些特性,如冗余交流電源、內置直流電源、冗余風扇,還有線纜連接的自動中斷、模塊的熱插拔、自動調整10Base-T接頭的極性,再如冗余配置存貯、冗余時鐘,有些集線器還集成了路由和橋接功能。
posted @
2009-06-10 15:46 黃劍父 閱讀(396) |
評論 (0) |
編輯 收藏