Tại sao HTTP/SOAP được coi là "dày"

Question

Tôi đã nghe một số ý kiến ​​cho rằng ngăn xếp cuộc gọi dịch vụ web SOAP/HTTP là "dày" hoặc "nặng", nhưng tôi thực sự không thể xác định lý do. Nó sẽ được coi là dày vì serialization/deserialization của phong bì SOAP và tin nhắn? Đó thực sự là một hoạt động nặng?

Hoặc nó chỉ được coi là "dày" so với truyền dữ liệu thô/nhị phân qua kết nối cố định?

Hoặc là một số lý do khác? Bất cứ ai có thể làm sáng tỏ về điều này?

Answer 1

SOAP được thiết kế đủ trừu tượng để sử dụng các phương tiện vận tải khác ngoài HTTP. Điều đó có nghĩa là, trong số những thứ khác, rằng nó không tận dụng các khía cạnh nhất định của HTTP (chủ yếu là sử dụng các URL và phương pháp RESTful, ví dụ: PUT /customers/1234 hoặc GET /customers/1234).

SOAP cũng bỏ qua các cơ chế TCP/IP hiện có vì lý do tương tự - không phụ thuộc vào vận chuyển. Một lần nữa, điều này có nghĩa là nó không thể tận dụng lợi thế của việc vận chuyển, chẳng hạn như quản lý chuỗi, kiểm soát luồng, phát hiện dịch vụ (ví dụ: accept() nhập kết nối trên một cổng nổi tiếng nghĩa là dịch vụ tồn tại), v.v.

SOAP use XML cho tất cả các tuần tự hóa của nó - trong khi đó có nghĩa là dữ liệu "có thể đọc được" chỉ với một trình phân tích cú pháp XML, nó giới thiệu rất nhiều bản mẫu mà bạn thực sự cần một trình phân tích cú pháp SOAP để hoạt động hiệu quả. Và tại thời điểm đó, bạn (là một người tiêu dùng phần mềm) đã mất đi lợi ích của XML anyways; những người quan tâm những gì tải trọng trông giống như trên dây nếu bạn cần libSOAP để xử lý nó anyways.

SOAP yêu cầu WSDL để mô tả giao diện. Bản thân WSDL không phải là một vấn đề, nhưng nó có xu hướng được quảng cáo nhiều hơn "năng động" hơn nó thực sự là. Trong nhiều trường hợp, một WSDL đơn lẻ được tạo và mã của nhà sản xuất/người tiêu dùng được tạo tự động từ đó và nó không bao giờ thay đổi. Nói chung, đòi hỏi rất nhiều công cụ xung quanh mà không thực sự giải quyết vấn đề ban đầu (làm thế nào để giao tiếp giữa các máy chủ khác nhau) bất kỳ tốt hơn. Và vì hầu hết các dịch vụ SOAP chạy trên HTTP, vấn đề ban đầu là đã chủ yếu được giải quyết để bắt đầu.

Answer 2

Trước hết, nó phụ thuộc rất nhiều vào cách các dịch vụ của bạn được triển khai (nghĩa là bạn có thể làm rất nhiều để giảm tải trọng bằng cách chỉ cẩn thận cách các chữ ký phương thức của bạn được thực hiện).

Điều đó nói rằng, không chỉ phong bì xà phòng mà bản thân thông điệp có thể cồng kềnh hơn trong xml chứ không phải là định dạng nhị phân được sắp xếp hợp lý. Chỉ cần chọn đúng tên lớp và tên thành viên có thể làm giảm rất nhiều ...

Hãy xem xét các ví dụ sau về phương thức trả về hàng loạt từ các phương thức trả về tập hợp một nội dung. Chỉ cần chọn tên [serialization] đúng cho lớp/trình bao bọc và các thành viên có thể tạo sự khác biệt lớn về độ dài của yêu cầu/phản hồi xà phòng được tuần tự hóa nếu bạn trả về dữ liệu lặp lại (ví dụ: danh sách/bộ sưu tập/mảng).

tên Giới thiệu tóm tắt/ngắn:

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ShortIDName> 
    <id>0</id> 
    <name>foo 0</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>1</id> 
    <name>foo 1</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>2</id> 
    <name>foo 2</name> 
    </ShortIDName> 
    ... 
</ArrayOfShortIDName> 

tên Long:

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    ... 
</ArrayOfThisClassHasALongClassNameIDName> 

Answer 3

Tôi nghĩ đó là chủ yếu mà phong bì SOAP cho biết thêm một số lượng lớn các nguyên cần thiết để xây dựng thông điệp, đặc biệt cho trường hợp phổ biến của một yêu cầu đơn giản chỉ với một vài tham số có cấu trúc không sâu. So sánh điều đó với dịch vụ web kiểu REST, nơi các tham số được bao gồm đơn giản trong truy vấn URL.

Sau đó, thêm vào đó sự phức tạp của WSDL và "doanh nghiệp" triển khai thư viện điển hình ...

Answer 4

tôi coi nó là "dày" vì chi phí khá lớn liên quan đến đóng gói và giải nén nhắn (serializing và deserializing).

Hãy xem xét dịch vụ web có phương pháp web có tên là Add có hai số nguyên 32 bit. Những người gọi gói lên hai số nguyên và nhận được một số nguyên duy nhất trong trả lời. Khi thực sự chỉ có 96 bit thông tin được truyền đi, việc bổ sung các gói SOAP có thể sẽ thêm khoảng 3.000 hoặc nhiều bit phụ theo mỗi hướng. Tăng 30 lần.

Được thêm vào đây là hiệu suất tương đối chậm liên quan đến tuần tự hóa và deserializing thư thành UTF-8 (hoặc bất kỳ) XML nào. Phải thừa nhận rằng nó khá nhanh những ngày này, nhưng nó chắc chắn không tầm thường.

Answer 5

Tỷ lệ tín hiệu trên nhiễu của SOAP quá thấp. Đối với một cuộc trò chuyện đơn giản, có quá nhiều chi phí cấu trúc không có giá trị dữ liệu; và có quá nhiều cấu hình rõ ràng cần thiết (so với cấu hình ngầm, như JSON).

Nó đã không bắt đầu theo cách đó, nhưng nó đã trở thành một poster-con cho những gì xảy ra với một ý tưởng tốt khi một ủy ban tiêu chuẩn được tham gia.

Answer 6

1 - Lược đồ XML, là một phần quan trọng của thông số WSDL, thực sự, thực sự lớn và phức tạp. Trong thực tế, các công cụ làm những việc như lược đồ XML bản đồ cho các cấu trúc ngôn ngữ lập trình chỉ hỗ trợ một phần các tính năng lược đồ XML.

2 - Thông số kỹ thuật WS- *, ví dụ: WS-Security và WS-SecureConversation, lại lớn và phức tạp. Chúng hầu như được thiết kế để không ai có ít tài nguyên hơn Microsoft hay IBM sẽ có thể thực hiện chúng hoàn toàn.

Answer 7

SOAP và WSDL là các tiêu chuẩn cực kỳ phức tạp, có nhiều triển khai hỗ trợ các tập con khác nhau của tiêu chuẩn. SOAP không ánh xạ rất tốt đến một giao diện chức năng nước ngoài đơn giản giống như cách mà XML-RPC thực hiện. Thay vào đó, bạn phải hiểu về các không gian tên XML, các phong bì, các tiêu đề, WSDL, các lược đồ XML, vv để tạo ra các thông báo SOAP chính xác. Tất cả những gì bạn cần làm để gọi một dịch vụ XML-RPC là định nghĩa và điểm cuối và gọi một phương thức trên đó. Ví dụ, trong Ruby:

require 'xmlrpc/client' 

server = XMLRPC::Client.new2("http://example.com/api") 
result = server.call("add", 1, 2) 

Bên cạnh đó XML-RPC, có các kỹ thuật khác mà cũng có thể là đơn giản hơn nhiều và nhẹ, chẳng hạn như XML đơn giản hoặc JSON qua HTTP (thường được gọi là REST, mặc dù điều đó có nghĩa một số cân nhắc thiết kế khác). Lợi thế của một cái gì đó như XML hoặc JSON qua HTTP là dễ sử dụng từ JavaScript hoặc thậm chí chỉ là một trang web câm với một biểu mẫu gửi. Nó cũng có thể được viết dễ dàng từ dòng lệnh với các công cụ như curl. Nó hoạt động với bất kỳ ngôn ngữ nào như thư viện HTTP, thư viện XML và thư viện JSON có sẵn ở hầu hết mọi nơi và ngay cả khi trình phân tích cú pháp JSON không có sẵn, nó rất dễ dàng để viết của riêng bạn.

Edit: tôi nên làm rõ rằng tôi đang đề cập đến cách SOAP khái niệm nặng là, như trái ngược với cân nặng đó là về mặt số lượng thô của dữ liệu.Tôi nghĩ rằng số lượng dữ liệu thô ít quan trọng (mặc dù nó tăng lên nhanh chóng nếu bạn cần xử lý nhiều yêu cầu nhỏ), trong khi trọng lượng khái niệm đó là khá quan trọng, vì điều đó có nghĩa là có nhiều nơi hơn có thể sai, nơi có thể có sự không tương thích, v.v.

Answer 8

Tôi đồng ý với áp phích đầu tiên, nhưng muốn thêm vào đó. Định nghĩa dày và mỏng là tương đối. Với các phương tiện như JSON hoặc REST, SOAP trông có vẻ nặng nề trên bề mặt cho các ví dụ "hello world". Bây giờ bạn có thể đã biết những gì làm cho SOAP nặng và WS 2.0 nói chung là các tính năng của doanh nghiệp/mạnh mẽ. JSON không an toàn theo cùng cách mà WS 2.0 có thể. Tôi đã không nghe nói SOAP được gọi là dày, nhưng nhiều hạt non-XML nhìn vào các thông số kỹ thuật như nặng hoặc dày. Để rõ ràng tôi không nói hoặc chống lại cả hai vì cả hai đều có vị trí của họ. XML chi tiết hơn và con người có thể đọc được và do đó "dày hơn". Phần cuối cùng là một số người xem HTTP một giao thức kết nối bền vững để được nặng cho các xu hướng web mới hơn như AJAX hơn là phục vụ trên trang lớn. Các chi phí kết nối lớn là có thực sự không có lợi ích.

Tóm lại, không có lý do thực sự ngoài ai đó muốn gọi SOAP/HTTP dày, tất cả đều tương đối. Ít tiêu chuẩn hơn là hoàn hảo và cho tất cả các kịch bản. Nếu tôi phải đoán một số nhà phát triển web thông minh nghĩ rằng anh ta đang rất thông minh bằng cách nói về cách nghĩ về công nghệ XML và cách siêu JSON. Mỗi người đều có một nơi.