Sự lựa chọn hiện tại để làm RPC trong Python là gì? [đóng cửa]


131

Trên thực tế, tôi đã thực hiện một số công việc với Pyro và RPyC, nhưng có nhiều triển khai RPC hơn hai điều này. Chúng ta có thể lập một danh sách của họ?

Các giao thức dựa trên Python nguyên gốc:

Các khung RPC với rất nhiều giao thức cơ bản:

Các khung dựa trên JSON-RPC:

XÀ BÔNG TẮM:

Các khung dựa trên XML-RPC:

Khác:


3
Nó thực sự phụ thuộc vào bối cảnh. Internet? LAN? Trang mạng? Tính toán phân tán? Nguyên mẫu nhanh? Băng thông? Kích thước của tin nhắn?
ddaa

@silentghost: xong. Tôi không muốn đặt "wiki cộng đồng" theo mặc định, vì đôi khi, tôi sai :) @ddaa: Bất kỳ. Tôi đang hỏi về RPC nói chung, nếu họ có một số ưu / nhược điểm trong bối cảnh cụ thể, vui lòng thêm chúng vào danh sách.
edomaur

Tôi đã có nhu cầu thực hiện RPC "thực sự" cách đây ít lâu (loại RFC 1050) và các lựa chọn sau đó không gây ấn tượng nhiều, vì vậy cuối cùng tôi đã phải tự mình làm hầu hết. Nếu bất cứ ai có một lựa chọn tốt cho điều đó, tôi muốn nghe về nó.
Mattias Nilsson

Đối với những người muốn Python-to-Python RPC - PyRo 4 phiên bản mới nhất không hỗ trợ SSL, nhưng PyRo 3 vẫn vậy - cả hai đều là Python nên họ hỗ trợ Python 2, Python 3, PyPy, Jython và IronPython. RPyc không hỗ trợ SSL, trong khi Circuits không đề cập đến điều này.
RichVel

Câu trả lời:


38

XML-RPC là một phần của thư viện chuẩn Python:


+1 cho XML-RPC để đơn giản, thậm chí tính toán rằng SimpleXMLRPCServer thiếu xử lý lỗi thích hợp.
Denis Otkidach

1
"Cảnh báo Mô-đun xmlrpc.server không an toàn trước dữ liệu được xây dựng độc hại.", Vì vậy nó có một số giai đoạn khá hạn chế.
Equidamoid

1
@Equidamoid Nếu bạn cần để phân tích dữ liệu không tin cậy hoặc không được thẩm định thấy docs.python.org/2/library/xml.html#xml-vulnerabilities
AmaChefe

16

Apache Thrift là một tùy chọn RPC ngôn ngữ chéo được phát triển tại Facebook. Hoạt động trên ổ cắm, chữ ký chức năng được xác định trong tệp văn bản theo cách độc lập với ngôn ngữ.


Thrift không hỗ trợ Python 3 chưa được hỗ trợ, đó là một sự xấu hổ
Roberto

Nhận xét cá nhân: Thrift là một cơn ác mộng bảo trì. Tôi đã không thấy hai bản phân phối Linux thậm chí sử dụng các cờ cấu hình có thể so sánh được. Cách đây không lâu (khi tôi xây dựng 0.10.0 từ nguồn), hầu hết các tính năng cần được tắt để làm cho nó được xây dựng trên các hệ thống "kỳ lạ" như Ubuntu, Debian hoặc Fedora hiện tại. Thay đổi kiểu dữ liệu dưới mui xe khiến việc sử dụng C ++ trở nên lộn xộn #ifdefvà trong 12 năm tồn tại, họ đã không thể thuyết phục bản thân phần mềm của họ đã sẵn sàng để phát hành 1.0.0. Tôi thích số lượng lớn ngôn ngữ được hỗ trợ, nhưng tôi nghĩ đó là điểm yếu của chúng: cố gắng làm quá nhiều.
Marcus Müller

(Tôi sử dụng tiết kiệm trong một trung cỡ GNU Project tôi duy trì @Roberto, hỗ trợ tiết kiệm Py3, ít nhất là bây giờ..)
Marcus Müller

Tôi thực sự khuyến khích mọi người thực sự suy nghĩ về việc bạn có thực sự cần một khung ngôn ngữ chéo mà thực sự cố gắng kết nối PHP với C ++ với Java với Python với Erlang với Common Lisp với Haskell với Swift hay không. Đây là những ngôn ngữ khác nhau, vì một lý do, và Thrift cần phải thỏa hiệp để tìm mẫu số chung. Tôi tranh luận rằng đại đa số mọi người thực sự chỉ cần kết nối 1 hoặc 2 ngôn ngữ khác nhau, và một khung mỏng hơn sẽ được ưa thích hơn.
Marcus Müller

6

Vì tôi đã hỏi câu hỏi này, tôi đã bắt đầu sử dụng python-symmetric-jsonrpc . Nó khá tốt, có thể được sử dụng giữa phần mềm python và non-python và tuân theo tiêu chuẩn JSON-RPC. Nhưng nó thiếu một số ví dụ.



2

Có một số nỗ lực để làm cho SOAP hoạt động với python, nhưng tôi chưa thử nghiệm nhiều vì vậy tôi không thể nói nó có tốt hay không.

SOAPy là một ví dụ.


2
Đã sử dụng hầu hết các khung SOAP và tự triển khai một khung để thực hiện RPC dựa trên phản xạ, lời khuyên của tôi rất đơn giản - đừng làm điều đó. Nếu bạn không cần giao tiếp ngôn ngữ chéo + mô tả giao diện độc lập + ánh xạ tới các lớp tùy chỉnh, thì sự phức tạp của SOAP sẽ chỉ là vấn đề đau đầu. Ngay cả khi bạn cần sử dụng nó, bạn sẽ cần có kinh nghiệm để biết tập hợp con nào của SOAP an toàn để sử dụng.
Kiến Aasma

3
SOAP là cơn ác mộng nói chung và đặc biệt là trong Python. Đừng sử dụng nó trừ khi bạn bị ép buộc.
Denis Otkidach

4
Kinh nghiệm hạn chế của tôi với SOAP đồng ý với các ý kiến ​​khác ở đây. xmlrpc thường làm mọi thứ tôi cần.
Mattias Nilsson

2

Chúng tôi đang phát triển Versile Python (VPy), một triển khai cho python 2.6+ và 3.x của khung ORB / RPC mới. Chức năng phát hành AGPL dev để xem xét và thử nghiệm có sẵn . VPy có các khả năng python riêng tương tự PyRo và RPyC thông qua lớp đối tượng gốc chung ( ví dụ mã ). Sản phẩm được thiết kế để tương tác đối tượng từ xa độc lập với nền tảng để triển khai Nền tảng Versile .

Tiết lộ đầy đủ: Tôi làm việc cho công ty phát triển VPy.


1

có thể ZSI thực hiện SOAP. Tôi đã sử dụng trình tạo sơ khai và Nó hoạt động đúng. Vấn đề duy nhất tôi gặp phải là về việc thực hiện SOAP thông qua HTTPS.


0

Bạn đã bỏ lỡ omniORB . Đây là một triển khai CORBA khá đầy đủ, vì vậy bạn cũng có thể sử dụng nó để nói chuyện với các ngôn ngữ khác có hỗ trợ CORBA.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.