Tiêu chuẩn Dịch vụ Web – Địa chỉ hóa (WS-Addressing) 

Đặc tả kỹ thuật WS-Addressing định nghĩa một tiêu chuẩn để kết hợp thông tin địa chỉ thông điệp vào các thông điệp dịch vụ web. WS-Addressing cung cấp một phương pháp giải quyết thống nhất cho các thông điệp SOAP được truyển tải đồng bộ hoặc bất đồng bộ...

I.  Giới thiệu về WS-Addressing

Đặc tả kỹ thuật WS-Addressing định nghĩa một tiêu chuẩn để kết hợp thông tin địa chỉ thông điệp vào các thông điệp dịch vụ web. WS-Addressing cung cấp một phương pháp giải quyết thống nhất cho các thông điệp SOAP được truyển tải đồng bộ hoặc bất đồng bộ. Ngoài ra, nó cung cấp các tính năng địa chỉ để giúp các nhà phát triển dịch vụ web xây dựng các ứng dụng xung quanh một loạt các mẫu thông điệp, vượt ra ngoài việc trao đổi thông thường giữa các yêu cầu và phản hồi. Bài viết này giới thiệu WS-Addressing, mô tả các thành phần và khám phá giá trị tiềm năng của nó cho các nhà phát triển.

Các đặc tả kỹ thuật của dịch vụ web (được kí hiệu như WS-*) là kết quả làm việc giữa các nhà cung cấp công nghệ lớn như Microsoft, Sun, BEA, IBM, và SAP, trong đó bao gồm cả WS-Addressing. Đặc tả được phát triển dưới sự bảo trợ của World Wide Web Consortium (W3C).  Đặc tả WS-Addressing được công bố bởi W3C  tháng 8 năm 2004, cung cấp một tiêu chuẩn để biểu diễn thông tin địa chỉ thông điệp trong các dịch vụ web và các mô tả dịch vụ.

Tất cả các thông số kỹ thuật của WS- * được thiết kế trên SOAP. Chúng xác định các lược đồ XML trong khối tiêu đề của một thông điệp SOAP. WS-Addressing độc lập với các đặc tả WS- * khác nhưng có thể được sử dụng kết hợp với chúng. Ví dụ, một ứng dụng có thể sử dụng WS-Addressing để xác định địa chỉ nguồn và đích của thông điệp.

WS-Addressing cũng duy trì một kết nối liên tục với Ngôn ngữ mô tả dịch vụ Web 1.1 (WSDL 1.1). Nó mở rộng và kết hợp một số khái niệm từ WSDL. Các nhà phát triển dịch vụ web có thể sử dụng một trong hai hoặc cả hai tiêu chuẩn, tùy thuộc vào nhu cầu của họ. WSDL cung cấp bộ từ vựng để mô tả một dịch vụ theo cả thuật ngữ trừu tượng (các tin nhắn được gửi và nhận) và các thuật ngữ cụ thể (định dạng truyền tải có dây). WS-Addressing sử dụng các khái niệm "dịch vụ" và "cổng" của WSDL.

WS-Addressing hiện được xuất bản dưới dạng ba đặc tả kỹ thuật riêng biệt, WS-Addressing Core (Đặc tả cốt lõi địa chỉ dịch vụ Web) , WS-Addressing SOAP Binding (Ràng buộc SOAP địa chỉ dịch vụ Web) và WS-Addressing WSDL Binding (Ràng buộc WSDL địa chỉ dịch vụ Web). Đặc tả WS-Addressing Core mô tả các thuộc tính trừu tượng và các đặc tả WS-Addressing Binding  mô tả phương thức trình diễn các thuộc tính đó trong SOAP và WSDL tương ứng.

SOAP không cung cấp cách thức để chỉ ra địa chỉ thông điệp được gửi tới, phương thức trả lại một phản hồi, và nơi báo cáo các thông điệp lỗi. Mọi vấn đề này đều được đẩy lên lớp truyền tải để xử lý (transport layer). Ví dụ, khi một yêu cầu SOAP chuẩn được gửi qua HTTP, URI của yêu cầu HTTP đóng vai trò là đích đến của thông điệp. Thông điệp phản hồi được đóng gói trong HTTP và được máy khách nhận qua kết nối HTTP. Khi một thông điệp yêu cầu SOAP được gửi bất đồng bộ thông qua JMS (Java Message Service (Dịch vụ thông điệp Java), một đích đến của các phản hồi có thể được xác định trong các tiêu đề thư JMS, và được tích hợp vào nội dung thư.

Việc địa chỉ hóa ở lớp truyền tải cho nhiều dịch vụ hiện có là cần thiết. WS-Addressing định nghĩa cách thức để định tuyến một thông điệp qua nhiều nút truyền tải hoặc gửi phản hồi tới bên thứ ba. Ví dụ, một ứng dụng máy khách có thể gửi một yêu cầu qua JMS và yêu cầu nhận phản hồi thông qua e-mail hoặc SMS. Để kích hoạt các loại ứng dụng này, WS-Addressing kết hợp truyền tải, trả lời và xử lý lỗi vào một phong bì SOAP. Ví dụ sau minh họa một thông điệp SOAP điển hình bằng cách sử dụng WS-Addressing:

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"

                xmlns:wsa="http://www.w3.org/2004/12/addressing">

    <S:Header>

        <wsa:MessageID>

            http://example.com/SomeUniqueMessageIdString

        </wsa:MessageID>

        <wsa:ReplyTo>

            <wsa:Address>http://myClient.example/someClientUser</wsa:Address>

        </wsa:ReplyTo>

        <wsa:FaultTo>

            <wsa:Address>http://myserver.example/DemoErrorHandler</wsa:Address>

        </wsa:FaultTo>

        <wsa:To>http://myserver.example/DemoServiceURI</wsa:To>

        <wsa:Action>http://myserver.example/DoSomething</wsa:Action>

    </S:Header>

    <S:Body>

         <!-- The message body of the SOAP request appears here -->

    </S:Body>

</S:Envelope>

II. Một số đặc điểm, tính năng của WS-Addressing

II.1 Mã hóa

WS-Addressing cũng định nghĩa một tiêu chuẩn, bao gồm các thuộc tính dịch vụ, được gán trong một địa, được sử dụng trong việc định tuyến thông điệp tới một dịch vụ. Các thuộc tính này đặc biệt hữu ích cho việc tạo ra các dịch vụ web trạng thái (là các dịch vụ có thể nhận được một loạt các yêu cầu từ một máy khách cụ thể và nhớ một số thông tin trạng thái giữa các yêu cầu đó)

II.2 Cấu trúc cốt lõi

WS-Addressing đưa ra 2 khái niệm mới về dịch vụ web: tham chiếu endpoint  và các thuộc tính địa chỉ thông điệp. "Endpoint" là một thuật ngữ được thiết lập cho các đích đến mà tại đó một dịch vụ web có thể được truy cập. Tham chiếu endpoint là mô hình mới cho việc mô tả các đích đến này. Thuộc tính địa chỉ thông điệp, có thể bao gồm một hoặc nhiều tham chiếu endpoint, cung cấp ngữ cảnh cho thông tin đích đó.

II.3 Phân tích một tham chiếu endpoint

Tham chiếu endpoint được định nghĩa là một kiểu phức trong lược đồ WS-Addressing. Tham chiếu endpoint chứa một địa chỉ (một URI), các thuộc tính tham chiếu, tham số tham chiếu, một kiểu cổng, tên dịch vụ và các phần tử chính sách (được xác định bởi đặc tả WS-Policy). Thành phần yêu cầu bắt buộc của tham chiếu endpoint là địa chỉ, vì vậy, có thể hiểu về bản chất, tham chiếu endpoint là một URI:

<wsa: Địa chỉ> http://ws.example.com/myservice </ wsa: Địa chỉ>

Các yếu tố khác của tham chiếu endpoint đều là tùy chọn, giúp ngưởi dùng dễ dàng chỉ sử dụng những gì họ cần. Các kiểu cổng và các thành phần tên dịch vụ rất giống với các kiểu cổng và thành phần trong WSDL. WSDL định nghĩa một kiểu cổng như một tên định danh gắn liền với một tập hợp các hoạt động trừu tượng.

Một khía cạnh quan trọng của tham chiếu endpoint là khả năng đính kèm dữ liệu từ không gian tên XML thông qua các thuộc tính tham chiếu, hoặc các tham số tham chiếu. Cả hai thành phần này là các tập hợp của các thuộc tính và giá trị giúp người lập trình có thể sử dụng để kết hợp các phần tử từ không gian tên XML của riêng họ vào tham chiếu endpoint. Sự khác biệt chính giữa một thuộc tính tham chiếu và một tham số tham chiếu không phải là định dạng mà là mục đích sử dụng

Thuộc tính tham chiếu được sử dụng để xác định endpoint mà tại đó dịch vụ được triển khai. Hai tham chiếu điểm cuối chia sẻ một URI nhưng chỉ định các giá trị thuộc tính tham chiếu khác nhau đại diện cho hai dịch vụ khác nhau. Thuộc tính tham chiếu được sử dụng để gửi yêu cầu đến các dịch vụ thích hợp.

Ngược lại, các tham số tham chiếu có nghĩa là xác định các tài nguyên được quản lý bởi một dịch vụ cụ thể. Tham số tham chiếu cho một dịch vụ biết về các tài nguyền cần quản lý. Các tham số này không xác định dịch vụ. Hai tham chiếu endpoint với các tham số tham chiếu khác nhau , có thể cùng tham chiếu đến một dịch vụ.

Ví dụ sau đây cho thấy một tham chiếu endpoint cho một dịch vụ cung cấp thông tin dự báo thời tiết cho công chúng. Các thông tin dự báo chi tiết được cung cấp cho các khách hàng trả tiền. URI của dịch vụ được xác định trong phần tử Address. Thuộc tính tham chiếu cho biết rằng yêu cầu là dành cho phiên bản dịch vụ cơ bản. Tham số tham chiếu cho biết thành phố mà chúng tôi đang yêu cầu dự báo:

<wsa:EndpointReference xmlns:wsa="..." xmlns:example="...">
   <wsa:Address>http://example.com/weather</wsa:Address>
   <wsa:ReferenceProperties>
       <example:ServiceLevel>Basic</example:ServiceLevel>
   </wsa:ReferenceProperties>
   <wsa:ReferenceParameters>
       <example:CityCode>NYC</example:CityCode>
   </wsa:ReferenceParameters>
</wsa:EndpointReference>

II.4 Các thuộc tính địa chỉ thông điệp

Như đã giải thích ở trên, các tham chiếu endpoint được sử dụng trong các thuộc tính địa chỉ thông điệp. Các tham số địa chỉ thông điệp này xác định tập hợp đầy đủ các thông tin địa chỉ có thể được gắn vào một thông điệp SOAP. Hầu hết các trường là tùy chọn; những trường bắt buộc duy nhất là các trường To (Đến) và Action (Hành động). Mỗi trường xác định một URI. Trong trường hợp một yêu cầu gửi qua HTTP, các trường “To” và “Action” này cùng sử dụng  một URI.

Trong trường hợp yêu cầu không phải gửi qua HTTP, URI của trường “To” có thể khác với URI của trường “Action”. Yêu cầu được gửi đến URI của trường To.  URI của trường “Action” cho biết hành động cần thực hiện. URI của Action phải đại diện cho một dịch vụ tương ứng với loại cổng WSDL. Ví dụ, một yêu cầu được gửi qua e-mail hoặc SMS có thể đi đến một đích,  không được đại diện bởi một loại cổng WSDL. Việc tách URI của trường “To” và URI của trươờng “Action”, cho phép cấu hình rất nhiều tính linh hoạt hơn trong các đích đến của dịch vụ web. Ví dụ, một địa chỉ email có thể nhận được các yêu cầu cho nhiều dịch vụ, tất cả các dịch vụ được xác định bởi giá trị URI của trường “Action” của các dịch vụ đó, URI của trường “To” xác định định "where" (địa điểm) và URI của trường Action xác định "what” (cái gì):

<!-- Message 1 -->
<wsa:To>mailto:ws@example.com</wsa:To>
<wsa:Action>http://example.com/aservice</wsa:Action>
// ...
<!-- Message 2 -->
<wsa:To>mailto:ws@example.com</wsa:To>
<wsa:Action>http://example.com/anotherservice</wsa:Action>

II.5 WS-Addressing cho các nhà phát triển

Các công cụ cho các nhà phát triển dịch vụ  làm việc với WS-Addressing đã được xây dựng  nhưng chưa được phổ biến rộng rãi. Nếu các ứng dụng dịch vụ web hiện tại xây dựng dựa trên WebLogic Workshop, Apache Axis hoặc  dựa trên một công cụ khác tạo ra một giao diện dịch vụ web cho một API Java, thì các ứng dụng này cần phải đợi cho đến khi các môi trường đó mở rộng để có thể kết hợp WS-Addressing.

Đối với các ứng dụng sử dụng các dịch vụ web để truy cập HTTP từ xa, WS-Addressing không phải là một giải pháp đột phá. Bởi vì một yêu cầu và phản hồi HTTP xảy ra đồng bộ qua một kết nối HTTP, việc địa chỉ hóa đóng vai trò quan trọng đối với dịch vụ web. Các giá trị của WS-Addressing trên HTTP là  không thực sự  rõ ràng tại thời điểm này. Nếu các dịch vụ web chỉ phục vụ các máy khách HTTP, thì các đặc tả WS-* cung cấp đẩy đủ các chức năng cho các dịch vụ web và WS-Addressing sẽ không trở nên thực sự cần thiết vào thời điểm này.

WS-Addressing cung cấp nhiều tính năng cho các nhà phát triển đang sử dụng các dịch vụ web trên các đường truyền không đồng bộ. Sử dụng một mô hình địa chỉ nhất quán trên nhiều kênh truyền, có thể đơn giản hóa một số vấn đề tích hợp. Ngoài ra, việc này còn giúp các nhà phát triển triển khai các hệ thống, trong đó người điều phối gửi yêu cầu đến một trong một số dịch vụ có liên quan bằng cách sử dụng tham chiếu endpoint. Khi điện toán di động trở nên quan trọng, các dịch vụ web không đồng bộ sẽ rất hữu ích cho việc hỗ trợ các máy khách di động. Một mô hình chung cho việc địa chỉ hóa, có thể giúp dễ dàng tạo ra một dịch vụ web cho nhiều máy khách không đồng bộ.

II.6 Các tiêu đề thông tin của thông điệp

Phần này định nghĩa mô hình và cú pháp của tiêu đề thông tin của thông điệp. Các tiêu đề thông tin của thông điệp  bổ sung thêm cho một thông điệp với các thuộc tính trừu tượng sau đây. Các thuộc tính này cho phép nhận dạng và xác định vị trí của các endpoint trong một tương tác. Một nguồn sẽ gửi một thông báo đến một đích đến mà không cần định nghĩa thêm về tương tác.

“Request Reply” (Phản hồi Yêu cầu) là một mẫu tương tác chung, bao gồm một thông báo ban đầu được gửi bởi một endpoint nguồn (người yêu cầu) và một thông điệp tiếp theo được gửi từ đích đến quay lại nguồn (người phản hồi). Một phản hồi có thể là một thông điệp ứng dụng, một lỗi hoặc bất kỳ thông điệp nào khác.

Các thuộc tính bên dưới hỗ trợ thông điệp một chiều, các phản hồi yêu cầu và bất kỳ mẫu tương tác nào khác:

[destination] (điểm đến): URI (bắt buộc) - Địa chỉ của người dự định nhận thông điệp này.

[source endpoint] (điểm cuối nguồn): tham chiếu điểm cuối (0..1) - Tham chiếu endpoint (điểm cuối) của nguồn thông điệp được gửi đi

[reply endpoint] (điểm cuối phản hồi): tham chiếu điểm cuối (0..1)Một tham chiếu endpoint xác định người nhận để trả lời thông điệp này. Nếu một thông điệp trả lời được mong đợi, một thông điệp PHẢI chứa một [reply endpoint] (điểm cuối trả lời). Người gửi PHẢI sử dụng nội dung của [reply endpoint] (điểm cuối trả lời) để xây dựng thông điệp trả lời. Nếu không có [reply endpoint], nội dung của [source endpoint] (điểm cuối của nguồn) có thể được sử dụng để xây dựng một thông điệp cho nguồn.

[fault endpoint] (điểm cuối lỗi): tham chiếu điểm cuối (0..1)

Một tham chiếu điểm cuối xác định người nhận cho các lỗi liên quan đến thông báo này. Khi xây dựng một thông báo lỗi, người gửi PHẢI sử dụng nội dung của [fault endpoint] (điểm cuối lỗi) của thông điệp trả lời để xây dựng thông báo lỗi. Nếu không có [fault endpoint], người gửi CÓ THỂ sử dụng nội dung của [reply endpoint] (điểm cuối trả lời) để xây dựng thông báo lỗi. Nếu cả [fault endpoint] và [reply endpoint] đều không xuất hiện, người gửi CÓ THỂ sử dụng nội dung của [source endpoint] (điểm đầu cuối nguồn) để xây dựng thông báo lỗi. Thuộc tính này có thể không xuất hiện nếu người gửi không thể nhận được thông báo lỗi (ví dụ: là thông báo ứng dụng một chiều).

[action] (hành động): URI (bắt buộc)

Một định danh duy nhất xác định ngữ nghĩa của thông điệp này. Nó được khuyến nghị rằng giá trị của thuộc tính [action] là một URI xác định đầu vào, đầu ra, hoặc thông báo lỗi trong loại cổng WSDL. Một hành động có thể được liên kết một cách rõ ràng với các định nghĩa WSDL tương ứng. Nếu ngoài thuộc tính [action], một SOAP Action URI được mã hóa trong một yêu cầu, URI của SOAP Action PHẢI giống như URI được chỉ định bởi thuộc tính [action].

[message id] (định danh thông điệp): URI (0..1)

URI xác định duy nhất một thông điệp theo thời gian và không gian. Không có hai thông điệp nào có mục đích ứng dụng riêng biệt có thể cùng chia sẻ một thuộc tính [message id].  Một thông điệp CÓ THỂ được truyền lại nếu thất bại trong lần đầu gửi và CÓ THỂ sử dụng cùng một thuộc tính [message id].

[relationship] (mối quan hệ): (QName, URI) (0..unbounded)

Một cặp giá trị cho biết mối liên hệ giữa thông điệp này với một thông điệp khác. Kiểu mối quan hệ được xác định bởi một QName. Thông điệp liên quan được xác định bởi một URI tương ứng với thuộc tính [message id] của thông điệp có liên quan.

Đặc tả kỹ thuật này có một loại quan hệ được xác định trước:

QName

Mô tả

wsa:Reply

Thông báo rằng đây là phản hồi của thông điệp được xác định bởi URI

Thông điệp trả lời PHẢI chứa thuộc tính [relationship] bao gồm wsa: Reply và thuộc tính message id của thông điệp yêu cầu. Việc gửi thông điệp đến dựa trên hai thuộc tính của thông điệp, trong đó trường "destination" và "action"  xác định vị trí  đích đến và mục đích của thông điệp.

Do phạm vi của các công nghệ mạng hiện đang được sử dụng rộng rãi (ví dụ, NAT, DHCP, tường lửa), nhiều triển khai không thể gán một URI ( có ý nghĩa toàn cầu) cho một endpoint đã cho. Để cho phép các endpoint "ẩn danh" này khởi tạo các mẫu trao đổi thông điệp và nhận trả lời, WS-Addressing định nghĩa URI phổ biến sau để sử dụng cho các endpoint   không có URI ổn định, có thể phân giải, như sau:

http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous

III. Kết luận

WS-Addressing được sử dụng phổ biến cho các dịch vụ web nhằm địa chỉ hóa các thông điệp, cung cấp một phương thức nhất quán cho các thông điệp đóng gói dưới dạng SOAP truyển tải đồng bộ hoặc bất đồng bộ.  Trong Thông tư số 39/2017/TT-BTTTT ngày 15/12/2017 của Bộ trưởng Bộ Thông tin và Truyền thông Công bố Danh mục tiêu chuẩn kỹ thuật về ứng dụng công nghệ thông tin trong cơ quan nhà nước quy định Khuyến nghị áp dụng tiêu chuẩn WS-Addressing phiên bản 1.2 và được xếp vào nhóm Tiêu chuẩn về kết nối.

Đỗ Tiến Thành

Tài liệu tham khảo

  1. https://www.oracle.com/technetwork/testcontent/ws-addressing-intro-087619.html
  2. https://msdn.microsoft.com/en-us/library/ms951225.aspx#ws-addressing-2004-08-04-rc1__toc79468955

 

769 Go top

Sự kiện nổi bật

Ý kiến về Trang thông tin điện tử Cục Tin học hóa?
1. Đạt yêu cầu, 1180 phiếu (88 %)
2. Chưa đạt yêu cầu, 107 phiếu (8 %)
3. Cần thêm chủ đề, 57 phiếu (4 %)
Tổng số phiếu: 1344
THÔNG KÊ TRUY CẬP
  • Người trực tuyến Người trực tuyến
    • Khách Khách 131
    • Thành viên Thành viên 0
    • Tổng Tổng 131
    • Tổng lượt truy cập: Tổng lượt truy cập: 12729415