Mô tả Wsdl. Tiêu chuẩn dịch vụ web SOAP, WSDL, UDDI

WSDL (Dịch vụ web Ngôn ngữ mô tả) phiên bản 1.1 được xuất bản vào ngày 15 tháng 3 năm 2001. WSDL là định dạng dựa trên XML được sử dụng để mô tả các dịch vụ web bằng cách sử dụng các thông báo chứa thông tin về cách truy cập một dịch vụ web cụ thể. WSDL có thể mở rộng, cho phép bạn mô tả các dịch vụ (dịch vụ) và tin nhắn của chúng, bất kể định dạng tin nhắn hoặc giao thức mạngđược sử dụng để vận chuyển, tuy nhiên, được sử dụng phổ biến nhất là WSDL 1.1 cùng với SOAP 1.1, HTTP GET/POST và MIME. Bởi vì WSDLđược phát triển cùng với SOAP, cùng những người đã tham gia phát triển nó Microsoft, Ariba và IBM. Nếu chúng ta xem xét tài liệu WSDL bằng trực giác, chúng ta có thể nói rằng nó cho phép trả lời 4 câu hỏi:

1) Bạn đang làm gì thế? Câu trả lời cho câu hỏi này được đưa ra dưới dạng phù hợp cho cả nhận thức của con người và dạng có thể nhận biết được bằng máy. Câu trả lời cho người trong thẻ:<tên/>, <tài liệu/>, dành cho ô tô -<tin nhắn/>, <loại điểm>

2) Bạn nói tiếng gì? (bạn đang sử dụng loại nào?) Trả lời trong thẻ:<các loại/>

3) tôi sẽ liên lạc với bạn bằng cách nào? (máy khách sẽ truy cập dịch vụ web như thế nào?): HTTP hoặc SMTP. Câu trả lời nằm ở<ràng buộc/>

4) tôi có thể tìm thấy bạn ở đâu? (tôi có thể tìm thấy dịch vụ web này ở đâu hoặc URL của nó là gì?). Câu trả lời là:<dịch vụ/>

Kết cấu:

Mỗi tài liệu WSDL có thể được chia thành ba phần logic:

1. xác định kiểu dữ liệu - xác định loại gửi và nhận Dịch vụ XML tin nhắn

2. hoạt động trừu tượng - danh sách các hoạt động có thể được thực hiện với tin nhắn

3. liên kết dịch vụ - phương thức gửi tin nhắn

Tài liệu WSDL có thể được tạo bằng tay, nhưng ngôn ngữ được chính thức hóa nghiêm ngặt WSDL cho phép bạn tự động hóa quá trình viết WSDL-các tài liệu. Nhiều công cụ soạn thảo dịch vụ Web chứa các tiện ích tự động tạo WSDL-files mô tả các dịch vụ Web làm sẵn. Ví dụ: Công cụ soạn thảo dịch vụ web Trục Apache chứa một lớp Java2WSDL, tạo WSDL- một tệp thuộc lớp hoặc giao diện Java mô tả một dịch vụ Web. Gói WSTK của IBM, bao gồm Trục, chứa tiện ích java2wsdl, tạo và chạy một đối tượng từ lớp này. Cô ấy làm việc từ dòng lệnh.

Các thành phần tài liệu WSDL

Hãy mô tả các thẻ WSDL được sử dụng phổ biến nhất:

Nhãn là thẻ gốc của tất cả các tài liệu WSDL. Nó định nghĩa một số không gian tên:

1)Không gian tên mục tiêu là không gian tên của dịch vụ web của chúng tôi

2) xmlns – không gian tên tài liệu WSDL tiêu chuẩn

3)xmlns: SOAP_ENC – không gian tên được sử dụng để mô tả mã hóa SOAP


4) xmlns: impl và intf – không gian tên triển khai và định nghĩa dịch vụ web của chúng tôi

· Tài liệu định nghĩa dịch vụ web

· Tài liệu triển khai dịch vụ web

Để đơn giản, theo quy định, họ sử dụng 1 tệp chứa tất cả thông tin

Yếu tố - cung cấp thông tin về dữ liệu được truyền từ điểm cuối này sang điểm cuối khác.

Để mô tả một cuộc gọi RPC, bạn phải tạo một thông báo đầu vào và một thông báo đầu ra.

Trong phần tử này, bạn có thể chỉ định các tham số phương thức bằng cách sử dụng phần tử

Yếu tố mô tả và xác định các hoạt động hoặc phương thức được hỗ trợ bởi dịch vụ web

Các hoạt động có thể có thông báo đầu vào cũng như thông báo lỗi.

Yếu tố - mô tả cách các hoạt động được chỉ định trong một loại cổng sẽ được truyền qua mạng. Bởi vì phần tử sử dụng một loại cổng, nó phải chỉ định một loại được xác định ở đâu đó trước đó trong tài liệu.

Yếu tố - cho biết nơi tìm thấy dịch vụ web

Yếu tố nhập khẩu . Phần tử dịch vụ rất thường được phân bổ cho tài liệu wsdl của nó vì lý do thực tế.

Để cho phép kết hợp nhiều tài liệu wsdl thành một, phần tử nhập được sử dụng. Nó cho phép bạn gộp một tài liệu wsdl này vào một tài liệu khác.

Yếu tố các loại cho phép bạn chỉ định loại dữ liệu được truyền nếu chúng không chuẩn.

WSDL hỗ trợ 4 chế độ hoạt động:

· Hoạt động một chiều hoặc một chiều. Tin nhắn được gửi đến điểm cuối dịch vụ. Trong trường hợp này, thao tác chỉ được mô tả bằng một thông báo đầu vào.

· Yêu cầu-Phản hồi – chế độ phản hồi yêu cầu. Chế độ hoạt động này là phổ biến nhất. Trong chế độ này, mô tả hoạt động chứa thông báo đầu vào và đầu ra và thông báo lỗi tùy chọn.

· Hoạt động kiểu yêu cầu-phản hồi. Trong chế độ này, điểm cuối là máy khách của điểm cuối khác. Định dạng hoạt động tương tự như chế độ phản hồi yêu cầu, nhưng dữ liệu đầu ra được liệt kê trước dữ liệu đầu vào.

· Thông báo hoạt động. Chế độ này là một phiên bản khác của chế độ truyền một chiều nguyên thủy, trong đó điểm cuối sẽ gửi tin nhắn thay vì nhận nó. Hoạt động chỉ chứa một thông báo đầu ra.

Mỗi dịch vụ web cung cấp một tài liệu WSDL (Ngôn ngữ mô tả dịch vụ web) mô tả mọi thứ mà khách hàng cần để làm việc với dịch vụ này. Tài liệu WSDL cung cấp một cách đơn giản và nhất quán để nhà phát triển chỉ định cú pháp gọi bất kỳ phương thức Web nào. Hơn nữa, tài liệu này cho phép bạn sử dụng các công cụ để tự động tạo các lớp proxy, chẳng hạn như các lớp có trong môi trường Visual Studio .NET và .NET Framework. Nhờ những công cụ này, việc sử dụng dịch vụ web cũng dễ dàng như sử dụng một lớp cục bộ.

Tài liệu WSDL dựa trên định dạng XML, theo đó thông tin được chia thành năm nhóm. Ba nhóm đầu tiên là các định nghĩa trừu tượng độc lập với các chi tiết cụ thể về nền tảng, mạng hoặc ngôn ngữ, trong khi hai nhóm còn lại bao gồm các mô tả cụ thể.

giao thức xà phòng

Giao tiếp giữa các dịch vụ web và máy khách của chúng được thực hiện thông qua các tin nhắn ở định dạng XML.

SOAP (Giao thức truy cập đối tượng đơn giản) là giao thức tin nhắn để chọn dịch vụ web.

Ý tưởng chính của tiêu chuẩn SOAP là các thông báo phải được mã hóa theo định dạng XML được tiêu chuẩn hóa.

Ngoài các tin nhắn SOAP, bạn có thể sử dụng các phương thức GET và POST để trao đổi dữ liệu với các dịch vụ .NET Giao thức HTTP.

Ưu điểm của việc sử dụng định dạng SOAP so với các định dạng khác để truyền dữ liệu:

    Mã hóa thành Cấu trúc XML dữ liệu và Bộ dữ liệu với sử dụng SOAP dễ dàng như dữ liệu của các loại vô hướng đơn giản.

    Khi sử dụng tin nhắn SOAP, công cụ bổ sung, chẳng hạn như cho phép bạn dễ dàng thêm các tính năng bảo mật hoặc truy tìm.

    Có bộ công cụ SOAP cho nhiều ngôn ngữ lập trình khác nhau (và thậm chí cả những ngôn ngữ trước đó). Phiên bản Microsoft C++ và Visual Basic). Mặt khác, để cung cấp thông tin liên lạc với dịch vụ thông qua Phương thức NHẬN và POST của giao thức HTTP, rõ ràng bạn sẽ phải tự xây dựng chuỗi truy vấn và sau đó phân tích cú pháp phản hồi.

Chuẩn disco

Tiêu chuẩn DISCO cung cấp cách đơn giản nhất để truy cập các tệp kê khai, cho phép bạn nhóm các tham chiếu đến các dịch vụ web.

Tệp DISCO có thể bao gồm các tệp từ các máy chủ web khác nhau và hỗ trợ "tìm kiếm động" - tìm kiếm tự động thư mục của các tập tin dịch vụ web trên máy chủ.

Tệp kê khai rất hữu ích vì chúng kết hợp nhiều dịch vụ web vào một danh sách duy nhất nhưng chúng không cho phép khách hàng tìm kiếm một loại dịch vụ web cụ thể mà không chỉ định tên công ty đã phát triển dịch vụ đó.

đặc điểm kỹ thuật uddi

Đặc tả UDDI (Mô tả, Khám phá và Tích hợp chung) tránh những vấn đề này bằng cách sử dụng bộ lưu trữ (kho lưu trữ) đặc biệt nơi các doanh nghiệp và tổ chức có thể đặt dữ liệu về các dịch vụ mà họ cung cấp. Hơn 100 công ty đã đi tiên phong trong việc tạo ra công nghệ UDDI (có thể tìm thấy danh sách đầy đủ tại http://www.uddi.org/community.html), bao gồm cả Sun và Microsoft. Bằng cách hợp lực, các công ty này đã phát triển một bản dự thảo đặc tả UDDI, được chuẩn hóa sau 18 tháng.

Thông tin trong kho lưu trữ này phải được cập nhật thủ công. Để đạt được mục đích này, một số "người vận hành nút" duy trì các bản sao giống hệt của kho lưu trữ UDDI. Các công ty này cung cấp kho lưu trữ được chỉ định và quyền truy cập miễn phí vào kho lưu trữ đó để phổ biến các dịch vụ web. Ngoài ra, Microsoft đã đưa vào phiên bản UDDI trong phần mềm Máy chủ Windows.NET để sử dụng trên mạng nội bộ của công ty.

Cửa hàng UDDI chứa thông tin về các doanh nghiệp cung cấp dịch vụ web, loại của từng dịch vụ và mối quan hệ với thông tin và thông số kỹ thuật liên quan đến các dịch vụ đó. Bản thân giao diện UDDI là một dịch vụ web. Để đăng ký hoặc tìm kiếm một dịch vụ, bạn phải gửi tin nhắn SOAP.

Nhược điểm chính của dịch vụ web là hiệu suất thấp hơn và kích thước lớn hơn lưu lượng mạng so với các công nghệ như RMI, CORBA, DCOM do sử dụng tin nhắn văn bản XML.

Ngôn ngữ mô tả dịch vụ web (WSDL)

Trong một số ví dụ vừa qua, bạn có thể đã thấy một số đoạn mã WSDL. Hãy nhớ lại rằng WSDL là một ngữ pháp dựa trên XML được thiết kế để mô tả cách các máy khách bên ngoài có thể tương tác với các phương thức Web có sẵn thông qua đến địa chỉ này URL trong mỗi giao thức truyền thông được hỗ trợ. Theo nhiều cách, một tài liệu WSDL có thể được coi là một "hợp đồng" giữa máy khách dịch vụ Web và chính dịch vụ Web đó. Đây là một ngôn ngữ kim loại khác. Cụ thể, WSDL được sử dụng để mô tả những đặc điểm sau bất kỳ phương pháp Web có sẵn nào:

Tên phương thức Web XML;

Số lượng, loại và thứ tự các tham số (nếu có);

Kiểu trả về (nếu được cung cấp);

Các điều kiện gọi HTTP GET, HTTP POST và SOAP.

Trong hầu hết các trường hợp, tài liệu WSDL được máy chủ Web tương ứng tạo ra tự động. Hãy nhớ lại rằng khi bạn thêm hậu tố ?wsdl vào địa chỉ URL trỏ tới tệp *.asmx, máy chủ Web sẽ tạo tài liệu WSDL cho dịch vụ Web XML được chỉ định.

http://localhost/SomeWS/theWS.asmx?wsdl

Nhưng nếu IIS tự động tạo ra tài liệu WSDL cho một dịch vụ Web XML nhất định thì tại sao bạn lại cần hiểu biết sâu sắc về cú pháp của dữ liệu WSDL được tạo ra? Câu trả lời thường phụ thuộc vào cách sử dụng dịch vụ của bạn ứng dụng bên ngoài. Đối với các dịch vụ Web XML dành cho mục đích sử dụng "nội bộ", WSDL do máy chủ Web tạo ra thường là đủ.

Trong khi đó. Hoàn toàn có thể bắt đầu phát triển một dịch vụ Web XML bằng cách tạo một tài liệu WSDL theo cách thủ công (như đã thảo luận ở trên). Ý tưởng chính của việc bắt đầu phát triển bằng cách tạo tài liệu WSDL có liên quan đến vấn đề tương thích. Hãy nhớ rằng trước khi có đặc tả WSI, các công cụ xây dựng dịch vụ Web khác nhau thường tạo ra các mô tả WSDL không tương thích. Nếu bạn bắt đầu phát triển bằng mã WSDL, bạn có thể xây dựng tài liệu theo yêu cầu.

Như bạn có thể tưởng tượng, việc bắt đầu phát triển dịch vụ Web XML bằng cách tạo một tài liệu WSDL đòi hỏi rất nhiều kiến thức tốt Ngữ pháp WSDL, không được thảo luận trong bối cảnh của chương này. Nhưng chúng ta sẽ xem xét cấu trúc cơ bản Tài liệu WSDL. Khi đã hiểu những điều cơ bản, bạn có thể đánh giá cao tính hữu ích của tiện ích dòng lệnh wsdl.exe.

Bình luận. Thông tin mới nhất về WSDL có thể được tìm thấy tại http://www.w3.org/tr/wsdl.

Xác định tài liệu WSDL

Giấy tờ hợp lệ WSDL mở và kết thúc bằng phần tử gốc ‹định nghĩa>. Bộ mô tả mở đầu thường xác định các thuộc tính xmlns khác nhau. Chúng định nghĩa các không gian tên XML xác định các phần tử con khác nhau. Ở mức tối thiểu, phần tử ‹defations> phải chỉ ra không gian tên nơi chính các phần tử WSDL được xác định (http://schemas.xmlsoap.org/wsdl). Để hữu ích, bộ mô tả mở ‹định nghĩa> cũng phải chỉ định các không gian tên XML xác định các loại đơn giản Dữ liệu WSDL, các kiểu Lược đồ XML, các phần tử SOAP và vùng tên đích. Ví dụ: đây là giao diện của phần ‹định nghĩa>> cho dịch vụ Web máy tính của chúng tôi.

‹wsdl:định nghĩa xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:tns="http://www.IntertechTraining.com/"

xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

xmlns:http="http://schemes.xmlsoap.org/wsdl/http/"

targetNamespace="http://www.IntertechTraining.com/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

‹/wsdl:các định nghĩa>

Trong bối cảnh phần tử gốc bạn có thể tìm thấy năm yếu tố phụ. Hình thức chung Tài liệu WSDL phải giống như thế này.

‹?xml version="1.0" mã hóa="utf-8"?>

‹wsdl:định nghĩa…uma

‹wsdl:các loại>

‹!-- Danh sách các loại có sẵn cho dịch vụ Web này --›

‹wsdl:/types>

‹wsdl:tin nhắn>

‹!-- Định dạng tin nhắn --›

‹wsdl:/tin nhắn>

‹wsdl:portType>

‹!-- Thông tin cổng --›

‹wsdl:/portType>

‹wsdl:ràng buộc>

‹!-- Thông tin ràng buộc --›

‹wsdl:/ràng buộc>

‹wsdl:dịch vụ>

‹!-– Thông tin về chính dịch vụ Web XML --›

‹wsdl:/dịch vụ>

‹wsdl:/định nghĩa>

Như bạn mong đợi, mỗi phần tử con này sẽ chứa các phần tử và thuộc tính bổ sung giúp làm rõ hơn mô tả về các khả năng sẵn có. Chúng ta hãy xem xét từng nút hợp lệ quan trọng nhất.

Phần tử ‹loại>>

Trước tiên, chúng ta sẽ xem xét phần tử ‹types, chứa mô tả về tất cả các loại dữ liệu được dịch vụ Web cung cấp. Bạn có thể biết rằng chính XML định nghĩa một số kiểu dữ liệu "cốt lõi", tất cả đều được định nghĩa trong không gian tên XML http://www.w3.org/2001/XMLSchema (phải được chỉ định trong ngữ cảnh của phần gốc). phần tử ‹ định nghĩa>). Lấy ví dụ: phương thức Subtract() của dịch vụ Web máy tính của chúng tôi, có hai tham số đầu vào kiểu số nguyên. Trong thuật ngữ WSDL, loại thời gian chạy ngôn ngữ phổ biến System.Int32 được mô tả trong ngữ cảnh của phần tử ‹complexType>.

‹s:tên phần tử= "Trừ">>

‹s:trình tự>

‹s:phần tử minOccurs=" 1 "maxOccurs=" 1 "tên=" x"loại=" s: int" /›

‹s:phần tử minOccurs="" 1 "maxOccurs=" 1 "tên=" y"loại=" s: int" /›

‹/s:trình tự>

‹/s:complexType>

‹/s:phần tử>

Số nguyên được trả về bởi phương thức Subtract() cũng được mô tả trong phần tử ‹types.

‹s:tên phần tử= " Trừ phản hồi"›

‹s:complexType>

‹s:trình tự>

‹s:phần tử minOccurs=" 1 " maxOccurs=" 1 "tên=" TrừKết quả"loại=" s: int"/›

‹/s:trình tự>

‹ /s:complexType>

‹/s:phần tử>

Nếu bạn có một phương thức Web trả về hoặc nhận các loại tùy chỉnh dữ liệu, chúng cũng sẽ xuất hiện trong ngữ cảnh của phần tử ‹complexType>. Chúng ta sẽ xem xét chi tiết về cách cung cấp các kiểu dữ liệu .NET tùy chỉnh bằng phương pháp Web sau. Vì lợi ích của ví dụ này, giả sử bạn xác định một phương thức Web trả về một cấu trúc có tên là Point.

Điểm cấu trúc công khai (

chuỗi công khai pointName;

Mô tả WSDL cho "cấu trúc phức tạp" này sẽ trông giống như thế này.

‹s:complexType name=" Điểm"›

‹s:trình tự>

‹s:phần tử minOccurs=" 1 "maxOccurs=" 1 "tên=" x"loại=" s: int" /›

‹s:phần tử minOccurs=" 1 "" maxOccurs=" 1 "tên=" y"loại=" s: int" /›

‹s:phần tử minOccurs=" 0 "maxOccurs=" 1 "tên=" tên điểm"loại=" s:chuỗi" /›

‹/s:trình tự>

‹/s:complexType>

phần tử ‹tin nhắn>

Phần tử ‹message> được sử dụng để xác định định dạng trao đổi yêu cầu và phản hồi cho một phương thức Web nhất định. Vì một dịch vụ Web đơn lẻ cho phép nhiều thông điệp được chuyển giữa người gửi và người nhận nên một tài liệu WSDL duy nhất được phép xác định nhiều thành phần thông báo. Thông thường, các định nghĩa này sử dụng các loại được chỉ định trong phần tử ‹types.

Bất kể số lượng phần tử ‹message> được xác định trong tài liệu WSDL là bao nhiêu, chúng thường "hiện diện" theo cặp. Định nghĩa đầu tiên thể hiện định dạng đầu vào của một thông báo và định nghĩa thứ hai thể hiện định dạng đầu ra của cùng một thông báo. Ví dụ: phương thức Subtract() của dịch vụ web Máy tínhWebService xác định các yếu tố sau.

‹wsdl:tên tin nhắn=" TrừXà PhòngTrong"›

‹wsdl:part name="parameters" element="tns:Subtract" />

‹/wsdl:tin nhắn>

‹wsdl: tên tin nhắn=" TrừXà PhòngRa"›

‹wsdl:part name="parameters" element="tns:SubtractResponse" />

‹/wsdl:tin nhắn>

Ở đây bạn chỉ thấy giao tiếp SOAP của dịch vụ tương ứng. Như đã thảo luận ở phần đầu của chương này, các dịch vụ Web XML có thể được gọi bằng cách sử dụng các phương thức SOAP hoặc HTTP GET và POST. Tuy nhiên, nếu bạn bật giao tiếp HTTP POST (sẽ giải thích sau), WSDL được tạo sẽ hiển thị dữ liệu ‹thông báo> sau.

‹wsdl: tên tin nhắn=" TrừHttpPostTrong"›

‹part name="n1" type="s:string" />

‹part name="n2" type="s:string" />

‹wsdl:/tin nhắn>

‹wsdl:tên tin nhắn=" TrừHttpPostOut"›

‹part name="Body" element="s0:int" />

‹wsdl:/tin nhắn>

Bản thân phần tử ‹tin nhắn không hữu ích lắm. Tuy nhiên, các định nghĩa thông báo này được tham chiếu bởi các phần khác của tài liệu WSDL.

Bình luận. Không phải tất cả các phương thức Web đều yêu cầu cả yêu cầu và phản hồi. Nếu phương thức Web là "một chiều" thì nó chỉ yêu cầu phần tử ‹message> của yêu cầu. Bạn có thể chỉ định một phương thức Web là một chiều bằng cách sử dụng thuộc tính này.

phần tử ‹portType>

Phần tử ‹portType> lồng nhau. Thật dễ dàng để đoán rằng các hoạt động điển hình nhất ở đây phải là SOAP, HTTP GET và HTTP POST. Tuy nhiên, có những hoạt động khác. Ví dụ: thao tác một chiều cho phép máy khách gửi tin nhắn đến một máy chủ Web nhất định nhưng không nhận được phản hồi (điều này tương tự như việc gọi một phương thức mà không mong đợi giá trị trả về). Hoạt động phản hồi yêu cầu cho phép máy chủ gửi yêu cầu trong khi máy khách đang phản hồi (có thể được coi là phần mở rộng của hoạt động phản hồi yêu cầu).

Để minh họa định dạng của phần tử phụ tùy chọn ‹opera, hãy xem xét định nghĩa WSDL cho phương thức Subtract().

‹tên loại cổng wsdl= "Máy tínhWebServiceSoap"›

‹wsdl:tên hoạt động=" Trừ"›

‹wsdl:tin nhắn đầu vào=" tns:Trừ xà phòngTrong" /›

‹wsdl:tin nhắn đầu ra=" tns:SubtractSoapOut" /›

‹ /wsdl:hoạt động>

‹wsdl:/portType>

Lưu ý cách các phần tử ‹input> và ‹output> đề cập đến tên thông báo tương ứng được xác định trong phần tử ‹message>yếu tố bổ sung.

‹wsdl:portType name="CalculatorWebServiceHttpPost">

‹wsdl:tin nhắn đầu vào=" s0: TrừHttpPostIn" /›

‹wsdl:tin nhắn đầu ra= " s0: TrừHttpPostOut" /›

‹ wsdl:/hoạt động>

‹wsdl:/portType>

Cuối cùng, hãy lưu ý rằng nếu một phương thức Web nhất định được mô tả bằng thuộc tính Mô tả, thì phần tử ‹ hoạt động sẽ chứa phần tử ‹tài liệu> lồng nhau.

Phần tử ‹ràng buộc>

Phần tử này chỉ định định dạng chính xác của trao đổi GET, POST và SOAP. Đây là phần tử dài dòng nhất trong số tất cả các phần tử có trong ngữ cảnh của phần tử ‹định nghĩa> gốc. Ví dụ: đây là định nghĩa về phần tử ‹bind> mô tả cách người gọi có thể tương tác với phương thức Web MyMethod(). sử dụng SOAP.

‹wsdl:bind name="СalculatorWebServiceSoap12" type=" tns:Máy tínhWebServiceSoap"›

‹soap12:vận chuyển ràng buộc=" http://schemas.xmlsoap.org/soap/http" /›

‹wsdl:tên hoạt động= " Trừ"›

‹soap12: hoạt động xà phòngAction=" http://www.IntertechTraining.com/Subtract" style="tài liệu" />

‹wsdl:đầu vào>

‹soap12:sử dụng cho cơ thể=" theo nghĩa đen" /›

‹/wsdl:input>

‹wsdl:đầu ra>

‹soap12:sử dụng cho cơ thể=" theo nghĩa đen" /›

‹/wsdl:đầu ra>

‹/wsdl:hoạt động>

‹/wsdl:ràng buộc>

phần tử ‹dịch vụ>

Cuối cùng, chúng ta có phần tử ‹service>, phần tử này chỉ định các đặc điểm của chính dịch vụ Web (ví dụ: URL của nó). Nhiệm vụ chính của phần tử này là mô tả tập hợp các cổng được mở bởi máy chủ Web này. Để đạt được điều này, phần tử ‹services> có thể sử dụng bất kỳ số lượng phần tử ‹port dồi dào nào (đừng nhầm lẫn với phần tử ‹portType>). Phần tử ‹service sẽ trông như thế này đối với Máy tínhWebService.

‹wsdl:tên dịch vụ= "Dịch vụ WebMáy tính"›

‹wsdl:tài liệu xmlns:wsdl ="http://schemas.xmlsoap.org/wsdl/">

Dịch vụ máy tính web tuyệt vời

‹/wsdl:tài liệu>

‹wsdl:tên cổng= "Máy tínhWebServiceSoap" ràng buộc= "tns:Máy tínhWebServiceSoap"

‹xà phòng:địa chỉ vị trí= "http://localhost:1109/CalculatorWebService/Service.asmx"/›

‹/wsdl:port>

‹wsdl:cổng name="Máy tínhWebServiceSoap12" ràng buộc=" tns:Máy tínhWebDịch vụXà phòng12"›

‹soap12:địa chỉ vị trí= "http://localhost:1109/CalculatorWebService/Service.asmx"/›

‹/wsdl:port>

‹/wsdl:dịch vụ>

Vì vậy, như bạn có thể thấy, mã WSDL được máy chủ ITS tự động trả về không quá phức tạp, nhưng vì WSDL là một ngữ pháp dựa trên XML nên mã này khá dài dòng. Tuy nhiên, bây giờ bạn đã hiểu rõ hơn về vai trò của WSDL, vì vậy chúng ta hãy xem xét kỹ hơn một chút về các giao thức truyền thông dịch vụ Web XML.

Bình luận. Hãy nhớ lại rằng không gian tên System.Web.Services.Description chứa nhiều loại cho phép bạn đọc và xử lý mã WSDL thô theo chương trình (hãy tự kiểm tra nếu bạn quan tâm).

Trang 2 trên 3

Mô tả bằng WSDL

SOAP hoạt động rất tốt nếu mọi thứ đều được biết về dịch vụ Web. Tuy nhiên, đây không phải là luôn luôn như vậy. Phương tiện mô tả giao diện để truy cập dịch vụ Web là ngôn ngữ WSDL (Ngôn ngữ mô tả dịch vụ web). Tiêu chuẩn này được IBM, Microsoft và webMethods cùng phát triển. Mỗi công ty trong số ba công ty này đều có cách tiếp cận riêng để phát triển một tiêu chuẩn mô tả các dịch vụ Web: IBM tạo ra NASSL, Microsoft phát triển SCL, và webMethods phát triển WIDL.

Kết quả của sự hợp tác của họ là phiên bản 1.1 của ngôn ngữ WSDL. Về W3C, cần lưu ý rằng, cũng như với SOAP, tập đoàn W3C dựa trên phiên bản 1.1 đã phát triển WSDL 1.2, hiện là khuyến nghị của W3C. Mô tả WSDL của một dịch vụ Web chứa tất cả thông tin cần thiết để sử dụng dịch vụ đó, bao gồm các phương thức có sẵn và các tham số của chúng. Thông tin này được chứa trong năm yếu tố sau:

  • - giao thức được hỗ trợ.
  • - Tin nhắn dịch vụ web (yêu cầu, phản hồi).
  • Tất cả các phương pháp có sẵn.
  • - URI dịch vụ.
  • - các loại dữ liệu được sử dụng

Tất cả thông tin này được lưu trữ trong phần tử gốc của mô tả WSDL , Danh sách bên dưới hiển thị một ví dụ về WSDL , mô tả về dịch vụ Web.

Mô tả WSDL của dịch vụ Web

Vâng... bạn không thể tìm ra nó nếu không có kính, nhưng đây là một trong những tệp WSDL (!) Đơn giản nhất. Thật không may, một trong những hạn chế của phần mở rộng SOAP cho PHP 5 là, không giống như các triển khai SOAP khác, nó không tự động tạo ra các mô tả WSDL (ít nhất là chưa). Chắc chắn lỗ hổng này sẽ được sửa chữa trong các phiên bản PHP sau này.

Nhân tiện!

Để tự động tạo mô tả WSDL, bạn có thể sử dụng các triển khai thay thế của giao thức SOAP trong PHP:

Tìm kiếm thư mục bằng UDDI

Bây giờ chúng ta đã biết cách lấy thông tin về một dịch vụ Web và cách truy vấn nó, chúng ta cần học cách tìm một dịch vụ như vậy. Vì mục đích này, có một cái gì đó tương tự như các Trang Vàng, cụ thể là các cơ quan đăng ký UBR (Cơ quan đăng ký doanh nghiệp toàn cầu) - các thư mục dịch vụ web.

Có một số cơ quan đăng ký như vậy, bao gồm cả IBM, Microsoft, NTT-Com và SAP. Các cơ quan đăng ký này đồng bộ hóa dữ liệu của chúng, vì vậy bạn có thể sử dụng bất kỳ cơ quan đăng ký nào trong số chúng. Phiên bản hiện tại của tiêu chuẩn UDDI là UDDI 3.0, mặc dù hầu hết các triển khai đều sử dụng phiên bản 2. Các nhà phát triển tiêu chuẩn này bao gồm các công ty khổng lồ như HP, Intel, Microsoft và Sun.

Để tương tác với UBR có hai loại API: API truy vấn và API xuất bản. Giao diện API truy vấn (Yêu cầu) là để yêu cầu dịch vụ trong sổ đăng ký UBR và giao diện API xuất bản cho phép nhà phát triển đăng ký dịch vụ của họ. Có vẻ như chỉ còn là vấn đề thời gian trước khi nội dung của sổ đăng ký trở nên đầy thư rác :)

Nhân tiện!

Có các cơ quan đăng ký thử nghiệm được thiết kế để kiểm tra việc đăng ký dịch vụ trước khi đặt chúng vào cơ quan đăng ký "thực".

Đây là giao diện của một yêu cầu dịch vụ Web:

SortByNameAsc sắp xếpByDateDesc %hướng dẫn%

Trong ví dụ trên, bạn có thể thấy yêu cầu UDDI được gói gọn trong một thông báo SOAP nên trông khá quen thuộc. Phản hồi cho yêu cầu cũng là một tài liệu SOAP, được hiển thị bên dưới:

Chuyến tham quan có hướng dẫn về dịch vụ web Dịch vụ web mẫu dành cho Sách hướng dẫn du lịch Hướng dẫn tham quan Dịch vụ StockQuote

Cài đặt

Việc cài đặt phần mở rộng SOAP cho PHP5 khá dễ dàng. Trên Windows, mô-đun này nằm trong thư mục con ext của thư mục cài đặt PHP. Để sử dụng nó, bạn cần thêm dòng sau vào tệp php.ini: tiện ích mở rộng=php_soap.dllĐể hoạt động, mô-đun này yêu cầu nó phải được đưa vào PHP 5 theo mặc định, ít nhất là trong phiên bản Windows.

Dịch vụ web là những công nghệ tích hợp ứng dụng có thể được sử dụng trên Internet. Như một ví dụ về khả năng sử dụng các dịch vụ web, hãy xem xét việc lập kế hoạch du lịch. Thông thường, tình huống này yêu cầu: đặt vé máy bay, đặt phòng khách sạn, thuê ô tô và có thể sử dụng dịch vụ của các công ty địa phương tổ chức các chuyến du ngoạn.

Theo truyền thống sử dụng Internet, bạn sẽ phải truy cập vào máy chủ của hãng hàng không, máy chủ của khách sạn hoặc chuỗi khách sạn, máy chủ của công ty cho thuê xe và máy chủ của công ty chuyên tổ chức các chuyến du ngoạn tại địa điểm bạn chọn . Tất cả những hành động này có thể mất khá nhiều thời gian trước khi bạn đạt được mục tiêu của mình. Đồng thời, không ai trong số các công ty bạn sử dụng sẽ biết kế hoạch của bạn là gì và do đó sẽ không thể tối ưu hóa thời gian của bạn. Vấn đề là các công ty chuyên về một số lĩnh vực nhất định - hãng hàng không, khách sạn, cho thuê ô tô, v.v., trong hầu hết các trường hợp đều đóng cửa và sử dụng các phương tiện lưu trữ và trình bày dữ liệu của riêng họ.

Sẽ thuận tiện hơn khi khởi chạy một ứng dụng nhận thông tin cần thiết từ bạn và thực hiện tất cả các hành động thường ngày - đặt vé, đặt phòng khách sạn, v.v. - một cách tự động mà không cần sự tham gia của bạn. Để thực hiện được điều này, bạn phải sử dụng các dịch vụ web. Hãy xem điều gì sẽ thay đổi trong trường hợp này.

Giả sử một hãng hàng không cung cấp dịch vụ web cho phép các ứng dụng truy xuất danh sách các chuyến bay giữa hai thành phố trong một ngày nhất định. Trong trường hợp này, bạn không cần phải truy cập trang web của hãng hàng không và nhập các tiêu chí tìm kiếm khác nhau - tất cả thông tin cần thiết đều có sẵn trong một tài liệu XML duy nhất. Bây giờ, giả sử rằng một hãng hàng không, khách sạn và đại lý cho thuê ô tô cung cấp các dịch vụ web cho phép bạn mua vé, đặt phòng và thuê ô tô theo chương trình. Trong trường hợp này, bạn có thể kết hợp các cuộc gọi tới tất cả các dịch vụ này thành một ứng dụng duy nhất có thể thực hiện tất cả công việc thường ngày mà không cần sự can thiệp của người dùng.

Tuy nhiên, chức năng của lớp ứng dụng web mới không dừng lại ở đó. Ví dụ: ứng dụng của chúng tôi có thể truy cập định kỳ vào dịch vụ web của hãng hàng không để xác định trạng thái chuyến bay và trong trường hợp bị chậm trễ, có thể thông báo cho dịch vụ khách sạn, dịch vụ cho thuê, v.v. để gia hạn đặt phòng của bạn.

Bên cạnh sự cải thiện rõ rệt về trải nghiệm của khách hàng, việc sử dụng dịch vụ web còn có nhiều lợi ích khác. Ví dụ: nếu đại lý cho thuê ô tô biết chuyến bay của bạn bị hoãn, họ có thể linh hoạt hơn với ô tô của mình. Khi số lượng dịch vụ web tăng lên, chúng ta sẽ thấy nhiều ví dụ phức tạp hơn về cách sử dụng chúng. Tuy nhiên, cần lưu ý rằng việc đưa ra khái niệm dịch vụ web không chỉ đòi hỏi phải sửa đổi nhiều quy tắc kinh doanh và mô hình tương tác giữa các ngành và lĩnh vực của một ngành cụ thể mà còn phải tăng cường tính bảo mật trong trao đổi dữ liệu.

Sau khi xem xét ứng dụng thực tế của các dịch vụ web, hãy chuyển sang các tiêu chuẩn cơ bản của các dịch vụ này.

tiêu chuẩn

Như chúng ta đã biết, các dịch vụ web đều dựa trên các tiêu chuẩn Internet. Các tiêu chuẩn này xác định các giao thức chứ không phải cách chúng được triển khai. Tuyên bố này là chìa khóa thành công của Internet - không công ty nào có thể tác động đến các tiêu chuẩn Internet và đặt ra các quy tắc trò chơi của riêng mình. Ví dụ: các tiêu chuẩn dịch vụ web được các công ty như IBM, Microsoft, Ariba và một số công ty khác cùng phát triển và được thảo luận bởi ủy ban World Wide Web Consortium (W3C).

Các dịch vụ web dựa trên ba tiêu chuẩn web chính:

SOAP (Giao thức truy cập đối tượng đơn giản) - giao thức gửi tin nhắn qua HTTP và các giao thức Internet khác;

WSDL (Ngôn ngữ mô tả dịch vụ web) - ngôn ngữ mô tả giao diện phần mềm của các dịch vụ web;

UDDI (Mô tả, Khám phá và Tích hợp chung) là một tiêu chuẩn để lập chỉ mục các dịch vụ web.

Máy chủ ứng dụng lưu trữ các dịch vụ web và cung cấp chúng thông qua các giao thức HTTP GET, HTTP POST và HTTP SOAP.

Các dịch vụ web hiện có được mô tả trong các tài liệu WSDL, được đặt trên máy chủ ứng dụng hoặc trong các cửa hàng XML đặc biệt. Tài liệu WSDL có thể tham chiếu các tài liệu WSDL và tài liệu XSD (Lược đồ XML) khác mô tả các loại dữ liệu được sử dụng bởi các dịch vụ web. Các cửa hàng XML được sử dụng để quản lý các tài liệu WSDL. Bên trong tài liệu WSDL là địa chỉ (URL) của dịch vụ web. Các dịch vụ web được mô tả và lập chỉ mục trong sổ đăng ký doanh nghiệp chứa địa chỉ (URL) của tài liệu WSDL.

Trong các phần sau, chúng ta sẽ xem xét ba tiêu chuẩn web chính làm cơ sở cho các dịch vụ web - SOAP, WSDL và UDDI - một cách chi tiết hơn.

SOAP - Giao thức truy cập đối tượng đơn giản

SOAP là một tiêu chuẩn để gửi và nhận tin nhắn qua Internet. Giao thức này ban đầu được Microsoft đề xuất như một phương tiện để gọi thủ tục từ xa (RPC, Cuộc gọi thủ tục từ xa) qua HTTP và đặc tả SOAP 1.0 (Userland, Microsoft, Developmentor) có liên quan chặt chẽ với Mô hình đối tượng thành phần. IBM và một số công ty khác, bao gồm cả Lotus, đã có một số đóng góp cho sự phát triển của giao thức này và thông số kỹ thuật của nó đã được gửi đến ủy ban W3C để xem xét.

Đặc tả SOAP xác định một "phong bì" XML để truyền thông báo, một phương thức mã hóa các cấu trúc dữ liệu có lập trình ở định dạng XML và một phương tiện giao tiếp qua giao thức HTTP.

Thông báo SOAP có hai loại: Yêu cầu và Phản hồi. Yêu cầu gọi một phương thức của đối tượng ở xa, phản hồi trả về kết quả thực hiện phương thức này. Dưới đây là ví dụ về yêu cầu ở định dạng SOAP:







HST


Và đây là câu trả lời:



xmlns:SOAP-ENV="http:///phong bì"
SOAP-ENV:encodingStyle="http:///encoding//"


48.6


Đặc tả SOAP xác định định dạng mã hóa, từ đó xác định cách dữ liệu được biểu diễn ở định dạng XML.

WSDL - Ngôn ngữ mô tả dịch vụ web

Để các ứng dụng sử dụng dịch vụ web, giao diện lập trình của chúng phải được mô tả chi tiết - theo quan điểm này, WSDL đóng vai trò tương tự như Ngôn ngữ định nghĩa giao diện (IDL) trong điện toán phân tán. Mô tả có thể bao gồm các thông tin như giao thức, địa chỉ máy chủ, số cổng được sử dụng, danh sách các hoạt động khả dụng, định dạng yêu cầu và phản hồi, v.v.

Một số ngôn ngữ đã được đề xuất để mô tả thông tin này. Một trong số đó là Ngôn ngữ mô tả dịch vụ (SDL), do Microsoft phát triển và đưa vào phiên bản đầu tiên của Bộ công cụ Microsoft SOAP. IBM đã làm lại đặc tả và sử dụng đặc tả Ngôn ngữ đặc tả dịch vụ có thể truy cập mạng (NASSL), đã phát hành Bộ công cụ NASSL như một phần của SOAP4J. Các ý tưởng được triển khai trong NASSL đã ảnh hưởng đến đặc tả Ngôn ngữ hợp đồng SOAP (SCL) do Microsoft đề xuất. Hiện tại, cả hai thông số kỹ thuật (NASSL và SDL/SCL), cũng như các đề xuất từ ​​các công ty khác, đều được tính đến trong đặc tả ngôn ngữ WSDL. Để mô tả logic nghiệp vụ, IBM và Microsoft đang nghiên cứu đặc tả Ngôn ngữ luồng dịch vụ web (WSFL). Dưới đây là ví dụ về khung mô tả dịch vụ trong WSDL:


xmlns:soap="http://(soaporg)/wsdl/soap"
xmlns="http://(soaporg)/wsdl/">

...

...
...


...
...


...

Như chúng ta có thể thấy, mô tả dịch vụ là một tài liệu XML bao gồm một số thành phần, bao gồm mô tả về không gian tên, mô tả về loại và thành phần, thông báo, cổng, cũng như các hoạt động có thể có - yêu cầu và phản hồi.

UDDI - Mô tả, khám phá và tích hợp phổ quát

Mục đích của UDDI là cung cấp cơ chế khám phá các dịch vụ web. UDDI xác định cơ quan đăng ký kinh doanh trong đó các nhà cung cấp dịch vụ web có thể đăng ký dịch vụ và nhà phát triển có thể tìm kiếm các dịch vụ họ cần. IBM, Microsoft và Ariba đã tạo các cơ quan đăng ký UDDI của riêng họ (sắp được sáp nhập vào cơ quan đăng ký web), trong đó các nhà phát triển có thể đăng ký dịch vụ web của họ, sau đó dữ liệu sẽ được tự động sao chép sang các cơ quan đăng ký khác.

UDDI dựa trên bốn loại thành phần: Thực thể kinh doanh, Dịch vụ kinh doanh, Mẫu ràng buộc và Mô hình công nghệ.

Phần tử Thực thể Kinh doanh mô tả ngành cung cấp dịch vụ web này. Phần tử này có thể bao gồm các mô tả danh mục cho một ngành nhất định, tạo điều kiện thuận lợi cho việc tìm kiếm dịch vụ chi tiết hơn.

Dịch vụ kinh doanh là một loại dịch vụ trong một ngành hoặc dịch vụ cụ thể. Mỗi ngành thuộc về một Thực thể kinh doanh cụ thể.

Mẫu ràng buộc và Mô hình công nghệ cùng nhau xác định một dịch vụ web. Mô hình công nghệ chứa mô tả trừu tượng và Mẫu ràng buộc chứa thông số kỹ thuật cụ thể của dịch vụ. Mỗi phần tử Mẫu liên kết thuộc về một phần tử Dịch vụ kinh doanh cụ thể, nhưng nhiều phần tử Mẫu liên kết có thể tham chiếu đến một phần tử Mô hình công nghệ duy nhất.

Bản thân cơ quan đăng ký kinh doanh UDDI là một dịch vụ web SOAP. Nó hỗ trợ các hoạt động tạo, sửa đổi, xóa và tìm kiếm các phần tử thuộc cả bốn loại đã thảo luận ở trên.

Người giám sát khoa học, tóm tắt của sinh viên ICSI – Sergey Kunegin