使用 Thrift 调用 Websphere 上的 Web 服务的正确方法是什么？
我正在 Thrift 上编写一个应用程序，并在 Websphere 上部署 Web 服务。 Thrift 客户端将调用 thrift 服务器，后者又对部署在 websphere 上的 web 服务进行 Web 服务调用。
我将在哪里托管 Thrift 服务器实现，因为它将是独立应用程序？它可以在 Websphere 应用程序服务器启动之前/启动时启动吗？
我是否应该将 Thrift 作为独立运行，然后 Thrift 服务器如何获得在 Thrift 服务器（Web 服务的客户端）和服务器（Websphere 上托管的 Web 服务）之间共享的公共 VO？
在这种情况下，正确的方法应该是什么，因为 Thrift 将打开一个正在进行 websphere 调用的套接字，即使两台服务器并置？
使用套接字作为 rmi/rpc 的媒介而不是 http 安全吗？由于打开端口进行通信，会存在哪些安全漏洞？
谢谢。 快速回复将不胜感激。
I am writing an app on Thrift and webservice deployed on Websphere. Thrift client will be calling thrift server which inturn make a webservice call to webservice deployed on websphere.
Where will I host Thrift server implementation since it will be standalone app? Can it be started before/on startup of Websphere app server?
Shall I run Thrift as a standalone and then how will Thrift server get the common VOs being shared between Thrift server (which is client to webservice) and server(webservice hosted on Websphere)?
What should be right approach in this case since Thrift will be opening a socket which is making a websphere call even though both servers are collocated?
Is it safe to use sockets as a medium of rmi/rpc instead of http? What will be security loopholes since port will be opened for communication?
Thanks.
Quick reply will be highly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Thrift 服务可以作为独立应用程序实现，也可以作为在同一应用程序服务器上运行的 Web 应用程序实现。在后一种情况下，thrift 服务不必服务任何 http 请求，它应该在应用程序启动/关闭时启动 thrift 服务器。优点是您可以利用所有应用程序服务器基础设施：生命周期、监控、JMX 等。
要在两个 JVM 之间共享 VO，通常只需使它们“实现可序列化”并将类添加到两个类路径即可。在单个 JVM 内共享是微不足道的。因此，这里应该没有问题。
是的，即使服务器并置，套接字通信也很好。
是的，如果配置正确的话，它是足够安全的。使用防火墙限制对相应端口的访问可能是最简单的。
Thrift service might be implemented either as a standalone application or as an webapp running on the same app server. In latter case thrift service doesn't have to serve any http requests, it should just start thrift server on app startup/shutdown. The advantage is that you can utilize all appserver infrastructure: lifecycle, monitoring, JMX, etc.
To share VOs between two JVMs, it's usually enough to make them 'implements Serializable' and add classes to both classpaths. Sharing within single JVM is trivial. So, there should be no problems here.
Yes, socket communication is just fine, even if servers are collocated.
Yes, it is safe enough, if configured properly. Restricting access to corresponding ports with firewall is probably the easiest.