1 ðặc tả WSDL

2. 3 Khuôn dạng thông ñiệp SOAP

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

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: Có hai vấn ñề quan trọng cần xem xét ở ñây:

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]:

<complexType name="ArrayOfDouble">

</restriction> </complexContent> </complexType> </schema> </types>

Ví dụ khai báo kiểu dữ liệu mới phức tạp hơn:

<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.

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].

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

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

<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>

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>

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

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

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à

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

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].

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 ở

Kiểu PDU và trạng thái lỗi

Kiểu PDU và trạng thái lỗi