nguy Ễn kh ƯƠ ng duy · 3 lỜi c Ảm Ơn tr ước h ết, xin ñược g ửi l ời c ảm...
TRANSCRIPT
1
ðẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ðẠI HỌC KHOA HỌC TỰ NHIÊN
------------------------
NGUYỄN KHƯƠNG DUY
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
LUẬN VĂN THẠC SĨ KHOA HỌC
Hà Nội – 2011
2
ðẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ðẠI HỌC KHOA HỌC TỰ NHIÊN
------------------------
NGUYỄN KHƯƠNG DUY
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
Chuyên ngành: Bảo ñảm toán học cho máy tính và hệ thống tính toán
Mã số: 60.46.35
LUẬN VĂN THẠC SĨ KHOA HỌC
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS. NGUYỄN HỮU ðIỂN
Hà Nội – 2011
3
LỜI CẢM ƠN
Trước hết, xin ñược gửi lời cảm ơn ñến thầy giáo hướng dẫn tôi là PGS Tiến
sỹ Nguyễn Hữu ðiển, người ñã giúp ñỡ tôi trong quá trình nghiên cứu hoàn thành
luận văn này.
Cho phép tôi gửi lời cảm ơn ñến Trung tâm ðiều hành thông tin, Trung tâm
Tin học - VNPT Hà nội, ñặc biệt là các anh chị em ñồng nghiệp tại Phòng ðiều
hành Quản lý chất lượng, nơi tôi ñang công tác, ñã tích cực tham gia và tạo ñiều
kiện ñể tôi ñược thử nghiệm, áp dụng các giải pháp liên quan ñến ñề tài.
Tôi cũng xin gửi lời cảm ơn ñến các bạn cùng học trong khóa ñào tạo thạc sỹ
chuyên ngành Bảo ñảm toán học cho máy tính và các hệ thống tính toán khóa 2009-
2011 ñã cung cấp các tài liệu cần thiết trong quá trình nghiên cứu và ñã giúp ñỡ tôi
rất nhiều trong quá trình học tập, chuẩn bị luận án.
Cuối cùng cho phép tôi cảm ơn các bạn bè, gia ñình ñã giúp ñỡ, ủng hộ tôi
rất nhiều trong toàn bộ quá trình học tập cũng như nghiên cứu hoàn thành luận văn
này.
4
Mục lục
Danh mục các bảng biểu ......................................................................................... 7
Danh mục hình ảnh ................................................................................................. 8
CÁC TỪ VIẾT TẮT ................................................................................................ 10
MỞ ðẦU ............................................................................................................... 12
CHƯƠNG 1 ......................................................................................................... 14
GIAO THỨC QUẢN LÝ MẠNG ðƠN GIẢN ................................................... 14
1.1. Tổng quan giao thức ................................................................................... 14
1.1.1 Lịch sử .................................................................................................... 14
1.1.2 Khái niệm SNMP ..................................................................................... 14
1.1.3 RFC và các phiên bản SNMP .................................................................. 15
1.2 Mô hình giao thức ....................................................................................... 16
1.2.1 Manager và Agent ................................................................................. 16
1.2.2 Hoạt ñộng của SNMP ............................................................................ 17
1.2.3 Bảo mật trong SNMP............................................................................ 18
1.2.4 Cấu trúc thông tin quản lý (SMI) ........................................................... 19
1.2.4.1 SMIv1 ................................................................................................ 20
1.2.4.2 MIB-II (RFC1213) ............................................................................. 24
1.2.4.3 SMIv2 ................................................................................................ 29
1.3 ðịnh dạng thông ñiệp và các phương thức vận hành................................... 33
1.3.1 ðịnh dạng thông ñiệp của SNMPv1 và 2 ............................................... 33
1.3.1.1 ðịnh dạng tổng quát............................................................................ 33
1.3.1.2 ðịnh dạng PDU .................................................................................. 34
1.3.1.2.1 ðịnh dạng PDU chung cho các phương thức .................................... 34
1.3.1.2.2 Kiểu PDU và trạng thái lỗi ............................................................... 35
1.3.1.2.3 ðịnh dạng Trap-PDU ....................................................................... 37
1.3.1.2.4 ðịnh dạng GetBulkRequest-PDU SNMPv2c ................................... 38
1.3.1.3 ðịnh dạng thông ñiệp SNMP Version 3 (SNMPv3) ............................ 39
1.3.2 Các phương thức ................................................................................... 42
1.3.2.1 Phương thức Get (GetRequest): .......................................................... 43
1.3.2.2 GetNextRequest: ................................................................................. 43
1.3.2.3 SetRequest: ......................................................................................... 44
1.3.2.4 GetResponse: ...................................................................................... 44
1.3.2.5 GetBulkRequest:................................................................................. 44
1.3.2.6 Trap .................................................................................................... 45
1.3.2.7 SNMP Notification ............................................................................. 46
1.3.2.8 SNMP Inform ..................................................................................... 47
5
1.3.2.9 SNMP Report ..................................................................................... 47
1.4 Sử dụng SNMP4J API xây dựng Một số phương thức SNMP ...................... 47
CHƯƠNG 2 ......................................................................................................... 48
CÔNG NGHỆ DỊCH VỤ WEB .......................................................................... 48
2.1 Khái niệm và kiến trúc dịch vụ Web ................................................................. 48
2.1.1 Khái niệm. ................................................................................................... 48
2.1.2 Kiến trúc ....................................................................................................... 48
2.1.2.1 Roles .................................................................................................. 48
2.1.2.2 Chồng giao thức ................................................................................. 49
2.2 Các dạng thông ñiệp XML ............................................................................... 50
2.2.1 SOAP .................................................................................................... 50
2.2.2 ðặc tả SOAP ......................................................................................... 51
2.2.3 SOAP Request ....................................................................................... 52
2.2.4 SOAP Response .................................................................................... 53
2.3 Thông ñiệp SOAP ............................................................................................ 53
2.3.1 Envelope................................................................................................ 53
2.3.2 Header ................................................................................................... 54
2.3.3 Body ...................................................................................................... 54
2.3.4 Fault ...................................................................................................... 55
2.3.5 SOAP Encoding .................................................................................... 56
2.3.5.1 Kiểu vô hướng .................................................................................... 56
2.3.5.2 Kiểu phức hợp .................................................................................... 58
2.3.6 Literal Encoding .................................................................................... 59
2.3.7 Truyền tải SOAP qua HTTP .................................................................. 60
2.4 Service Description: WSDL ............................................................................. 62
2.4.1 Các thành phần trong file WSDL ........................................................... 64
2.4.2 Kiểu dữ liệu XML Schema. ................................................................... 65
2.5. Service Discovery: UDDI ............................................................................... 68
2.5.1 Hoạt ñộng của UDDI ............................................................................. 69
2.5.2 Mô hình dữ liệu UDDI .......................................................................... 71
2.6 Bảo mật dịch vụ Web ....................................................................................... 74
2.6.1 WS-Security .......................................................................................... 74
2.6.2 Thông ñiệp bảo mật SOAP .................................................................... 74
2.6.3 Thẻ bài bảo mật và ñịnh danh ................................................................ 75
2.6.4 Thẻ bài bảo mật và xác thực .................................................................. 76
2.6.5 WS-Federation ...................................................................................... 76
2.6.6 WS-SecureConversation ........................................................................ 76
6
CHƯƠNG 3 ......................................................................................................... 78
THIẾT KẾ HT KHAI THÁC ðƯỜNG DÂY THUÊ BAO ............................... 78
3.1 Một số khai niệm ............................................................................................. 78
3.1.1 DSLAM, xDSL ..................................................................................... 78
3.1.2 Mạng cung cấp dịch vụ ñiện thoại cố ñịnh(PSTN) ................................ 78
3.2 Thuê bao Internet ............................................................................................ 80
3.2.1 Chức năng hệ thống ............................................................................... 80
3.2.2 Thiết kế hệ thống ................................................................................... 81
3.2.2.1Mô hình và kiến trúc hệ thống ............................................................. 81
3.2.2.1.1 Mô hình hệ thống ............................................................................. 81
3.2.2.1.2 Kiến trúc hệ thống ........................................................................... 81
3.2.2.2 Biểu ñồ ca sử dụng ............................................................................. 82
3.2.2.2.1 Danh sách các tác nhân .................................................................... 82
3.2.2.2.2 ðặc tả các Use Case ......................................................................... 82
3.2.2.3 Biểu ñồ lớp ......................................................................................... 84
3.2.2.4 Biểu ñồ tuần tự ................................................................................... 87
3.2.2.5 Kết quả triển khai sử dụng .................................................................. 87
3.3 Thuê bao ñiện thoại cố ñịnh ............................................................................. 89
3.3.1 Chức năng hệ thống ............................................................................... 89
3.3.2 Thiết kế hệ thống ................................................................................... 90
3.3.2.1 Mô hình và kiến trúc hệ thống ............................................................ 90
3.3.2.1.1 Mô hình hệ thống ............................................................................. 90
3.3.2.1.2 Kiến trúc hệ thống ........................................................................... 90
3.3.2.2 Biểu ñồ ca sử dụng ............................................................................. 92
3.3.2.2.1 Các tác nhân .................................................................................... 92
3.3.2.2.2 Các ca sử dụng ................................................................................. 92
3.3.2.3 Biểu ñồ lớp ......................................................................................... 94
3.3.2.4 Biểu ñồ tuần tự .................................................................................... 97
3.3.2.5 Kết quả triển khai sử dụng ................................................................... 98
KẾT LUẬN .......................................................................................................... 100
TÀI LIỆU THAM KHẢO ...................................................................................... 102
7
Danh mục các bảng biểu
CHƯƠNG 1: GIAO THỨC QUẢN LÝ MẠNG ðƠN GIẢN 1.2.4.1 - Các kiểu dữ liệu SMIv1 ........................................................................... 24
1.2.4.2 - Mô tả MIB-II trong RFC1213 .................................................................. 28
1.2.4.3.1 – ðịnh nghĩa một số kiểu dữ liệu mới trong SMIv2. ................................ 30
1.2.4.3.2 -Những cải tiến ñịnh nghĩa ñối tượng trong SMIv2 ................................ 31
1.2.4.3.3 - Các quy ước về văn bản cho SMIv2 ...................................................... 33 1.3.1.1 - ðịnh dạng thông ñiệp[4] ......................................................................... 34
1.3.1.2.1 - ðịnh dạng chung PDU .......................................................................... 35
1.3.1.2.2.1 - Kiểu PDU .......................................................................................... 35
1.3.1.2.2.2 - Các giá trị trường Error Status trong PDU SNMP .............................. 37
1.3.1.2.3.1 - ðịnh dạng Trap PDU ......................................................................... 38
1.3.1.2.3.2 - Mô tả các Generic trap ....................................................................... 38
1.3.1.2.4 - ðịnh dạng GetBulkRequest-PDU [4] .................................................... 39
1.3.1.3.1 - ðịnh dạng tổng quát thông ñiệp SNMPv3 ............................................. 41
1.3.1.3.2 - Msg Flags ............................................................................................. 42
1.3.1.3.3 Scoped PDU ........................................................................................... 42 CHƯƠNG 2: CÔNG NGHỆ DỊCH VỤ WEB 2.3.4.1 - Mô tả các phần tử con trong phần tử fault ................................................ 55
2.3.4.2 - Mô tả các giá trị trong phần tử faultCode ................................................. 56
2.3.5.1 - Các kiểu dựng sẵn ................................................................................... 57
2.4.2 - Danh sách các kiểu dữ liệu dựng sẵn trong XML Schema .......................... 66
8
Danh mục hình ảnh
CHƯƠNG 1: GIAO THỨC QUẢN LÝ MẠNG ðƠN GIẢN 1.2.1 - Mối quan hệ giữa NMS và agent ................................................................ 17
1.2.2 - Mô hình hoạt ñộng SNMP ......................................................................... 17
1.2.4.1 - ðặc tả MIB theo dạng cây ....................................................................... 22
1.2.4.3 - Cấu trúc SMIv2 ....................................................................................... 30
1.3.1.1 - ðịnh dạng tổng quát [5] ........................................................................... 33
1.3.1.2.1 - ðịnh dạng chung PDU .......................................................................... 34
1.3.1.2.3 - ðịnh dạng Trap PDU [4]....................................................................... 37
1.3.1.2.4 - ðịnh dạng GetBulkRequest-PDU [4] .................................................... 38
1.3.1.3 - ðịnh dạng tổng quát thông ñiệp SNMP Version 3 (SNMPv3) ................. 40
1.3.2.1 - Mô hình truyền thông ñiệp của phương thức get ...................................... 43
1.3.2.5 - Mô hình truyền thông ñiệp của phương thức get-bull ............................... 45
1.3.2.6 - Mô hình biểu diễn sự phát sinh trap ......................................................... 46 CHƯƠNG 2: CÔNG NGHỆ DỊCH VỤ WEB 2.1.2.1 - Mô tả các Role trong kiến trúc một Dịch vụ Web .................................... 49
2.1.2.2 - Mô tả chồng giao thức của Dịch vụ Web ................................................. 49
2.2.2 - Mô tả mô hình SOAP ................................................................................. 52
2.3 - Khuôn dạng thông ñiệp SOAP ....................................................................... 53
2.4.1 - ðặc tả WSDL ............................................................................................ 65
2.5.1.1 - Luồng thông ñiệp trong hệ thống giữa máy trạm và nút ñăng ký UDDI ... 69
2.5.1.2 - Lược ñồ tác nghiệp của UDDI ................................................................. 70
2.5.2 - Mô hình dữ liệu UDDI ............................................................................... 71
2.6.2 - Cấu trúc một thông ñiệp ............................................................................. 74
2.6.4 - Mô hình xác thực ........................................................................................ 76
2.6.5 - Mô hình WS-Federation ............................................................................. 76 CHƯƠNG 3: THIẾT KẾ HT KHAI THÁC ðƯỜNG DÂY THUÊ BAO 3.2.2.1.1 - Mô hình hệ thống mở rộng khai thác thuê bao Internet ......................... 81
3.2.2.1.2 – Kiến trúc hệ thống ................................................................................ 81
3.2.2.2 - Biểu ñồ ca sử dụng .................................................................................. 82
3.2.2.3 - Biểu ñồ lớp .............................................................................................. 84
3.2.2.4 - Biểu ñồ tuần tự ........................................................................................ 87
3.2.2.5.1 - Giao diện ño thử chất lượng .................................................................. 88
3.2.2.5.2 -Giao diện ñổi tốc ñộ cổng ...................................................................... 88
3.2.2.5.3 -Giao diện xem trạng thái và reset cổng .................................................. 88
3.2.2.5.4 -Giao diện kiểm tra khả năng phát triển dịch vụ ...................................... 88
3.3.2.1.1 – Mô hình triển khai dịch vụ Web(webservice) ....................................... 90
3.3.2.1.2.1 - Thông ñiệp ñi qua các hàng ñợi tương ứng với các tổng ñài(Host) .... 91
3.3.2.1.2.2 - Kiến trúc hệ thống tổng quát .............................................................. 91
3.3.2.2 - Biểu ñồ ca sử dụng .................................................................................. 92
3.3.2.3 - Biểu ñồ lớp .............................................................................................. 94
9
33.3.2.4.1 - Biểu ñồ tuần tự gửi yêu cầu ................................................................ 97
3.3.3.2.4.2 -Biểu ñồ tuần tự thực hiện yêu cầu ....................................................... 97
3.3.2.4.3 - Biểu ñồ tuần tự nhận kết quả................................................................. 98
3.3.2.5.1 - Giao diện ño thử chất lượng .................................................................. 98
3.3.2.5.2 - Giao diện truy vấn thông tin thuê bao ................................................... 98
3.3.2.5.3 - Giao diện báo cáo trạng thái thực hiện treo/khôi phục nợ cước ............. 99
10
CÁC TỪ VIẾT TẮT
ADSL Asymmetric Digital Subscriber Line
ATM Asynchronous Transfer Mode
ASN.1 Abstract Syntax Notation 1
BEEP Blocks Extensible Exchange Protocol
BER Basic Encoding Rules
BGP Border Gateway Protocol
DSLAM Digital Subscriber Line Access Multiplexer
CCITT International Telegraph and Telephone Consultative Comittee
FTP File Tranfer Protocol
HMMP HyperMedia Management Protocol
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IAB Internet Architecture Board
IANA Internet Assigned Numbers Authority
IETF Intemet Engineering Task Force
IOS Internetwork Operating System
IP Internet Protocol
ITU-T International Telecommunication Union - Telecommunication
Standardization Sector
MIB Managerment Information Base
MTU Maxium Transfer Unit
NMS Network Management System
OID Object Identifier
OMG Object Management Group
PDU Protocol Data Unit
PTTB Phát triển thuê bao
PSTN Public Switched Telephone Network
11
RADIUS Remote Authentication Dial In User Service
RDBMS Relational Database Management System
RFC Request For Comment
RPC Remote Procedure Call
SAML Security Assertion Markup Language
SHDSL Symmetric High-speed Digital Subscriber Line
SMI Structure of Management Information
SMTP Simple Mail Tranfer Protocol
SNMP Simple Network Management Protocol
SOAP Simple Object Access Protocol
TDM Time-division multiplexing
TCP Transmission Control Protocol
UDDI Universal Description, Discovery and Integration
UDP User Datagram Protocol
URL Uniform Resource Locator
USM User-based Security Model
VDSL Very high bit-rate DSL
XML Extention Markup Language
xDSL ADSL, SHDSL, VDSL, DSL
WSDL Web Service Definition Language
WWW World Wide Webservice
W3C World Wide Web Consortium
12
MỞ ðẦU
Cùng với sự phát triển nhanh chóng của các công nghệ mạng truyền tải dữ
liệu và tín hiệu thoại, các thiết bị tham gia thực hiện truyền tải cũng ngày càng ñược
phát triển cả về số lượng, chất lượng và công nghệ, bên cạnh ñó các hệ thống phần
mềm quản lý khai thác theo mô hình quản lý tập trung ñể quản lý ñược số lượng lớn
node mạng cũng ñóng vai trò rất quan trọng, các hệ thống phần mềm chuyên dụng
ñó ñã ñáp ứng tốt những yêu cầu quản lý, khai thác của nhà cung cấp dịch vụ. Tuy
nhiên do tính ña dạng chủng loại thiết bị, mỗi thiết bị có một phần mềm và phương
thức quản lý khai thác khác nhau, dẫn ñến khó khăn khi tập trung hóa giao diện sửa
dụng, mở rộng và tích hợp với các hệ thống quản lý và khai thác của nhà cung cấp
dịch vụ, ñây là vấn ñề rất quan trọng ñối với các nhà cung cấp dịch vụ thoại và dịch
vụ Internet cần phải giải quyết nhằm nâng cao chất lượng dịch vụ của mình. Dựa
trên những ưu ñiểm của công nghệ dịch vụ Web như khả năng sử dụng ñược ở mọi
nơi, mọi lúc, vào mọi thời ñiểm mà không phụ thuộc vào hệ thống nền tảng hay
khoảng cách ñịa lý, không phải triển khai cài ñặt phía máy trạm chỉ sử dụng trình
duyệt Web, dựa trên phương thức giao tiếp giữa NMS và thiết cung cấp dịch vụ
Internet bằng SNMP, dựa trên ñặc thù kết nối của các tổng ñài ñiện thoại thông qua
RS232 với các phần mềm quản lý và khai thác, nhằm khắc phục những khó khăn
nêu trên, chúng tôi ñề xuất thiết kế hệ thống phần mềm sử dụng công nghệ dịch vụ
Web cho phép mở rộng giao tiếp với các hệ thống tác nghiệp bên ngoài, cho phép
kết nối bằng SNMP với các thiết bị cung cấp dịch vụ Internet, sử dụng thiết bị
chuyển ñổi giao diện RS232 sang giao diện IP, cho phép thực hiện các lệnh của
tổng ñài bằng trình Telnet client. Từ ý tưởng thiết kế như trên chúng tôi ñã tiến
hành xây dựng hệ thống phần mềm trên nền WEB phục vụ công tác cung cấp và
quản lý chất lượng dịch vụ internet và ñiện thoại cố ñịnh hiện ñang ñược áp dụng tại
VNPT Hà nội.
Về phương diện lý thuyết, luận văn này sẽ ñi sâu vào tìm hiểu giao thức quản
lý mạng SNMP và mô hình quản trị mạng dựa trên giao thức này, kiến trúc và ñịnh
dạng thông ñiệp của dịch vụ Web cũng sẽ ñược giới thiệu ở các khía cạnh chính, có
13
liên quan ñến việc xây dựng hệ thống trên.
Luận văn ñược trình bày trong 3 chương với các nội dung như sau:
- Chương 1: Giao thức quản lý mạng ñơn giản
- Chương 2: Công nghệ dịch vụ Web
- Chương 3: Thiết kế hệ thống khai thác ñường dây thuê bao.
Tuy ñã hết sức cố gằng trình bày những nội dung ngắn gọn, dễ hiểu và chủ
yếu ñi sâu vào những khái niệm cơ bản, nhưng vẫn không thể tránh ñược nhiều sai
sót. Rất mong bạn ñọc thông cảm và góp ý ñể luận văn ñược hoàn thiện hơn.
Trân trọng cảm ơn!
Nguyễn Khương Duy
14
CHƯƠNG 1
GIAO THỨC QUẢN LÝ MẠNG ðƠN GIẢN
1.1. Tổng quan giao thức
1.1.1 Lịch sử
Ngày nay, việc quản lý, khai thác một mạng lưới bao gồm các router, các
switch, máy chủ, trở lên khó khăn và phức tạp. Ngoài việc phải ñảm bảo tất cả các
thiết bị chạy liên tục mà còn phải tối ưu hiệu suất làm việc của từng thiết bị. ðiều
này có thể ñược hỗ trợ bởi giao thức quản lý mạng ñơn giản:SNMP. SNMP ñược
giới thiệu năm 1988 bởi Tổ chức kiến trúc Internet IAB[6], ñể ñáp ứng nhu cầu
quản lý các thiết bị sử dụng giao thức IP ngày càng tăng. SNMP cung cấp cho
người sử dụng một tập ñược gọi là “ñơn giản” các thao tác cho phép quản lý các
thiết bị từ xa.
Trước sự phát triển không ngừng gia tăng và phức tạp của mạng internet
tháng 4 năm 1993, SNMPv2 trở thành tiêu chuẩn quản lí mạng ñơn giản thay thế
SNMPv1. SNMPv2 bổ sung một số vấn ñề mà SNMPv1còn thiếu như nhận thực và
bảo mật. Tuy nhiên, SNMPv2 khá phức tạp và khó tương thích với SNMPv1[4].
Năm 1997, SNMPv3 ra ñời nhằm tương thích với các giao thức ña phương
tiện trong quản lí mạng, phát triển trên nền java và ñưa ra kiến trúc và giao thức mới
như giao thức quản lí ña phương tiện HMMP.
1.1.2 Khái niệm SNMP
SNMP là giao thức quản lý mạng ñơn giản dịch từ cụm từ “Simple Network
Management Protocol”. Giao thức này ñược sử dụng rất phổ biến ñể giám sát và
ñiều khiển các thiết bị mạng IP. SNMP là một thành phần của tập hợp các giao thức
truyền thông phù hợp với Internet và các mạng tương tự ñược ñịnh nghĩa bởi IETF.
Nó bao gồm một tập hợp các tiêu chuẩn quản lý mạng, giao thức tầng ứng dụng,
lược ñồ cơ sở dữ liệu và tập hợp các ñối tượng dữ liệu[13].
SNMP là giao thức ñơn giản, do nó ñược thiết kế ñơn giản trong cấu trúc
thông ñiệp và thủ tục hoạt ñộng, và còn ñơn giản trong bảo mật (ngoại trừ SNMP
version 3).
15
Giao thức SNMP cung cấp một phương thức ñơn giản nhằm quản lý tập
trung mạng TCP/IP. Người quản trị có thể thông qua giao thức này ñể quản lý các
hoạt ñộng hay thay ñổi các trạng thái hệ thống mạng.
Giao thức SNMP ñược sử dụng ñể quản lý các hệ thống Unix, Window…,
các thiết bị mạng như router, gateway, firewall, switch…, thông qua một số phần
mềm cho phép quản trị với SNMP[6].
Ví dụ cho việc sử dụng hệ thống quản trị SNMP với giao thức SNMP trên
phần mềm với các ứng dụng trong hệ thống mạng:
� Theo dõi tốc ñộ ñường truyền của một router, biết ñược tổng số byte
truyền/nhận
� Lấy thông tin máy chủ có bao nhiêu ổ cứng, mỗi ổ cứng còn trống bao nhiêu
� Tự ñộng nhận cảnh báo khi thiết bị switch có 1 cổng bị down
� ðiều khiển tắt các cổng trên switch.
1.1.3 RFC và các phiên bản SNMP
IETF là tổ chức ñã ñưa ra chuẩn SNMP thông qua các RFC.
SNMP version 1: Chuẩn của giao thức SNMP ñược ñịnh nghĩa trong RFC
1157 và là một chuẩn ñầy ñủ của IETF. Vấn ñề bảo mật của SNMP v1 dựa
trên nguyên tắc cộng ñồng, không có nhiều mật khẩu, chuổi văn bản thuần và
cho phép bất kỳ một ứng dụng nào ñó dựa trên SNMP có thể hiểu các chuỗi
này ñể có thể truy cập vào các thiết bị quản lý. Có 3 quyền tiêu biểu: read-
only, read-write và trap[6].
SNMP version 2: Phiên bản này dựa trên các chuỗi “community”. Do ñó
phiên bản này ñược gọi là SNMPv2c, ñược ñịnh nghĩa trong RFC 1905,
1906, 1907, và ñây chỉ là bản thử nghiệm của IETF. Mặc dù chỉ là thử
nghiệm nhưng nhiều nhà sản xuất ñã ñưa nó vào thực nghiệm[6].
SNMP version 3: Là phiên bản tiếp theo ñược IETF ñưa ra. Nó ñược khuyến
nghị làm bản chuẩn, ñược ñịnh nghĩa trong RFC1905, RFC1906, RFC1907,
RFC2571, RFC2572, RFC2573, RFC2574 vàRFC 2575. Nó hỗ trợ các kiểu
truyền thông riêng tư và có xác nhận giữa các thực thể[6].
16
1.2 Mô hình giao thức
1.2.1 Manager và Agent
Trong SNMP có 3 vấn ñề cần quan tâm: Manager, Agent và MIB.
MIB là cơ sở dữ liệu dùng phục vụ cho Manager và Agent.
Manager:
Manager là một máy tính có chạy các chương trình có thể thực hiện một số
chức năng quản lý mạng. Manager có thể xem như là NMS. NMS có khả năng thăm
dò và thu thập các cảnh báo từ các Agent trong mạng. Thăm dò trong quản lý mạng
là cách ñặt ra các câu truy vấn ñến các Agent ñể có ñược thông tin về thiết bị mạng
mà agent ñang thường chú. Các cảnh báo của Agent là cách mà Agent báo với NMS
khi có sự cố xảy ra. Cảnh bảo của Agent ñược gửi một cách không ñồng bộ, không
nằm trong việc trả lời truy vấn của NMS. NMS dựa trên các thông tin trả lời của
Agent ñể có các phương án giúp mạng hoạt ñộng hiệu quả hơn. Ví dụ khi ñường
dây T1 kết nối tới Internet bị giảm băng thông nghiêm trọng, router sẽ gửi một
thông tin cảnh báo tới NMS. NMS sẽ có một số hành ñộng như là lưu lại thông tin
ñó, giúp ta có thể biết việc gì ñã xảy ra với thiết bị. Các hành ñộng này của NMS
phải ñược cài ñặt trước[6].
Agent:
Agent là một phần trong các chương trình chạy trên các thiết bị mạng cần quản
lý. Nó có thể là một chương trình ñộc lập như các deamon trong Unix, hoặc ñược
tích hợp vào hệ ñiều hành như IOS của Cisco trên router. Ngày nay, ña số các thiết
bị hoạt ñộng trong mạng IP ñược cài ñặt SMNP agent. Các nhà sản xuất ngày càng
muốn phát triển các agent trong các sản phẩm của họ ñể công việc của người quản
lý hệ thống hay quản trị mang ñơn giản hơn. Các agent cung cấp thông tin cho NMS
bằng cách lưu trữ các hoạt ñộng khác nhau của thiết bị. Một số thiết bị thường gửi
một thông báo “tất cả ñều bình thường” khi nó chuyển từ một trạng thái xấu sang
một trạng thái tốt. ðiều này cho phép xác ñịnh khi nào thì một sự cố ñược giải
quyết[6].
17
Hình 1.2.1 - Mối quan hệ giữa NMS và agent
1.2.2 Hoạt ñộng của SNMP
Hoạt ñộng của SNMP theo mô hình sau:
Hình 1.2.2 - Mô hình hoạt ñộng SNMP
SNMP sử dụng UDP ñể truyển tải dữ liệu giữa các Manager và các Agent,
nó sử dụng cổng 161 ñể gửi và nhận thông ñiệp, cổng 162 ñể nhận trap từ thiết bị
ñang theo dõi[6].
18
1.2.3 Bảo mật trong SNMP
SNMPv1 và SNMPv2 sử dụng khái niệm của Community ñể thiết lập xác
thực giữa Manager và Agent. Một Agent ñược cấu hình với 3 Community: read-
only, read-write, và trap. Giống như tên của nó, read-only cho phép chỉ ñọc giá trị
dữ liệu nhưng không cho phép sửa và khởi tạo dữ liệu. Ví dụ cho phép ta ñọc số gói
ñược truyền qua cổng của router nhưng không cho phép ta khởi tạo lại giá trị của bộ
ñếm này. Read-write cho phép chúng ta ñọc và sửa giá trị dữ liệu, với Community
này ta có thể ñọc số gói truyền qua cổng và khởi tạo lại bộ ñếm như trong ví dụ
trên, và sự kiện khởi tạo lại hoặc làm một số hành ñộng khác là sự thay ñổi cấu hình
của router. Cuối cùng, chuỗi community trap cho phép ta nhận các trap(thông báo
không ñồng bộ) từ agent[6].
Do sử dụng community như là mật khẩu nên SNMPv1 là giao thức rất yếu về
bảo mật. Các gói tin ñược gửi ñi dưới dạng thuần văn bản nên không phòng chống
ñược kiểu tấn công bằng cách nghe lén(sniffer).
SNMPv2 cố gắng giải quyết vấn ñề này dựa trên các cách tiết cận chặt chẽ
hơn. Một phiên bản gọi là SNMPv2 party-based tiếp cận theo hướng: Tùy từng yêu
cầu về xác thực và tính bảo mật mà có thể sử dụng các kênh khác nhau ñể trao ñổi
thông tin. Tuy nhiên, với nhiều nỗ lực ñể tăng cường bảo mật trong SNMP ñã dẫn
tới ba phiên bản không tương thích với nhau là: SNMPv2p hay SNMPv2 party-
based, SNMPv2u hay SNMPv2 user-based và SNMPv2*. Các phiên bản này ñã
thất bại trong việc tìm ñược sử hỗ trợ của các nhà sản xuất và dừng lại ở bản thảo,
rồi chuyển sang quá khứ. Cuối cùng, một sự thỏa hiệp ñược thực hiện và kết quà là
chuẩn SNMPv2c hay SNMP community-string-based. ðây là một bước tụt lùi khi
quay lại sử dụng community như SNMPv1, tuy nhiên chuẩn này lại ñược hỗ trợ của
IETF cũng như cách nhà sản xuất. Trong tài liệu này, khi nói ñến SNMPv2 là ám
chỉ SNMPv2c. Vấn ñề về bảo mật chỉ ñược giải quyết triệt ñể chỉ khi xuất hiện
phiên bản SNMPv3[2].
SMNPv3 ra ñời chủ yếu ñể giải quyết vấn ñề còn hạn chế về bảo mật trong
hai phiên bản trước. Phiên bản này không có sự thay ñổi về giao thức, không có
19
thêm PDU mới, chỉ có một vài quy chuẩn mới, khái niệm và thuật ngữ mới, cũng
không nằm ngoài việc làm tăng tính chính xác. Thay ñổi quan trọng nhất trong
SNMPv3 này là sử dụng khái niệm SNMP entity thay cho cả manager và agent.
Mỗi SNMP entity gồm một SNMP engine và một hoặc nhiều SNMP application. Sự
thay ñổi về khái niệm này quan trọng ở chỗ thay ñổi về kiến trúc, tách biệt hai phần
của hệ thống SNMP, giúp cho việc thực hiện các chính sách bảo mật. ðiểm quan
trọng là SNMPv3 vẫn tương thích ngược với các phiên bản trước[2].
1.2.4 Cấu trúc thông tin quản lý (SMI)
SMI cung cấp một phương pháp ñể ñịnh nghĩa các ñối tượng bị quản lý và
cách ñối xử với chúng. Một Agent sở hữu một danh sách các ñối tượng mà nó theo
dõi. Một trong những ñối tượng là trạng thái của một Cổng(Interface) của một
router(ví dụ up, down, testing). Danh sách chung này ñịnh nghĩa các thông tin mà
NMS có thể sử dụng ñể xác ñịnh sức khỏe của toàn thiết bị có agent hỗ trợ[6].
MIB có thể xem như một cơ sở dữ liệu quản lý các ñối tượng mà Agent theo
dõi. Bất kỳ kiểu trạng thái hoặc thống kê thông tin có thể truy nhập bởi NMS ñều
ñược ñịnh nghĩa trong MIB. SMI cung cấp phương pháp quản lý ñối tượng trong
khi MIB thì ñịnh nghĩa(sử dụng cú pháp SMI) chính các ñối tượng ñó. Giống như
một từ ñiển trình diễn cách ñánh vần một từ và ñưa ra ý nghĩa hoặc ñịnh nghĩa của
nó, một MIB ñịnh nghĩa một tên dưới dạng văn bản cho một ñối tượng bị quản lý và
giải thích ý nghĩa của nó[6].
Một Agent có thể thực thi rất nhiều MIB, nhưng tất cả các Agent thực thi
một MIB ñặc biệt ñược gọi là MIB-II(RFC 1213, MIB-I là phiên bản gốc của MIB-
II). Chuẩn này ñịnh nghĩa các biến cho những thông tin kiểu như các số liệu thống
kê về một cổng(tốc ñộ, MTU, octet(Một octet là 8 bit, nó là một ñơn vị cơ sở truyền
trong mạng IP ) gửi, octet nhận,..) cũng như nhiều thứ khác liên quan ñến chính hệ
thống ñang cài ñặt Agent.[6].
Những loại thông tin gì khác có thể có ích ñể thu thập? Thứ nhất, nhiều dự
thảo và các tiêu chuẩn ñề xuất ñã ñược phát triển ñể giúp quản lý những thứ như
20
Frame relay, ATM, FDDI, và dịch vụ (Mail, Domain Name System (DNS), vv).
Một số ví dụ về những MIBs và RFC[6]:
ATM MIB (RFC 2515)
Frame Relay DTE Interface Type MIB (RFC 2115)
BGP Version 4 MIB (RFC 1657)
RDBMS MIB (RFC 1697)
RADIUS Authentication Server MIB (RFC 2619)
Mail Monitoring MIB (RFC 2789)
DNS Server MIB (RFC 1611)
Nhưng nhà sản xuất cũng như người dùng có thể ñịnh nghĩa các biến MIB
riêng cho họ trong từng tình huống quản lý của họ.
1.2.4.1 SMIv1
RFC1155 mô tả cấu trúc của một tập tin MIB, cấu trúc này gọi là SMI
(Structure of Management Information). Sau này người ta mở rộng thêm cấu trúc
của MIB thành SMI version 2, và phiên bản trong RFC1155 ñược gọi là SMIv1.
Trước khi ñi vào tìm hiểu cấu trúc của MIB, chúng ta phải ñi sơ lược qua một chuẩn
gọi là ASN.1 . ASN.1 (Abstract Syntax Notation One) là chuẩn mô tả các luật mã
hóa dữ liệu cho các hệ thống truyền thông số. Một trong 3 hệ thống luật mã hóa
trong ASN.1 là BER (Basic Encoding Rules). BER ñược SNMP dùng làm phương
pháp mã hóa dữ liệu. Vì vậy trong các RFC liên quan ñến SNMP ta hay bắt gặp
dòng ghi chú “use of the basic encoding rules of ASN.1”. BER mô tả nhiều kiểu
dữ liệu như : BOOLEAN, INTEGER, ENUMERATED, OCTET STRING,
CHOICE, OBJECT IDENTIFIER, NULL, SEQUENCE, …. [6]
RFC1155 mô tả mỗi ñối tượng bao gồm 3 phần : Name, Syntax và Encoding.
Name hay OID(Object identifier)
Name hoặc OID là ñịnh nghĩa một ñối tượng quản lý, có kiểu OBJECT
IDENTIFIER. Name thường là một chuỗi thứ tự các số nguyên hoặc chuỗi ký tự
biểu diễn các nút (node) của một cây từ gốc ñến ngọn[6].
Gốc (root node) trong MIB không có Name. Dưới root là 3 node con :
21
- ccitt(0) : do CCITT quản lý (Consultative Committee for International
Telephone and Telegraph).
- iso(1) : do tổ chức ISO quản lý (International Organization for
Standardization).
- joint-iso-ccitt(2) : do cả ISO và CCITT quản lý.
- Dưới node iso(1), tổ chức ISO thiết kế 1 node dành cho các tổ chức khác là
org(3).
- Dưới org(3) có nhiều node con, một node ñược dành riêng cho US
Department of Defense, dod(6). Bộ Quốc phòng Mỹ ñược coi là nơi sáng lập
ra mạng Internet,
- Dưới dod(6) chỉ có 1 node dành cho cộng ñồng internet ngày nay, là node
internet(1).
Tất cả mọi thứ thuộc về cộng ñồng Internet ñều nằm dưới
.iso.org.dod.internet, mọi ñối tượng của các thiết bị TCP/IP ñều bắt ñầu với tiền tố
.1.3.6.1 (dấu chấm ñầu tiên biểu diễn rằng .iso là cây con của root, và root thì không
có Name) RFC1155 ñịnh nghĩa các cây con như sau [6]:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
- directory : dành riêng cho tương lai nếu dịch vụ OSI Directory ñược sử dụng
trên internet.
- mgmt (management) : tất cả các MIB chính thức của internet ñều nằm dưới
mgmt. Mỗi khi một RFC mới về MIB ra ñời thì tổ chức IANA (Internet
Assigned Numbers Authority) sẽ cấp cho MIB ñó một object-identifier nằm
dưới mgmt.
- experimental : dùng cho các ñối tượng ñang trong quá trình thử nghiệm,
ñược IANA cấp phát.
- private : dùng cho các ñối tượng do người dùng tự ñịnh nghĩa, tuy nhiên các
22
chỉ số cũng do IANA cấp. Tất cả các ñơn vị cung cấp hệ thống mạng có thể
ñăng ký object-identifier cho sản phẩm của họ, chúng ñược cấp phát dưới
node private.enterprises.
enterprises OBJECT IDENTIFIER ::= { private 1 }
Hình 1.2.4.1 - ðặc tả MIB theo dạng cây
Ví dụ: chỉ số enterprises private của Cisco là 9 và OID là
iso.org.dod.internet.private.enterprises.cisco, hoặc 1.3.6.1.4.1.9.
Kiểu và Cú pháp (Syntax )
Kiểu dữ liệu của ñối tượng cần quản lý ñược ñịnh nghĩa trong ASN.1(
Abstract Syntax Notation One). ASN.1 chỉ ra cách dữ liệu ñược biểu diển và truyền
ñi giữa Manager và Agent. Các thông tin mà ASN.1 thông báo là ñộc lập với hệ
ñiều hành. ðiều này giúp một máy tính chạy WindowNT có thể liên lạc với một
máy chạy Sun SPARC dễ dàng[6].
Cú pháp ñược lấy từ chuẩn ASN.1 nhưng không phải tất cả các kiểu ñều
23
ñược hỗ trợ. SMIv1 chỉ hỗ trợ 5 kiểu nguyên thủy (primitive types) lấy từ ASN.1 và
6 kiểu ñịnh nghĩa thêm (defined types)[6].
Kiểu dữ liệu Mô tả
INTEGER
Một số 32 bit ñược sử dụng ñể xác ñịnh các kiểu liệt kê trong
ngữ cảnh của một ñối tượng quản lý. VD: trạng thái của một
cổng trên router có thể có các giá trị interger: 1(up), 2(down),
3(testing). Theo RFC1155
OCTET STRING
Một chuỗi số không hoặc nhiều octet (thường ñược gọi là byte)
thường ñược sử dụng ñể biểu diễn cho các chuỗi văn bản,
nhưng cũng ñôi khi ñược sử dụng ñể biểu diễn cho ñịa chỉ vật
lý
Counter
Một số 32-bit với giá trị nhỏ nhất là 0 và giá trị lớn nhất 232 - 1
(4294967295). Khi ñạt ñược giá trị lơn nhất, nó quay lại bắt ñầu
từ 0. Nó chủ yếu ñược sử dụng ñể theo dõi các thông tin như số
lượng octet gửi và nhận hoặc số lượng các lỗi trên một cổng
mạng.
OBJECT
IDENTIFIER
Một chuỗi dấu chấm thập phân biểu diễn một ñối tượng quản lý
trong cây ñối tượng. Ví dụ, 1.3.6.1.4.1.9 biểu diễn OID
enterprises riêng của Cisco System.
NULL Không ñược sử dụng trong SNMP.
SEQUENCE ðịnh nghĩa danh sách chứa 0 hoặc các kiểu dữ liệu ASN.1
khác.
SEQUENCE OF ðịnh nghĩa một ñối tượng quản lý ñược tạo ra từ kiểu
SEQUENCE
IpAddress Kiểu ñịa chỉ internet 32-bit (ipv4), gồm 4 octet liên tục.
NetworkAddress Giống như ñịa chỉ ip, nhưng có thể biểu diễn các kiểu ñịa chỉ
mạng khác.
Gauge
Kiểu số nguyên không âm 32-bit, có thể tăng hoặc giảm nhưng
không tăng quá giá trị tối ña 232 - 1. Tốc ñộ cổng mạng trên
24
router ñược ño bằng giá trị Gause.
TimeTicks
kiểu số nguyên từ 0- 232 - 1, chỉ khoảng thời gian trôi qua kể từ
một thời ñiểm nào ñó, tính bằng phần trăm giây. VD từ khi hệ
thống khởi ñộng ñến hiện tại là 1000 giây thì giá trị
sysUpTime=100000
Opaque
Cho phép bất kỳ một giá trị có kiểu bất kỳ, mã hóa theo quy
cách ASN.1 ñược ñóng thành từng OCTET-STRING.
Bảng 1.2.4.1 - Các kiểu dữ liệu SMIv1
Encoding
Mã hóa các ñối tượng quản lý thành các chuổi octet dùng BER (Basic
Encoding Rules). BER xây dựng cách mã hóa và giải mã ñể truyền các ñối tượng
qua các môi trường truyền như Ethernet.
1.2.4.2 MIB-II (RFC1213)
RFC1155 mô tả cách trình bày một tệp MIB như thế nào chứ không ñịnh
nghĩa các ñối tượng. RFC1213 là một chuẩn ñịnh nghĩa nhánh MIB nằm dưới
iso.org.dod.internet.mgmt.mib-2 (tất nhiên phải theo cấu trúc mà RFC1155 quy
ñịnh)[6].
RFC1156 là ñặc tả MIB chuẩn cho các thiết bị TCP/IP, ñược coi là Internet-
Standard Mib (MIB-I). RFC1213 là ñặc tả MIB chuẩn version 2, thường gọi là
MIB-II. Chú ý phân biệt MIB-I và MIB-II là các chuẩn ñặc tả ñịnh nghĩa của các
ñối tượng, còn SMIv1 và SMIv2 là ñặc tả cấu trúc của tập tin MIB. MIB-I và MIB-
II sử dụng cấu trúc của SMIv1[6].
MIB-II là một trong những MIB ñược hỗ trợ rộng rãi nhất. Nếu một thiết bị
ñược tuyên bố là có hỗ trợ SNMP thì hãng sản xuất phải chỉ ra nó hỗ trợ các RFC
nào, và thường là RFC1213. Nhiều người chỉ biết thiết bị của mình “có hỗ trợ
SNMP” nhưng không rõ hỗ trợ các RFC nào, khi dùng phần mềm giám sát SNMP
hỗ trợ RFC1213 ñể giám sát thiết bị nhưng không thu ñược kết quả. Lý do là phần
mềm thì hỗ trợ RFC1213 nhưng thiết bị thì không. Vị trí của MIB-II trong MIB như
trong hình 3[6]:
25
Các kiểu dữ liệu mới ñược ñịnh nghĩa trong MIB-II gồm :
Display String: kế thừa từ kiểu OCTET STRING nhưng chỉ bao gồm các ký
tự in ñược (printable characters) và dài không quá 255 ký tự.
Physical Address : giống kiểu OCTET STRING, ñược dùng ñể biểu diễn ñịa
chỉ vật lý của thiết bị.
Tên Kiểu, Cú
pháp
Mô tả
mib-2(1) Internet-standard mib version 2 (RFC1213)
OID : .1.3.6.1.2.1
system(1)
sysDescr(1)
DisplaySt
ring
Dòng văn bản mô tả node hiện ñang hỗ trợ
mib này, có thể bao gồm tên, version,
kiểu phần cứng, hệ ñiều hành, …
sysObjectID(2)
Object
identifier
ðịnh danh ñã ñược ñăng ký của hảng sản
xuất hệ thống. Giá trị này phải khó nhầm
lẫn và miêu tả ñược ñây là loại thiết bị gì
sysUpTime(3) TimeTick
s
Thời gian tính từ khi module quản trị mạng
của hệ thống khởi ñộng lại (kiểu
TimeTicks tính bằng phần trăm giây)
sysContact(4) DisplaySt
ring
Dòng văn bản chỉ ñịnh người cần liên lạc
nếu có
các vấn ñề ñối với hệ thống
sysName(5) DisplaySt
ring
Tên ñược gán cho node ñể quản lý
sysLocation(6) DisplaySt
ring
Vị trí vật lý ñặt node
26
sysServices(7) Integer
Chỉ ra node có thể hoạt ñộng ở các layer
nào của OSI. Giá trị của nó là tổng tất cả
các 2(Layer-1) với Layer là số lớp OSI. VD
một router hoạt ñộng ở lớp 3 thì giá trị này
sẽ là 2(3-1)=4
interfaces(2)
ifNumber(1) Integer Tổng số giao tiếp mạng hiện có trong hệ
thống
ifTable(2) Sequence Danh sách các thông tin của từng interface
ifEntry(1) ifEntry Một entry chứa các object mang thông tin
của một interace trong danh sách
ifIndex(1) integer Giá trị duy nhất của mỗi interface, giá trị
này chạy từ 1 ñến ifNumber, và không thay
ñổi ít nhất cho ñến khi hệ thống khởi ñộng
lại
ifDescr(2) DisplaySt
ring
Dòng text mang thông tin của một interface
fType(3)
Integer Kiểu interface, dựa vào giao thức lớp
physical/link của interface. VD :
ethernetCsmacd(6), fddi(15), e1(19),
atm(37), sonet(39), v35(45)
ifMtu(4)
Integer Kích thước của datagram lớn nhất có thể
truyền/nhận trên interface
ifSpeed(5)
Gauge Băng thông hiện tại của interface, tính bằng
bit per second
ifPhysAddress(6) Physical
Address
ðịa chỉ vật lý của interface
ifAdminStatus(7) Integer Trạng thái mong muốn của interface
ifOperStatus(8) Integer Trạng thái hoạt ñộng thực tế của interface
27
ifLastChange(9)
TimeTick
s
Giá trị của sysUpTime tại thời ñiểm
interface ñi vào trạng thái hoạt ñộng như
hiện tại
ifInOctets(10) Counter Tổng số octet ñã nhận trên interface
ifInUcastPkts(11
)
Counter Số gói unicast ñược ñưa ñến giao thức lớp
cao hơn
ifInNUcastPkts(1
2)
Counter Số gói nonunicast ñược ñưa ñến giao thức
lớpcao hơn (broadcast, multicast)
ifInDiscards(13)
Counter Số gói tin nhận ñược bị hủy (kể cả các
gói không bị lỗi) ñể ngăn không cho chúng
ñến tầng xử lý cao hơn, vd khi tràn bộ ñệm
nhận.
ifInErrors(14) Counter Số gói tin nhận ñược có chứa lỗi
ifInUnknownPro
tos(15)
Counter Số gói tin nhận ñược từ interface nhưng bị
discard vì nó thuộc giao thức không ñược
hỗ trợ
ifOutOctets(16) Counter Tổng số octet ñã truyền ra interface
ifOutUcastPkts(1
7)
Counter Tổng số gói tin unicast mà tầng giao thức
cao hơn yêu cầu truyền ra (kể cả các gói sẽ
bị discard)
ifOutNUcastPkts
(18)
Counter Tổng số gói tin non-unicast mà tầng giao
thức cao hơn yêu cầu truyền ra (kể cả các
gói sẽ bị discard)
ifOutDiscards(19
)
Counter Số gói tin cần truyền ra bị hủy (kể cả các
gói không bị lỗi) ñể ngăn không cho chúng
ñến tầng xử lý cao hơn, vd khi tràn bộ ñệm
phát
28
ifOutErrors(20) Counter Số gói tin không thể truyền ra do có lỗi
ifOutQLen(21) Gauge ðộ dài của hàng ñợi thông ñiệp truyền ñi
ifSpecific(22) Object
identifier
Tham chiếu ñến ñịnh nghĩa mib dành riêng
cho loại media của interface. VD nếu
interface thuộc
ethernet thì giá trị này chỉ ra tài liệu mô tả
cá object của riêng ethernet. Nếu node
không cung
cấp ñược thông tin này thì giá trị của
ifSpecific phải là .0.0
Bảng 1.2.4.2 - Mô tả MIB-II trong RFC1213
Sau khi các OID ñược ñịnh nghĩa, chúng ta mới thực sự ñịnh nghĩa ñối
tượng. mọi ñịnh nghĩa ñối tượng ñều có ñịnh dạng ñược mô tả trong RFC1212[6].
<name> OBJECT-TYPE
SYNTAX <datatype>
ACCESS <either read-only, read-write, write-only, or not-accessible>
STATUS <either mandatory, optional, or obsolete>
DESCRIPTION"Textual description describing this particular
managed object."::= { <Unique OID that defines this object> }
Ví dụ ñịnh nghĩa cho object ifTable trong RFC1213 như sau:
ifTable
OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "A list of interface entries. The number of entries is
given by the value of ifNumber." ::= { interfaces 2 }
OBJECT-TYPE bao gồm các trường :
29
- SYNTAX : kiểu của ñối tượng, một trong các primitive types hoặc defined
types ở trên.
- ACCESS : mức truy nhập của ñối tượng, mang một trong các giá trị read-
only, read-write, write-only, not-accessible.
- STATUS : mang một trong các giá trị mandatory (bắt buộc phải hỗ trợ),
optional (có thể hỗ trợ hoặc không), obsolete (ñã bị thay thế). Một Agent nếu
hỗ trợ một chuẩn MIB nào ñó thì bắt buộc phải hỗ trợ tất cả các ñối tượng có
status=mandatory, còn status=optional thì có thể hỗ trợ hoặc không.
- DESCRIPTION : dòng giải thích cho ý nghĩa của ñối tượng.
Cấu trúc của MIB là dạng cây, ñể xác ñịnh OID của một ñối tượng ta phải ñi từ
gốc ñến ñối tượng ñó[6].
Ví dụ 1: bandwidth của interface thứ 3 trên thiết bị thì có OID là
.1.3.6.1.2.1.2.2.1.5 tương ñương
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifSpeed.3
Chú ý: mặc dù MIB-II ñã quy ñịnh index của từng interface phải liên tục và chạy từ
1 ñến ifNumber, nhưng trong thực tế nhiều thiết bị không ñặt index liên tục mà ñặt
theo cách riêng ñể dễ quản lý. Do ñó ñối với C2950 thì interface thứ 3 có index là 3,
nhưng ñối với thiết bị khác thì interface thứ 3 có thể có index khác 3, thậm chí là số
rất lớn. Chẳng hạn một switch có nhiều card, mỗi card có 12 port thì port1-card1 có
index là 101, port12-card1 có index là 112, port1-card2 có index là 201[6].
1.2.4.3 SMIv2
SMIv2 mở rộng cây ñối tượng SMI bằng cách bổ sung nhánh snmpv2 vào
cây con internet, bổ sung một vài kiểu dữ liệu mới và tạo ra một số thay ñổi khác.
Hình 4 biểu diễn cách các ñối tượng snmpv2 tạo thành nhánh mới với OID là
1.3.6.1.6.3.1.1, hoặc
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.[6]
30
Hình 1.2.4.3 - Cấu trúc SMIv2
Kiểu dữ liệu Mô tả
Integer32 Giống như INTEGER.
Counter32 Giống như Counter.
Gauge32 Giống như Gauge.
Unsigned32 Biểu diễn giá trị thập phân trong khoảng 0 tới 232 – 1
Counter64 Tương tự Counter32, nhưng giá trị tối thiểu là
18,446,744,073,709,551,615. Counter64 là ý tưởng khắc phục tình
huống khi một Counter32 có thể trở về 0 quá nhanh.
BITS Một dãy các bit không âm.
Bảng 1.2.4.3.1 – ðịnh nghĩa một số kiểu dữ liệu mới trong SMIv2.
ðịnh nghĩa một ñối tượng trong SMIv2 ñược thay ñổi sáng sủa hơn SMIv1.
Có một số tùy chọn các lĩnh vực mới, ñem lại cho ta kiểm soát nhiều hơn cách ñối
tượng ñược truy cập như thế nào, cho phép bạn gia tăng thêm bảng bằng cách thêm
các cột, và cho phép ta mô tả tốt hơn. Sau ñây là cú pháp của một ñịnh nghĩa một
ñối tượng trong SMIv2. Nhưng thay ñổi ñược tô ñậm[6]:
31
<name> OBJECT-TYPE
SYNTAX <datatype>
UnitsParts <Optional, see below>
MAX-ACCESS <See below>
STATUS <See below>
DESCRIPTION
"Textual description describing this particular managed object."
AUGMENTS { <name of table> }
::= { <Unique OID that defines this object> }
ðịnh nghĩa
Cải tiến
Mô tả
UnitsParts
Một mô tả dạng văn bản của các ñơn vị(giây, mini giây, …) ñược
sử dụng ñể biểu diễn ñối tượng.
MAX-
ACCESS
Một kiểu truy nhập của OBJECT-TYPE có thể là MAX-ACCESS
trong SNMPv2. Các tùy chọn hợp lệ cho MAX-ACCESS là read-
only, read-write, read-create, not-accessible, và accessible-for-
notify.
STATUS
Mệnh ñề này ñược mở rộng ñể cho phép các từ khóa current,
obsolete, và deprecated. current trong SNMPv2 thì giống như
mandatory trong SNMPv1 MIB.
AUGMENTS
Trong một số trường hợp, nó rất hữu ích ñể thêm một cột vào một
bảng hiện có. Mệnh ñề AUGMENTS cho phép bạn mở rộng một
bảng bằng cách thêm một hoặc nhiều cột, ñược biểu diễn bằng một
số ñối tượng khác. mệnh ñề này yêu cầu tên của bảng ñối tượng sẽ
tăng thêm.
Bảng 1.2.4.3.2 -Những cải tiến ñịnh nghĩa ñối tượng trong SMIv2
SMIv2 ñịnh nghĩa một kiểu trap mới ñược gọi là NOTIFICATION-TYPE
(sẽ ñược mô tả mục sau). SMIv2 cũng giới thiệu các quy ước mới về dạng văn bản
32
cho phép các ñối tượng quản lý ñược tạo ra bằng cách trừu tượng hơn. RFC2579
ñịnh nghĩa quy ước về văn bản ñược sử dụng trong SNMPv2, ñược liệt kê trong
bảng 0.3 dưới ñây[6]:
Quy ước Mô tả
DisplayString
Một chuỗi các ký tự NVT ASCII. Một DisplayString có thể có
ñộ dài lớn hớn 255 ký tự.
PhysAddress Một ñịa chỉ mức vật lý, biểu diễn như một OCTET STRING.
MacAddress
ðịnh nghĩa một ñịa chỉ truy nhập phương tiện truyền thông do
IEEE 802 (the standard for LANs) theo thứ tự canonical(ñịa chỉ
phải ñược biểu diễn các bít ñầu tiên bởi ít nhất một số bít cần
thiết). (Ngày nay thường là ñịa chỉ Ethernet) ñịa chỉ này ñược
biểu diễn bằng 6 octet.
TruthValue ðịnh nghĩa hai giá trị true và false.
TestAndIncr
ðược sử dụng ñể theo dõi hai trạm quản lý cùng sửa một ñối
tượng quản lý tại cùng một thời ñiểm.
AutonomousType
Một OID ñược sử dụng ñể ñịnh nghĩa một cây con với bổ sung
các ñịnh nghĩa MIB liên quan
VariablePointer
Một con trỏ trỏ tới một ñại diện ñối tượng ñặc biệt, giả sử
ifDescr với cổng 3. Trong trường hợp này, VariablePointer có
OID là ifDescr.3.
RowPointer
Một con trỏ trỏ tới một dòng trong một bảng. Ví dụ, ifIndex.3
trỏ tới dòng thứ 3 trong bảng ifTable.
RowStatus
ðược sử dụng ñể quản lý việc tạo và xóa các dòng trong một
bảng, vì bản thân SNMP không có cách làm các thao tác trên.
RowStatus có thể theo dõi trạng thái của một dòng trong một
bảng cũng như nhận các lệnh ñể tạo và xóa các dòng. Quy ước
văn bản này ñược thiết kế ñể cải tiến tính toàn vẹn khi có nhiều
bộ phận quản lý cùng cập nhật dòng. Các kiểu ñược liệt kê sau
33
ñây ñịnh nghĩa các lệnh và các biến trạng thái: active(1),
notInService(2), notReady(3), createAndGo(4),
createAndWait(5), và anddestroy(6).
TimeStamp
ðo lượng thời gian trôi qua giữa thời gian hoạt ñộng hệ thống
của thiết bị và một số sự kiện.
TimeInterval
Giai ñoạn thời gian biểu diễn dưới dạng % giây. Nó có thể nhận
giá trị trong khoảng 0-2147483647.
DateAndTime Một OCTET STRING ñược sử dụng ñể biểu diễn thông tin thời
gian.
StorageType
ðịnh nghĩa kiểu bộ nhớ mà một agent sử dụng. Các giá trị có
thể là other(1), volatile(2), nonVolatile(3), permanent(4), và
readOnly(5).
Tdomain Ký hiệu một loại dịch vụ truyền tải.
Taddress Ký hiệu ñịa chỉ dịch vụ truyền tải. Taddress ñược ñịnh nghĩa từ
1-255 octet.
Bảng 1.2.4.3.3 - Các quy ước về văn bản cho SMIv2
1.3 ðịnh dạng thông ñiệp và các phương thức vận hành
Các phiên bản SNMP khác nhau một chút ở ñịnh dạng thông ñiệp và phương
thức hoạt ñộng. Hiện nay SNMPv1 và 2 là phổ biến nhất do có nhiều thiết bị tương
thích nhất và có nhiều phần mềm hỗ trợ nhất. Trong khi ñó chỉ có một số thiết bị và
phần mềm hỗ trợ SNMPv3.
1.3.1 ðịnh dạng thông ñiệp của SNMPv1 và 2
1.3.1.1 ðịnh dạng tổng quát.
Version Community PDU Hình 1.3.1.1 - ðịnh dạng tổng quát [5]
Tên
trường
Kiểu
DL
Kích cỡ
(bytes)
Mô tả
Version Integer 4 Version Number: Mô tả phiên bản SNMP của
thông ñiệp; với SNMPv1 thì giá trị này là 0,
34
với SNMPv2 là 1.
Community Octet
String
Variable Community String: Mật khẩu sử dụng ñể xác
thực giữa người gửi và người nhận thông ñiệp
này
PDU — Variable Protocol Data Unit: Giao thức ðơn vị dữ
liệu ñược sử dụng ñể giao tiếp, nội dung của
thông ñiệp.
Bảng 1.3.1.1 - ðịnh dạng thông ñiệp[4]
1.3.1.2 ðịnh dạng PDU
Tất cả các PDU trong SNMP V1,2 ñều có ñịnh dạng giống nhau, riêng PDU
của thông ñiệp Trap thì khác. Ngữ nghĩa chính xác trong mỗi trường của PDU dựa
trên thông ñiệp cụ thể. Ví dụ, trường ErrorStatus chỉ có nghĩa trong thông ñiệp trả
lời không có trong thông ñiệp yêu cầu, và các giá trị ñối tượng sử dụng cũng khác
nhau trong các thông ñiệp yêu cầu và thông ñiệp trả lời [4].
1.3.1.2.1 ðịnh dạng PDU chung cho các phương thức
Các bảng và hình dưới biểu diễn ñịnh dạng chung cho hầu hết các PDU
SNMPv1,2: GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU và
GetResponse-PDU[4].
PDU type RequestID ErrorStatus Errorindex Variable Bindings
Hình 1.3.1.2.1 - ðịnh dạng chung PDU
Tên
trường
Kiểu DL Kích cỡ
(bytes)
Mô tả
PDU Type Integer
(Enumerated)
4
Xem bảng 8
Request
ID
Integer 4 Request Identifier: Một số ñược sử dụng
ñể khớp nối giữa ñịnh danh yêu cầu và trả
lời. Nó ñược sinh ra bới thiết bị gửi yêu
cầu và coppy vào trong trường này trong
35
GetResponse-PDU của thông ñiệp trả lời.
Error
Status
Integer
(Enumerated)
4 Xem bảng 9
Error
Index
Integer 4 Error Index: Khi Error Status khác 0,
trương này chứa một con trỏ chỉ rõ ñối
tượng sinh ra lỗi, luôn luôn =0 trong thông
ñiệp yêu cầu.
Variable
Bindings
Variable Variabl
e
Variable Bindings: Một tập hợp các cặp
tên-giá trị xác ñịnh các ñối tượng MIB
trong PDU, và trong trường hợp của một
SetRequest-PDU hoặc GetResponse-PDU,
có chứa các giá trị của chúng.
Bảng 1.3.1.2.1 - ðịnh dạng chung PDU
1.3.1.2.2 Kiểu PDU và trạng thái lỗi
PDU[4] (các giá trị kiểu PDU của version 1 tương ứng từ 0-3):
Giá trị PDU Type
PDU Type
0 GetRequest-PDU
1 GetNextRequest-PDU
2 GetResponse-PDU
3 SetRequest-PDU
4 Không sử dụng(Trap-PDU trong SNMPv1)
5 GetBullRequest-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]:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeather xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-
encoding/"> <zipcode xsi:type="xsd:string">10016</zipcode>
</ns1:getWeather> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
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]:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body><ns1:getWeatherResponse
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-
encoding/"> <return xsi:type="xsd:int">65</return>
</ns1:getWeatherResponse>
/SOAP-ENV:Body> </SOAP-ENV:Envelope>
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ử <Envelope> bắt buộc, trong ñó bao gồm một phần tử <Body>
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(http://schemas.xmlsoap.org/soap/envelope/), mã hóa dữ liệu bằng các
XML schema (http://www.w3.org/2001/XMLSchema-instance và
http://www.w3.org/2001/XMLSchema), 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ử <Body> ñó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à <getWeather> 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ử <zipcode>, ñượ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ử <Envelop> và <Body>, và 4 XML namespace. Tuy
nhiên phần tử <Body> bao gồm một phần tử <getWeatherResponse>, 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ử <Envelope>. Ví dụ: <SOAP-ENV:Envelope
xmlns:SOAP-NV=http://schemas.xmlsoap.org/soap/envelope/.
SOAP 1.1 namespace có URI là http://schemas.xmlsoap.org/soap/envelope/,
trong khi ñó của SOAP 1.2 là http://www.w3.org/2001/09/soap-envelope. 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:
<SOAP-ENV:Header><ns1:PaymentAccount xmlns:ns1="urn:ecerami" SOAP-ENV:
mustUnderstand="true"> orsenigo473 </ns1:PaymentAccount > </SOAP-ENV:Header>.
2.3.3 Body
Phần tử Body là bắt buộc cho tất cả các thông ñiệp SOAP. Như chúng ta ñã
biết, sử dụng của các phần tử Body bao gồm cả RPC Request và Response[8].
55
2.3.4 Fault
Trong trường hợp một lỗi xảy ra, phần tử <Body> sẽ bao gồm phần tử
<Fault>. Phần tử con lỗi ñược ñịnh nghĩa trong bảng 16 gồm có <faultCode>,
<faultString>, <faultActor>, và chi tiết các phần tử. Các mã lỗi SOAP ñược ñịnh
nghĩa trước trong bảng 17. Dưới ñây là một ví dụ về lỗi, máy trạm yêu cầu phương
thức tên là ValidateCreditCard, nhưng dịch vụ không hỗ trợ. Dưới ñây là một yêu
cầu máy trạm bị lỗi, và máy chủ trả về một phản hồi SOAP[8].
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
<faultstring xsi:type="xsd:string">
Failed to locate method (ValidateCreditCard) in class
(examplesCreditCard) at /usr/local/ActivePerl-5.6/lib/
site_perl/5.6.0/SOAP/Lite.pm line 1555.
</faultstring>
</SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Tên phần tử Mô tả
faultCode Mã xác ñịnh lớp xảy ra lỗi
faultString Mô tả chi tiết lỗi ñể người quản trị có thế hiểu ñược.
faultActor Chỉ rõ bộ phận nào là nguyên nhân xảy ra lỗi
Detail Mang thông ñiệp lỗi của ứng dụng ñặc biệt. có thể có phần tử con
bên trong phần tử này
Bảng 2.3.4.1 - Mô tả các phần tử con trong phần tử fault
Tên Mô tả
SOAP-ENV:VersionMismatch Chỉ rõ phần tử Envelope có một namespace
không hợp lệ
SOAP-ENV:MustUnderstand Người nhận không thể xử lý ñược Header
SOAP-ENV:Client Yêu cầu phía máy trạm lỗi
56
SOAP-ENV:Server Máy chủ không thể xử lý yêu cấu của máy trạm
Bảng 2.3.4.2 - Mô tả các giá trị trong phần tử faultCode
2.3.5 SOAP Encoding
SOAP bao gồm một tập các quy tắc dựng sẵn ñể mã hóa các kiểu dữ liệu.
Cho phép các thông ñiệp SOAP chỉ ra các kiểu dữ liệu cụ thể như Integer, float,
double, mảng. Hầu hết các quy tắc mã hóa ñược thực thi trực tiếp bởi công cụ
SOAP, vì vậy ta không nhìn thấy. Tuy nhiên khi debug một ứng ta vẫn phải hiểu
những cơ sở mã hóa của SOAP[8].
Các kiểu dữ liệu SOAP ñược chia thành hai loại: vô hướng và phức hợp.
Kiểu vô hướng chứa chính xác một giá trị, ví dụ như tên họ, giá, mô tả sản phẩm.
Kiểu phức hợp chứa nhiều giá trị, ví dụ như hóa ñơn mua hàng hoặc danh sách giá
cổ phiếu. Kiểu phức hợp ñược chia thành các kiểu mảng và cấu trúc. Mảng chứa
nhiều giá trị, nhưng mỗi phần tử ñược quy ñịnh bởi tên truy nhập. Thông tin về kiểu
mã hóa cho các thông ñiệp SOAP thiết lập qua thuộc tính SOAP-
ENV:encodingStyle. ðể sử dụng mã hóa SOAP 1.1, sử dụng giá trị[8].
http://schemas.xmlsoap.org/soap/encoding/.
ðể sử dụng mã hóa SOAP 1.2, sử dụng giá trị.
http://www.w3.org/2001/09/soap-encoding.
2.3.5.1 Kiểu vô hướng
Với kiểu vô hướng, SOAP thông qua tất cả các kiểu ñơn giản dựng sẵn ñược
xác ñịnh bởi ñặc tả XML Schema. Bao gồm các kiểu string, float, double, integer.
Xem bảng dưới[8].
57
Bảng 2.3.5.1 - Các kiểu dựng sẵn
Như trong Ví dụ 2.2.1.2 trên ta thấy thuộc tính xsi:type thiết lập là xsd:int, xác
ñịnh giá trị trả về là giá trị kiểu int. ðặc tả SOAP cung cấp vài tùy chọn ñể chỉ ñịnh
kiểu dữ liệu cho phần tử XML cụ thể. Tùy chọn thứ nhất ñể xác ñịnh một thuộc tính
xsi:type cho mỗi phần tử. Thứ hai ñể lưu trữ thông tin kiểu dữ liệu trong một XML
Schema bên ngoài hoặc thậm trí là tài liệu con người có thể hiểu ñược. Các công cụ
SOAP có thể tự ñộng thêm hoặc bỏ qua thuộc tính xsi:type trong khi khai báo phần
tử[8].
58
2.3.5.2 Kiểu phức hợp
Các mảng SOAP có một tập hợp các quy tắc rất rõ ràng, nó yêu cầu phải chỉ
rõ cả kiểu phần tử và kích cỡ mảng. SOAP cũng hỗ trợ mảng nhiều chiều, nhưng
không phải tất cả các triển khai SOAP hỗ trợ chức năng nhiều chiều(tùy thuộc vào
công cụ triển khai SOAP ).
ðể tạo một mảng ta phải chỉ rõ thuộc tính xsi:type của mảng. Mảng cũng bao
gồm thuộc tính arrayType. Thuộc tính ñược yêu cầu ñể xác ñịnh khiểu dữ liệu cho
các phần tử của mảng và số chiều của mảng. ví dụ: khai báo mảng 1 chiều với kích
cỡ 10, kiểu dữ liệu là double arrayType="xsd:double[10]". Hoặc khai bảo mảng hai
chiều kiểu dữ liệu string và kích cỡ mỗi chiều ñều là 5 phần tử
arrayType="xsd:string[5,5]" [8].
Dưới ñây là ví dụ một phản hồi SOAP với một mảng với các giá trị kiểu
double
<SOAP-ENV:Body>
<ns1:getPriceListResponse
xmlns:ns1="urn:examples:pricelistservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
<return xmlns:ns2="http://www.w3.org/2001/09/soap-encoding"
xsi:type="ns2:Array" ns2:arrayType="xsd:double[2]">
<item xsi:type="xsd:double">54.99</item>
<item xsi:type="xsd:double">19.99</item>
</return>
</ns1:getPriceListResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Chú ý: khi arrayType ñặt là xsd:double[2] thì mỗi phần tử trong mảng phải ñược
chỉ rõ trong phần tử item như trên. Ngược lại với mảng, cấu trúc chứa nhiều giá trị,
nhưng mỗi phần tử ñược xác ñịnh với duy nhất một phần tử truy nhập. Ví dụ, xét
một mục trong bảng các sản phẩm thì cấu trúc mô tả mục ñó có thể chứa
59
productSKU, productName, mô tả và giá. Dưới ñây là cấu trúc biểu diễn thông ñiệp
SOAP[8].
<SOAP-ENV:Body>
<ns1:getProductResponse
xmlns:ns1="urn:examples:productservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
<return xmlns:ns2="urn:examples" xsi:type="ns2:product">
<name xsi:type="xsd:string">Red Hat Linux</name>
<price xsi:type="xsd:double">54.99</price>
<description xsi:type="xsd:string">Red Hat Linux Operating System
</description>
<SKU xsi:type="xsd:string">A358185</SKU>
</return>
</ns1:getProductResponse>
</SOAP-ENV:Body>
Mỗi phần tử trong cấu trúc ñược xác ñịnh với một tên truy nhập duy nhất. Ví
dụ, thông ñiệp trên bao gồm 4 phần tử truy nhập, name, price, description, và SKU.
Mỗi phần tử có thể có một kiểu dữ liệu riêng; như name có kiểu là string, price là có
kiểu là double.
2.3.6 Literal Encoding
Không cần thiết phải sử dụng mã hóa kiểu mẫu SOAP. Thực tế, thỉnh thoảng
ta muốn bỏ qua các quy tắc mã hóa SOAP và nhúng một tài liệu XML trực tiếp vào
thông ñiệp SOAP. ðể làm như vậy ta phải tham chiếu tới một kiểu mã hóa Literal
XML, và phải chỉ rõ mã hóa kiểu mẫu Literal XML. Trong Apache SOAP, mã hóa
kiểu mẫu Literal XML ñược chỉ rõ với namespace http://xml.apache.org/xml-
soap/literalxml. Ví dụ, dưới ñây là tùy chọn thứ hai về mã hóa thông tin sản phẩm
trong mục 2.3.5.2. Sẽ ñơn giản hơn nếu thay vì mã hóa sản phẩm thành cấu trúc
SOAP, dữ liệu ñược mã hóa như một tài liệu XML mã hóa kiểu mẫu Literal[8].
60
<SOAP-ENV:Body>
<ns1:getProductResponse
xmlns:ns1="urn:examples:XMLproductservice"
SOAP-ENV:encodingStyle= "http://xml.apache.org/xml-soap/literalxml">
<return>
<product sku="A358185">
<name>Red Hat Linux</name>
<description>Red Hat Linux Operating System</description>
<price>54.99</price></product>
</return>
</ns1:getProductResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
2.3.7 Truyền tải SOAP qua HTTP
SOAP không phân biệt bất kỳ giao thức truyền tải nào. Trên thực tế, SOAP
có thể ñược truyền tải qua SMTP, FTP, MQSeries của IBM, Microsoft Message
Queue(MMQ). Tuy nhiên, ñặc tả SOAP chỉ mô tả chi tiết về HTTP và nó là giao
thức truyền tài SOAP phổ biến. Các yêu cầu SOAP ñược gửi qua yêu cầu HTTP và
các phản hồi SOAP ñược trả về trong nội dung của phản hồi HTTP. Mặc dù các yêu
cầu SOAP có thể ñược gửi qua HTTP GET, nhưng ñặc tả SOAP chỉ mô tả chi tiết
HTTP POST(HTTP POST ñược ưu tiên hơn bởi vì hầu hết các máy chủ ñặt yêu cầu
hạn chế ký tự trên các yêu cầu GET). Thêm nữa, cả hai yêu cầu và phản hồi HTTP
phải ñược thiết lập kiểu nội dung là text/xml. Như một yêu cầu bổ sung, các máy
trạm phải chỉ rõ một SOAP Action header. SOAP Action header là một URI ñược
sử dụng ñể chỉ ra mục ñích của yêu cầu. ðiều này làm nó có xác ñịnh nhanh bản
chất của một yêu cầu SOAP, không cần phải kiểm tra nội dung thông ñiệp
SOAP[8].
ðặc tả SOAP yêu cầu máy trạm phải cung cấp một SOAP Action header,
nhưng giá trị thực của nó bị phụ thuộc triển khải trên máy chủ SOAP. ví dụ, ñể truy
61
nhập dịch vụ AltaVista BabelFish Translation ñược cài ñặt bằng Xmethods, bạn
phải chỉ rõ urn:xmethodsBabelFish#BabelFish như một SOAP Action header. Thậm
trí nếu máy chủ không yêu cầu một SOAP Action header ñầy ñủ, máy trạm phải chỉ
rõ một chuỗi trống hoặc ñặt giá trị rỗng. Ví dụ:
SOAPAction: ""
SOAPAction:
Ví dụ ñơn giản về yêu cầu ñược gửi qua HTTP tới dịch vụ XMethods Babelfish
Translation[8].
POST /perl/soaplite.cgi HTTP/1.0
Host: services.xmethods.com
Content-Type: text/xml; charset=utf-8
Content-Length: 538
SOAPAction: "urn:xmethodsBabelFish#BabelFish"
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:BabelFish xmlns:ns1="urn:xmethodsBabelFish"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<translationmode xsi:type="xsd:string">en_fr</translationmode>
<sourcedata xsi:type="xsd:string">Hello, world!</sourcedata>
</ns1:BabelFish>
</SOAP-ENV:Body> </SOAP-ENV:Envelope>
Chú ý: Content-Type, SOAPAction, và phương thức BabeFish yêu cầu hai tham số
kiểu chuỗi. Chế ñộ thông dịch en_fr sẽ thông dịch từ tiếng Anh sang tiếng Pháp.
ðây là phản hồi từ Xmethods:
62
HTTP/1.1 200 OK
Date: Sat, 09 Jun 2001 15:01:55 GMT
Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2
SOAPServer: SOAP::Lite/Perl/0.50
Cache-Control: s-maxage=60, proxy-revalidate
Content-Length: 539 Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope …> <SOAP-ENV:Body>
<namesp1:BabelFishResponse xmlns:namesp1="urn:xmethodsBabelFish">
<return xsi:type="xsd:string">Bonjour, monde!</return>
</namesp1:BabelFishResponse>
</SOAP-ENV:Body> </SOAP-ENV:Envelope>
Các SOAP response ñược phân phối qua HTTP bắt buộc phải theo các mã trạng
thái giống HTTP, ví dụ trạng thái 200 OK xác ñịnh là thành công, 500 là trạng thái
lỗi trong máy chủ và phản hồi SOAP gồm có phần tử Fault.
2.4 Service Description: WSDL
WSDL là một ñặc tả ñịnh nghĩa phương pháp mô tả dịch vụ Web trong một ngữ
pháp XML chung, nó thường ñược lưu dưới dạng file *.wsdl, ñược máy trạm sử
dụng mỗi khi kết nối với dịch vụ Web. WSDL mô tả 4 thông tin quan trọng của
dịch vụ Web[8]:
Thông tin mô tả tất cả các Hàm ñược công bố.
Thông tin kiểu dữ liệu cho tất cả các thông ñiệp yêu cầu và phản hồi.
Thông tin về giao thức truyền tải ñược sử dụng.
Thông tin ñịa chỉ xác ñịnh dịch vụ cụ thể.
WSDL không nhất thiết phải gắn liền với một hệ thống thông ñiệp XML cụ thể,
nhưng nó bao gồm phần mở rộng dựng sẵn cho mô tả các dịch vụ SOAP.
Ví dụ 2.4 cung cấp một file WSDL ñơn giản. File này mô tả các giao diện công
bố dịch vụ thông tin thời tiết ở trên. Có hai ñiểm chính cần quan tâm.
63
ðầu tiên, Các phần tử <message> xác ñịnh các thông ñiệp XML riêng biệt
ñược chuyển giao giữa các máy tính. Trong trường hợp này, chúng ta có một
getWeatherRequest và getWeatherResponse.
Thứ hai, các phần tử <service> xác ñịnh rằng dịch vụ sẵn sàng dưới dạng
SOAP tại http://localhost:8080/soap/servlet/rpcrouter[8].
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="WeatherService"
targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="getWeatherRequest">
<part name="zipcode" type="xsd:string"/>
</message>
<message name="getWeatherResponse">
<part name="temperature" type="xsd:int"/>
</message>
<portType name="Weather_PortType">
<operation name="getWeather">
<input message="tns:getWeatherRequest"/>
<output message="tns:getWeatherResponse"/>
</operation>
</portType>
<binding name="Weather_Binding" type="tns:Weather_PortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getWeather"> <soap:operation soapAction=""/>
<input>
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
64
namespace="urn:examples:weatherservice" use="encoded"/>
</input>
<output>
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice" use="encoded"/>
</output> </operation> </binding>
<service name="Weather_Service">
<documentation>WSDL File for Weather Service</documentation>
<port binding="tns:Weather_Binding" name="Weather_Port">
<soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port> </service> </definitions>
Ví dụ 2.4 : Mô tả một file *.WSDL
2.4.1 Các thành phần trong file WSDL
ðặc tả WSDL chia làm 6 phàn tử chính[8]:
definitions: Phần tử <definition> phải là phần tử gốc của tài liệu WSDL. Nó
ñịnh nghĩa tên của dịch vụ Web, khai báo nhiều namespace ñược sử dụng
trong suốt phần còn lại của tài liệu, và chứa tất cả các phần tử dịch vụ ñược
mô tả ở ñây.
Types: Phần tử <types> mô tả tất cả các kiểu dữ liệu ñược sử dụng giữa máy
trạm và máy chủ. WSDL không bị ràng buộc vào một hệ thống duy nhất,
nhưng nó mặc ñịnh sử dụng ñặc tả W3C XML Schema. Nếu dịch vụ chỉ sử
dụng các kiểu dựng sẵn, ñơn giản của XML Schame, như string, integer, thì
phần tử types không cần thiết phải có.
Message: Phần tử <message> mô tả một thông ñiệp một chiều, nó là một
thông ñiệp yêu cầu hoặc phản hồi. Nó ñịnh nghĩa tên của thông ñiệp và bao
gồm không hoặc có thêm phần tử <part> có thể tham chiếu tới các tham số
hoặc giá trị mà thông ñiệp trả về.
portType: Phần tử <portType> bao gồm nhiều phần tử <message> dưới hình
thức hoàn toàn một chiều hoặc thao tác di chuyển vòng tròn. Ví du, một
65
portType có thể kết hợp một thông ñiệp yêu cầu và một thông ñiệp phản hồi
trong một thao tác Request/Response ñơn lẻ, ñây là cách thông thường nhất
ñược sử dụng trong các dịch vụ SOAP. Chú ý rằng một port Type có thể (và
thường xuyên) ñịnh nghĩa nhiều thao tác.
Binding: Phần tử <binding> mô tả các chi tiết cụ thể một dịch vụ sẽ ñược
thực thi trên môi trường mạng. WSDL gồm có các ñịnh nghĩa mở rộng dựng
sẵn về các dịch vụ SOAP, và thông tin cụ thể của SOAP tại ñây.
Service: Phần tử <service> ñịnh nghĩa ñịa chỉ thực hiện một dịch vụ cụ thể.
Thông thường nhất là một URL ñể thực hiện dịch vụ SOAP.
Hình 2.4.1 - ðặc tả WSDL
Ngoài 6 phần tử chính, ñặc tả WSDL cũng ñịnh nghĩa các phần tử phụ trợ:
documentation: Phần tử <documentation> ñược sử dụng ñể cung cấp tài liệu
mà con người có thể hiểu và có thể ñược ñưa vào trong bất kỳ một phần tử
WSDL khác.
Import:Phần tử <import> ñược sử dụng ñể nhập khẩu các tài liệu WSDL
khác hoặc các XML Schema. ðiều này cho phép các tài liệu WSDL mô-dun
hóa hơn. Ví dụ, hai tài liệu WSDL có thể cùng nhập khẩu các phần tử cơ bản
và chưa bao gồm các phần tử dịch vụ của nó ñể tạo ra cùng một dịch vụ trên
hai ñịa chỉ vật lý.
2.4.2 Kiểu dữ liệu XML Schema.
ðể một máy trạm SOAP giao tiếp hiệu quả với một máy chủ SOAP, máy
trạm và máy chủ phải thống nhất một hệ thống kiểu dữ liệu. Mặc ñịnh, XML 1.0
không cung cấp một hệ thống kiểu dữ liệu. Ngược lại, mọi ngôn ngữa lập trình cung
66
cấp một vài cơ sở ñể khai báo các kiểu dữ liệu, như integer, float, double và string.
Một trong những thách thức lớn nhất trong việc xây dựng dịch vụ Web là tạo một
hệ thống kiểu dữ liệu chung có thể ñược sử dụng bởi tập hợp ña dạng các ngôn ngữ
lập trình chạy trên tập hợp ña dạng các hệ ñiều hành[8].
WSDL không có mục ñích tạo ra kiểu dữ liệu chuẩn cho XML. Trong thực
tế, WSDL ñược ñặc tả một cách mềm dẻo nhất và nó không bị ràng buộc với bất kỳ
một hệ thống kiểu dữ liệu nào. Tuy nhiên, WSDL các kiểu ñược ñặc tả mặc ñịnh
bởi W3C XML Schema. ðặc tả XML Schema hiện nay cũng ñược sử dụng rộng rãi
nhất ñể ñặc tả kiểu dữ liệu[8].
Bảng 2.4.2 - Danh sách các kiểu dữ liệu dựng sẵn trong XML Schema
Có hai vấn ñề quan trọng cần xem xét ở ñây:
67
Thứ nhất, ñặc tả XML Schema gồm có một hệ thống kiểu dữ liệu cơ bản ñể
mã hóa hầu hết các kiểu dữ liệu. Hệ thống kiểu này bao gồm một danh sách dài các
kiểu ñơn giản dựng sẵn, như string, float, integer, double, time, date, như bảng trên.
Nếu ứng dụng có sử dụng những kiểu ñơn giản ñó, thì không cần phải thêm vào
WSDL phần tử types, và file WSDL sẽ hết sức ñơn giản.
Thứ hai, ñặc tả XML Schema cung cấp một cơ sở ñể tạo mới các kiểu dữ
liệu. ðiều này rất quan trọng nếu muốn tạo các kiểu dữ liệu dựa trên những gì ñã
ñược ñịnh nghĩa trong lược ñồ. Ví dụ, một dịch vụ có thể trả về một mảng các giá
trị có kiểu float hoặc một ñối tượng phức tạp hơn như bảng giá cổ phiếu chứa các số
liệu high, low, và khối lượng của một cổ phiếu cụ thể. Mặc dù dịch vụ dựa trên các
kiểu dữ liệu ñơn giản của XML Schema, ta vẫn phải khai báo một kiểu dữ liệu mới
trong phần tử types của WSDL.
Ví dụ khai báo kiểu dữ liệu mới là mảng trong một file WSDL ñặc tả về dịch
vụ cung cấp bảng giá chứng khoán[8]:
<types> <…. targetNamespace="http://www.ecerami.com/schema" ….>
<complexType name="ArrayOfString">
<complexContent> <restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="string[]"/>
</restriction> </complexContent> </complexType>
<complexType name="ArrayOfDouble">
<complexContent> <restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="double[]"/>
</restriction> </complexContent> </complexType> </schema>
</types>
<message name="PriceListRequest">
<part name="sku_list" type="xsd1:ArrayOfString"/>
</message> <message name="PriceListResponse">
<part name="price_list" type="xsd1:ArrayOfDouble"/> </message>
68
Ví dụ khai báo kiểu dữ liệu mới phức tạp hơn:
<types> <xsd:schema targetNamespace="http://www.ecerami.com/schema"
xmlns="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="product">
<xsd:sequence> <xsd:element name="name" type="xsd:string"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="price" type="xsd:double"/>
<xsd:element name="SKU" type="xsd:string"/>
</xsd:sequence></xsd:complexType> </xsd:schema> </types>
2.5. Service Discovery: UDDI
UDDI hiện tại biểu diễn tầng tìm kiếm trong chồng giao thức của dịch vụ
Web. Nguồn gốc ban ñầu UDDI ñược tạo bởi Microsoft, IBM và Ariba, biểu diễn
một ñặc tả kỹ thuật công bố và tìm kiếm thương mại của các dịch vụ Web. Trọng
tâm của nó bao gồm hai phần[8].
Thứ nhất UDDI là ñặc tả kỹ thuật xây dựng và ñăng ký phân phối thương
mại của dịch vụ Web. Dữ liệu ñược lưu trữ theo ñịnh dạng XML. ðặc tả
UDDI bao gồm các chi tiết API cho phép tìm kiếm dữ liệu ñang tồn tại và
công bố dữ liệu mới.
Thứ hai, ñăng ký thương mại UDDI là một thực thi ñầy ñủ hoạt ñộng của
ñặc tả UDDI (thường ñược gọi là ñám mây dịch vụ).
Ra mắt tháng 5 năm 2001 bởi Microsoft và IBM, hiện giờ UDDI Registry cho
phép bất cứ ai tìm kiếm các dữ liệu UDDI. Nó cũng cho phép các Công ty bất kỳ tự
ñăng ký dịch vụ của mình. Dữ liệu trong UDDI ñược chia làm ba loại[8]:
Trang trắng: loại này bao gồm thông tin tổng quát về công ty cụ thể, ví dụ
tên, mô tả ngành nghề, ñịa chỉ.
Trang vàng: Bao gồm các dữ liệu phân loại chung về công ty hoặc
dịch vụ ñược cung cấp. Ví dụ, dữ liệu này có thể bao gồm ngành công
nghiệp, sản phẩm, hay mã số ñịa lý dựa trên nguyên tắc phân loại chuẩn.
69
Trang xanh: Bao gồm thông tin kỹ thuật về một dịch vụ Web (một con trỏ
ñến một ñặc ñiểm kỹ thuật bên ngoài và một ñịa chỉ ñể gọi các dịch vụ Web).
2.5.1 Hoạt ñộng của UDDI
Một hệ thống ñăng ký UDDI chứa các mô tả chương trình truy nhập của các
doanh nghiệp và các dịch vụ họ cung cấp. Nó cũng chứa các tài liệu tham chiếu, ñặc
tả về nghành nghề mà dịch vụ Web hỗ trợ. Các ñịnh nghĩa phân loại và các hệ thống
ñịnh danh. UDDI cung cấp một mô hình và lược ñồ lập trình, nó ñịnh nghĩa các qui
tắc giao tiếp với hệ thống ñăng ký. Tất cả các API trong ñặc tả UDDI ñược ñịnh
nghĩa dưới dạng XML, ñược ñặt trong một thẻ envelop và ñược gửi bằng
HTTP[12].
Hình 2.5.1.1 - Luồng thông ñiệp trong hệ thống giữa máy trạm và nút ñăng ký
UDDI
Hình 2.5.1.1 minh họa việc truyền tải thông ñiệp UDDI, từ một yêu cầu SOAP
của máy trạm trên HTTP tới một nút ñăng ký và trở lại. SOAP server của máy chủ
ñăng ký xử lý thông ñiệp UDDI SOAP, xử lý nó, và trả về một phản hồi SOAP tới
máy trạm. Tương tự như các vấn ñề về chính sách ñăng ký, các yêu cầu máy trạm
liên quan ñến sửa ñổi dữ liệu phải ñược bảo ñảm và chứng thực các giao dịch[12].
70
Hình 2.5.1.2 - Lược ñồ tác nghiệp của UDDI
Hình 2. 5.1.2 minh họa cách một ñăng ký UDDI ñược phổ biến với dữ liệu và
cách các khách hàng tìm kiếm và sử dụng thông tin. Một ñăng ký UDDI ñược xây
dựng trên dữ liệu ñược cung cấp bởi các khách hàng. Các bước tạo dữ liệu hữu
dụng trong UDDI:
Bước 1, công bố thông tin ñể bắt ñầu ñăng ký khi các công ty phần mềm và các
cơ quan tiêu chuẩn ñịnh nghĩa các ñặc tả kỹ thuật về ngành nghề công nghiệp hoặc
kinh doanh, mà họ ñăng ký trong UDDI. ðiều này thường ñược gọi là tModels[12].
Trong bước 2, các công ty cũng ñăng ký bản mô tả kinh doanh các dịch vụ của
họ. Một bản ghi UDDI sẽ theo dõi tất cả các ñiểm này bằng cách gán cho mỗi ñiểm
một ñịnh danh duy nhất, ñược biết ñến như là một khóa ñịnh danh phổ biến duy
nhất (Unique Universal Identifier - UUID) như trong bước 3. Một khóa UUID ñược
ñảm bảo là duy nhất và không bao giờ thay ñổi trong một bản ghi UDDI. Những
khóa này trông giống như một chuỗi số hexa ngẫu nhiên có ñịnh dạng (ví dụ,
C0B9FE13-179F-413D-8A5B-5004DB8E5BB2). Chúng có thể ñược sử dụng ñể
tham chiếu ñến một ñiểm mà chúng ñược gán vào. Các khóa UUID tạo trong một
bản ghi chỉ có nghĩa nội trong bản ghi ñó. Các máy trạm khác, như siêu thị ñiện tử,
máy tìm kiếm, các ứng dụng thương mại trong bước 4, sử dụng một ñăng ký UDDI
ñể tìm kiếm các dịch vụ liên quan. ðổi lại, các doanh nghiệp có thể thực hiện các
71
dịch vụ ñó, cho phép tích hợp ñơn giản và uyển chuyển như minh họa trong bước
5[12].
2.5.2 Mô hình dữ liệu UDDI
UDDI bao gồm một XML Schema mô tả 4 kiểu thông tin lõi[8]:
Hình 2.5.2 - Mô hình dữ liệu UDDI
businessEntity:
Phần tử businessEntity gồm có thông tin về một thực thể kinh doanh. Như tên,
mô tả, ñịa chỉ, và thông tin liên hệ. Ví dụ: dưới ñây là một bản ghi từ Microsoft
businessEntity
<businessEntity businessKey="0076b468-eb27-42e5-ac09-9955cff462a3"
operator="Microsoft Corporation" authorizedName="Martin Kohlleppel">
<name>Microsoft Corporation</name> <description xml:lang="en"> …..
</description>
<contacts> ….</contacts> <identifierBag> <keyedReference
tModelKey="uuid:8609c81e-ee1f-4d5a-b202-3eb13ad01823"
keyName="D-U-N-S" keyValue="08-146-6849" />
</identifierBag> <categoryBag> <keyedReference
tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2"
keyName="NAICS: Software Publisher" keyValue="51121" />
</categoryBag> </businessEntity>
72
Như ñăng ký ở trên, một dịch vụ kinh doanh nhận một giá trị khóa duy nhất,
ở ñây, khóa businessKey của microsoft là 0076b468-eb27-42e5-ac09-
9955cff462a3. Khóa ñược sử dụng ñể nhận biết một dịch vụ kinh doanh với một
dịch vụ ñược công bố. Ngoài thông tin liên lạc cơ bản, bản ghi businessEntity có thể
bao gồm tùy chọn ñịnh danh (<identifierBag>) và loại(<categoryBag>) dịch vụ kinh
doanh. Các ñịnh danh có thể biểu diễn giá trị bất kỳ xác ñịnh duy nhất một công ty
nào ñó.
businessService:
Phần tử businessService bao gồm thông tin về một dịch vụ Web hoặc một nhóm
các dịch vụ Web liên quan. Bao gồm tên, mô tả, và danh sách tùy chọn của
bindingTemplates[8].
Ví dụ, một bản ghi ñơn giản businessService cho dịch vụ Delayed Stock Quote của
Xmethods.net
<businessService
serviceKey="d5921160-3e16-11d5-98bf-002035229c64"
businessKey="ba744ed0-3aaf-11d5-80dc-002035229c64">
<name>XMethods Delayed Stock Quotes</name>
<description xml:lang="en">20-minute delayed stock quotes</description>
<bindingTemplates> <bindingTemplate
serviceKey="d5921160-3e16-11d5-98bf-002035229c64"
bindingKey="d594a970-3e16-11d5-98bf-002035229c64">
<description xml:lang="en"> SOAP binding for delayed stock quotes service
</description>
<accessPoint URLType="http"> http://services.xmethods.net:80/soap
</accessPoint> <tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uuid:0e727db0-3e14-11d5-98bf-
002035229c64" /> </tModelInstanceDetails> </bindingTemplate>
</bindingTemplates> </businessService>
Giống như businessEntity, mỗi businessService có một serviceKey duy nhất.
73
bindingTemplate
Phần tử bindingTemplate bao gồm thông tin về cách và nơi truy nhập một dịch
vụ Web cụ thể. Ví du, bản ghi Xmethods.net trong ví dụ trên, chúng ta có thể thấy
dịch vụ Stock Quote sẵn sàng ñể thực hiện qua SOAP tại ñịa chỉ
http://services.xmethods.net:80/soap. Các binding không nhất thiết chỉ tham chiếu
tới các dịch vụ HTTP-based. Trong thực tế, UDDI binding có thể chỏ tới dịch vụ
email-based, dịch vụ Fax-based, dịch vụ FTP-based, hoặc thậm trí cả dịch vụ
Telephone-based[8].
tModel
tModel là kiểu dữ liệu lõi cuối cùng, nhưng khó nắm bắt nhất. tModel là viết tắt
của từ mô hình kỹ thuật. tModels chủ yếu ñược sử dụng ñể cung cấp các con trỏ, trỏ
ñến kỹ thuật bên ngoài. Ví dụ, bindingTemplate trong dịch vụ Stock Quote của
Xmethods cung cấp thông tin về nơi truy nhập SOAP binding, nhưng không cung
cấp thông tin làm thế nào ñể nhìn thấy nó. Phần tử tModel ñiền chỗ khuyết này
bằng cách cung cấp một con trỏ trỏ tới một ñặc tả bên ngoài. Ví dụ, ở ñây tModel
ñược tham chiếu bởi XMethods Stock Quote binding[8]:
<tModel
tModelKey="uuid:0e727db0-3e14-11d5-98bf-002035229c64"
operator="www.ibm.com/services/uddi" authorizedName="0100001QS1">
<name>XMethods Simple Stock Quote</name>
<description xml:lang="en">Simple stock quote interface</description>
<overviewDoc> <description xml:lang="en">wsdl link</description>
<overviewURL>
http://www.xmethods.net/tmodels/SimpleStockQuote.wsdl
</overviewURL> </overviewDoc> <categoryBag>
<keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-
39b756e62ab4" keyName="uddi-org:types" keyValue="wsdlSpec" />
</categoryBag> </tModel>
74
Trong bản ghi này Xmethods ñược thi hành tốt nhất bằng ñặc tả giao diện
SOAP sử dụng WSDL, và ñược cung cấp một con trỏ thực sự tới file WSDL.
Chúng ta không phải luôn luôn chỉ rõ file WSDL, có thể chỉ cần chỉ ñịnh một trang
web chung với các chỉ dẫn chi tiết về giao tiếp với dịch vụ[8].
tModel là cực kỳ quan trọng bởi vì chúng cho phép xác ñịnh các ñặc tả kỹ
thuật ñược triển khai. Quan trọng hơn, nếu hai công ty tham chiếu tới cùng một
tModel, ta có thể ñược ñảm bảo rằng cả hai công ty triển khai cùng một ñặc tả[8].
2.6 Bảo mật dịch vụ Web
Cả hai XML-RPC và SOAP ñều chạy trên HTTP vì vậy nó ñược kế thừa tất cả
các tiêu chuẩn an toàn cho HTTP. Ngoài ra ñể ñảm bảo tính toàn vẹn và riêng tư
của thông ñiệp XML truyền trên mạng người ta ñưa ra một chuẩn gọi là WS-
Security (bảo mật cho dịch vụ Web).
2.6.1 WS-Security
Các tiêu chuẩn WS-Security áp dụng ñể ñảm bảo an toàn cho XML(mã hóa và
chữ ký số XML) ñể triển khai bảo mật cho thông ñiệp SOAP trao ñổi qua nhiều
miền xác thực ñộc lập. Mục tiêu là ñảm bảo an toàn mức thông ñiệp, cung cấp cơ
chế mã hóa và ký số giữa thông ñiệp SOAP ñộc lập với mức truyền tải. Các phần
của nội dung thông ñiệp ñược mã hóa, ký số ñược lưu trữ trong phần header[9].
2.6.2 Thông ñiệp bảo mật SOAP
Hình 2.6.2 - Cấu trúc một thông ñiệp
75
WS-Security hỗ trợ một loạt các cơ chế xác thực ủy quyền bằng cách chèn thêm các
thẻ bài tương ứng trong phần Security header của thông ñiệp. Các loại thẻ bài[9]:
- Simple tokens:
o Username/Clear Password
o Username/Password Digest
- Binary Tokens
o X.509 certificates
o Kerberos
- XML Tokens
o SAML assertions
o XrML (eXtensible Rights Markup Language)
o XCBF (XML Common Biometric Format)
- Token reference
o WS-SecureConversation
2.6.3 Thẻ bài bảo mật và ñịnh danh
Một thẻ bài bảo mật có thể ñược sử dụng ñể yêu cầu ñịnh danh nguồn thông
ñiệp gửi ñến. Username/PasswordText là thẻ bài ñơn giản nhất ñược sử dụng ñể
truyền ñạt ñịnh danh nhưng nó cũng không ñược an toàn, mật khẩu trong thông ñiệp
SOAP không cần phải ñược mã hóa. Vì vậy ta nên sử dụng
Username/PasswordDigest[9]:
<UsernameToken>
<Username>Scott Tiger</Username>
<Password Type=“PasswordDigest”>XYZAAA9</Password>
<Nonce>123521</Nonce>
<Created>2005-11-24T15:00:00Z</Created>
</UsernameToken>
ðể sinh ra chữ ký số, mật khẩu ñược băm cùng với một nhãn thời gian và
một Nonce.
76
2.6.4 Thẻ bài bảo mật và xác thực
Một thẻ bài bảo mật có thể ñược ký ñể xác thực một yêu cầu tạo lên bởi
người gửi thông ñiệp. Các chữ ký số kết hợp với các thẻ bài có thể ñược kiểm tra
bởi người nhận ñể xác thực ñịnh danh của người gửi. Ví dụ chứng chỉ X509(khóa
công khai) có thể ñược dùng ñể cung cấp chứng nhận về người gửi(bằng chứng về
sở hữu, tương ñương khóa bí mật) [9].
Hình 2.6.4 - Mô hình xác thực
2.6.5 WS-Federation
Các hệ thống khác nhau có thể thuộc về các miền bảo mật khác nhau, ñược
sử dụng các cơ chế và chính sách bảo mật khác nhau. Mặc dù SOAP cho phép khả
năng tương tác giữa những hệ thống ñó, việc chuyển ñổi các siêu dữ liệu bảo mật
giữa các miền khác nhau là một bài toàn phức tạp. WS-Security là một bước ñầu
tiên hướng tới việc cung cấp chuẩn hóa cú pháp và ngữ nghĩa ñể biểu diễn an toàn
thông tin. WS-Trust
Bổ sung một giao diện chuẩn ñể cung cấp dịch vụ thẻ bài bảo mật, nó ñược sử dụng
ñể phát hành và thay mới các thẻ bài bảo mật ñể ñính kèm vào một thông ñiệp
SOAP với WS-Security. Chuyển ñổi các thẻ bài bảo mật giữa các miền chia sẻ một
quan hệ tin cậy[9].
Hình 2.6.5 - Mô hình WS-Federation
2.6.6 WS-SecureConversation
77
Kết nối bảo mật liên quan ñến việc tạo ra các thẻ bài và công nhận chúng có
thể áp ñặt một chi phí cao.
WS-SecureConversation ñịnh nghĩa một bối cảnh chia sẻ bảo mật ñể tái sử
dụng qua việc trao ñổi nhiều thông ñiệp, tương tự như vậy các thông tin bảo mật kết
hợp(xác thực, ủy quyền) và khóa mã cũng có thể ñược tái sử dụng.
Một khi các quy ước ñược thành lập, người yêu cầu và dịch vụ chia sẻ một bí
mật là máy trạm không phải bổ sung các siêu dữ liệu bảo mật cho mỗi thông ñiệp,
dịch vụ không phải xác nhận lại cùng một thẻ bài cho mỗi thông ñiệp. ðiều này
ñược triển khai bằng cách sử dụng một thẻ bài ñặc biệt <SecurityContextToken>[9].
78
CHƯƠNG 3
THIẾT KẾ HT KHAI THÁC ðƯỜNG DÂY THUÊ BAO
3.1 Một số khai niệm
3.1.1 DSLAM, xDSL
DSLAM: là bộ ghép kênh truy nhập ñường dây thuê bao số tập trung, có
nhiệm vụ ñảm bảo các dịch vụ DSL (như ADSL, VDSL...). DSLAM ñược ñặt ở
phía tổng ñài, là ñiểm cuối của kết nối xDSL. Mỗi DSLAM có thể có từ từ 1 ñến 15
card thuê bao trên mỗi card thuê bao có khoảng 32, 48 ñến 64 cổng, mỗi cổng tương
ứng với thuê bao internet. DSLAM tập hợp tín hiệu số ñến từ nhiều cổng lại thành
một tín hiệu nhờ vào kỹ thuật ghép kênh, sau ñó thông tin sẽ ñược vận chuyển trên
nền IP hoặc ATM ñến nhà cung cấp dịch vụ tương ứng.
DSL: Digital Subcriber Line (kênh thuê bao số), là một họ những kỹ thuật
mà nó cung cấp kết nối kỹ thuật số thông qua cáp ñồng của mạng ñiện thoại nội hạt.
Năm 1988, các kỹ sư tại Bell Labs ñã nghĩ ra cách thức truyền tải các tín hiệu số
thông qua phổ tần số không ñược dùng tới trong dịch vụ thoại truyền thống. Vì vậy,
trên ñường dây ñiện thoại thông thường, người ta có thể ñồng thời cung cấp dịch vụ
truyền tín hiệu số mà không làm gián ñoạn dịch vụ thoại. Nhưng phải ñến cuối
những năm 1990 trước sự bùng nổ các yêu cầu về dịch truyền dữ liệu tốc ñộ cao thì
các kỹ thuật này mới thức sự ñược phát triển. Lưu lượng dữ liệu dịch vụ DSL
thường ñạt trong khoảng 256kbit/s ñến 40Mbit/s hướng xuống khách hàng, tùy theo
công nghệ DSL, chất lượng ñường dây, mức dịch vụ triển khai. Thuật ngữ DSL bao
gồm các công nghệ ADSL, SDSL, VDSL,.. và thường gọi chung là xDSL. Dự vào
sự chênh lệch tốc ñộ giữa chiều tải lên và tải xuống, nếu tải xuống lớn hơn tải lên
thì là ADSL, nếu bằng nhau thì là SDSL. Còn VDSL là công nghệ truy nhập với tốc
ñộ rất cao.
3.1.2 Mạng cung cấp dịch vụ ñiện thoại cố ñịnh(PSTN)
PSTN là một mạng ñiện thoại công cộng sử dụng công nghệ chuyển mạch
kênh. Nó bao gồm các ñường dây thuê bao, cáp quang, truyền dẫn viba, mạng di
ñộng, truyền thông vệ tinh,… Tất cả ñược kết nối tới trung tâm chuyển mạch, cho
79
phép bất kỳ một thuê bao nào trên thế giới cũng có thể giao tiếp ñược với nhau. Ban
ñầu là một mạng lưới các hệ thống ñiện thoại cố ñịnh tương tự, PSTN ngay nay nó
gần như hoàn toàn là kỹ thuật số, bao gồm ñiện thoại di ñộng cũng như cố ñịnh
Các hoạt ñộng kỹ thuật của mạng PSTN sử dụng các tiêu chuẩn ñược tạo ra
bởi ITU-T. Những tiêu chuẩn này cho phép các mạng khác nhau ở các quốc gia
khác nhau có thể kết nối ñược với nhau. Ngoài ra không gian số ñiện thoại ñược
quy ñịnh và phần chia cho mỗi quốc gia trên thế giới dựa trên các tiêu chuẩn E.163,
E.164. Sự kết hợp giữa tiêu chuẩn kêt nối mạng và quy hoạch số ñiện thoại cho
phép bất kỳ thuê bào nào trên thế giới có thể quay số và ñàm thoại với thuê bao
khác.
ðể cung cấp dịch vụ thoại cho người sử dụng, mạng PSTN phải gồm 4 thành
phần cơ bản:
Thuê bao(subscriber): Thuê bao là thiết bị kết nối tới mạng. Hiện nay, hầu
hết các thuê bao kết nối tới mạng PSTN là máy ñiện thoại.
Vòng nội bộ(local loop): Vòng nội bộ là tuyến giữa thuê bao và mạng, còn
ñược gọi là vòng thuê bao.Hấu hết các kết nối vòng nội bộ sử dụng dây xoắn.
Chiều dài các vòng nội bộ từ vài km tới vài chục km.
Tổng ñài(exchange): -Tổng ñài là trung tâm chuyển mạch của mạng. Trung
tâm chuyển mạch kết nối trực tiếp với thuê bao gọi là tổng ñài cuối (end
office), các end office kết nối với nhau bằng tổng ñài trung gian (Tandem
office). Một tổng ñài cuối hỗ trợ vài chục ngàn thuê bao trong một ñịa
phương. Các tổng ñài trung gian chịu trách nhiệm trong việc ñịnh tuyến và
chuyển mạch giữa các tổng ñài cuối. ðể kết nối hai thuê bao trong cùng một
tổng ñài cuối, mạch ñược thiết lập ñơn giản thông qua tổng ñài ñó.Nhưng
nếu hai thuê bao kết nối tới các tổng ñài cuối khác nhau, mạch liên kết có thể
gồm một hay nhiều tổng ñài trung gian.
Trung kế(trunk): Trung kế là các tuyến giữa các tổng ñài. Trung kế tải cùng
lúc nhiều cuộc ñiện thoại sử dụng kỹ thuật ghép kênh theo tần số FDM hoặc
theo thời gian TDM.
80
3.2 Thuê bao Internet
3.2.1 Chức năng hệ thống
Hệ thống là một dịch vụ Web có khả năng kết nối với các DSLAM, thực
hiện ñóng gói các yêu cầu theo ñịnh dạng PDU của phương thức SNMP tương ứng,
thực hiện phương thức ño và nhận kết quả trả ra của DSLAM. Các hệ thống liên
quan triển khai nhúng và thực hiện gọi các phương thức của dịch vụ Web tương ứng
với yêu cầu của người sử dụng. Với kiến trúc như trên hệ thống cho phép nhiều
người dùng cuối có thể gửi lệnh vào DSLAM, không cần qua các tác nhân trung
gian, rút ngắn thời gian truy vấn thông tin. Hệ thống có thể ñáp ứng ñược các
nghiệp vụ:
Truy vấn tham số cổng: Chức năng cho phép người sử dụng thu thập các
thông tin:
- Tên gói cước ñang dùng.
- Tốc ñộ hiện tại hai chiều up/down
- Tốc ñộ lớn nhất có thể ñạt ñược hai chiều up/down
- Suy hao hai chiều up/down
- Tỷ số tín hiệu/ tạp âm hai chiều up/down
- Trạng thái thuê bao
ðể quyết ñịnh hướng xử lý với các yêu cầu về báo hỏng, thay ñổi tốc ñộ, phát
triển thêm dịch vụ của thuê bao. Chức năng này thường ñược sử dụng trước khi
thực hiện hai mục dưới.
Thực hiện lệnh thay ñổi trạng thái cổng: ñược thực hiện mỗi khi cổng bị treo
hoặc kích hoạt trạng thái sử dụng của thuê bao.
Thực hiện lệnh thay ñổi gói cước: ñược thực hiện mỗi khi có yêu cầu về thay
ñổi tốc ñộ truy nhập của thuê bao, hoặc gán tốc ñộ truy nhập cho thuê bao
mới.
81
3.2.2 Thiết kế hệ thống
3.2.2.1Mô hình và kiến trúc hệ thống
3.2.2.1.1 Mô hình hệ thống
Hình 3.2.2.1.1 - Mô hình hệ thống mở rộng khai thác thuê bao Internet
Hệ thống ñược cài ñặt trên một máy chủ nằm trong mạng NMS, giao tiếp với
mạng các thiết bị DSLAM và mạng ðiều hành sản xuất kinh doanh(SXKD).
3.2.2.1.2 Kiến trúc hệ thống
Hình 3.2.2.1.2 – Kiến trúc hệ thống
Kiến trúc của dịch vụ Web bao gồm module quản trị dữ liệu về thông tin của
các DSLAM như ñịa chỉ IP, chủng loại. ðể module ñiều khiển trung tâm sẽ kết nối
và tìm kiếm thông tin về DSLAM mỗi khi có yêu cầu từ ngoài vào, sau ñó module
Webservice Sql server
Gửi lênh SNMP
ðiều khiển trung tâm - Kết nôi DB - Tìm kiếm IP - Nhận biết họ DSLAM - Tính index cổng
Ping/ Ktra kết nối
82
này thực hiện kiểm tra kết nối thông quan module Ping, nếu kết nối thành công nó
tiếp tục gửi lệnh SNMP vào DSLAM, và sau ñó nhận và gửi kết quả về cho hệ
thống ñã gửi yêu cầu ñó, trường hợp kết nối không thành công thì gửi thông báo
không kết nối ñược và kết thúc yêu cầu không gửi lệnh SNMP nữa.
3.2.2.2 Biểu ñồ ca sử dụng
kiemtraketnoi
Dslam
Kich_hoat_lai_trang_thai
thay_doi_goi_cuoc
DoThu_thamso_chatluong
hethong_dieuhanh
_tacnghiep
<<users>>
<<uses>>
<<users>>
quantri_tt_dslamNguoi_quantri
<<uses>>
<<uses>>
<<uses>>
kiemtra_tontai_dslam
<<users>>
<<uses>>
<<users>>
Hình 3.2.2.2 - Biểu ñồ ca sử dụng
3.2.2.2.1 Danh sách các tác nhân
Hethong_dieuhanh_tacnghiep: Là các ứng dụng thực hiện chức năng ñiều hành
tác nghiệp của ñơn vị, kết nối và thông qua dịch vụ Web yêu cầu thực hiện các
chức năng ño thử các tham số chất lượng, thay ñổi trạng thái, thay ñổi gói cước
của cổng.
Nguoi_quantri: Thực hiện cập nhật các thông tin về mã(code), ñịa chỉ ip của
DSLAM.
Dslam: Thiết bị cung cấp dịch vụ truy internet.[1]
3.2.2.2.2 ðặc tả các Use Case
DoThu_thamso_chatluong:
o Tác nhân tham gia: hethong_dieuhanh_tacnghiep, dslam.
83
o Mô tả: Người sử dụng dùng giao diện chương trình ñiều hành tác nghiệp
nhập thông tin về mã dslam, ñịa chỉ vật lý của cổng thuê bao trên dslam
ñó và yêu cầu thực hiện lệnh ño các tham số chất lượng.
o Chức năng: Tìm ñịa chỉ ip của dslam, kiểm tra kết nối mạng, tính toán
Ifindex và OID tương ứng với cổng thuê bao ñược yêu cầu, thực hiện
thao tác Get của SNMP vào dslam thông qua ñịa chỉ IP.
thay_doi_goi_cuoc:
o Tác nhân tham gia: hethong_dieuhanh_tacnghiep, dslam.
o Mô tả: Người sử dụng dùng giao diện chương trình ñiều hành tác nghiệp
nhập thông tin về mã dslam, ñịa chỉ vật lý của cổng thuê bao trên dslam
ñó và yêu cầu thực hiện lệnh thay ñổi gói cước của thuê bao.
o Chức năng: Tìm ñịa chỉ ip của dslam, kiểm tra kết nối mạng, tính toán
Ifindex và OID tương ứng với cổng thuê bao ñược yêu cầu, thực hiện
thao tác Set của SNMP vào dslam thông qua ñịa chỉ IP.
Kich_hoat_lai_trang_thai:
o Tác nhân tham gia: hethong_dieuhanh_tacnghiep, dslam.
o Mô tả: Người sử dụng dùng giao diện chương trình ñiều hành tác nghiệp
nhập thông tin về mã dslam, ñịa chỉ vật lý của cổng thuê bao trên dslam
ñó và yêu cầu thực hiện lệnh Thực hiện chức năng thay ñổi trạng thái
hoạt ñộng của một cổng thuê bao, ví dụ: chuyển từ trạng thái hoạt
ñộng(active) về trạng thái ñóng(deactive), hoặc ngược lại..
o Chức năng: Tìm ñịa chỉ ip của dslam, kiểm tra kết nối mạng, tính toán
Ifindex và OID tương ứng với cổng thuê bao ñược yêu cầu, thực hiện
thao tác Set của SNMP vào dslam thông qua ñịa chỉ IP.
quantri_tt_dslam:
o Tác nhân: Nguoi_quantri.
o Mô tả: Cung cấp gia diện và kết nối cơ sở dữ liệu cho phép người quản trị
cập nhật thông tin về mã và ñịa chỉ IP của một dslam.
84
o Chức năng: kết nối cơ sở dữ liệu, thêm mới, sửa, xóa và truy vấn thông
tin về dslam.
kiemtra_tontai_dslam: Các use case a,b,c trước khi kết nối và thực hiện lệnh
snmp vào dslam, sử dụng use case này ñể kiểm tra xem có tồn tại dslam ñó trên
mạng khai thác không, nếu có thì nó trả về ñịa chỉ ip của dslam ñó, nếu không
thì thông báo không tồn tại dslam.
Kiemtraketnoi: Sau khi tìm ñược ñịa chỉ ip của dslam, các use case a,b,c sử dụng
use case này kiểm tra xem có thể kết nối ñược tới dslam không.[1]
3.2.2.3 Biểu ñồ lớp
SNMP
read_community : String = public
write_community : String = privateudp_port : Integer = 161
snmpGet(ip,oid)()snmpSet(ip,oid,valuetype,value)()
Ping
PingTest(ip)()
Dslams
dbname : String
dbuser : String
dbpassword : Stringservername : String
Dslams(db,server,user,password)()getIpByCode(code)()
LenhSNMP
oids : String
ip : Stringport : Integer
tinhIfindex()getThamSoChatLuong()
setTrangThaiCong(status)()
setGoiCuoc(profile)()
DoThu
loaiDslam : String
getPortInfByCode(code,port)()
getSnmpInf(ip,loaidslam, port, oid)()
setPortStatus(code,loaidslam,port,status)()
setLineProfile(code,loaidslam,port,profile)()
+*+1
+*
+1
+*
+1
Hình 3.2.2.3 - Biểu ñồ lớp
Lớp SNMP
o Chức năng: Là lớp supper ñược kế thừa bởi lớp lenhSNMP, chịu trách
nhiệm chính trong việc xây dựng các phương thức get, set,… của giao
thức SNMP.
o Các thuộc tính
� Read_community: kiểu dữ liệu là String, lưu trữ và thể hiện thông
tin về mật khẩu(community) quyền ñọc(read-only) các thông tin
của thiết bị khi thực hiện phương thức get. ñược mô tả trong phần
bảo mật của SNMP, thường mặc ñịnh là “public”.
� Write_community: kiểu dữ liệu là String, lưu trữ và thể hiện thông
tin về mật khẩu(community) quyền ghi(read-only) các thông tin
85
của thiết bị khi thực hiện phương thức set. ñược mô tả trong phần
bảo mật của SNMP, thường mặc ñịnh là “private”.
� udp_port: số cổng mà thiết bị ñang mở ñể giao tiếp với hệ thống
quản lý bằng giao thức SNMP, mặc ñịnh là 161.
o Các phương thức
� snmpGet: ñây chính là nội dung cài ñặt của phương thức get trong
mô tả giao thức SNMP.
� snmpSet: ñây chính là nội dung cài ñặt của phương thức set trong
mô tả giao thức SNMP.
Lớp LệnhSNMP
o Chức năng: ðịnh nghĩa các ñối tượng cho từng loại dslam cụ thể, tùy vào
từng loại mà việc tính Ifindex, OID và có thể là ñịa chỉ IP khác nhau. Kế
thừa các thuộc tính và phương thức của lớp SNMP ñể thực hiện gửi lệnh
SNMP và Dslam theo từng yêu cầu cụ thể.
o Các thuộc tính
� Oids: khai báo thông tin về ñịnh danh của một ñối tượng quản lý
trong MIB.
� IP: ñịa chỉ IP quản lý của Dslam.
� Port: ðịa chỉ vật lý cổng thuê bao internet cần thực hiện lệnh ñể
nhận hoặc thiết lập thông tin. Nó xác ñịnh vị trí vật lý của một
thuê bao trên Dslam, nó bao gồm các thông số frame(mã số rack
chứa Dslam), slot(sô thứ tự chỉ vị trí card thuê bao trên rack),
port(số hiệu của thuê bao trên slot, mỗi slot có thể có 32 hoặc 64
port)
o Các phương thức
� TinhIfindex: Port cần ñược chuyển ñổi ra dạng index phù hợp với
quy ñịnh ñánh số của mỗi loại Dslam. Việc chuyển ñổi phải dựa
theo một công thức ñược cung cấp riêng của từng hãng cung cấp
Dslam.
86
� getThamSoChatLuong: phương thức thực hiện thao tác snmpGet
của lớp SNMP sau khi ñã tính Ifindex.
� setTrangThaiCong: phương thức này cũng thực hiện tính Ifindex
và sau ñó gọi phương thức snmpSet của lớp cha SNMP, thiết lập
trạng thái của một cổng thuê bao.
� setGoiCuoc: thiết lập tên gói cước sử dụng cho một cổng thuê bao.
Sau khi tính Ifindex nó gọi phương thức snmpSet của lớp cha
SNMP.
Lớp Dothu
o Chức năng: Tạo một ñối tượng lenhSNMP ñể thực hiện các lệnh ño các
tham số ñanh giá chất lượng cổng.
o Các thuộc tính: Thuộc tính loaiDslam cho phép chương trình biết phải tạo
ra ñối tượng lenhSNMP phù hợp với Dslam tương ứng.
o Các phương thức:
� getPortInfByCode: Thực hiện một loạt các lệnh tương ứng với các
tham số chất lượng cổng.
� setPortStaus: Phương thức thực hiện lệnh thiết lập trạng thái cổng
� setLineProfile: Phương thức thực hiện lệnh gán tên một gói cước
cho một cổng.
Lớp Dslams
o Chức năng: Mở một kết nối tới cơ sở dữ liệu lưu trữ thông tin về ñịa chỉ
IP và mã(code) của các DSLAM trên mạng. Trả về ñịa chỉ IP và chủng
loại dslam tương ứng với code ñó.
o Các thuộc tính:
� Dbname: tên cơ sở dữ liệu
� Username: tên ñăng nhập cơ sở dữ liệu
� Password; mật khẩu ñăng nhập cơ sở dữ liệu
� Servername; tên hoặc ñịa chỉ ip của máy chủ cơ sở dữ liệu
o Các phương thức
87
� getIpFromCode: mở kết nối và truy vấn thông tin dslam theo
mã(code).
Lớp Ping
o Chức năng: kiểm tra kết nối từ máy chủ thực hiện lệnh và dslam.
o Các phương thức:
� PingTest: thực hiện lệnh “ping” tới ñịa chỉ Ip cần kiểm tra.[1]
3.2.2.4 Biểu ñồ tuần tự
:
hethong_dieuhanh_tacnghiep
:
hethong_dieuhanh_tacnghiep
: DoThu : DoThu : Dslams : Dslams : Ping : Ping sn :
LenhSNMP
sn :
LenhSNMP
: Dslam : Dslam
getPortInforByCode(code,port)
getIP(code)
khong ton tai code
khong ton tai code
pingtest(ip)
ping command
reply
khong ket noi duoc
getSnmpInfor(ip,port,oidindex)
new(ip,oidindex,port,community,udpport)
getThamsoChatLuong()
snmpGet(ip,OID+Ifindex)
msg
msg
msg
while(param<max_param)
end while
tinhIfindex( )
Hình 3.2.2.4 - Biểu ñồ tuần tự
3.2.2.5 Kết quả triển khai sử dụng
Chúng tôi xin trình bày giao diện web của chương trình ñiều hành sửa chữa
sử dụng dịch vụ Web trên:
88
- ðo chất lượng cổng
Hình 3.2.2.5.1 - Giao diện ño thử chất lượng
- ðổi tốc ñộ cổng
Hình 3.2.2.5.2 -Giao diện ñổi tốc ñộ cổng
- Xem và reset trạng thái
Hình 3.2.2.5.3 -Giao diện xem trạng thái và reset cổng
- Kiểm tra khả năng phát triển dịch vụ
Hình 3.2.2.5.4 -Giao diện kiểm tra khả năng phát triển dịch vụ
89
3.3 Thuê bao ñiện thoại cố ñịnh
3.3.1 Chức năng hệ thống
Hệ thống là một Dịch vụ Web kết nối bằng phương thức telnet tới ñịa chỉ IP
tương ứng với mỗi tổng ñài. Mỗi khi có yêu cầu từ hệ thống người dùng bên ngoài,
chuyển các yêu cầu thành dạng lệnh khai thác tương ứng với loại tổng ñài, gửi lệnh
vào tổng ñài, nhận và gửi trả kết quả cho hệ thống ñã yêu cầu vào. Hệ thống cung
cấp các phương thức xử lý các nghiệp vụ:
ðo thử các tham số chất lượng ñường dây thuê bao: Mỗi khi thuê bao thông báo
yêu cầu kiểm tra sửa chữa, bộ phận tiếp nhận sẽ sử dụng chức năng này ñể thu
thập thông tin về chất lượng thuê bao, ñánh giá, gửi cho bộ phận hỗ trợ trực tiếp
nếu cần, bộ phần này sẽ căn cứ vào các thông tin ñó ñể có cách sửa chữa phù
hợp.
Thực hiện thay ñổi các dịch vụ giá trị gia tăng của thuê bao: mở/ñóng hướng gọi
liên tỉnh, quốc tế, di ñộng, 108, vvv, treo do nợ cước hoặc thuê bao yêu cầu,
khôi phục nợ cước hoặc thuê bao yêu cầu, tháo hủy thuê bao không sử dụng ñể
giải phóng cổng của tổng ñài.
Truy vấn thông tin cấu hình thuê bao: Khi tiếp nhận yêu cầu chăm sóc từ thuê
bao, trước khi thực hiện hai mục trên, nhân viên tiếp nhận dựa vào yêu cầu của
thuê bao ñể thực hiện tính năng này ñể kiểm tra tình trạng thuê bao xem ñã tồn
tại dịch vụ thuê bao yêu cầu hay chưa?, ñang ñóng hay mở cước?, hoặc bị cấm
hướng gọi? Sau ñó sẽ thực hiện một trong hai chức năng trên.
90
3.3.2 Thiết kế hệ thống
3.3.2.1 Mô hình và kiến trúc hệ thống
3.3.2.1.1 Mô hình hệ thống
Hình 3.3.2.1.1 – Mô hình triển khai dịch vụ Web(webservice)
dịch vụ Web ñược cài ñặt trên một máy chủ nằm giữa mạng liên kết giữa các tổng ñài (Host) và mạng các máy tính ñiều hành sản xuất. 3.3.2.1.2 Kiến trúc hệ thống
Do hệ thống tổng ñài chuyển mạch chỉ cho phép thực hiện tuần tự lệnh vì
vậy tại một thời ñiểm chỉ thực hiện một lệnh của một tổng ñài. Hệ thống cung cấp
các hàng ñợi tương ứng với từng tổng ñài như vậy tại một thời ñiểm có thể gửi ñồng
thời nhiều lệnh ño cho nhiều tổng ñài khác nhau. Các yêu cầu ñược hệ thống phân
loại và ñưa vào hàng ñợi tương ứng, sau ñó hệ thống tự ñộng lấy yêu cấu từ hàng
ñợi phân tích nội dung, thành lập lệnh theo ñúng cú pháp của tổng ñài, kết nối và
gửi lệnh váo tổng ñài, khi tổng ñài trả về kết quả hệ thống gửi kết quả ñó vào hàng
ñợi kết quả, hoàn tất quy trình thức hiện một yêu cầu. Quy trình trên ñược hệ thống
lặp lại với các yêu cầu ñược gửi lên hàng ñợi cho ñến khi hàng ñợi không còn yêu
cầu nào. Hệ thống là một dịch vụ Web thực hiện cơ chế không ñồng bộ, các yêu cầu
ñược gửi lên hàng ñợi qua một phương thức của dịch vụ Web, sau ñó kết quả ñược
gửi trả lại vào một hàng ñợi khác, hệ thống tác nghiệp sẽ ñăng ký ñể nhận kết quả
này thông qua một phương thức khác của dịch vụ Web[7].
Các ứng dụng sử dụng WS
Webservice
Nport 1 Host 1
Nport 2 Host 2
Nport n Host n
…. Mạng Metronet Mạng ðHSXKD
91
Hình 3.3.2.1.2.1 - Thông ñiệp ñi qua các hàng ñợi tương ứng với các tổng
ñài(Host)
Hình 3.3.2.1.2.2 - Kiến trúc hệ thống tổng quát
Hàng ñợi yêu cầu
Hàng ñợi kết quả
File XML danh sách Host,IP, Acc
ðiều khiển trung tâm
Ping/Ktra kết nối
Telnet
Ghi log
92
3.3.2.2 Biểu ñồ ca sử dụng
Queue
Host
KiemTraTonTaiHost
KiemTraKetNoi
LayYCTuHangDoiGuiYC_vaoHangDoi
GuiLenhVaoHost
GuiKetQuaVaoHangDoiTopic
HeThong_DieuHanh_TacNghie
p
Topic
DangKyNhanKetQua
QuanTri
KhoiDongQueueListener
NguoiQuantriHeThong
<<uses>>
<<uses>>
<<communicate>>
<<communicate>>
<<uses>>
Hình 3.3.2.2 - Biểu ñồ ca sử dụng
3.3.2.2.1 Các tác nhân
Hethong_DieuHanh_Tacnghiep: Là các hệ thống phần mềm thực hiện các
nghiệp vụ khác nhau của ñơn vị, thực hiện kết nối với dịch vụ Web ñể thực
hiện một nghiệp vụ nào ñó, ví dụ như truy vấn hồ sơ thuê bao, do thử chất
lượng ñường dây,..
Queue: Là hàng ñợi lưu các yêu cầu do người sử dụng thông qua giao diện
các hệ thống tác nghiệp gửi lên, chờ ñược dịch vụ Web thực hiện.
Topic: Là hàng ñợi lưu kết quả của một yêu cầu sau khi dịch vụ Web ñã thực
hiện.
NguoiQuantriHeThong: Quản lý, cập nhật thông tin về các tổng ñài, như mã,
ñịa chỉ IP, port telnet. Thực hiện khởi ñộng các luồng chờ(Listenner) nhận
yêu cầu lên hàng ñợi.
Host: Tổng ñài chuyển mạch, cung cấp dịch vụ ñiện thoại cố ñịnh.[1]
3.3.2.2.2 Các ca sử dụng
GuiYC_vaoHangDoi: Phương thức cho phép các hệ thống tác nghiệp gửi yêu
cầu vào hàng ñợi.
93
DangKyNhanKetQua: Các hệ thống tác nghiệp sử dụng phương thức này
ñăng ký là một thuê bao của dịch vụ Web ñể nhận kết quả của yêu cầu.
LayYCTuHangDoi: Các yêu cầu trên hàng ñợi tự ñộng ñược lấy ra ñể thực
hiện.
GuiLenhVaoHost: Gửi lệnh vào tổng ñài và ñợi kết quả từ tổng ñài.
GuiKetQuaVaoHangDoiTopic: Sau khi có kết quả thì gửi vào hàng ñợi kết
quả.
KiemTraTonTaiHost: Truy vấn và kiểm tra xem mã tổng ñài có tồn tại
không, nếu có thì trả về IP và Port telnet ñể chuẩn bị kết nối, nếu không thì
trả thông báo không tồn tại.
KiemTraKetNoi: Thực hiện lệnh ping ñể kiểm tra kết nối mạng trước khi
thực hiện lệnh.
QuanTri: Quản trị thông tin về tổng ñài
KhoiDongQueueListener: Mỗi hàng ñợi ñược xây dựng dưới dạng một
luồng(Thread), luồng này sẽ ñược khởi ñộng trước ñể mở hàng ñợi cho phép
các yêu cầu ñược nhận vào.[1]
94
3.3.2.3 Biểu ñồ lớp
clsTelnet
telnet : TelnetClient
in : InputStream
out : OutputStream
timeout : Integer = 50
new(ip,port)()
isOpen()
disConnect()
Login(user,password)()
readUntil(stop_prompt)()
write(msg)()
sendCommand(msg,stop_prompt)()
clsTextListener
onMessage(msg)()
clsPing
PingTest(ip)()
clsHostTelnet
atc : clsTelnet
dothu(code,sub)()
getSubInf(code.sub)()
setupService(code,sub,command,service)()
clsTopicSubcriber
connectionFactory : String
topicname : String
setTopic(topicname)()
getSynchronousMessage()
clsService
getJMSTopicResult()
jmsSendToHost(host,sub,option)()
jmsSendToHostSetupService(host,sub,command,service)()
clsInitQueueListener
queue_name : String
thQueueStart[] : Thread
run()
main()
clsHostInf
hostname : String
hostip : String
telnet_port : Integer = 23
loai_host
new(connectString)()
searchByHost()
getHostIP()()
getListHost()()
clsAsynQueueConsumer
getAsynchConsumer(queue)()
clsTopicPublisher
connectionFactory : String
topicname : String
setTopic(topicname)()
sendToClient(msg)()
clsQueueProducer
sendToClient(msg,queue)()
clsContext
context_url
username
password
context_package
getInitContext()()
Hình 3.3.2.3 - Biểu ñồ lớp
a. clsTelnet:
Chức năng: Cung cấp các phương thức kết nối trực tiếp với tổng ñài, ñăng
nhập, gửi lệnh, ñọc và chờ kết quả từ tổng ñài, ñóng kết nối.
Các thuộc tính:
- telnet: ñối tượng cụ thể của lớp TelnetClient, thực hiện mở một kết nối
bằng telnet.
- Inputstream: ñối tượng xử lý luồng dữ liệu vào của telnet.
- Outputstream: ñối tượng xử lý luồng dữ liệu cả telnet
- Timeout: thời gian tối ña ñể thực hiện và ñọc kết quả của một lệnh mà
telnet thực hiện.
95
Các phương thức:
- New: Tạo mới một ñối tượng clsTelnet, mở một phiên telnet tới ip và port,
tương với một tổng ñài cụ thể.
- isOpen: cho biết trạng thái ñóng hay mở của phiên telnet.
- DisConnect: ñóng phiên telnet.
- Login: ñăng nhập vào phiên telnet
- readUntil: ñọc luồng dữ liệu ra của phiên telnet, kết thúc khi gặp chuỗi ký
tự stop_promt.
- Write: gửi một thông ñiệp vào vào phiên telnet
- sendCommand: gửi một lệnh vào phiện telnet, chờ kết quả trả ra của telnet,
kết thúc khi gặp chuỗi stop_promt.
b. clsHostTelnet.
Chức năng: Thể hiện một tổng ñài cụ thể, cung cấp các phương thức thực
hiện các yêu cầu.
Thuộc tính:
- Atc: ñối tượng sử dụng clsTelnet, mở phiên telnet vào tổng ñài.
Phương thức:
- Dothu: Thực hiện lệnh ño thử vào tổng ñài tương ứng với tham số code và
số thuê subc
- getSubInf: Truy vần thông tin về một thuê bao(subc) của tổng ñài tương
ứng với mã tổng ñài.
- setupService: cái ñặt các dịch vụ gia tăng dichvu, cho thuê bao subc, của
tổng ñài code.
c. clsPing: Cung cấp phương thức kiểm tra kết nối từ máy chủ dịch vụ Web tới
một ñịa chỉ IP.
d. clsHostInf:
Chức năng: Cung cấp các phương thức tìm kiếm của một tổng ñài cần kết nối
trong cơ sở dữ liệu.
Thuộc tính:
96
- Hostname: Mã tổng ñài
- Hostip: ñịa chỉ IP tương ứng với mã tổng ñài
- Telnet_port: cổng sử dụng ñể kết nối tới tổng ñài qua phương thức telnet
- Loaihost: chủng loại tổng ñài cần kết nối, dựa trên thuộc tính này mà ta có
các tập lệnh khai thác khác nhau.
Phương thức:
- SearchByHost: tìm kiếm theo một mã tổng ñài, trả về các thông tin như IP,
Port, chủng loại
- getHostIP: Tìm kiếm ñịa chỉ IP của một mã tổng ñài
- GetListHost: Trả về danh sách tất cả các tổng ñài khai báo trong hệ thống,
phục vụ cho module khởi ñộng luồng hàng ñợi.
e. clsService: Cung cấp giao diện dịch vụ Web cho phép các hệ thống tác
nghiệp gửi yêu cầu và ñăng ký nhận kết quả.
f. clsTopicSubcriber: Cung cấp phương thức nhận kết quả từ hàng ñợi.
g. clsQueueProceder: Cung cấp phương thức gửi yêu cầu vào hàng ñợi
h. clsTopicPublisher: Cung cấp phương thức gửi yêu cầu vào hàng ñợi
i. clsInitQueueListener: Khởi ñộng luồng mở hàng ñợi chờ gửi yêu cầu.
j. clsAsynConsumer: Cung cấp phương thức ñược luồng sử dụng ñể khởi ñộng
ñối tượng clsTextListenner.
k. clsTextListener: Cung cấp phương thức tự ñộng lấy yêu cầu từ hàng ñợi
l. clsInitContext: Cung cấp thông tin và phương thức kết nối tới hàng ñợi trên
webserver.[1]
97
3.3.2.4 Biểu ñồ tuần tự
Sơ ñồ 1: Một yêu cầu ñược gửi vào hàng ñợi từ hệ thống tác nghiệp[1]
:
HeThong_DieuHanh_TacNghiep
:
HeThong_DieuHanh_TacNghiep
: clsService : clsService : clsQueueProducer : clsQueueProducer : Queue : Queue
1: jmsSenToHost(host,sub)
2: new()
3: sne2client(hostQueue,sub)
Hình 33.3.2.4.1 - Biểu ñồ tuần tự gửi yêu cầu
Sơ ñồ 2: Yêu cầu ñược lấy ra từ hàng ñợi, xử lý và gửi kết quả vào hàng ñợi
kết quả. [1]
: Queue : Queue
: clsTextListener : clsTextListener host : clsHostTelnethost : clsHostTelnet : clsHostInf : clsHostInf : clsPing : clsPing atc : clsTelnetatc : clsTelnet pubtopic :
clsTopicPublisher
pubtopic :
clsTopicPublisher : Topic : Topic : Host : Host
1: onMessage
2: new()
3: setupService(host,sub)
4: getIP(host)
5: khong ton tai host
6: new()
7: sendToTopicClient(msg:Khong ton tai host)
9: sendTextMessage(msg)
8: newpublisher()
10: pingTest(ip)
11: ping command
12: reply
16: new(ip,port)
13: sendToTopicClient(msg:Khong ket noi)
14: newPublisher()
15: sendTextMessage(msg)
18: setupService(msg)
17: setMsg()
19: msg
20: sendToTopicClient(msg)
21: newPublisher()
22: sendTextMessage(msg)
Hình 3.3.3.2.4.2 -Biểu ñồ tuần tự thực hiện yêu cầu
98
Sơ ñồ 3: Hệ thống tác nghiệp ñăng ký là thuê bao của dịch vụ Web ñể tự
ñộng nhận kết quả từ hàng ñợi kết quả.[1]
:
HeThong_DieuHanh_TacNghiep
:
HeThong_DieuHanh_TacNghiep
: clsService : clsService : clsTopicSubcriber : clsTopicSubcriber : Topic : Topic
1: getJMSTopicResult
2: new()
3: getSynchronousMessage
Hình 3.3.2.4.3 - Biểu ñồ tuần tự nhận kết quả
3.3.2.5 Kết quả triển khai sử dụng
Chúng tôi xin trình bày giao diện web của một số phần mềm ðiều hành sửa
chữa và phát triển thuê bao sử dụng dịch vụ Web trên:
- Giao diện ño thử thông tin chất lượng ñường dây.
Hình 3.3.2.5.1 - Giao diện ño thử chất lượng
- Giao diện truy vấn thông tin thuê bao
Hình 3.3.2.5.2 - Giao diện truy vấn thông tin thuê bao
99
Giao diện chương trình Phát triển thuê bao thực hiện nghiệp vụ treo/khôi
phục nợ cước và tháo hủy dịch vụ thuê bao
Hình 3.3.2.5.3 - Giao diện báo cáo trạng thái thực hiện treo/khôi phục nợ cước
100
KẾT LUẬN
ðánh giá kết quả
Luận văn ñã trình bày các khái niệm cơ bản về SNMP như mô hình hoạt
ñộng, cấu trúc quản lý thông tin(SMI) và phương thức quản lý thông tin cơ
sở(MIB), ñịnh dạng thông ñiệp, các phương thức hoạt ñộng của SNMP và giới thiệu
một số công cụ triển khai, xây dựng, khai thác SNMP. Kiến trúc, ñịnh dạng XML
của các thông ñiệp, cấu trúc nội dung các thông ñiệp SOAP, cấu trúc nội dung tệp
wsdl, mô hình ñăng ký và công bố dịch vụ Web UDDI, mô hình bảo mật thông ñiệp
SOAP. Mô tả các kiểu dữ liệu trong SNMP và dịch vụ Web.
Dựa trên những kiến thức tiếp thu ñược về SNMP và dịch vụ Web, chúng tôi
ñã thiết kế và xây dựng một số dịch vụ Web thực hiện khai thác thuê bao internet và
ñiện thoại cố ñịnh. Hiện tại dịch vụ Web ñã ñược triển khai áp dụng trong hệ thống
ñiều hành sửa chữa và phát triển thuê bao của VNPT Hà nội và thu ñược kết quả tốt.
Khi sử dụng các dịch vụ Web, làm cho phạm vi và ñối tượng tham gia khai thác hệ
thống DSLAM và tổng ñài ñiện thoại ñã ñược mở rộng tới từng nhân viên kỹ thuật
và giao dịch. Giao diện khai thác ñược tập trung vào một hệ thống duy nhất. Cho
phép nhân viên khai thác truy vấn thông tin thuê bao trong quá trình lắp ñặt, sửa
chữa, tư vấn phát triển dịch vụ, kịp thời ñưa ra quyết ñịnh hỗ trợ khi cần thiết. Hệ
thống ñã ñáp ứng ñầy ñủ các yêu cầu ñã ñề ra khi tiến hành xây dựng.
Hàng ngày, có khoảng 10 000 yêu cầu vào hệ thống cung cấp dịch vụ
internet và khoảng 100/tổng ñài yêu cầu ño thử và treo/khôi phục nợ cước thuê bao
ñiện thoại cố ñịnh. Hệ thống còn cho phép thực hiện tự ñộng hóa một số nghiệp vụ,
thu thập thông tin phục vụ công tác ñánh giá chất lượng mạng lưới. Thực sự là một
kênh kết nối trong suốt giữa người sử dụng và hệ thống thiết bị, bỏ qua các thao tác
trung gian không cần thiết.
Hướng phát triển tiếp theo
- Triển khai tìm hiểu và áp dụng quản lý các thiết bị mạng của Cisco,
Alcatel,….
- Mở rộng khả năng quan trắc lưu lượng mạng IP bằng SNMP.
101
Tự ñánh giá
Mặc dù ñã cố gắng ñể hoàn thiện ñề tài, nhưng chắc chắn không thể tránh ñược
những thiếu sót, em rất mong nhận ñược sự chỉ bảo và giúp ñỡ của các thầy cô giáo,
cùng với sự góp ý kiến của những ai quan tâm.
102
TÀI LIỆU THAM KHẢO
Tiếng Việt 1. ðoàn Văn Ban (2011), “Giáo trình Phân tích, thiết kế hướng ñối tượng với
UML”, Viện CNTT. 2. Trần Vĩnh Thanh (2006), “Quản trị mạng tập trung trên nền WEB sử dụng
công nghệ SNMP, CGI và CORBA cho hệ thống cung cấp dịch vụ Digital Subscriber Line (DSL) của Bưu ñiện Hà nội” - Luận Văn Thạc sỹ khoa học - Ngành: Xử lý thông tin và truyền thông.
Tiếng Anh 3. 3WC working Group (2004), “Web Services Architecture”,
http://www.w3.org/TR/ws-arch/. 4. Charles M. Kozierok (2010), "TCP/IP Simple Network Management Protocol
(SNMP) Protocol", http://www.tcpipguide.com. 5. David Chappell, Tyler Jewell (2002), "The Java™ Webservice Services",
O'Reilly, United States of America. 6. Douglas Mauro, Kevin Schmidt (2005), “Essential SNMP, 2nd Edition”,
O'Reilly, United States of America. 7. Eric Armstrong, Jennifer Ball, Stephanie Bodoff, Debbie Bode Carson, Ian
Evans, Dale Green, Kim Haase, Eric Jendrock (2005), "The J2EE1.4 Tutorial", Sun Microsystems.
8. Ethan Cerami (2002), “Web Services Essentials, First Edition”, O'Reilly, United States of America.
9. Gustavo Alonso (2004), “WS-SOA-Security - Web Services - Concepts, Architectures and Applications”, Web Services - Concepts, Architectures and Applications, Computer Science DepartmentSwiss Federal Institute of Technology (ETHZ), slide 9.
10. Kim Haase (2002), “Java™ Message Service API Tutorial”, Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303 U.S.A.
11. The Internet Engineering Task Force(IETF), “Request For Comments(RFC)”, http://www.ietf.org/rfc.html.
12. Tom Bellwood (2002), “Understanding UDDI” , Senior Technical Staff Member, EMC, IBM inc.
13. Wikipedia,“Simple_Network_Management_Protocol”, http://en.wikipedia.org/wiki/.