SOAP-proxy tại Scala - tôi cần gì?

Question

Tôi đang cố gắng viết một chương trình trong Scala, sẽ chấp nhận các yêu cầu SOAP, nhận phản hồi từ máy chủ thực (hoặc đọc nó từ đĩa cục bộ) và trả lại dữ liệu cho máy khách gốc.

Tôi mới tham gia hệ sinh thái java/scala, vì vậy tôi không có đầu mối, nên chọn thư viện nào. Tôi nghe xử lý XML của Scala khá tốt, vì vậy tôi không biết, cho dù tôi nên sử dụng một số thư viện/khung thư viện enterprisey như jax-ws, jboss-ws, trục, cxf, xmlbeans, v.v.

về cơ bản, tôi chỉ cần

• thư viện, chấp nhận các yêu cầu (hiện tại, tôi đang nhìn jetty, nhưng tôi muốn cái gì đó natively hỗ trợ diễn viên. scala-http dường như để bù đắp đó, nhưng không phải là sản xuất -hoặc duy trì, cho rằng vấn đề)
• một số thư viện để yêu cầu dữ liệu từ máy chủ khác (như curl, libwww-perl cho java/scala)
• một hệ thống xây dựng (kiến? SBT?)
• một IDE (Tôi đang sử dụng để che khuất, nhưng hỗ trợ scala IntelliJ được cho là tốt hơn)
• một công cụ để kiểm tra nó (hiện tại, tôi đang sử dụng SoapUI)

Answer 1

SOAP thực sự là một đặc điểm kỹ thuật gớm ghiếc, với rất nhiều tiềm năng cho các hành vi rìa bất thường. Trong khi đúng là sự hỗ trợ XML trong Scala sẽ giúp bạn viết một thư viện như vậy từ đầu, nó vẫn sẽ là một nỗ lực lớn (tùy thuộc vào lượng thông số bạn cần).

Tương tự như vậy, Jetty có nhiều năm phát triển đằng sau nó; đối phó với các yêu cầu hiệu năng và hành vi bất ngờ khác mà bạn có thể chưa xem xét ... Ngay cả khuôn khổ web nổi tiếng nhất của Scala, Lift, chạy trên đỉnh một máy chủ web Java vì những lý do này. Nó vẫn hoạt động rất vui vẻ với các diễn viên.

Vì vậy, tại thời điểm này, bạn gần như chắc chắn sẽ sử dụng giải pháp đã thử và thử nghiệm với máy chủ web Java và Thư viện Java SOAP sẵn có. Nỗ lực để thêm một wrapper Scala mỏng xung quanh chúng sẽ ít hơn nhiều so với nỗ lực để xây dựng những thứ này từ đầu.

Đối với hệ thống xây dựng, sbt là công cụ mạnh mẽ nhất hiện có sẵn cho Scala, nhưng bạn có thể cần phải quay lại Maven nếu điều này là cần thiết để tạo mã bằng thư viện SOAP đã chọn của bạn.

Cuối cùng, để chọn trình chỉnh sửa. Nếu bạn hài lòng khi sử dụng Emacs thì plugin Ensime chỉ là tuyệt vời.Nếu một IDE Java thông thường hơn theo ý thích của bạn, thì IntelliJ hiện có vẻ là tùy chọn ổn định nhất, mặc dù lưu ý rằng điều này có thể thay đổi rất nhanh chóng.

Answer 2

Just một câu trả lời một phần.

Nhìn vào:

• HttpClient để làm HTTP yêu cầu
• hệ thống xây dựng, nếu bạn không có kinh nghiệm trước với ant Tôi muốn giới thiệu sbt
• Đối với IDE, tôi đã thành công tốt đẹp với IntelliJ một cách đây vài tháng. Tôi tin rằng Eclipse đã được cải thiện nhưng tôi không biết bao nhiêu.
• soapUI vẫn sẽ làm việc một cách hoàn hảo

Answer 3

Máy chủ proxy là trường hợp sử dụng cổ điển cho IO không đồng bộ/không chặn. Nếu tôi bắt tay vào dự án này, tôi sẽ bắt đầu bằng cách xem qua số Netty's HTTP support và xây dựng một proxy ngược đơn giản (chuyển tiếp các yêu cầu front-end tới các máy chủ phụ trợ và các đáp ứng phụ trợ cho các máy khách trước) trước khi chuyển sang giao thức dịch .

Khi đến lúc làm việc trên bản dịch giao thức, bạn sẽ phải chịu cơn thịnh nộ của các trình phân tích cú pháp XML. Thật không may, với kiến ​​thức của tôi, không có một trình phân tích cú pháp thấp, hiệu suất cao, hiệu năng thấp mà tự nhiên xử lý IO không đồng bộ; một vài trong số đó có thể tồn tại nhưng được nhúng vào các sản phẩm thương mại. Xem this thread để biết thêm thông tin. Tuy nhiên, bạn có thể "ăn gian", với chi phí sử dụng luồng bổ sung, bằng cách sử dụng trình phân tích cú pháp SAX, thường dựa vào việc chặn IO, để tiêu thụ đầu ra của một đường ống "đẩy tôi-kéo-bạn". Vì các phần HTTP của máy chủ của bạn không bị chặn, bạn có thể đủ khả năng sử dụng vài tá chủ đề chỉ để bung các byte xung quanh.

Khi điều đó xảy ra, tôi đã been there, and done that. :)