Xstream/HTTP 服务
我们运行多个网站，这些网站使用相同的丰富功能后端作为库运行。后端由多个组件组成，这些组件之间共享许多对象。现在，出于安全原因，我们需要将无状态规则执行组件分离到不同的容器中。如果我能够在规则组件中无缝访问所有后端对象（而不是定义新的接口和对象/适配器），那就太好了。
我想使用 RPC 机制来无缝支持通过网络传递 java pojo（其中一些是 hibernate beans）。 JAXB、Axis 等 Web 服务需要为每个对象提供大量样板和配置。虽然使用 Java 序列化的那些看起来很简单，但我担心向后/向前兼容性问题。
我们正在使用 Xstream 将我们的对象序列化到持久性存储中，到目前为止很高兴。但流行的 rpc/webservice 框架似乎都没有使用 xstream 进行序列化。可以使用 xstream 并使用我的自定义实现通过 HTTP 发送我的对象吗？或者java序列化可以正常工作还是有更好的选择？
预先感谢您的建议。
We run multiple websites which use the same rich functional backend running as a library. The backend is comprised of multiple components with a lot of objects shared between them. Now, we need to separate a stateless rule execution component into a different container for security reasons. It would be great if I could have access to all the backend objects seamlessly in the rules component (rather than defining a new interface and objects/adapters).
I would like to use a RPC mechanism that will seamlessly support passing our java pojos (some of them are hibernate beans) over the wire. Webservices like JAXB, Axis etc. are needing quite a bit of boiler plate and configuration for each object. Whereas those using Java serialization seem straightforward but I am concerned about backward/forward compatibility issues.
We are using Xstream for serializing our objects into persistence store and happy so far. But none of the popular rpc/webservice framework seem use xstream for serialization. Is it ok to use xstream and send my objects over HTTP using my custom implementation? OR will java serialization just work OR are there better alternatives?
Advance thanks for your advise.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
标准 Java 序列化的好处是它生成二进制流，比任何这些 XML 序列化机制都更节省空间和带宽。但正如您所写，XML 可以更加向后/向前兼容性友好，并且如果需要的话，可以更轻松地手动和/或通过脚本进行解析和修改。这是一个权衡；如果您需要长时间存储，那么建议避免简单的序列化。
我是一名快乐的 XStream 用户。到目前为止零问题。
The good thing with standard Java serialization is that it produces binary stream which is quite a bit more space- and bandwidth-efficient than any of these XML serialization mechanisms. But as you wrote, XML can be more back/forward compatibility friendly, and it's easier to parse and modify by hand and/or by scripts, if need arises. It's a trade-off; if you need long-time storage, then it's advisable to avoid plain serialization.
I'm a happy XStream user. Zero problems so far.