Luận văn Giao thức quản lý mạng và công nghệ dịch vụ web thực hiện khai thác ðường dây thuê bao

-PDU 6 InformRequest-PDU 7 Trapv2-PDU 8 Report-PDU Bảng 1.3.1.2.2.1 - Kiểu PDU 36 Trạng thái lỗi [4] (Các giá trị lỗi của version 1 tương ứng các dòng từ 0-5) Giá trị trạng thái lỗi Mã lỗi Mô tả 0 noError Không có lỗi. 1 tooBig Kích thước của Response-PDU có thể quá lớn ñể truyền qua mạng. 2 noSuchName Không tìm thấy tên ñối tượng yêu cầu. 3 badValue Một giá trị trong yêu cầu không phù. Ví dụ, một ñối tượng trong yêu cầu ñược quy ñịnh với chiều dài hoặc kiểu không chính xác. 4 readOnly Xuất hiện khi cố gắng gán giá trị cho một biến chỉ cho phép ñọc giá trị. 5 genErr Xuất hiện khi một lỗi xảy ra không ñược ñịnh nghĩa trước trong bảng này. 6 noAccess Truy nhập bị từ chối vì nguyên nhân bảo mật. 7 wrongType Không ñúng kiểu ñối tượng. 8 wrongLength ðộ dài không phù hợp với ñối tượng trong biến 9 wrongEncoding Mã hóa không phù hợp với ñổi tượng trong biến 10 wrongValue Giá trị truyền vào trong biến không thể gán cho ñối tượng. 11 noCreation Biến chưa tồn tại và không thể khởi tạo. 12 inconsistentValu e Biến truyền vào giá trị phù hợp với ñối tượng nhưng không thể gán cho ñối tượng tại thời ñiểm này 13 resourceUnavail able Tài nguyên không có sẵn. 14 commitFailed Thiết lập một biến cụ thể không thành công. 37 15 undoFailed Thực hiện lùi lại không thành công các thiết lập ñã thực hiện. 16 authorizationErr or Lỗi khi xác thực 17 notWritable Biến không cho phép gán hoặc khởi tạo. 18 inconsistentNam e Tên biến không tốn tại. Bảng 1.3.1.2.2.2 - Các giá trị trường Error Status trong PDU SNMP 1.3.1.2.3 ðịnh dạng Trap-PDU PDU type Enterprise Agent Addr Generic trap Specific trap Time stamp Variable Bindings Hình 1.3.1.2.3 - ðịnh dạng Trap PDU [4] Tên trường Kiểu DL Kích cỡ (bytes) Mô tả PDU Type Integer (Enumerated) 4 PDU Type: Xác ñịnh kiểu PDU, luôn là 4 cho thông ñiệp Trap PDU. Enterprise Sequence of Integer Variable Enterprise: ðịnh danh ñối tượng của một nhóm, nó chỉ ra kiểu ñối tượng sinh ra trap. Agent Addr NetworkAddress 4 Agent Address: ðịa chỉ IP của agent sinh ra trap. Nó cúng bao gồm trong IP header ở tầng thấp hơn nhưng cũng bao gôm trong ñịnh dạng thông ñiệp SNMP ñể dễ dàng ghi log trong SNMP, ñồng thời có thể phân biệt ñược trong trường có nhiều host. Generic Trap Integer (Enumerated) 4 Generic Trap Code: Giá trị mã xác ñịnh một trong các một số kiểu trap “chung chung” ("generic") hoặc ñã ñược xác 38 ñịnh trước. Specific Trap Integer 4 Specific Trap Code: Một giá trị mã xác ñịnh một loại trap thực hiện cụ thể Time Stamp TimeTicks 4 Time Stamp: Lượng thời gian kể từ khi thực thể SNMP ñang gửi thông ñiệp này khởi tạo hoặc khởi tạo lại lần cuối. ðược sử dụng ñể ghi log thời gian. Variable Bindings Variable Variable Variable Bindings: Tập hợp các cặp tên-giá trị xác ñịnh các ñối tượng MIB trong PDU. Bảng 1.3.1.2.3.1 - ðịnh dạng Trap PDU Tên và số Generic trap Mô tả coldStart (0) Chỉ ra rằng một agent ñã bị khởi ñộng lại. warmStart (1) Chỉ ra rằng agent tự khởi tạo lại. linkDown (2) ðược gửi khi một interface trên thiết bị bị lỗi. linkUp (3) ðược gửi khi một interface hoạt ñộng trở lại. authenticationFailure (4) Chỉ ra rằng một người nào ñó ñã cỗ gắng truy vấn agent mà không ñúng chuỗi community, dùng ñể phát hiện các truy nhập bất hợp phát egpNeighborLoss (5) Chỉ ra rằng EGP bên cạnh bị lỗi. enterpriseSpecific (6) Chỉ ra trap cụ thể ñược nhà cung cấp thiết bị ñịnh nghĩa. Bảng 1.3.1.2.3.2 - Mô tả các Generic trap 1.3.1.2.4 ðịnh dạng GetBulkRequest-PDU SNMPv2c PDU type Request Identify Non Repeaters Max Repeaters PDU variable Bindings Hình 1.3.1.2.4 - ðịnh dạng GetBulkRequest-PDU [4] 39 Tên trường Kiểu DL Kích cỡ (bytes) Mô tả PDU Type Integer (Enumerated) 4 PDU Type: Một gái trị nguyên xác ñịnh kiểu PDU, với bản GetBulkRequest-PDU thì giá trị là 5. Request ID Integer 4 Request Identifier: Một số ñược sử dụng ñể so khớp các thông ñiệp yêu cầu với các thông ñiệp trả lời. Nó ñược sinh ra bởi thiết bị gửi yêu cầu và ñược copy vào trường này trong Response-PDU. Non Repeaters Integer 4 Non Repeaters: Chỉ ñịnh số ñối tượng ñầu tiên không lặp lại lệnh getnext. Max Repetitions Integer 4 Max Repetitions: Số lần lặp lại lệnh getnext với các ñối tượng còn lại. Variable Bindings Variable Variable Variable Bindings: Một tập hợp các cặp ten-gái trị ñịnh danh các ñối tượng MIB trong PDU. Bảng 1.3.1.2.4 - ðịnh dạng GetBulkRequest-PDU [4] 1.3.1.3 ðịnh dạng thông ñiệp SNMP Version 3 (SNMPv3) ðịnh dạng tổng quát của SNMPv3 vẫn sử dụng ý tưởng thông ñiệp tổng thể “mở rộng” của SNMPv2. Tuy nhiên, trong v3 khái niệm này ñược ñịnh nghĩa lại. Các trường header tự chia thành những vùng có hoặc không xử lý bảo mật. Các trường “non- security” là chung cho tất cả các triển khai SNMP v3, trong khi việc sử dụng các trường bảo mật có thể ñược thiết kế riêng cho từng mô hình bảo mật SNMPv3, và ñược xử lý bởi module trong thực thể xử lý bảo mật SNMP. Giải pháp này cung cấp sự linh hoạt ñáng kể trong khi tránh những vấn ñề SNMPv2 bị hạn chế. Tất cả ñịnh dạng thông ñiệp SNMP v3 ñược mô tả trong RFC3412. Những ñặc ñiểm bảo mật cung cấp trong SNMPv3 là[4]: - Tính toàn vẹn thông tin : ðảm bảo các gói tin không bị sửa trong khi truyền. 40 - Sự xác nhận: Xác nhận nguồn của thông tin gửi ñến. - Mã khoá: ðảo nội dung của gói tin, ngăn cản việc gửi thông báo từ nguồn không ñược xác nhận. Tuy nhiên việc sử dụng SNMPv3 rất phức tạp và cồng kềnh dù nó là sự lựa chọn tốt nhất cho vấn ñề bảo mật của mạng. Việc sử dụng sẽ tốn rất nhiều tài nguyên do trong mỗi thông ñiệp truyền ñi sẽ có phần mã hóa BER. Phần mã hóa này sẽ chiếm một phần băng thông ñường truyền do ñó làm tăng chi phí. Mặc dù ñược coi là phiên bản ñề nghị cuối cùng và ñược coi là ñầy ñủ nhất nhưng SNMPv3 vẫn chỉ là tiêu chuẩn dự thảo và vẫn ñang ñược nghiên cứu hoàn thiện[4]. Hình 1.3.1.3 - ðịnh dạng tổng quát thông ñiệp SNMP Version 3 (SNMPv3) Tên trường Kiểu DL Kích cỡ (bytes) Mô tả Msg Version Integer 4 Message Version Number: Mô tả số phiên bản SNMP của thông ñiệp, với SNMPv3 là 3. Msg ID Integer 4 Message Identifier: Một số ñược sử dụng ñể 41 xác ñịnh một thông ñiệp SNMPv3 và ñể so khớp với thông ñiệp trả lời với thông ñiệp yêu cầu. Sử dụng của trường này là tương tự như của trường Request ID trong các ñịnh dạng PDU, nhưng chúng không giống nhau. Trường này ñược tạo ra ñể cho phép kết hợp ở mức ñộ xử lý thông ñiệp không phân biệt nội dung của PDU, ñể bảo vệ chống lại các cuộc tấn công bảo mật. Như vậy, Msg ID và Request ID ñược sử dụng ñộc lập. Msg Max Size Integer 4 Maximum Message Size: Kích thước tối ña của một thông ñiệp. Tối thiểu là 484. Msg Flags Octet String 1 Msg Security Model Integer 4 Message Security Model: Một giá trị nguyên xác ñịnh mô hình bảo mật nào ñược sử dụng cho thông ñiệp, với user-based(mặc ñịnh của SNMP v3) thì giá trị là 3. Msg Security Parameters — Variable Message Security Parameters: Một tập hợp các trường chứa các tham sô yêu cầu ñể thực hiện mô hình bảo mật cụ thể ñược sử dụng cho thông ñiệp. Nội dung của trường này ñược chỉ ñịnh trong mỗi văn bản mô tả một mô hình bảo mật SNMP v3. ví dụ, các tham số của mo hình user-based ñược mô tả trong RFC3414. Scoped PDU — Variable Bảng Bảng 1.3.1.3.1 - ðịnh dạng tổng quát thông ñiệp SNMPv3 42 Tên SubField Kích thước(byte) Mô tả Reserved 5/8(5 bit) Dự phòng cho tương lai Reportable flag 1/8(1 bit) Khi ñặt là 1, thiết bị nhận thông ñiệp này phải gửi trở lại nơi sinh ra PDU, một Report-PDU mỗi lần các ñiều kiện phát sinh Priv Flag 1/8(1 bit) Khi ñặt là 1, chỉ ra rằng sự mã hóa ñược sử dụng ñể bảo về sự riêng tư của thông ñiệp. Có thể không là 1 trừ khi Auth Flag cũng ñược ñặt là 1. Auth Flag 1/8(1 bit) Khi ñặt là 1, chỉ ra rằng xác thực ñược sử dụng ñể bảo vệ tính xác thức của thông ñiệp Bảng 1.3.1.3.2 - Msg Flags Tên subfield Syntax Kích thước(byte) Mô tả Context Engine ID Octet String Variable ðược sử dụng ñể ñịnh danh ứng dụng nào xử lý PDU Context Name Octet String Variable Một ñịnh danh ñối tượng chỉ rõ nội dung ñặc biệt ñược kết hợp với PDU PDU - Variable PDU sẽ ñược truyền Bảng 1.3.1.3.3 Scoped PDU SNMPv3 sử dụng các hoạt ñộng giao thức từ SNMPv2, ñược mô tả trong RFC3416 và sửa ñổi trong RFC1904, vì vậy ñịnh dạng PDU của SNMPv3 cũng tương tụ như SNMPv2[4]. 1.3.2 Các phương thức Các thao tác tương ứng với các phiên bản SNMP[6]: 43 get getnext getbulk (SNMPv2 and SNMPv3) set getresponse trap notification (SNMPv2 and SNMPv3) inform (SNMPv2 and SNMPv3) report (SNMPv2 and SNMPv3) 1.3.2.1 Phương thức Get (GetRequest): Thông ñiệp GetRequest ñược Manager gửi ñến Agent ñể lấy một thông tin nào ñó. Trong GetRequest có chứa ID của ñối tượng muốn lấy. Ví dụ: Muốn lấy thông tin tên của Device1 thì manager gửi thông ñiệp GetRequest ID=1.3.6.1.2.1.1.5 ñến Device1, tiến trình SNMP Agent trên Device1 sẽ nhận ñược thông ñiệp và tạo thông ñiệp trả lời. Trong một thông ñiệp GetRequest có thể chứa nhiều OID, nghĩa là dùng một GetRequest có thể lấy về cùng lúc nhiều thông tin[6]. Hình 1.3.2.1 - Mô hình truyền thông ñiệp của phương thức get 1.3.2.2 GetNextRequest: Thông ñiệp GetNextRequest cũng dùng ñể lấy thông tin và cũng có chứa OID, tuy nhiên nó dùng ñể lấy thông tin của ñối tượng nằm kế tiếp object ñược chỉ ra trong thông ñiệp. Chúng ta ñã biết khi ñọc qua những phần trên: một MIB bao gồm nhiều OID ñược sắp xếp thứ tự nhưng không liên tục, nếu biết một OID thì không xác ñịnh ñược OID kế tiếp. Do ñó ta cần GetNextRequest ñể lấy về giá trị 44 của OID kế tiếp. Nếu thực hiện GetNextRequest liên tục thì ta sẽ lấy ñược toàn bộ thông tin của Agent[6]. 1.3.2.3 SetRequest: Thông ñiệp SetRequest ñược Manager gửi cho Agent ñể thiết lập giá trị cho một ñối tượng nào ñó. Ví dụ: Có thể ñặt lại tên của một máy tính hay router bằng phần mềm SNMP Manager, bằng cách gửi thông ñiệp SetRequest có OID là 1.3.6.1.2.1.1.5.0 (sysName.0) và có giá trị là tên mới cần ñặt[6]. 1.3.2.4 GetResponse: Mỗi khi SNMP Agent nhận ñược các thông ñiệp GetRequest, GetNextRequest hay SetRequest thì nó sẽ gửi lại thông ñiệp GetResponse ñể trả lời. Trong thông ñiệp GetResponse có chứa OID của ñối tượng ñược yêu cầu và giá trị của ñối tượng ñó[6]. 1.3.2.5 GetBulkRequest: Chức năng của câu lệnh GetBulkRequest tương tự như câu lệnh GetNextRequest ngoại trừ vấn ñề liên quan tới số lượng dữ liệu ñược lấy ra. GetBulkRequest cho phép Agent gửi lại Manager dữ liệu liên quan tới nhiều ñối tượng thay vì từng ñối tượng bị quản lý. Như vậy, GetBulkRequest có thể giảm bớt lưu lượng truyền dẫn và các bản tin ñáp ứng thông báo về các ñiều kiện vi phạm[6]. Tuy nhiên, kích thước của câu hỏi có thể bị giới hạn bởi Agent. Khi ñó nếu nó không thể trả lời toàn bộ yêu cầu, nó gửi trả một thông ñiệp lỗi mà không có dữ liệu. Với trường hợp dùng câu lệnh ”get-bulk”, Agent sẽ gửi cang nhiều trả lời nếu nó có thể. Do ñó, việc trả lời một phần của yêu cầu là có thể xảy ra. Hai trường cần khai báo trong ”get-bulk” là: ”nonrepeaters” và ”max-repetitions”. ”nonrepeaters” báo cho Agent biết N ñối tượng ñầu tiên có thể trả lời lại như một câu lệnh ”get” ñơn. ”max-repeaters” báo cho Agent biết cần cố gắng tăng lên tối ña M yêu cầu ”get-next” cho các ñối tượng còn lại[6]. Ví dụ : $ snmpbulkget -v2c -B 1 3 linux.ora.com public sysDescr ifInOctets ifOutOctets 45 system.sysDescr.0 = “Linux linux 2.2.5-15 #3 Thu May 27 19:33:18 EDT 1999 i686″ interfaces.ifTable.ifEntry.ifInOctets.1 = 70840 interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840 interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020 interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152 interfaces.ifTable.ifEntry.ifInOctets.3 = 0 interfaces.ifTable.ifEntry.ifOutOctets.3 = 0 ở ñây, ta hỏi về 3 varbind: sysDescr, ifInOctets, và ifOutOctets. Tổng số varbind ñược tính theo công thức: N + (M * R) N: nonrepeater, tức số các ñối tượng vô hướng M: max-repeatition R: số các ñối tượng có hướng, trong yêu cầu chỉ có sysDescr là vô hướng. Với N = 1, M ñặt là 3 , tức là 3 trường cho cặp ifInOctets và ifOutOctets. Có 2 ñối tượng có hướng là ifInOctets và ifOutOctets vậy R = 2 Tổng số có 1 + 3*2 = 7 varbind Còn trường ”–v2c” là do ”get-bulk” là câu lệnh của SNMPv2 nên sử dụng ”- v2c” ñể chỉ rằng sử dụng PDU của SNMPv2. ”-B 1 3” là ñể ñặt tham số N và M cho lệnh. Hình 1.3.2.5 - Mô hình truyền thông ñiệp của phương thức get-bull 1.3.2.6 Trap Thông ñiệp Trap ñược Agent tự ñộng gửi cho Manager mỗi khi có sự kiện xảy ra bên trong Agent, các sự kiện này không phải là các hoạt ñộng thường xuyên của Agent mà là các sự kiện mang tính biến cố. Ví dụ: Khi có một port down, khi có 46 một người dùng login không thành công, hoặc khi thiết bị khởi ñộng lại, Agent sẽ gửi trap cho Manager. Tuy nhiên không phải mọi biến cố ñều ñược Agent gửi trap, cũng không phải mọi Agent ñều gửi trap khi xảy ra cùng một biến cố. Việc Agent gửi hay không gửi trap cho biến cố nào là do hãng sản xuất Device/Agent quy ñịnh[6]. Hình 1.3.2.6 - Mô hình biểu diễn sự phát sinh trap 1.3.2.7 SNMP Notification ðể hoàn thiện và chuẩn hóa ñịnh dạng PDU của trap SNMP v1, SNMPv2 ñịnh nghĩa một NOTIFICATION-TYPE. ðịnh dạng PDU cho NOTIFICATION- TYPE giống nhau cho cả get và set. RFC2863 ñịnh nghĩa lại kiểu thông báo chung chung linkDown như sau[6]: linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } OID cho trap này là 1.3.6.1.6.3.1.1.5.3, hoặc 47 iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps .linkDown. 1.3.2.8 SNMP Inform SNMPv2 cung cấp cơ chế truyền thông giữa những NMS với nhau, gọi là SNMP inform. Khi một NMS gửi một SNMP inform cho một NMS khác, NMS nhận ñược sẽ gửi trả một ACK xác nhận sự kiện. Việc này giống với cơ chế của “get” và “set”.. [6] 1.3.2.9 SNMP Report ðược ñịnh nghĩa trong bản nháp của SNMPv2 nhưng không ñược phát triển. Sau ñó ñược ñưa vào SNMPv3 và hy vọng dùng ñể truyền thông giữa các hệ thống SNMP với nhau[6]. 1.4 Sử dụng SNMP4J API xây dựng Một số phương thức SNMP SNMP4J API là một thư viện lập trình ứng dụng mã nguồn mở ñược xây dựng trên nền ngôn ngữ Java. Tất cả các mã nguồn ñược triển khai bằng ngôn ngữ lập trình java vì vậy các tệp ñược lưu dưới dạng *.java, nội dung mã nguồn tham khảo trong [6]. 48 CHƯƠNG 2 CÔNG NGHỆ DỊCH VỤ WEB 2.1 Khái niệm và kiến trúc dịch vụ Web 2.1.1 Khái niệm. Theo ñịnh nghĩa của W3C, dịch vụ Web là một hệ thống phần mềm ñược thiết kế ñể hỗ trợ khả năng tương tác giữa các ứng dụng trên các máy tính khác nhau thông qua mạng Internet, giao diện chung và sự gắn kết của nó ñược mô tả bằng XML. dịch vụ Web là tài nguyên phần mềm có thể xác ñịnh bằng ñịa chỉ URL, thực hiện các chức năng và ñưa ra các thông tin người dùng yêu cầu. Một dịch vụ Web ñược tạo nên bằng cách lấy các chức năng và ñóng gói chúng sao cho các ứng dụng khác dễ dàng nhìn thấy và có thể truy cập ñến những dịch vụ mà nó thực hiện, ñồng thời có thể yêu cầu thông tin từ dịch vụ Web khác. Nó bao gồm các mô ñun ñộc lập cho hoạt ñộng của khách hàng và doanh nghiệp và bản thân nó ñược thực thi trên server[3]. Một dịch vụ Web như bất kỳ dịch vụ nào sẵn có trên internet, sử dụng hệ thống thông ñiệp chuẩn hóa XML, và không phụ thuộc bất kỳ một hệ ñiều hành hoặc ngôn ngữ lập trình. Có một vài lựa chọn ñịnh dạng thông ñiệp XML, như XML-RPC hoặc SOAP. Ngoài ra chúng ta có thể sử dụng HTTP GET/POST ñể chuyển các tài liệu XML qua môi trường mạng[8]. 2.1.2 Kiến trúc Có hai cách ñể xem xét kiến trức dịch vụ Web 2.1.2.1 Roles Có 3 Role chính trong kiến trúc dịch vụ Web [8]: Service provider: ðây là thành phần cung cấp dịch vụ Web, nó triển khai dịch vụ và làm cho nó sẵn sàng trên internet. Service requestor: ðây là thành phần thực hiện công việc khai thác dịch vụ Web. Người dùng sử dụng một dịch vụ Web bằng cách mở một kết nối mạng và gửi một yêu cầu XML. 49 Service registry: ðây là thư mục trung tâm hóa dạng logic của dịch vụ. Nó cung cấp một ñịa chỉ trung tâm ñể người phát triển có thể công bố một dịch vụ mới hoặc tìm kiếm một dịch vụ có sẵn. Nó ñóng vai trò như một trung tâm tập trung các công ty và các dịch vụ của họ. Hình 2.1.2.1 - Mô tả các Role trong kiến trúc một Dịch vụ Web 2.1.2.2 Chồng giao thức Service transport: Tầng này chịu trách nhiệm truyền tải các thông ñiệp giữa các ứng dụng. Hiện tại tầng này bao gồm bao gồm các giao thức HTTP, SMTP, FTP, BEEP. XML messaging: Tầng này chịu trách nhiệm mã hòa các thông ñiệp theo một dạng XML thông thường mà phía máy khai thác ñầu cuối có thể hiểu ñược. Hiện tại tầng này bao gồm XML-RPC và SOAP. Service description: Tầng này chịu trách nhiệm mô tả các giao diện công cộng của một dịch vụ Web cụ thể. Hiện tại, mô tả dịch vụ ñược xử lý qua WSDL. Service discovery: Tầng này chịu trách nhiệm trung tâm hóa các dịch vụ vào trong một ñăng ký chung, và cung cấp các chức năng dễ dàng công bố hoặc tìm kiếm. Hiện tại, tầng này ñược xử lý qua UDDI.[8] Hình 2.1.2.2 - Mô tả chồng giao thức của Dịch vụ Web 50 2.2 Các dạng thông ñiệp XML Như ñã nói ở trên có hai dạng thông ñiệp XML ñược sử dụng trong dịch vụ Web, trong ñó XML-RPC là cách dễ nhất ñể bắt ñầu với dịch vụ Web. Nó ñơn giản hơn và dễ hiểu hơn SOAP. Tuy nhiên, không giống như SOAP, XML-RPC không có ngữ pháp mô tả dịch vụ tương ứng. ðiều này hạn chế việc gọi tự ñộng một loạt các dịch vụ XML-RPC một yếu tố quan trọng ñể cho phép xây dựng các ứng dụng tích hợp tức thời. Trong phạm vi tài liệu chúng tôi xin trình bày chi tiết về ñịnh dạng thông ñiệp SOAP. Nội dung của các thông ñiệp ñược hệ thống tự sinh mã XML trong quá trình duyệt và hiển thị. 2.2.1 SOAP SOAP là một giao thức dựa trên XML, ñược sử dụng ñể trao ñổi thông tin giữa các máy tính. Mặc dù SOAP có thể ñược sử dụng trong một loạt các hệ thống thông ñiệp và có thể ñược phân phối qua nhiều giao thức truyền tải, ñiểm chính của SOAP là truyển tải các RPC qua HTTP. Giống như XML-RPC, SOAP là nền tảng ñộc lập và do ñó cho phép các ứng dụng ña dạng có thể giao tiếp với nhau. ðể hiểu hơn về SOAP, chúng ta hãy xem xét lại dịch vụ Web cho phép truy vấn thông tin thời tiết. Dưới ñây là một ví dụ về SOAP Request (HTTP header ñã ñược bỏ qua) [8]: <SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:xsi="" xmlns:xsd=""> <ns1:getWeather xmlns:ns1="urn:examples:weatherservice" SOAP-ENV:encodingStyle=" encoding/"> 10016 Ví dụ 2.2.1.1: SOAP Request 51 Nội dung của SOAP Request quy ñịnh cụ thể cả tên phương thức và một danh sách các các tham số. SOAP response trả về từ dịch vụ thông tin thời tiết như sau[9]: <SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:xsi="" xmlns:xsd=""> <ns1:getWeatherResponse xmlns:ns1="urn:examples:weatherservice" SOAP-ENV:encodingStyle=" encoding/"> 65 /SOAP-ENV:Body> Ví dụ 2.2.1.2: SOAP Request 2.2.2 ðặc tả SOAP Các ñặc tả SOAP ñịnh nghĩa 3 phần chính[9]: Envelope: Các ñịnh nghĩa Envelope xác ñịnh quy tắc ñóng gói dữ liệu ñang ñược truyền giữa các máy tính. Bao gồm các dữ liệu ñặc tả ứng dụng như tên phương thức thực hiện, các tham số, hoặc giá trị trả về. Nó cũng có thể bao gồm thông tin về ai sẽ xử lý nội dung và trong trường hợp xảy ra lỗi thì cách mã hóa thông ñiệp lỗi như thế nào. Các quy tắc mã hóa dữ liệu: ðể trao ñổi dữ liệu, các máy tính phải thống nhất các quy tắc mô tả mã hóa các kiểu dữ liệu. Ví dụ hai máy tính xử lý gía cổ phiếu cần thống nhất quy tắc cho việc mã hóa dữ liệu kiểu float; tương tự hai máy tính xử lý giá nhiều loại cổ phiếu cấn phải thống nhất quy tắc mã hóa mảng. Ví vậy SOAP bao gồm trong nó tập hợp các quy ước về mã hóa các kiểu dữ liệu. Hầu hết những quy ước ñó dựa trên ñặc tả W3C XML schema. 52 RPC conventions: SOAP có thể ñược sử dụng trong hàng loạt các hệ thống thông tin một hoặc hai chiều. Với thông tin hai chiều, SOAP ñịnh nghĩa một quy ước ñơn giản ñể biểu diễn việc gọi các thủ tục từ xa và các phản hồi. ðiều này cho phép một ứng dụng máy trạm xác ñịnh tên một phương thức từ xa, bao gồm số các tham số và nhận một phản hồi từ máy chủ. Chúng ta xem xét mô tả một giao thức SOAP, bắt ñầu bằng cách trình diễn một quy ước SOAP ñơn giản. Xmethoads.net cung cấp dịch vụ thông tin thời tiết, liệt kê danh sách nhiệt ñộ theo mã zip. Phương thức dịch vụ, getTemp, yêu cầu một chuỗi mã zip và trả về một giá trị float[8]. Hình 2.2.2 - Mô tả mô hình SOAP 2.2.3 SOAP Request Yêu cầu từ máy trạm phải bao gồm tên của phương thức ñể thực hiện và các tham số ñược yêu cầu. Xét bản tin SOAP Request trong ví dụ 2.2.1.1. Có một cặp phần tử rất quan trọng cần phải chú ý ở ñây. Thứ nhất Request gồm có một phần tử bắt buộc, trong ñó bao gồm một phần tử bắt buộc. Thứ hai tất cả có 4 Namespace ñược ñịnh nghĩa. Các Namespace ñược sử dụng ñể phân biệt các phần tử XML và các thuộc tính, và thường ñược sử dụng ñể tham chiếu các lược ñồ bên ngoài. Trong ví dụ trên chúng ta sử dụng namespace ñể phân biệt các ñịnh danh ñược kết hợp với SOAP Envelope( mã hóa dữ liệu bằng các XML schema ( và và các ñịnh danh ứng dụng cụ thể là dịch vụ (urn:examples:weatherservice). ðiều này cho phép mô-dun hóa ứng dụng, trong 53 khi vẫn cung cấp sự mềm dẻo tối ña cho những thay ñổi ñặc tả trong tương lai. Phần tử ñóng gói phần thân(payload) chính của thông ñiệp SOAP. Chỉ có một phần tử là là gắn liền với namespace và tương ứng với tên phương thức từ xa. Mỗi tham số của phương thức xuất hiện trong một phần tử con. Trong trường hợp này chúng ta có phần tử , ñược gán với XML schema với kiểu dữ liệu xsd:string và giá trị là 10016[8]. 2.2.4 SOAP Response Từ ví dụ 2.2.1.1 và 2.2.1.2 ta thấy, cũng giống như SOAP Request, SOAP Response gồm các phần tử và , và 4 XML namespace. Tuy nhiên phần tử bao gồm một phần tử , tương ứng với yêu cầu ban ñầu. Như trên ta thấy nhiệt ñộ cho mã zip 10016 là 65 ñộ F[8]. 2.3 Thông ñiệp SOAP Một thông ñiệp một chiều là một yêu cầu từ máy trạm, hoặc một phản hồi từ máy chủ thông thường nó ñược biết ñến như là một thông ñiệp SOAP. Mọi thông ñiệp SOAP phải có từ khóa Envelop, không bắt buộc có phần tử Header, nhưng bắt buộc phải có phần tử Body. Những phần tử này ñược kết hợp với tập hợp các quy tắc, và ñể có thể debug ñược ứng dụng SOAP thì phải hiểu các quy tắc này.[8] Hình 2.3 - Khuôn dạng thông ñiệp SOAP 2.3.1 Envelope Mọi thông ñiệp SOAP ñều có phần tử gốc Envelop. Khác với các ñặc tả khác, như HTTP và XML, SOAP không ñịnh nghĩa một mô hình phiên bản truyền thống dựa trên số phiên bản phát hành chính và phụ(HTTP 1.0, HTTP1.1). SOAP 54 sử dụng SOAP namespace ñể ñánh dấu các phiên bản khác nhau. Phiên bản phải ñược tham chiếu trong phần tử . Ví dụ: <SOAP-ENV:Envelope xmlns:SOAP-NV= SOAP 1.1 namespace có URI là trong khi ñó của SOAP 1.2 là Nếu Envelop là một namespace bất kỳ, thì coi như là một lỗi phiên bản[8]. 2.3.2 Header Phần tử tùy chọn Header cung cấp một khuôn khổ linh hoạt cho việc bổ sung các yêu cầu ở cấp ứng dụng. ví dụ: phần tử Header có thể ñược sử dụng ñể xác ñịnh một chữ ký số cho dịch vụ bảo vệ bằng mật khẩu, giồng như vậy, nó có thể ñược sử dụng ñể xác ñịnh một số tài khoản của dịch vụ SOAP “pay-per-use”. Hiện tại có rất nhiều dịch vụ SOAP không sử dụng phần tử Header, nhưng các dịch vụ SOAP an toàn, thì Header cung cấp một bộ máy mở cho xác thực, quản lý giao dịch, và thanh toán ủy quyền[8]. Phần tử Header có hai thuộc tính: - Actor: Giao thức SOAP ñịnh nghĩa một message path như một danh sách các nút dịch vụ SOAP. Mỗi một nút trung gian ñó có thể thực hiện một vài xử lý và sau ñó chuyển tiếp thông ñiệp tới nút tiếp theo trong chuỗi. Bằng cách thiết lập thuộc tính này, máy trạm có thể chỉ rõ người nhận của SOAP header. - MustUnderstand:Chỉ ñịnh một phần tử Header là tùy chọn hay bắt buộc. Nếu ñặt là true, người nhận phải hiểu và xử lý thuộc tính Header tùy theo ñịnh nghĩa của nó hoặc trả về lỗi. Header chỉ rõ tài khoản thanh toán, nó phải ñược hiểu và xử lý bởi máy chủ SOAP như ví dụ sau: <ns1:PaymentAccount xmlns:ns1="urn:ecerami" SOAP-ENV: mustUnderstand="true"> orse