Thực đơn
trang chủSự cố

Giới thiệu về SOAP. Giao thức SOAP

Bản dịch Brett McLaughlin của Ilya Chekmenev

SOAP là Giao thức truy cập đối tượng đơn giản. Nếu bạn chưa bao giờ nghe nói về nó trước đây, thì bạn phải sống ở một nơi xa xôi, xa nền văn minh. Nó đã trở thành mốt mới nhất trong lập trình web và là một phần không thể thiếu của các dịch vụ web, được sử dụng một cách cuồng nhiệt trong các phát triển web thế hệ mới nhất. Nếu bạn đã nghe nói về .NET của Microsoft, hay "cuộc cách mạng" ngang hàng thì bạn cũng đã nghe nói về các công nghệ dựa vào SOAP (ngay cả khi bạn không biết nó là gì). Không có một, nhưng hai Việc triển khai SOAP từ Apache và Microsoft, có hàng nghìn trang dành riêng cho chúng trên trang hỗ trợ MSDN của họ (http://msdn.microsoft.com/).

Trong bài viết này tôi sẽ cho bạn biết SOAP là gì và tại sao nó lại là một phần quan trọng trong quá trình phát triển mô hình lập trình web. Điều này sẽ giúp bạn bỏ qua các nguyên tắc cơ bản và bắt đầu làm việc với bộ công cụ SOAP. Sau đó, tôi sẽ cung cấp cái nhìn tổng quan nhanh về các dự án SOAP hiện có và đi sâu vào cách triển khai Apache. Bài viết này không nhằm mục đích cung cấp một bức tranh hoàn chỉnh về SOAP; cuốn sách của tôi, Java & XML, Ấn bản thứ 2, sẽ lấp đầy nhiều khoảng trống. Bạn sẽ tìm thấy câu trả lời cho nhiều câu hỏi nảy sinh sau khi đọc bài viết này trong cuốn sách.

Giới thiệu

Đầu tiên bạn cần hiểu SOAP là gì. Bạn có thể đọc ý kiến ​​đầy đủ (và khá dài) của W3C tại http://www.w3.org/TR/SOAP. Sau đó, khi đã tìm ra và loại bỏ hết lớp vỏ trấu, bạn sẽ hiểu rằng SOAP chỉ là một giao thức. Đó là một giao thức đơn giản (không cần phải viết một giao thức mới để sử dụng) dựa trên ý tưởng rằng tại một thời điểm nào đó trong kiến ​​trúc phân tán cần có nhu cầu trao đổi thông tin. Ngoài ra, đối với các hệ thống có khả năng xảy ra tình trạng quá tải và khó khăn trong quá trình xử lý, giao thức này rất thuận lợi vì nó nhẹ và yêu cầu lượng tài nguyên tối thiểu. Cuối cùng, nó cho phép tất cả các hoạt động được thực hiện qua HTTP, điều này giúp bạn có thể vượt qua những thứ phức tạp như tường lửa và bảo vệ bạn khỏi bị nghe lén bằng cách sử dụng ổ cắm trên một số lượng cổng đáng kinh ngạc. Điều quan trọng là bạn nhận ra điều này, còn mọi thứ khác đều là chi tiết.

Tất nhiên, bạn muốn biết những chi tiết này và tôi sẽ không bỏ qua chúng. Có ba thành phần cơ bản trong đặc tả SOAP: đường bao SOAP, bộ quy tắc mã hóa và phương tiện tương tác giữa yêu cầu và phản hồi. Hãy coi thông điệp SOAP như một lá thư thông thường. Bạn có còn nhớ những món đồ xa xưa đựng trong phong bì có tem bưu chính và địa chỉ ghi ở mặt trước không? Sự tương tự này sẽ giúp bạn hiểu khái niệm SOAP như một "phong bì" rõ ràng hơn. Hình 12-1 mô tả các quy trình SOAP dưới dạng tương tự này.

Hình 12-1. Quy trình thông báo SOAP

Hãy ghi nhớ hình ảnh này và hãy xem xét ba thành phần của đặc tả SOAP. Tôi sẽ nói ngắn gọn về từng người trong số họ, đưa ra những ví dụ thể hiện rõ nhất khái niệm này. Ba thành phần chính này làm cho SOAP trở nên quan trọng và có ý nghĩa. Xử lý lỗi, hỗ trợ nhiều loại mã hóa, tuần tự hóa tham số và thực tế là SOAP hoạt động qua HTTP trong hầu hết các trường hợp khiến nó trở nên hấp dẫn hơn các giải pháp khác dành cho giao thức phân tán. SOAP cung cấp khả năng tương tác cao với các ứng dụng khác mà tôi đã trình bày chi tiết hơn trong cuốn sách của mình. Hiện tại, tôi muốn tập trung vào các yếu tố cốt lõi của SOAP.

Phong bì

Phong bì SOAP tương tự như phong bì thư thông thường. Nó chứa thông tin về tin nhắn sẽ được mã hóa trong phần SOAP chính, bao gồm thông tin về người nhận và người gửi, cũng như thông tin về chính tin nhắn đó. Ví dụ: tiêu đề phong bì SOAP có thể cho biết cách xử lý thông báo. Trước khi một ứng dụng bắt đầu xử lý một tin nhắn, nó sẽ kiểm tra thông tin về tin nhắn đó, bao gồm cả việc liệu nó có thể xử lý tin nhắn đó hay không. Không giống như tình huống với các lệnh gọi XML-RPC tiêu chuẩn (bạn có nhớ không? Thông báo XML-RPC, mã hóa, v.v., mọi thứ được kết hợp thành một đoạn XML duy nhất), với SOAP, quá trình xử lý liên tục diễn ra để tìm hiểu điều gì đó về thông báo. Một tin nhắn SOAP điển hình cũng có thể bao gồm kiểu mã hóa sẽ hỗ trợ người nhận xử lý tin nhắn. Ví dụ 12-1 cho thấy một phong bì SOAP kết thúc bằng đặc tả mã hóa.

Ví dụ 12-1: Phong bì SOAP

hộp xà phòng http://www-106.ibm.com/developerworks/library/x-soapbx1.html

Như bạn có thể thấy, mã hóa được đặt bên trong đường bao, cho phép ứng dụng xác định (sử dụng giá trị thuộc tính kiểu mã hóa), liệu nó có thể đọc tin nhắn đến nằm trong phần tử hay không Thân hình. Hãy đảm bảo rằng không gian tên phong bì SOAP là chính xác, nếu không các máy chủ SOAP nhận được tin nhắn của bạn sẽ báo cáo lỗi phiên bản không khớp và bạn sẽ không thể liên lạc với chúng.

Mã hóa

Yếu tố quan trọng thứ hai của SOAP là khả năng mã hóa các kiểu dữ liệu tùy chỉnh. Với RPC (và XML-RPC), mã hóa chỉ có thể được thực hiện trên các loại dữ liệu được xác định trước được hỗ trợ trong bộ công cụ XML-RPC mà bạn đã tải xuống. Việc mã hóa các loại dữ liệu khác yêu cầu bạn phải tự sửa đổi máy chủ và máy khách RPC. Với SOAP, một lược đồ XML có thể được sử dụng khá dễ dàng để xác định các kiểu dữ liệu mới (sử dụng cấu trúc loại phức hợp, được thảo luận trong Chương 2 của cuốn sách của tôi) và những kiểu mới này có thể được biểu diễn bằng XML như một phần của phần chính của SOAP. Nhờ tích hợp Lược đồ XML, bạn có thể mã hóa bất kỳ loại dữ liệu nào trong thông báo SOAP bằng cách mô tả nó một cách logic trong Lược đồ XML.

Gọi

Cách tốt nhất để hiểu cách hoạt động của lệnh gọi SOAP là so sánh nó với thứ gì đó bạn quen thuộc, chẳng hạn như XML-RPC. Nếu bạn nhớ lại, lệnh gọi XML-RPC trông giống như đoạn mã được trình bày trong Ví dụ 12-2.

Ví dụ 12-2. Gọi tới XML-RPC

// Chỉ định bộ xử lý XML (trình phân tích cú pháp) để sử dụng XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Chỉ định máy chủ mà kết nối được thực hiện XmlRpcClient client = new XmlRpcClient("http://rpc.middleearth.com"); // Tạo tham số Vector params = new Vector(); params.addElement(flightNumber); params.addElement(numSeats); params.addElement(creditCardType); params.addElement(creditCardNum); // Yêu cầu Boolean buyTickets = (Boolean)client.execute("ticketCounter.buyTickets", params); // Xử lý phản hồi

Tôi đã tạo một chương trình đơn giản để đặt vé máy bay. Bây giờ hãy xem Ví dụ 12-3, minh họa lệnh gọi SOAP.

Ví dụ 12-3. Gọi tới SOAP

// Tạo tham số Vector params = new Vector(); params.addElement(new Parameter("flightNumber", Integer.class, FlightNumber, null)); params.addElement(new Parameter("numSeats", Integer.class, numSeats, null)); params.addElement(new Parameter("creditCardType", String.class, creditCardType, null)); params.addElement(new Parameter("creditCardNumber", Long.class, creditCardNum, null)); // Tạo một đối tượng Call Call call = new Call(); call.setTargetObjectURI("urn:xmltoday-airline-tickets"); call.setMethodName("buyTickets"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); call.setParams(params); // Phản hồi cuộc gọi res = call.invoke(URL mới("http://rpc.middleearth.com"), ""); // Xử lý phản hồi

Như bạn có thể thấy, cuộc gọi thực tế được đại diện bởi đối tượng Gọi, cư trú bộ nhớ. Nó cho phép bạn chỉ định mục tiêu cuộc gọi, phương thức cuộc gọi, kiểu mã hóa, tham số và nhiều tham số khác không được trình bày trong ví dụ này. Đây là một cơ chế linh hoạt hơn phương pháp XML-RPC, cho phép bạn chỉ định rõ ràng một tập hợp các tham số khác nhau được xác định ngầm trong XML-RPC. Ở phần sau của bài viết này, bạn sẽ tìm hiểu thêm về quy trình cuộc gọi, bao gồm cách SOAP xử lý các yêu cầu không hợp lệ, hệ thống phân cấp lỗi và tất nhiên là kết quả cuộc gọi được trả về.

Sau phần giới thiệu ngắn gọn như vậy, bạn đã biết đủ để hứng thú với điều thú vị này rồi. Bây giờ hãy để tôi giới thiệu cho bạn cách triển khai SOAP mà tôi sắp sử dụng. Tôi sẽ giải thích lý do tại sao tôi chọn nó và xem xét một số ví dụ về mã.

Cài đặt

Bây giờ bạn đã học được những khái niệm cơ bản, đã đến lúc chuyển sang phần thú vị: lập trình. Để làm điều này, bạn sẽ cần một dự án hoặc sản phẩm thuận tiện, dễ tìm thấy hơn so với cái nhìn đầu tiên. Nếu bạn cần một dự án Java cung cấp các khả năng SOAP, bạn không cần phải mất nhiều thời gian để tìm một dự án. Có hai nhóm sản phẩm: thương mại và miễn phí. Như trong cuốn sách của tôi, tôi sẽ tránh đề cập đến các sản phẩm thương mại. Điều này hoàn toàn không phải vì chúng tệ (ngược lại, một số trong số chúng rất xuất sắc), mà bởi vì tôi muốn bất kỳ độc giả nào cũng có thể thử bất kỳ ví dụ nào được đưa ra. Điều này là do khả năng tiếp cận mà nhiều sản phẩm thương mại không có. Bạn phải trả tiền để sử dụng chúng hoặc tạm thời sử dụng chúng trong một khoảng thời gian giới hạn sau khi tải xuống.

Vì vậy, chúng tôi đã tiếp cận một cách suôn sẻ các dự án nguồn mở. Từ lĩnh vực này tôi chỉ có thể đặt tên cho một sản phẩm: Apache SOAP. Nó được đặt tại http://xml.apache.org/soap và cung cấp bộ công cụ SOAP cho Java. Tại thời điểm viết bài, phiên bản 2.2 đã được phát hành, bạn có thể tải xuống từ trang web Apache. Đây là phiên bản mà tôi sẽ sử dụng trong các ví dụ của bài viết này.

Các lựa chọn thay thế khác

Trước khi chuyển sang cài đặt và định cấu hình Apache SOAP, tôi sẽ trả lời một số câu hỏi có thể nảy ra trong đầu bạn. Tôi nghĩ tôi đã giải thích khá rõ ràng lý do tại sao tôi không sử dụng sản phẩm thương mại. Tuy nhiên, bạn có thể đang nghĩ đến một số dự án nguồn mở hoặc liên quan khác mà bạn có thể muốn sử dụng và bạn sẽ ngạc nhiên khi tôi chưa nhận xét về chúng.

Còn IBM SOAP4J thì sao?

Đầu tiên trong danh sách các lựa chọn thay thế là một triển khai của IBM: SOAP4J. Công việc của IBM đã hình thành nên nền tảng của dự án Apache SOAP, giống như XML4J của IBM đã phát triển thành dự án mà ngày nay được gọi là dự án trình phân tích cú pháp XML của Apache Xerces. Người ta giả định rằng việc triển khai IBM sẽ được thiết kế lại, hợp nhất với Apache SOAP. Điều tương tự cũng xảy ra với XML4J của IBM: giờ đây nó chỉ cung cấp gói đóng gói trong Xerces. Điều này chỉ nêu bật các xu hướng - các nhà sản xuất lớn thường hỗ trợ và sử dụng các dự án OpenSource, trong trường hợp này cả hai dự án (Apache và IBM) đều sử dụng cùng một cơ sở mã.

Microsoft có bị loại khỏi cuộc chơi không?

Dĩ nhiên là không. Microsoft và việc triển khai SOAP của nó, cũng như toàn bộ phong trào .NET (được thảo luận chi tiết hơn trong cuốn sách của tôi), là khá quan trọng. Tôi thực sự muốn dành phần lớn thời gian của mình để xem xét chi tiết việc triển khai SOAP của Microsoft, nhưng nó chỉ hỗ trợ các đối tượng COM và không hỗ trợ Java. Vì những lý do này, mô tả như vậy không thể được đưa vào một bài viết về Java và XML. Tuy nhiên, Microsoft (bất chấp tất cả những lời phàn nàn mà chúng tôi, với tư cách là nhà phát triển, về công ty này) đã thực hiện được công việc quan trọng trong lĩnh vực dịch vụ web và bạn sẽ mắc sai lầm nếu loại bỏ nó mà không suy nghĩ, chỉ được hướng dẫn bởi những cảm xúc thô sơ. Nếu bạn có nhu cầu làm việc với các thành phần COM hoặc Visual Basic, tôi khuyên bạn nên thử sử dụng bộ công cụ Microsoft SOAP, có sẵn tại http://msdn.microsoft.com/library/default.asp?url=/nhp/Default .asp ?contentid=28000523 cùng với nhiều tài nguyên SOAP khác.

Trục là gì?

Những ai theo dõi các hoạt động của Apache chắc hẳn đã nghe nói về Apache Axis. Axis là bộ công cụ SOAP thế hệ tiếp theo cũng được phát triển dưới sự bảo trợ của Apache XML. SOAP (một đặc tả, không phải một triển khai cụ thể), gần đây đang phát triển nhanh chóng và triệt để, rất khó theo dõi. Việc cố gắng tạo một phiên bản SOAP đáp ứng đầy đủ các yêu cầu hiện tại khi chúng phát triển cũng khá khó khăn. Kết quả là phiên bản hiện tại của Apache SOAP đưa ra một giải pháp bị giới hạn bởi thiết kế của nó. Sau khi quyết định rằng việc cố gắng thiết kế lại hoàn toàn công cụ hiện có là không đáng, các nhà phát triển Apache bắt đầu tạo một dự án dựa trên mã mới. Thế là Axis ra đời. Tên của SOAP cũng thay đổi, đầu tiên từ SOAP thành XP và sau đó thành XMLP. Sau đó, tên đặc tả được loại bỏ khỏi tên của SOAP mới và tên "Trục" ra đời. Nhưng bây giờ có vẻ như W3C sẽ quay trở lại tên của đặc tả SOAP (phiên bản 1.2 hoặc 2.0), vì vậy mọi thứ có thể vẫn thay đổi và sẽ còn nhiều nhầm lẫn hơn!

Hãy nghĩ về IBM SOAP4J như một kiến ​​trúc?1 của bộ công cụ SOAP. Còn Apache SOAP (được thảo luận trong bài viết này) như một kiến ​​trúc thì sao?2. Và Axis đại diện cho kiến ​​trúc ?3, một kiến ​​trúc thế hệ mới. Dự án này sử dụng SAX trong khi Apache SOAP dựa trên DOM. Ngoài ra, Axis, không giống như Apache SOAP, cung cấp cách tiếp cận thân thiện hơn với người dùng trong tương tác. Sau khi liệt kê những ưu điểm này, có thể bạn sẽ thắc mắc tại sao tôi không chọn Axis làm đối tượng nghiên cứu của mình. Sẽ chỉ hơi sớm một chút thôi. Hiện tại, chỉ có phiên bản 0.51 của Axis đang được chuẩn bị phát hành. Đây chưa phải là phiên bản beta hoặc thậm chí là phiên bản alpha. Tôi muốn nói về các tính năng mới của Axis, nhưng bạn sẽ không có cơ hội thuyết phục ban quản lý của mình rằng bạn có thể sử dụng phần mềm nguồn mở sub-alpha cho các nhu cầu hệ thống quan trọng của mình. Vì vậy tôi quyết định tập trung vào điều gì đó mà bạn là thật bạn có thể dùngđã Hôm nay- Apache SOAP. Tôi nghĩ rằng vào thời điểm phiên bản cuối cùng của Apache Axis được phát hành, tôi sẽ cập nhật tài liệu này trong ấn bản tiếp theo của cuốn sách của mình. Cho đến lúc đó, hãy tập trung vào giải pháp đã có sẵn.

Cài đặt

Có hai hình thức cài đặt SOAP. Đầu tiên là khởi động ứng dụng khách SOAP bằng API SOAP để liên lạc với máy chủ có thể chấp nhận thông báo SOAP. Cách thứ hai là chạy máy chủ SOAP có thể nhận tin nhắn từ máy khách SOAP. Trong phần này tôi đã mô tả cả hai quy trình.

Khách hàng

Để sử dụng ứng dụng khách SOAP, trước tiên bạn cần tải xuống Apache SOAP, có sẵn tại http://xml.apache.org/dist/soap. Tôi đã tải xuống phiên bản 2.2 ở định dạng nhị phân (từ thư mục con phiên bản-2.2). Sau đó, bạn phải giải nén nội dung của kho lưu trữ vào một thư mục trên máy tính của mình. Trong trường hợp của tôi đó là thư mục javaxml2 (c:\javaxml2 trên máy tính Windows của tôi /javaxml2 trên máy tính Mac OS X của tôi). Kết quả là các tập tin đã được giải nén vào /javaxml2/xà phòng-2_2. Bạn cũng sẽ cần tải xuống gói JavaMail có sẵn từ Sun http://java.sun.com/products/javamail/. Nó sẽ được yêu cầu hỗ trợ giao thức truyền SMTP được sử dụng bởi Apache SOAP. Sau đó tải xuống Khung kích hoạt Đậu Java (JAF), cũng có sẵn từ Sun http://java.sun.com/products/beans/glasgow/jaf.html. Dựa trên giả định rằng bạn đã cài đặt Xerces hoặc một trình phân tích cú pháp XML khác và sẵn sàng sử dụng.

Ghi chú:Đảm bảo trình phân tích cú pháp XML của bạn tuân thủ JAXP và sử dụng không gian tên một cách chính xác. Trình phân tích cú pháp của bạn rất có thể đáp ứng các yêu cầu này. Nếu bạn gặp sự cố, tốt nhất bạn nên quay lại sử dụng Xerces.

Ghi chú: Sử dụng các phiên bản mới nhất của Xerces. Phiên bản 1.4 trở lên sẽ làm được. Có một số lỗi với SOAP và Xerces 1.3(.1), vì vậy tôi khuyên bạn không nên sử dụng kết hợp này.

Giải nén các gói JavaMail và JAF, sau đó đưa các tệp jar của chúng vào đường dẫn lớp cũng như thư viện của bạn xà phòng.jar. Mỗi tệp jar này phải được đặt trong thư mục gốc của chương trình tương ứng hoặc trong thư mục con /lib. Khi hoàn thành biến của bạn đường dẫn lớp sẽ trông giống như thế này:

$ echo $CLASSPATH /javaxml2/soap-2_2/lib/soap.jar:/javaxml2/lib/xerces.jar: /javaxml2/javamail-1.2/mail.jar:/javaxml2/jaf-1.0.1/activation.jar

Đối với Windows, nó sẽ trông như thế này:

c:\>echo %CLASSPATH% c:\javaxml2\soap-2_2\lib\soap.jar;c:\javaxml2\lib\xerces.jar; c:\javaxml2\javamail-1.2\mail.jar;c:\javaxml2\jaf-1.0.1\activation.jar

Và cuối cùng thêm thư mục javaxml2/soap-2_2/ trong của bạn đường dẫn lớpđể chạy các ví dụ SOAP. Tôi đã mô tả cách thiết lập cho một số ví dụ trong chương này.

Máy chủ

Để tạo một bộ thành phần máy chủ tương thích với SOAP, trước tiên bạn cần có một công cụ servlet. Như trong các chương trước, tôi đã sử dụng Apache Tomcat (có tại http://jakarta.apache.org/) làm ví dụ cho chương này. Bạn sẽ cần thêm mọi thứ khách hàng cần vào đường dẫn lớp máy chủ. Cách dễ nhất để làm điều này là thiết lập lại xà phòng.jar, kích hoạt.jar Và thư.jar, cũng như trình phân tích cú pháp của bạn, vào thư mục thư viện của công cụ servlet của bạn. Đối với Tomcat, đây là thư mục /lib, chứa các thư viện để tải tự động. Nếu bạn muốn cung cấp hỗ trợ cho các tập lệnh (không được thảo luận trong chương này nhưng có trong các ví dụ SOAP của Apache), bạn cần đặt bsf.jar(có tại http://oss.software.ibm.com/developerworks/projects/bsf) và js.jar(có tại http://www.mozilla.org/rhino/) vào cùng thư mục.

Ghi chú: Nếu bạn đang sử dụng Xerces với Tomcat, bạn sẽ cần lặp lại thủ thuật mà tôi đã trình bày ở Chương 10. Đổi tên trình phân tích cú pháp.jar V. z_parser.jar, MỘT jaxp.jar V. z_jaxp.jarđể đảm bảo rằng xerces.jar và phiên bản JAXP đi kèm sẽ được tải trước bất kỳ trình phân tích cú pháp hoặc triển khai JAXP nào khác.

Sau đó khởi động lại công cụ servlet của bạn, sau đó bạn đã sẵn sàng viết các thành phần máy chủ SOAP.

Bộ định tuyến Servlet và máy khách quản trị

Ngoài các hoạt động cơ bản, Apache SOAP còn bao gồm một bộ định tuyến servlet cũng như một máy khách quản trị. Ngay cả khi bạn không có ý định sử dụng chúng, tôi khuyên bạn nên cài đặt chúng để kiểm tra xem SOAP đã được cài đặt đúng chưa. Quá trình này phụ thuộc vào công cụ servlet nào bạn đang sử dụng, vì vậy tôi sẽ giới hạn quá trình cài đặt ở Tomcat. Hướng dẫn cài đặt cho một số công cụ servlet khác có thể được tìm thấy tại http://xml.apache.org/soap/docs/index.html.

Việc cài đặt trong Tomcat rất đơn giản: chỉ cần lấy file xà phòng.war từ thư mục xà phòng-2_2/ứng dụng web và thả nó vào thư mục $TOMCAT_HOME/ứng dụng web- và thế là xong! Để kiểm tra cài đặt, hãy nhập địa chỉ vào trình duyệt của bạn http://localhost:8080/soap/servlet/rpcrouter. Bạn sẽ nhận được phản hồi tương tự như trong Hình 12-2.

Hình 12-2. Bộ định tuyến RPC Servlet

Mặc dù thông báo có vẻ là một thông báo lỗi nhưng nó cho thấy mọi thứ đều hoạt động bình thường. Bạn sẽ nhận được phản hồi tương tự nếu bạn trỏ trình duyệt của mình tới địa chỉ máy khách của quản trị viên: http://localhost:8080/soap/servlet/messagerouter.

Để hoàn tất việc kiểm tra máy chủ và máy khách, hãy đảm bảo bạn đã làm theo đầy đủ tất cả các hướng dẫn. Sau đó chạy lớp Java sau như hiển thị bên dưới để hỗ trợ URL servlet của bạn cho servlet bộ định tuyến RPC:

C:\>java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter list Các dịch vụ đã triển khai:

Bạn sẽ nhận được một danh sách các dịch vụ trống như được hiển thị ở trên. Nếu bạn nhận được bất kỳ thông báo nào, vui lòng xem lại danh sách dài các lỗi có thể xảy ra tại http://xml.apache.org/soap/docs/trouble/index.html. Đây là danh sách đầy đủ nhất các vấn đề bạn có thể gặp phải. Nếu bạn nhận được một danh sách trống, điều này có nghĩa là quá trình thiết lập đã hoàn tất và bạn đã sẵn sàng bắt đầu xem các ví dụ được đưa ra trong chương này.

Bắt đầu nào

Có ba giai đoạn chính khi viết bất kỳ hệ thống dựa trên SOAP nào. Sau khi liệt kê chúng, tôi sẽ thảo luận ngắn gọn về từng vấn đề:

  • Lựa chọn giữa các tin nhắn SOAP-RPC và SOAP;
  • Viết hoặc giành quyền truy cập vào dịch vụ SOAP;
  • Viết hoặc truy cập ứng dụng khách SOAP.

Bước đầu tiên là chọn xem bạn sẽ sử dụng SOAP cho các cuộc gọi RPC (trong đó thủ tục từ xa được thực thi trên máy chủ) hay tin nhắn (trong đó máy khách chỉ gửi các mẩu thông tin đến máy chủ). Tôi thảo luận chi tiết về các quá trình này dưới đây. Sau khi đưa ra quyết định này, bạn sẽ cần truy cập hoặc tạo dịch vụ của riêng mình. Tất nhiên, vì tất cả chúng ta đều là chuyên gia Java nên chương này sẽ đề cập đến cách tạo Java của riêng bạn. Và cuối cùng, bạn cần viết một ứng dụng khách cho dịch vụ này, chỉ vậy thôi!

RPC hay Nhắn tin?

Nhiệm vụ đầu tiên của bạn không liên quan gì đến lập trình mà thiên về thiết kế hơn. Bạn cần chọn xem bạn sẽ sử dụng dịch vụ RPC hay dịch vụ tin nhắn. Chúng tôi sẽ cho rằng bạn đã quen thuộc với RPC (ví dụ: bằng cách đọc một trong các chương trong cuốn sách của tôi). Máy khách thực hiện một thủ tục từ xa trên máy chủ và sau đó nhận được phản hồi. Trong kịch bản này, SOAP hoạt động như một hệ thống XML-RPC nâng cao, cung cấp khả năng xử lý lỗi và truyền các loại dữ liệu phức tạp qua mạng tốt hơn. Bạn đã quen với khái niệm này và vì hệ thống RPC dễ viết bằng SOAP hơn nên tôi sẽ bắt đầu với chúng. Bài viết này mô tả cách tạo dịch vụ RPC, máy khách RPC và đưa hệ thống vào hoạt động.

Một cách khác để làm việc với SOAP là dựa trên trao đổi tin nhắn. Thay vì thực hiện các thủ tục từ xa, nó chỉ được sử dụng để trao đổi thông tin. Như bạn có thể đoán, đây là một công cụ mạnh mẽ không yêu cầu khách hàng phải biết các phương thức riêng lẻ của bất kỳ máy chủ nào. Nó cũng làm cho việc mô hình hóa các hệ thống từ xa trở nên cô lập hơn bằng cách cho phép các gói dữ liệu (các gói theo nghĩa bóng, không phải theo nghĩa mạng) được gửi đến các hệ thống khác. Đồng thời, các hệ thống khác không cần biết về các hoạt động được thực hiện với dữ liệu này. Phong cách này phức tạp hơn lập trình RPC nên tôi sẽ không mô tả nó ở đây. Bạn sẽ tìm thấy nó trong cuốn sách của tôi, cùng với các chi tiết khác về tương tác giữa doanh nghiệp với doanh nghiệp. Đầu tiên, hãy làm quen với lập trình SOAP-RPC.

Giống như hầu hết các vấn đề về thiết kế, việc đưa ra quyết định này tùy thuộc vào bạn. Phân tích ứng dụng của bạn và cố gắng xác định lý do tại sao bạn cần sử dụng SOAP. Nếu bạn có một máy chủ và một nhóm máy khách thực hiện các chức năng kinh doanh cụ thể theo yêu cầu thì RPC sẽ phù hợp hơn với bạn. Trong các hệ thống phức tạp trong đó việc trao đổi dữ liệu không chỉ thực hiện các chức năng kinh doanh cụ thể theo yêu cầu, việc sử dụng các thông báo SOAP được ưu tiên hơn nhiều.

Dịch vụ RPC

Bây giờ các thủ tục đã xong, đã đến lúc phải hành động. Như bạn đã biết, trong RPC bạn sẽ cần các lớp có phương thức được thực thi từ xa.

Đoạn mã

Tôi sẽ bắt đầu bằng cách xem xét một số đoạn mã cho máy chủ. Các đoạn này là các lớp có các phương thức được thực thi cho máy khách RPC. Tôi đã sử dụng mã từ cuốn sách của mình làm ví dụ. Thay vì sử dụng các lớp đơn giản, tôi chọn một ví dụ phức tạp hơn để thể hiện khả năng của SOAP một cách rõ ràng nhất có thể. Vì vậy, tôi đã sử dụng lớp CD làm ví dụ. Đầu tiên chúng ta xác định phần tử bản đồ cho từng loại tham số không chuẩn. Đối với thuộc tính kiểu mã hóa, ít nhất là trong Apache SOAP 2.2. bạn phải cung cấp giá trị http://schemas.xmlsoap.org/soap/encoding/. Đây hiện là mã hóa được hỗ trợ duy nhất. Bạn cần chỉ định không gian tên cho loại do người dùng xác định và sau đó tên lớp có tiền tố không gian tên cho loại đó. Trong trường hợp của chúng tôi, vì những mục đích này, tôi đã sử dụng một không gian tên hư cấu và một tiền tố đơn giản " x". Sau đó sử dụng thuộc tính javaType, đặt tên thật của lớp Java (đối với trường hợp này - javaxml2.CD). Và cuối cùng là kuralesil với thuộc tính java2XMLClassName Và xml2JavaClassName. Với sự trợ giúp của họ, một lớp được chỉ định sẽ được chuyển đổi từ Java sang XML và ngược lại. Tôi đã sử dụng lớp BeanSerializer cực kỳ tiện dụng, cũng có trong Apache SOAP. Nếu tham số tùy chỉnh của bạn ở định dạng JavaBean, trình tuần tự hóa và trình giải tuần tự này sẽ giúp bạn không phải viết tham số của riêng mình. Bạn cần một lớp có hàm tạo mặc định (hãy nhớ, đối với lớp CD, tôi đã định nghĩa một hàm tạo đơn giản, không tham số) và xuất bản tất cả dữ liệu của lớp này bằng các phương thức tậpXXX Và nhậnXXX. Bởi vì lớp đĩa CDđáp ứng hoàn hảo tất cả các yêu cầu này, BeanSerializer hoạt động hoàn hảo.

Ghi chú: lớp nào đĩa CDđáp ứng yêu cầu BeanSerializer. không quan trọng lắm Hầu hết các lớp đều có thể dễ dàng chuyển đổi sang định dạng này. Vì vậy, tôi khuyên bạn nên tránh viết các trình tuần tự hóa và trình giải tuần tự của riêng mình. Đây là một vấn đề khiến bạn phải đau đầu hơn (không có gì phức tạp nhưng quá tốn công) và tôi khuyên bạn nên tiết kiệm năng lượng và sử dụng tính năng chuyển đổi đậu trong các thông số tùy chỉnh của mình. Trong nhiều trường hợp, chuyển đổi đậu chỉ yêu cầu một hàm tạo mặc định (không có tham số) trong lớp của bạn.

Bây giờ hãy tạo lại cái lọ tập tin và cài đặt lại dịch vụ của chúng tôi:

(gandalf)/javaxml2/Ch12$ java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter xml/CDCatalogDD.xml

Chú ý: Nếu bạn để công cụ servlet của mình chạy và lưu trữ lại một dịch vụ cùng lúc, bạn sẽ cần phải khởi động lại công cụ servlet để kích hoạt các lớp mới cho dịch vụ SOAP và lưu trữ lại dịch vụ đó.

Bây giờ tất cả những gì còn lại là sửa đổi ứng dụng khách để sử dụng các lớp và phương thức mới. Ví dụ 12-10 chứa phiên bản sửa đổi của lớp máy khách CDAdder. Những thay đổi được thực hiện đối với phiên bản trước sẽ được đánh dấu.

Ví dụ 12-10: Cập nhật lớp CDAdder

gói javaxml2; nhập java.net.URL; nhập java.util.Vector; nhập org.apache.soap.Constants; nhập org.apache.soap.Fault; nhập org.apache.soap.SOAPException; nhập org.apache.soap.encoding.SOAPMappingRegistry; nhập org.apache.soap.encoding.soapanc.BeanSerializer; nhập org.apache.soap.rpc.Call; nhập org.apache.soap.rpc.Parameter; nhập org.apache.soap.rpc.Response; nhập org.apache.soap.util.xml.QName; lớp công khai CDAdder( public void add(URL url, String title, String artist, String label) ném ra SOAPException ( System.out.println("Thêm CD có tiêu đề "" + tiêu đề + "" nghệ sĩ "" + nghệ sĩ + "" studio " + nhãn); CD cd = CD mới (tiêu đề, nghệ sĩ, nhãn); // Tạo đối tượng cuộc gọi Call Call call = new Call(); call.setSOAPMappingRegistry(đăng ký); call.setTargetObjectURI("urn:cd-catalog"); call.setMethodName("addCD"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); // Thiết lập tham số Vector params = new Vector(); params.addElement(Tham số mới("cd", CD.class, cd, null)); call.setParams(params); // Xử lý phản hồi phản hồi cuộc gọi gọi; phản hồi = call.invoke(url, ""); if (!response.generatedFault()) ( System.out.println("Thêm CD đã hoàn thành thành công."); ) else ( Faultault = reply.getFault(); System.out.println(Lỗi: " + error.getFaultString ()); public static void main(String args) ( if (args.length != 4) ( System.out.println("Mẫu: java javaxml2.CDAdder " + "\"[Tiêu đề CD]\" \"[Tên nghệ sĩ]\ " \"[Studio CD]\""); quay lại; try ( // URL của máy chủ SOAP nơi kết nối được thực hiện URL url = new URL(args); // Lấy giá trị cho Chuỗi CD mới title = args; Nghệ sĩ đàn dây = args; Nhãn chuỗi = args; // Thêm CDAdder adder = new CDAdder(); adder.add(url, tiêu đề, nghệ sĩ, nhãn); ) bắt (Ngoại lệ e) ( e.printStackTrace(); ) ) )

Thay đổi thực sự thú vị duy nhất là trong bản đồ lớp đĩa CD:

// Ánh xạ loại này để có thể sử dụng nó với SOAP SOAPMappingRegistry register = new SOAPMappingRegistry(); Bộ nối tiếp BeanSerializer = BeanSerializer mới(); register.mapTypes(Constants.NS_URI_SOAP_ENC, new QName("urn:cd-catalog-demo", "cd"), CD.class, serializer, serializer);

Đây là cách thông số người dùng có thể được mã hóa và truyền qua mạng. Tôi đã kể cho bạn nghe lớp học thế nào rồi BeanSerializer có thể được sử dụng để xử lý các tham số ở định dạng JavaBean, chẳng hạn như lớp đĩa CD. Tôi đã sử dụng một bộ mô tả vị trí để chỉ ra những thứ này cho máy chủ, mặc dù bây giờ tôi cần yêu cầu khách hàng sử dụng bộ tuần tự hóa và bộ giải tuần tự này. Chức năng này được thực hiện bởi lớp SOAPBản đồĐăng ký. Phương pháp bản đồTypes() lấy chuỗi được mã hóa (một lần nữa, tốt hơn là sử dụng hằng số cho chuỗi này NS_URI_SOAP_ENC) và thông tin về loại tham số cần sử dụng tính năng tuần tự hóa đặc biệt. QName được chỉ định đầu tiên. Đây là lý do tại sao không gian tên lạ được sử dụng trong bộ mô tả dịch vụ lưu trữ. Bạn cần cung cấp cùng một URN ở đây, cũng như tên cục bộ của phần tử (đối với ví dụ này là "CD"), sau đó là đối tượng Java Lớp học lớp sẽ được tuần tự hóa ( CD.class) và cuối cùng là một thể hiện của lớp tuần tự hóa và giải tuần tự hóa. Đối với ví dụ này, cả hai trường hợp sẽ liên quan đến một thể hiện BeanSerializer. Khi tất cả các cài đặt này đã được nhập vào sổ đăng ký, hãy thông báo cho đối tượng Gọi sử dụng phương pháp setSOAPMapping-Registry().

Bạn có thể chạy lớp này như được hiển thị trước đó, thêm đĩa CD và mọi thứ sẽ hoạt động như mong đợi:

C:\javaxml2\build>java javaxml2.CDAdder http://localhost:8080/soap/servlet/rpcrouter "Tony Rice" "Manzanita" "Sugar Hill" Thêm CD có tựa đề "Tony Rice" của "Manzanita" của Sugar Hill Đã thêm CD thành công.

Tôi đã rời bỏ việc sửa đổi lớp học CDLister cho bạn. Mọi thứ đều được sản xuất theo cùng một khuôn mẫu. Để tự kiểm tra, bạn có thể tham khảo các tệp ví dụ cho cuốn sách của tôi, vốn đã chứa các lớp cập nhật này.

Lưu ý: Bạn có thể quyết định điều đó vì lớp CDLister không tương tác trực tiếp với đối tượng đĩa CD(trả về bằng phương thức danh sách() loại quan trọng bảng băm), thì bạn không cần thực hiện bất kỳ thay đổi nào. Tuy nhiên, lớp được trả về bảng băm chứa các thể hiện đối tượng đĩa CD. Nếu SOAP không biết cách giải tuần tự hóa chúng, máy khách sẽ báo lỗi. Trong trường hợp này, để giải quyết vấn đề bạn phải chỉ định trong đối tượng Gọi sao chép SOAPBản đồĐăng ký.

Xử lý lỗi hiệu quả

Bây giờ bạn đã thấy các đối tượng tùy chỉnh và thực hiện lệnh gọi RPC, v.v., hãy để tôi nói về một chủ đề ít thú vị hơn: xử lý lỗi. Với bất kỳ giao dịch mạng nào, nhiều lỗi có thể xảy ra. Dịch vụ không khởi động, có lỗi trong máy chủ, không tìm thấy đối tượng, thiếu lớp và nhiều vấn đề khác. Cho đến nay tôi chỉ đơn giản sử dụng phương pháp lỗi.getString()để tạo ra các thông báo lỗi. Nhưng phương pháp này có thể không phải lúc nào cũng hữu ích. Để xem nó hoạt động, hãy bỏ ghi chú hàm tạo Danh mục CDC:

CDCatalog công khai() ( //catalog = new Hashtable(); // Tạo thư mục addCD(CD mới("Nickel Creek", "Nickel Creek", "Sugar Hill")); addCD(CD mới("Let it Fall", "Sean Watkins", "Sugar Hill")); addCD(CD mới("Ranh giới trên không", "Michael Hedges", "Windham Hill")); addCD(CD mới("Taproot", "Michael Hedges", "Windham Hill")); )

Biên dịch lại nó, khởi động lại công cụ servlet và lưu trữ lại nó. Điều này sẽ dẫn đến một ngoại lệ NullPointerNgoại lệ khi người xây dựng lớp cố gắng thêm CD vào chưa được khởi tạo bảng băm. Khi khởi động máy khách, một thông báo lỗi sẽ xuất hiện nhưng nó sẽ không có nhiều thông tin:

(gandalf)/javaxml2/build$ java javaxml2.CDLister http://localhost:8080/soap/servlet/rpcrouter Xem thư mục CD hiện tại. Lỗi: Không thể giải quyết đối tượng mục tiêu: null

Đây hoàn toàn không phải là thông tin có thể giúp xác định và sửa lỗi. Tuy nhiên, khung này xử lý lỗi đúng cách. Bạn có nhớ Trình nghe DOMFault, mà bạn đã chỉ định làm giá trị của phần tử người nghe lỗi? Đã đến lúc anh ấy phải vào cuộc chơi. Đối tượng được trả về trong trường hợp có lỗi Lỗi chứa DOM (Mô hình đối tượng tài liệu) org.w3c.dom.Element với thông tin chi tiết về lỗi. Trước tiên hãy thêm biểu thức nhập vào mã nguồn của bạn java.util.Iterator:

nhập java.net.URL; nhập java.util.Enumutions; nhập java.util.Hashtable; nhập java.util.Iterator; nhập java.util.Vector; nhập org.apache.soap.Constants; nhập org.apache.soap.Fault; nhập org.apache.soap.SOAPException; nhập org.apache.soap.encoding.SOAPMappingRegistry; nhập org.apache.soap.encoding.soapanc.BeanSerializer; nhập org.apache.soap.rpc.Call; nhập org.apache.soap.rpc.Parameter; nhập org.apache.soap.rpc.Response; nhập org.apache.soap.util.xml.QName;

Bây giờ hãy thực hiện các thay đổi để xử lý lỗi trong phương thức list():

if (!response.generatedFault()) ( Tham số returnValue = reply.getReturnValue(); Hashtable catalog = (Hashtable)returnValue.getValue(); Enumeration e = catalog.keys(); while (e.hasMoreElements()) ( String title = (String)e.nextElement(); CD cd = (CD)catalog.get(title); System.out.println(" "" + cd.getTitle() + "" artist " + cd.getArtist() + " studios " + cd.getLabel()); ) else ( Lỗi lỗi = reply.getFault(); System.out.println("Lỗi: " + error.getFaultString()); Các mục vectơ = error.getDetailEntries(); for (Iterator i =entry.iterator(); i.hasNext();) ( org.w3c.dom.Element entry = (org.w3c.dom.Element)i.next(); System.out.println(entry .getFirstChild().getNodeValue());

Phương pháp sử dụng getDetailEntries() bạn có quyền truy cập vào dịch vụ SOAP và máy chủ dữ liệu thô hỗ trợ sự cố. Đoạn mã xử lý lại chúng (thường chỉ có một phần tử nhưng cần hết sức chú ý) và chặn DOM Yếu tố, có trong mỗi mục. Về cơ bản, đây là XML bạn đang làm việc:

SOAP-ENV:Server.BadTargetObjectURI Không thể giải quyết mục tiêu: null Đây là những gì chúng ta muốn!

Nói cách khác, đối tượng Lỗi cho phép bạn truy cập vào phần đường bao SOAP có chứa lỗi. Ngoài ra, Apache SOAP còn cung cấp dấu vết ngăn xếp Java khi xảy ra lỗi, cung cấp thông tin chi tiết cần thiết để sửa chúng. Chặn một phần tử ngăn xếpTrace và in ra giá trị nút Chữ từ phần tử này, khách hàng của bạn có thể in dấu vết ngăn xếp máy chủ. Bằng cách biên dịch những thay đổi này và khởi động lại máy khách, bạn sẽ nhận được kết quả sau:

C:\javaxml2\build>java javaxml2.CDLister http://localhost:8080/soap/servlet/rpcr bên ngoài Xem thư mục CD hiện tại. Lỗi: Không thể giải quyết mục tiêu: null java.lang.NullPointerException trong javaxml2.CDCatalog.addCD(CDCatalog.java:24) trong javaxml2.CDCatalog. (CDCatalog.java:14) trong java.lang.Class.newInstance0(Phương thức gốc) trong java.lang.Class.newInstance(Class.java:237)

Nó không tốt hơn nhiều, nhưng ít nhất bạn có thể thấy một số thông tin nhỏ đã xảy ra ngoại lệ NullPointerNgoại lệ và thậm chí tìm ra số dòng trong các lớp máy chủ nơi xảy ra sự cố này. Kết quả của những thay đổi gần đây này đã cho bạn một bức tranh rõ ràng về vấn đề xử lý lỗi. Bây giờ bạn nên kiểm tra các lớp máy chủ của mình để tìm lỗi. Vâng, tôi gần như quên mất, trước đó đừng quên đổi lớp của bạn trở lại Danh mục CDCđể loại bỏ các lỗi chúng tôi cố tình giới thiệu cho rõ ràng!

  1. Có rất nhiều thảo luận về việc chạy SOAP trên các giao thức khác như SMTP (hoặc thậm chí là Jabber). Tiêu chuẩn SOAP hiện không cung cấp điều này, nhưng những khả năng tương tự có thể được bổ sung trong tương lai. Vì vậy, đừng ngạc nhiên nếu bạn gặp phải những cuộc thảo luận tích cực về chủ đề này.

Phần trữ tình.

Hãy tưởng tượng rằng bạn đã triển khai hoặc đang triển khai một hệ thống nhất định có thể truy cập được từ bên ngoài. Những thứ kia. có một máy chủ nhất định mà bạn cần liên lạc. Ví dụ: một máy chủ web.

Máy chủ này có thể thực hiện nhiều hành động, làm việc với cơ sở dữ liệu, thực hiện một số yêu cầu của bên thứ ba tới các máy chủ khác, thực hiện một số phép tính, v.v. sống và có thể phát triển theo kịch bản mà anh ta biết (tức là theo kịch bản của nhà phát triển). Sẽ không có gì thú vị khi một người giao tiếp với một máy chủ như vậy, bởi vì anh ta có thể không/muốn cung cấp các trang đẹp có hình ảnh và nội dung thân thiện với người dùng khác. Nó được viết và hoạt động để hoạt động và cung cấp dữ liệu khi được yêu cầu mà không cần lo lắng rằng con người có thể đọc được, khách hàng sẽ tự xử lý nó.

Các hệ thống khác, truy cập vào máy chủ này, có thể tùy ý xử lý dữ liệu nhận được từ máy chủ này - xử lý, tích lũy, phát hành cho khách hàng của họ, v.v.

Chà, một trong những lựa chọn để liên lạc với các máy chủ như vậy là SOAP. Giao thức trao đổi tin nhắn SOAP xml.

Phần thực tế.

Một dịch vụ web (đây là tên của những gì máy chủ cung cấp và những gì khách hàng sử dụng) giúp giao tiếp với máy chủ bằng các thông báo có cấu trúc rõ ràng. Thực tế là dịch vụ web không chấp nhận bất kỳ dữ liệu nào. Dịch vụ web sẽ phản hồi bằng một lỗi đối với bất kỳ thông báo nào không tuân thủ các quy tắc. Nhân tiện, lỗi cũng sẽ ở dạng xml với cấu trúc rõ ràng (điều này không đúng với nội dung của tin nhắn).

WSDL (Ngôn ngữ mô tả dịch vụ web). Các quy tắc soạn thư cho dịch vụ web cũng được mô tả bằng xml và cũng có cấu trúc rõ ràng. Những thứ kia. Nếu một dịch vụ web cung cấp khả năng gọi một phương thức thì nó phải cho phép khách hàng biết những tham số nào được sử dụng cho phương thức này. Nếu dịch vụ web yêu cầu một chuỗi cho Method1 làm tham số và chuỗi đó phải được đặt tên là Param1 thì các quy tắc này sẽ được chỉ định trong mô tả dịch vụ web.

Không chỉ các kiểu đơn giản mà cả các đối tượng và tập hợp các đối tượng cũng có thể được truyền dưới dạng tham số. Việc mô tả một đối tượng sẽ dẫn đến việc mô tả từng thành phần của đối tượng. Nếu một đối tượng bao gồm một số trường thì mỗi trường sẽ được mô tả, loại, tên của nó (các giá trị có thể có là gì). Các trường cũng có thể thuộc loại phức tạp, v.v. cho đến khi mô tả các loại kết thúc bằng các loại đơn giản - chuỗi, boolean, số, ngày tháng... Tuy nhiên, một số loại cụ thể có thể trở nên đơn giản, điều quan trọng là khách hàng phải có thể hiểu chúng có thể chứa những giá trị gì.

Đối với khách hàng, chỉ cần biết url của dịch vụ web là đủ; wsdl sẽ luôn ở gần, từ đó bạn có thể biết được các phương thức và thông số của chúng mà dịch vụ web này cung cấp.

Ưu điểm của tất cả những chiếc chuông và còi này là gì:

  • Trong hầu hết các hệ thống, việc mô tả các phương thức và loại diễn ra tự động. Những thứ kia. lập trình viên trên máy chủ chỉ cần nói rằng phương thức này có thể được gọi thông qua dịch vụ web và mô tả wsdl sẽ được tạo tự động.

    • Mô tả có cấu trúc rõ ràng có thể được đọc bởi bất kỳ khách hàng xà phòng nào. Những thứ kia. bất kể dịch vụ web nào, khách hàng sẽ hiểu dịch vụ web nhận được dữ liệu gì. Bằng cách sử dụng mô tả này, máy khách có thể xây dựng cấu trúc bên trong của các lớp đối tượng, được gọi là. ràng buộc" và. Kết quả là, lập trình viên sử dụng dịch vụ web phải viết một cái gì đó như (mã giả):

    Người dùng mới:=TSoapUser.Create("Vasya","Pupkin","admin"); xà phòng.AddUser(Người dùng mới);

  • Xác thực tự động.

    • xác thực xml. xml phải được định dạng đúng. Xml không hợp lệ - ngay lập tức có lỗi đối với khách hàng, hãy để anh ấy sắp xếp nó.
    • xác thực lược đồ. xml phải có cấu trúc nhất định. xml không khớp với lược đồ - ngay lập tức có lỗi đối với khách hàng, hãy để anh ấy sắp xếp nó.
    • Việc xác minh dữ liệu được thực hiện bởi máy chủ xà phòng sao cho các loại dữ liệu và các hạn chế khớp với mô tả.
  • Việc ủy ​​quyền và xác thực có thể được thực hiện bằng một phương pháp riêng biệt. nguyên bản. hoặc sử dụng ủy quyền http.
  • Các dịch vụ web có thể hoạt động cả thông qua giao thức xà phòng và qua http, tức là thông qua các yêu cầu nhận. Nghĩa là, nếu các tham số là dữ liệu đơn giản (không có cấu trúc), thì bạn có thể chỉ cần gọi get thông thường là www.site.com/users.asmx/GetUser?Name=Vasia hoặc post. Tuy nhiên, điều này không phải ở khắp mọi nơi và không phải luôn luôn.
  • ... xem trên Wikipedia

Nhược điểm cũng có rất nhiều:

  • Kích thước tin nhắn lớn một cách bất hợp lý. Chà, bản chất của xml ở đây là định dạng dư thừa, càng nhiều thẻ thì thông tin càng vô dụng. Ngoài ra, xà phòng còn bổ sung thêm tính dư thừa của nó. Đối với các hệ thống mạng nội bộ, vấn đề về lưu lượng truy cập ít nghiêm trọng hơn so với internet, do đó, nhu cầu về mạng cục bộ cao hơn, đặc biệt Sharepoint có dịch vụ web xà phòng mà bạn có thể giao tiếp thành công (và một số hạn chế).
  • Việc tự động thay đổi mô tả của một dịch vụ web có thể làm hỏng tất cả các máy khách. Chà, hệ thống nào cũng vậy, nếu không hỗ trợ khả năng tương thích ngược với các phương pháp cũ, mọi thứ sẽ sụp đổ...
  • Không phải là một điểm trừ, mà là một nhược điểm. Tất cả các cuộc gọi phương thức phải là nguyên tử. Ví dụ: khi làm việc với cơ sở dữ liệu, chúng ta có thể bắt đầu một giao dịch, thực hiện một số truy vấn, sau đó khôi phục hoặc cam kết. Không có giao dịch trong xà phòng. Một yêu cầu, một câu trả lời, cuộc trò chuyện kết thúc.
  • Việc xử lý mô tả về những gì ở phía máy chủ (mọi thứ có được mô tả chính xác không?) và những gì ở phía máy khách (những gì được mô tả cho tôi ở đây?) có thể khá khó khăn. Đã có vài lần tôi phải làm việc với phía máy khách và thuyết phục người lập trình máy chủ rằng dữ liệu của anh ta được mô tả không chính xác, nhưng anh ta không thể hiểu gì về nó cả, bởi vì việc tạo tự động và anh ta không nên làm vậy, đó là vấn đề của phần mềm. Và lỗi tất nhiên là ở mã phương thức; đơn giản là người lập trình đã không nhìn thấy nó.
  • Thực tiễn cho thấy rằng các nhà phát triển dịch vụ web rất xa cách với những người sử dụng các dịch vụ web này. Để đáp lại bất kỳ yêu cầu nào (có giá trị từ bên ngoài), một lỗi không thể hiểu được “Lỗi 5. Mọi thứ đều tệ” có thể xảy ra. Tất cả phụ thuộc vào lương tâm của các nhà phát triển :)
  • Tôi chắc chắn mình vẫn không nhớ điều gì đó...

Ví dụ: có một dịch vụ web mở belavia:

  • http://86.57.245.235/TimeTable/Service.asmx - điểm vào, cũng có mô tả văn bản về các phương pháp dành cho nhà phát triển bên thứ ba.
  • http://86.57.245.235/TimeTable/Service.asmx?WSDL - mô tả wsdl về các phương pháp và loại dữ liệu đã nhận và trả về.
  • http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - mô tả một phương pháp cụ thể kèm theo ví dụ về loại yêu cầu xml và phản hồi xml.

Bạn có thể tạo và gửi yêu cầu theo cách thủ công như:

POST /TimeTable/Service.asmx HTTP/1.1 Máy chủ: 86.57.245.235 Loại nội dung: text/xml; charset=utf-8 Độ dài nội dung: độ dài SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

câu trả lời sẽ đến:

HTTP/1.1 200 OK Ngày: Thứ Hai, ngày 30 tháng 9 năm 2013 00:06:44 GMT Máy chủ: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Kiểm soát bộ đệm: riêng tư, tối đa -age=0 Loại nội dung: văn bản/xml; charset=utf-8 Độ dài nội dung: 2940

Tái bút Trước đây, dịch vụ web Aeroflot đã được mở, nhưng sau khi 1C bổ sung hỗ trợ xà phòng cho 8ku, một loạt người thử nghiệm phiên bản 1C beta đã cài đặt thành công dịch vụ này. Bây giờ có gì đó đã thay đổi ở đó (tôi không biết địa chỉ, bạn có thể tra cứu nếu quan tâm).
Tuyên bố từ chối trách nhiệm của ZZY. Anh ấy nói ở mức độ hàng ngày. Bạn có thể đá.

Lịch sử sáng tạo

Với sự ra đời của máy tính cá nhân, nhu cầu kết hợp chúng nảy sinh. Lúc đầu chỉ có những kết nối cáp đơn giản, sau đó các giao thức mạng xuất hiện cho phép các máy tính thống nhất chạy trên cùng một hệ điều hành; với sự phát triển của công nghệ, nhu cầu phải có một hệ điều hành trên tất cả các máy tính đã biến mất và có thể kết hợp các máy tính chạy các hệ điều hành khác nhau. Internet đã thay đổi tốc độ di chuyển trên con đường thống nhất.

Nhưng ngay cả ngày nay, không phải tất cả các vấn đề tích hợp đều được giải quyết; thật không may, không có giao thức duy nhất để liên lạc giữa các ứng dụng và dịch vụ Internet. Để giải quyết vấn đề này, các công ty như Microsoft, DevelopmentMentor, UserLand Software, IBM và Lotus Development đã hợp tác và nhờ các hoạt động chung của họ, Giao thức truy cập đối tượng đơn giản đã được tạo ra, một giao thức truy cập đối tượng đơn giản mô tả một tiêu chuẩn cho các lệnh gọi thủ tục từ xa. dựa trên XML (Ngôn ngữ đánh dấu mở rộng). SOAP được thiết kế để đơn giản hóa đáng kể việc phát triển các ứng dụng đa ngôn ngữ và các công cụ tích hợp kinh doanh. Sự khởi đầu được thực hiện với SOAP 1.0, yêu cầu giao thức HTTP hoạt động.

Sau khi xuất hiện phiên bản đầu tiên của SOAP, được tạo ra, như đã lưu ý, nhờ nỗ lực chung của Microsoft, DevelopmentMentor và UserLand, IBM và Lotus đã tham gia phát triển sản phẩm. Do đó, thông số kỹ thuật đã trải qua một cuộc cải tiến đáng kể để phù hợp hơn với việc tích hợp các môi trường không đồng nhất. Sự khác biệt chính giữa phiên bản tiếp theo của SOAP 1.1 và phiên bản đầu tiên là sự chuyển đổi từ Dữ liệu XML của Microsoft sang Lược đồ XML. Ngoài ra, trong phiên bản mới, thông số kỹ thuật không còn phụ thuộc vào các giao thức truyền tải nữa. SOAP 1.0 yêu cầu giao thức HTTP, trong khi đối với SOAP 1.1, loại phương thức vận chuyển không thành vấn đề: bạn có thể sử dụng email hoặc các liên kết xếp hàng xoa bóp để chuyển tiếp thư. Các công ty đã áp dụng SOAP 1.0 nhận thấy mình bị ràng buộc với công nghệ phi tiêu chuẩn của Microsoft. Tuy nhiên, một số sản phẩm đầy hứa hẹn của tập đoàn này, bao gồm BizTalk Server và SQL Server 7.0, cũng dựa vào Dữ liệu XML. Với sự ra đời của phiên bản 1.1, vòng tròn những người ủng hộ giao thức SOAP ngày càng mở rộng

Phiên bản gốc của SOAP 1.1 được đệ trình lên Lực lượng đặc nhiệm kỹ thuật Internet của IETF dựa trên công nghệ Dữ liệu XML do Microsoft đề xuất vào tháng 1 năm 1998. Tuy nhiên, trong quá trình xem xét tiêu chuẩn W3C, cấu trúc cơ bản đã được thay thế bằng Lược đồ XML. World Wide Web Consortium được yêu cầu coi SOAP 1.1 là một tiêu chuẩn tiềm năng.

Phiên bản mới nhất của đặc tả Giao thức truy cập đối tượng đơn giản (SOAP) hiện có trên máy chủ web phục vụ các thành viên Chương trình nhà phát triển MSDN™ (http://msdn.microsoft.com/). SOAP là một giao thức mở, dựa trên tiêu chuẩn, xác định, dựa trên XML (Ngôn ngữ đánh dấu mở rộng), một định dạng chung để liên lạc giữa mọi ứng dụng và dịch vụ Internet. Phiên bản này mở rộng khả năng của SOAP cho truyền thông không đồng bộ để bao gồm hỗ trợ không chỉ cho HTTP mà còn cho các giao thức Internet như SMTP, FTP và TCP/IP. Phiên bản mới nhất của đặc tả SOAP đã nhận được sự hỗ trợ rộng rãi từ các công ty như ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopmentMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software và Zveno Pty. Công ty TNHH Đặc tả SOAP cung cấp một cơ chế chung để tích hợp các dịch vụ trên Internet và/hoặc mạng nội bộ, bất kể hệ điều hành, mô hình đối tượng hoặc ngôn ngữ lập trình được sử dụng. Dựa trên các tiêu chuẩn Internet XML và HTTP, SOAP cho phép mọi ứng dụng mới hoặc hiện có giao tiếp với nhau. Các trang web hỗ trợ SOAP có thể trở thành các dịch vụ Web có thể truy cập hoàn toàn theo chương trình và không cần sự can thiệp của con người. Một cơ sở hạ tầng duy nhất cho phép tương tác trực tiếp giữa các ứng dụng sử dụng Internet sẽ mở ra những cơ hội mới cho việc tích hợp các dịch vụ và thiết bị—bất kể chúng ở đâu trên Internet.

Dịch vụ Web và SOAP

Các dịch vụ web và SOAP được thiết kế để giải quyết các vấn đề về giao tiếp ứng dụng đa nền tảng. Bài viết này sẽ giúp bạn hiểu rõ hơn về những công nghệ mới đầy hứa hẹn này.

SOAP là gì

Các công nghệ hiện đang được sử dụng để gọi phương thức từ xa (DCOM, CORBA/IIOP và RMI) khá khó để định cấu hình và tổ chức tương tác. Điều này kéo theo các vấn đề trong vận hành và hoạt động của các hệ thống phân tán (vấn đề bảo mật, truyền tải qua tường lửa, v.v.). Các vấn đề hiện tại đã được giải quyết thành công bằng cách tạo ra SOAP (Giao thức truy cập đối tượng đơn giản), một giao thức đơn giản dựa trên XML để trao đổi thông báo trong môi trường phân tán (WWW). Nó được thiết kế để tạo các dịch vụ web và các phương thức gọi từ xa. SOAP có thể được sử dụng với các giao thức truyền tải khác nhau, bao gồm HTTP, SMTP, v.v.

Dịch vụ web là gì

Dịch vụ web là chức năng và dữ liệu được hiển thị để sử dụng bởi các ứng dụng bên ngoài tương tác với dịch vụ thông qua các giao thức và định dạng dữ liệu tiêu chuẩn. Các dịch vụ web hoàn toàn độc lập với ngôn ngữ và nền tảng triển khai. Công nghệ dịch vụ web là nền tảng của mô hình lập trình .NET của Microsoft. Để chứng minh khả năng của SOAP, tôi đã sử dụng triển khai SOAP Toolkit phiên bản 2.0 được phát hành gần đây của Microsoft. Cần lưu ý rằng phiên bản hiện tại của Bộ công cụ khác biệt đáng kể so với phiên bản trước đó (Bộ công cụ Microsoft SOAP cho Visual Studio 6.0) và so với phiên bản beta của Bộ công cụ SOAP 2.0.

Cơ chế tương tác giữa client và server

  1. Ứng dụng khách khởi tạo một đối tượng SOAPClient
  2. SOAPClient đọc các tệp mô tả phương thức dịch vụ web (WSDL và Ngôn ngữ meta dịch vụ web - WSML). Những tập tin này cũng có thể được lưu trữ trên máy khách.
  3. Ứng dụng khách, sử dụng khả năng liên kết muộn của đối tượng SOAPClient, gọi một phương thức dịch vụ. SOAPClient tạo gói yêu cầu (Phong bì SOAP) và gửi nó đến máy chủ. Bất kỳ giao thức truyền tải nào cũng có thể được sử dụng, nhưng HTTP thường được sử dụng.
  4. Gói này lấy một ứng dụng máy chủ Listener (có thể là ứng dụng ISAPI hoặc trang ASP), tạo một đối tượng SOAPServer và chuyển gói yêu cầu đến nó
  5. SOAPServer đọc mô tả dịch vụ web, tải mô tả và gói yêu cầu vào cây XML DOM
  6. SOAPServer gọi một phương thức của đối tượng/ứng dụng triển khai dịch vụ
  7. Kết quả thực hiện phương thức hoặc mô tả lỗi được đối tượng SOAPServer chuyển đổi thành gói phản hồi và gửi đến máy khách
  8. Đối tượng SOAPClient phân tích gói tin đã nhận và trả về ứng dụng khách kết quả của dịch vụ hoặc mô tả lỗi đã xảy ra.

Tệp WSDL là một tài liệu XML mô tả các phương thức được cung cấp bởi dịch vụ web. Ngoài ra còn có các tham số của các phương thức, loại, tên và vị trí của Trình nghe dịch vụ. Trình hướng dẫn Bộ công cụ SOAP sẽ tự động tạo ra tài liệu này.

SOAP Envelope (Package) - một tài liệu XML chứa yêu cầu/phản hồi để thực thi một phương thức. Sẽ thuận tiện nhất nếu coi nó như một phong bì bưu điện chứa đựng thông tin. Thẻ Phong bì phải là thành phần gốc của gói. Phần tử Tiêu đề là tùy chọn, nhưng phần tử Nội dung phải có mặt và là phần tử con trực tiếp của phần tử Phong bì. Nếu xảy ra lỗi thực thi phương thức, máy chủ sẽ tạo một gói chứa phần tử Lỗi trong thẻ Nội dung, chứa mô tả chi tiết về lỗi. Nếu bạn sử dụng giao diện cấp cao SOAPClient và SOAPServer, thì bạn không cần phải đi sâu vào sự phức tạp của định dạng gói, nhưng nếu muốn, bạn có thể sử dụng giao diện cấp thấp hoặc thậm chí tạo gói bằng tay.

Mô hình đối tượng của Bộ công cụ SOAP cho phép làm việc với các đối tượng API cấp thấp:

  • SoapConnector - Cung cấp hoạt động với giao thức truyền tải để trao đổi các gói SOAP
  • SoapConnectorFactory - Cung cấp phương thức tạo trình kết nối cho giao thức truyền tải được chỉ định trong tệp (thẻ) WSDL
  • SoapReader - Đọc thông báo SOAP và xây dựng cây XML DOM
  • SoapSerializer - Chứa các phương thức tạo thông báo SOAP
  • IsoapTypeMapper, SoapTypeMapperFactory - Giao diện cho phép bạn làm việc với các kiểu dữ liệu phức tạp

Khi sử dụng các đối tượng API cấp cao, bạn chỉ có thể truyền dữ liệu thuộc các kiểu đơn giản (int, srting, float ...), nhưng đặc tả SOAP 1.1 cho phép bạn làm việc với các kiểu dữ liệu phức tạp hơn, chẳng hạn như mảng, cấu trúc, danh sách và sự kết hợp của chúng. Để làm việc với các loại như vậy, bạn phải sử dụng giao diện IsoapTypeMapper và SoapTypeMapperFactory.

Nói chung, ngày nay có các giao thức trao đổi dữ liệu XML tiêu chuẩn:

  • XML-RPC– bạn chuyển gói và cho biết phương thức nào trên máy chủ bạn muốn gọi.
  • NGHỈ NGƠI- có một số đối tượng trên máy chủ. Mỗi đối tượng được đặc trưng bởi một số loại định danh. Mỗi phần tử có url riêng. Bạn có thể thực hiện các thao tác sau với bất kỳ phần tử nào: chèn, xóa, cập nhật, chọn. Bạn chỉ cần gửi yêu cầu mong muốn đến máy chủ (ví dụ: chèn phần tử như vậy). Trao đổi máy khách-máy chủ dựa trên JSON hoặc XML.

SOAP (kiến trúc hướng dịch vụ, một tập hợp các dịch vụ liên kết lỏng lẻo tương tác với nhau) dựa trên RPC. Ưu điểm chính của RPC là số lượng tài nguyên mạng (điểm vào) nhỏ và nhiều phương pháp liên quan. Bất chấp lợi thế này, RPC là một giao thức lỗi thời có một số nhược điểm:

  • Không thể xác minh tính hợp lệ của thông báo XML-RPC. Giao thức cũ được tạo trước khi các lược đồ (phương pháp xác thực dữ liệu) được chuẩn hóa bằng XML. Những thứ kia. Máy chủ chấp nhận các yêu cầu, nó phải đảm bảo rằng các yêu cầu đó dành cho nó và dữ liệu nhất quán. Trong XML-RPC, các kiểu dữ liệu được khai báo cho việc này, nhưng đây là kiểm tra kiểu dữ liệu và tính nhất quán của dữ liệu không được kiểm tra (bạn đã nhận được cấu trúc với tất cả các tham số cần thiết).
  • Bạn không thể tạo tin nhắn kết hợp.
  • Bạn không thể sử dụng không gian và thời gian (xuất hiện sau khi tạo RPC).
  • Bạn không thể mở rộng tin nhắn, tức là. thêm thông tin bổ sung.

Tất cả những thiếu sót này đã được giải quyết trong Lược đồ XML. Đây là tiêu chuẩn công nghiệp để mô tả một tài liệu XML. Những thứ kia. đó là một cách để mô hình hóa dữ liệu tùy ý. Lược đồ XML có thể mô tả một mô hình (mối quan hệ giữa các phần tử và thuộc tính cũng như cấu trúc của chúng), các kiểu dữ liệu (mô tả các kiểu dữ liệu) và một từ điển (tên của các phần tử và thuộc tính).

Dựa trên tất cả những thiếu sót của XML-RPC, giao thức SOAP đã được tạo ra.

XÀ BÔNG(Giao thức truy cập đối tượng đơn giản) - giao thức truy cập vào một đối tượng (đến điểm vào). Ngày nay nó là tiêu chuẩn công nghiệp chính để xây dựng các ứng dụng phân tán.

Nó đại diện cho các phần mở rộng của ngôn ngữ XML-RPC. Những thứ kia. nó được xây dựng trên nguyên tắc: 1 điểm vào và bất kỳ phương thức nào. Bản thân giao thức về mặt vận chuyển (cách truyền dữ liệu) mang lại nhiều lựa chọn: SMTP, FTP, HTTP, MSMQ.

SOAP làm nền tảng cho việc triển khai các dịch vụ web XML (dịch vụ web XML). Nhược điểm của SOAP là khó học.

SOAP dựa trên việc trao đổi tin nhắn giữa máy khách và máy chủ (đồng bộ và không đồng bộ). Mỗi tin nhắn mang thông tin về dữ liệu (dữ liệu nào được truyền và nhận). SOAP mô tả trước toàn bộ cấu trúc của một thông báo bằng cách sử dụng các lược đồ XML: nội dung trong thông báo là gì, nó sẽ được truyền đi như thế nào. Điều này giúp bạn có thể hiểu được điều gì đang xảy ra ở đó mà không cần biết máy chủ và cho phép máy chủ kiểm tra xem thông báo này có dành cho nó hay không.

Lược đồ XML

Mục đích của lược đồ là mô tả cấu trúc của dữ liệu, tức là những gì chúng tôi có. Tất cả dữ liệu được chia thành các loại đơn giản và phức tạp (vô hướng và cấu trúc). Một kiểu đơn giản (chuỗi, số, boolean, ngày) sẽ không bao giờ chứa bất cứ thứ gì bên trong. Và một cấu trúc (đối tượng) có thể chứa các thuộc tính.

Các hoạt động SOAP cơ bản

  • Không chỉ trao đổi thông tin client-server đơn giản. Nhưng cũng có thể tự động nhận dạng máy chủ và tìm kiếm máy chủ này, tức là. khách hàng thậm chí có thể không biết gì về máy chủ. Những thứ kia. Đầu tiên, máy khách tìm kiếm máy chủ, tìm các dịch vụ phù hợp, hiểu những phương thức nào ở đó, máy chủ có những gì và gọi nó.
  • Máy chủ công bố thông tin của nó (vị trí, phương thức hỗ trợ) để khách hàng tìm thấy máy chủ này. Việc xuất bản xảy ra trong thư mục UDDI.

Cấu trúc thông báo SOAP:

  • Phong bì SOAP - bao gồm toàn bộ tin nhắn. Gồm phần đầu và phần thân.
  • Tiêu đề SOAP (tiêu đề) - thông tin bổ sung (ví dụ: ủy quyền).
  • SOAP Body (nội dung) - chính thông điệp đó.
  • SOAP Fault (lỗi) là phương thức truyền lỗi từ máy chủ đến máy khách.

WSDL

WSDL(Ngôn ngữ mô tả dịch vụ web) - ngôn ngữ mô tả các dịch vụ web. Được sử dụng trong SOAP. Đây là một loại tài liệu mô tả mọi thứ: không gian tên nào đã được sử dụng, lược đồ dữ liệu nào đã được sử dụng, loại thông báo mà máy chủ mong đợi từ máy khách, phong bì nào thuộc về phương thức nào, phương thức nào tồn tại, địa chỉ nào cần gửi đến, v.v. . Thực ra WSDL là một dịch vụ web. Chỉ cần khách hàng nghiên cứu nội dung của tài liệu này là đủ; anh ta đã biết mọi thứ về máy chủ.

Bất kỳ máy chủ nào cũng phải xuất bản WSDL.

WSDL bao gồm các khối:

  • Định nghĩa về chính dịch vụ, tức là điểm vào, cổng được chỉ định.
  • Định dạng phương thức. Điểm vào được liên kết với các hoạt động, tức là. nó hỗ trợ những phương pháp nào? Loại cuộc gọi và phương thức truyền được chỉ định. Bên trong mỗi phương thức có phần giải thích về hình thức truyền dữ liệu - dưới dạng SOAP.
  • Các phương thức liên kết với một tin nhắn.
  • Mô tả của các tin nhắn.

Như đã thảo luận ở chương trước, các dịch vụ Web giao tiếp với các máy khách và với nhau bằng cách gửi các thông báo dưới dạng XML. Các thẻ triển khai XML này, các quy tắc định dạng tài liệu XML và thứ tự trao đổi tài liệu được xác định bởi giao thức SOAP. Giao thức SOAP được tạo ra vào năm 1998 bởi một nhóm các nhà phát triển do Dave Winer đứng đầu, người từng làm việc tại Microsoft Corporation và Userland. Tên của giao thức - "Giao thức truy cập đối tượng đơn giản" - phản ánh mục đích ban đầu của nó - để truy cập các phương thức của các đối tượng từ xa. Mục đích của giao thức đã thay đổi; giờ đây nó là giao thức cho mọi tương tác giữa các dịch vụ Web và các thành phần của ứng dụng phân tán được liên kết lỏng lẻo. Nó không còn đơn giản nữa và không nói gì về đồ vật. Nhiều nhà phát triển đề xuất gọi nó là "Giao thức kiến ​​trúc hướng dịch vụ", để lại tên viết tắt trước đó. Để ngăn chặn những nỗ lực này, đặc tả SOAP 1.2 nêu rõ rằng từ "SOAP" sẽ không còn được đánh vần theo bất kỳ cách nào nữa.

Vào cuối năm 1999, việc phát triển giao thức đã được chuyển giao cho tập đoàn W3C (http:// www.w3.org/).

Vào tháng 5 năm 2000, tập đoàn đã phát hành phiên bản SOAP 1.1. Thông báo được viết bằng giao thức SOAP được định dạng dưới dạng tài liệu XML sử dụng tích cực các không gian tên. Tên phần tử XML SOAP 1.1 đề cập đến mã định danh không gian tên http://schemas.xmlsoap.org/soap/envelope/.

Bản thảo thứ hai của SOAP 1.2 được phát hành vào năm 2001, namespace của nó lúc đó được gọi là http://www.w3.org/2001/06/soap-envelope.

Lưu ý rằng chính mã định danh không gian tên chứ không phải số 1.1 hoặc 1.2 sẽ xác định phiên bản SOAP. Máy chủ sẽ không xem xét thông báo SOAP và sẽ trả về thông báo lỗi nếu nhận thấy

không gian tên không khớp.

Khi tôi viết bài này, SOAP 1.1 vẫn hoạt động. Phiên bản 1.2 không thể rời khỏi giai đoạn chuẩn bị nhưng đã được sử dụng, ví dụ: trong SOAP::Lite, Apache SOAP 2.3, Apache Axis. Vì vậy, trong chương này tôi sẽ phác thảo phiên bản 1.2, lưu ý những điểm khác biệt của nó so với phiên bản 1.1.

Đặc tả SOAP đang hoạt động luôn được lưu trữ tại http://www.w3.org/TR/SOAP/. Các tài liệu có tại địa chỉ này sẽ được thay thế bằng tài liệu mới khi phiên bản làm việc được thay thế.

Bản dự thảo SOAP được cập nhật liên tục và mã định danh không gian tên thay đổi. Phiên bản dự thảo mới nhất tại thời điểm viết bài có tại http://www.w3.org/TR/soapl2-partl/ và không gian tên mà nó sử dụng là http://www.w3.org/2002/06/soap - phong bì. Lưu ý rằng đặc tả SOAP 12 bao gồm hai phần: phần 1 và phần2. Phần thứ hai của đặc tả - ứng dụng - chứa các quy tắc ghi các kiểu dữ liệu phức tạp. Đặc tả có một phần khác của partO - ví dụ về các thông báo được biên dịch theo quy tắc của SOAP 1.2.

Cấu trúc thông báo SOAP

Đặc tả xác định thông báo SOAP là một tài liệu XML không chứa khai báo loại tài liệu hoặc hướng dẫn xử lý. Phần tử gốc của tài liệu XML này được gọi là . Một phần tử có thể có các thuộc tính xác định không gian tên,

và các thuộc tính khác được cung cấp cùng với tiền tố. Phần tử gốc chứa một phần tử tùy chọn chứa tiêu đề thư và một phần tử bắt buộc , trong đó nội dung của tin nhắn được ghi lại. Phiên bản 1.1 được phép sau phần thân để viết ra các phần tử tùy ý, tên của chúng phải có tiền tố. Phiên bản 1.2 cấm viết bất cứ điều gì sau phần tử . Nói tóm lại, cấu trúc chung của thông báo SOAP là:

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

< ! - Блоки заголовка ->

Yếu tố

, nếu nó có trong tin nhắn, thì nó được viết đầu tiên trong phần nội dung của phần tử . Ngoài các thuộc tính xmlns, nó có thể chứa một thuộc tính tác nhân, cho biết địa chỉ URI của máy chủ SOAP cụ thể mà thông báo được gửi tới.

Thực tế là một thông báo SOAP có thể đi qua một số máy chủ SOAP hoặc qua một số ứng dụng trên cùng một máy chủ. Các ứng dụng này xử lý trước các khối tiêu đề thư và truyền nó cho nhau. Tất cả các máy chủ và/hoặc ứng dụng này được gọi là nút SOAP. Đặc tả SOAP không xác định các quy tắc để truyền tin nhắn qua chuỗi máy chủ. Với mục đích này, các giao thức khác đang được phát triển, ví dụ: Microsoft WS-Routing.

Thuộc tính tác nhân chỉ định nút SOAP mục tiêu - nút nằm ở cuối chuỗi và sẽ xử lý toàn bộ tiêu đề. Nghĩa

Thuộc tính diễn viên chỉ ra rằng tiêu đề sẽ được xử lý bởi máy chủ đầu tiên nhận nó. Thuộc tính diễn viên có thể xuất hiện trong các khối tiêu đề riêng biệt, cho biết nút xử lý khối này. Sau khi xử lý, khối sẽ bị xóa khỏi thông báo SOAP.

Trong phiên bản 1.2, thuộc tính tác nhân được thay thế bằng thuộc tính vai trò vì trong phiên bản SOAP này, mỗi nút đóng một hoặc nhiều vai trò. Đặc tả hiện xác định ba vai trò nút SOAP.

Vai trò của http://^.w3.org/2002/06/soap-envelope/role/ultimateReceiver được thực hiện bởi nút mục tiêu cuối cùng sẽ xử lý tiêu đề.

Vai trò http://www.w3.org/2002/06/soap-envelope/role/next được thực hiện bởi nút trung gian hoặc nút mục tiêu. Một nút như vậy có thể đóng các vai trò bổ sung khác.

Bất kỳ nút SOAP nào cũng không được phép đóng vai trò http://www.w3.org/2002/06/soap-envelope/role/none.

Các ứng dụng phân tán, dựa trên nhu cầu của chúng, có thể thêm các vai trò khác vào các vai trò này, chẳng hạn như giới thiệu một máy chủ trung gian xác minh chữ ký số và xác định vai trò này cho nó bằng một số chuỗi URI.

Giá trị của thuộc tính vai trò có thể là bất kỳ chuỗi URI nào cho biết vai trò của nút mà khối tiêu đề này hướng tới. Giá trị mặc định cho thuộc tính này là giá trị trống, tức là chỉ một cặp dấu ngoặc kép hoặc chuỗi URI http://\vw\v.w3.org/2002/06/soap-envelope/rale/ultimateReceiver.

Giá trị của thuộc tính vai trò chỉ ra rằng khối phải được xử lý bởi một nút đóng vai trò được chỉ định bởi cùng một chuỗi.

Thuộc tính phần tử khác

, được gọi là urnstUnderstand, nhận các giá trị o hoặc 1. Giá trị mặc định của nó là o. Nếu thuộc tính mustknow bằng 1 thì nút SOAP khi xử lý phần tử phải tính đến cú pháp của nó được xác định trong lược đồ tài liệu hoặc hoàn toàn không xử lý thông báo. Điều này làm tăng độ chính xác của việc xử lý tin nhắn.

Trong SOAP phiên bản 1.2, thay vì số o, bạn cần viết từ false, và thay vì số 1, hãy viết từ true.

Trong phần tiêu đề

Bạn có thể lồng các phần tử tùy ý, trước đây gọi là mục tiêu đề. Trong phiên bản 1.2, chúng được gọi là khối tiêu đề. Tên của họ nhất thiết phải được đánh dấu bằng tiền tố. Các khối tiêu đề có thể chứa vai trò hoặc tác nhân và các thuộc tính phải hiểu. Hành động của họ sẽ chỉ áp dụng cho khối này. Điều này cho phép các khối tiêu đề riêng lẻ được xử lý bởi các nút SOAP trung gian, những nút có vai trò phù hợp với vai trò được chỉ định bởi thuộc tính vai trò. Liệt kê 3.1 cho thấy một ví dụ về khối như vậy.

Liệt kê 3.1. Tiêu đề có một khối

xmlns:t="http://some.com/transaction" env:role=

"http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" env:mustUnderstand="1">

Các phần tử lồng trong khối tiêu đề không còn được gọi là khối nữa. Chúng không thể chứa các thuộc tính vai trò, diễn viên và phải hiểu.

Yếu tố phải được viết ngay sau phần tử

, nếu nó có trong tin nhắn hoặc đầu tiên trong tin nhắn SOAP nếu thiếu tiêu đề. Đến phần tử Bạn có thể lồng các phần tử tùy ý; đặc tả không xác định cấu trúc của chúng theo bất kỳ cách nào. Tuy nhiên, một phần tử được xác định có chứa thông báo lỗi.

Thông báo lỗi

Nếu một máy chủ SOAP, trong khi xử lý một tin nhắn SOAP mà nó nhận được, nhận thấy có lỗi, thì nó sẽ ngừng xử lý và gửi một tin nhắn SOAP đến máy khách, trong phần thân của nó sẽ ghi một phần tử với một thông báo lỗi.

Trong thông báo được viết trong phần nội dung của phần tử SOAP 1.1,

Có bốn phần được mô tả bởi các phần tử con sau đây.

Mã lỗi - một thông báo cho biết loại lỗi. Nó được dành cho một chương trình xử lý lỗi.

Mô tả lỗi - mô tả bằng lời về loại lỗi dành cho một người.

Vị trí xảy ra lỗi - URI của máy chủ nhận thấy lỗi. Hữu ích khi một thông báo đi qua một chuỗi các nút SOAP để làm rõ bản chất của lỗi. Các nút SOAP trung gian được yêu cầu phải ghi lại phần tử này; máy chủ SOAP mục tiêu không bắt buộc phải làm như vậy.

Chi tiết lỗi - mô tả các lỗi gặp phải trong cơ thể tin nhắn, nhưng không có trong tiêu đề của nó. Nếu không tìm thấy lỗi trong quá trình xử lý nội dung thì phần tử này bị thiếu.

Ví dụ:

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

env:Phải hiểu SOAP Phải Hiểu Lỗi

Phiên bản SOAP 1.2 đã thay đổi nội dung của phần tử Như được mô tả trong

không gian tên http://www.w3.org/2002/06/soap-envelope, nó bao gồm hai phần tử bắt buộc và ba phần tử tùy chọn.

Các yếu tố cần thiết.

Mã lỗi . Nó chứa một phần tử phụ bắt buộc<:value>với mã lỗi và phần tử phụ tùy chọn , một lần nữa chứa phần tử với mã lỗi và phần tử làm rõ , và sau đó mọi thứ được lặp lại một cách đệ quy.

Lý do lỗi . Chứa thuộc tính xml tùy chọn: lang, biểu thị ngôn ngữ thông báo (xem Chương D) và một số phần tử lồng nhau tùy ý mô tả lỗi.

Các yếu tố tùy chọn.

? - Địa chỉ URI của nút SOAP trung gian nhận thấy lỗi.

? - vai trò của nút SOAP đã nhận thấy lỗi.

? - mô tả lỗi nhận thấy trong khi xử lý nội dung tin nhắn, nhưng không phải tiêu đề.

Liệt kê 3.2 hiển thị một thông báo lỗi xảy ra khi cố gắng thực hiện một thủ tục. Lỗi là tên của các đối số của thủ tục được viết không chính xác trong thông báo SOAP và thủ tục không thể hiểu chúng.

Liệt kê 3.2. Thông báo lỗi

xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc=’http://www.w3.org/2002/06/soap-rpc'>

env:Người gửi

rpc:BadArgumentsc/env:Value>

Ptocessing ETor

xmlns:e="http://www.example.org/faults"> #tôi không khớp 999

Các loại lỗi

Danh sách mã lỗi liên tục thay đổi và mở rộng. Phiên bản 1.1 xác định bốn loại lỗi.

VersionMismatch - không gian tên không được nhận dạng. Nó có thể đã lỗi thời hoặc tên của nó có thể bị sai chính tả.

MustUnderstand - Khối tiêu đề được đánh dấu bằng thuộc tính mustUnderstand có giá trị 1 không tuân theo cú pháp của nó như được xác định trong lược đồ tài liệu.

Máy khách - tài liệu XML chứa thông báo không đúng định dạng và vì lý do này mà máy chủ không thể xử lý nó. Khách hàng nên thay đổi tin nhắn.

Máy chủ - máy chủ không thể xử lý tin nhắn được ghi chính xác vì lý do nội bộ.

Phiên bản 1.2 xác định năm loại lỗi.

VersionMismatch - không gian tên không được nhận dạng. Nó có thể đã lỗi thời hoặc tên của nó có thể sai chính tả hoặc có thể có tên thành phần XML trong thông báo không được xác định trong không gian tên đó. Máy chủ ghi phần tử vào tiêu đề phản hồi , liệt kê các phần tử lồng nhau đúng tên không gian tên được máy chủ hiểu. Phản hồi của máy chủ được hiển thị trong Liệt kê 3.3.

MustUnderstand - Khối tiêu đề được đánh dấu bằng thuộc tính mustunder được đặt thành true không tuân theo cú pháp của nó như được xác định trong lược đồ tài liệu. Máy chủ ghi các phần tử sau vào tiêu đề phản hồi: , thuộc tính qname chứa tên của khối không chính xác. Liệt kê 3.4 chứa một ví dụ về phản hồi mà máy chủ sẽ thực hiện nếu tiêu đề trong Liệt kê 3.1 bị sai chính tả.

DataEncodingUnknown - tin nhắn chứa dữ liệu khó hiểu, có lẽ nó được viết bằng một mã hóa không xác định.

Người gửi - tài liệu XML chứa thư không đúng định dạng và vì lý do này mà máy chủ không thể xử lý nó. Khách hàng nên thay đổi tin nhắn.

Người nhận - máy chủ không thể xử lý tin nhắn được ghi chính xác vì các lý do nội bộ của chính nó, ví dụ: thiếu trình phân tích cú pháp XML bắt buộc.

Máy chủ có thể thêm một số loại riêng của nó vào các loại lỗi này. Thường xuyên

họ nêu chi tiết các loại tiêu chuẩn và thông báo về chúng xuất hiện trong các phần tử , như được hiển thị ở trên trong Liệt kê 3.2.

? Liệt kê 3.3. Phản hồi của máy chủ với thông báo lỗi như VersionMismatch

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

xmlns:upg="http://www.w3.org/2002/06/soap-upgrade">

xmlns:nsl="http://www.w3.org/2002/06/soap-envelope"/>

xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>

env:Phiên bảnKhông khớp

Phiên bản không phù hợp

ListongZ.4. Phản hồi của máy chủ với thông báo lỗi như MustUnderstand

xmlns:t=’http://some.com/transaction’ />

env:Phải hiểu

Một hoặc nhiều tiêu đề bắt buộc không được hiểu

Văn học:

Khabibullin I. Sh. Phát triển dịch vụ Web sử dụng Java. - St. Petersburg: BHV-Petersburg, 2003. - 400 tr.: ill.