1 ðặc tả WSDL

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

2.4. 1 ðặc tả WSDL

Ngồ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:

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

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

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ố. Ngồ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>

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 ngồ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 ngồ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 ln 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. Ngồi ra để đảm bảo tính tồ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 tồ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 tồ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 tồ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

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

Kiểu dữ liệu XML Schema

2 Lược ñồ tác nghiệp của UDDI