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
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>
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" />
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
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à
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
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 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
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