使用 Java 实现高度互操作的 SOA 需要考虑哪些因素？
自从有人问“已经过去两年多了您会推荐哪种 Java SOAP XML 对象序列化库？”并假设从那时起发生了很多事情，我相信这足以成为修改该主题的充分理由。
因此，在第一个分析中，我不是用 Java 实现 SOA，而是尽可能与 .NET Framework（或任何其他企业平台）进行互操作。我正在考虑使用 Apache Tuscany 但我想知道是否有任何理由不应该这样做？任何反馈都将不胜感激。
It's been more than two years since someone asked "Which SOAP XML object serialization library for Java would you recommend?" and assuming a lot of things changed since then, I believe that's enough of a good reason to revamp the topic.
So in lieu of implementing SOA in Java that will be as interoperable as possible with the .NET Framework (or any other enterprise platform for that matter), in a first analysis I'm considering going with Apache Tuscany but I was wondering if there's any reason I should not? Any feedback will be definitely appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
实际上，我首先要考虑的是“我真的需要 SOAP/XML 吗？”。
特别是：
还有其他共享定义的方法- 例如，我们都可以使用一个 API 文档来管理“这个 API 返回这种形状的 JSON {...}”。 WSDL主要似乎可以帮助拖放开发人员；我不是其中之一。
因此，我建议查看更简单的（例如：YAGNI）协议。对于有效负载，我是 protobuf 的忠实粉丝，它故意采用更简单的模式，因此可以减少不同实现可以/不能处理什么的不确定性，同时仍然涵盖每个合理的用例。它也非常高效或者CPU/带宽都高效。 非常便携，并具有用于定义数据的架构定义语言 (.proto) ，但是比 WSDL 简单多。震撼恐怖！它不是人类可读的...好吧，有一些工具可以做到这一点:)为什么要把我们周的失败和缓慢的基于肉体的单元强加在我们的 API 上？
Actually, the first consideration I'd make is "do I really need SOAP/XMl?".
In particular:
There are other ways of sharing a definition - for example, we all manage just fine with an API document that says "this API returns JSON in this shape {...}". WSDL mainly seems to help drag-and-drop developers; of which I am not one.
As such, I suggest looking at simpler (think: YAGNI) protocols. For payload, I'm a big fan of protobuf, which deliberately is a simpler schema and therefore allows for much less uncertainty over what can/can't be handled by different implementations, while still covering every sane use-case. It is also very efficient or both CPU/bandwidth. Very portable, and has a schema definition language (.proto) for defining the data, but MUCH simpler than WSDL. Shock horror! It isn't human readable... Well, there are tools for that :) why impose the failings of us week and slow flesh-based units on our APIs?
我们使用 metro 框架，到目前为止，它已被证明与 WCF 具有高度的互操作性，包括复杂的消息级安全性使用相互证书身份验证和用户名令牌。在我们的例子中，WCF 是服务器，Java 是客户端。
We use the metro framework and so far it has proven to be highly interoperable with WCF including complex message level security using mutual certificate authentication and username token. In our case WCF is server and Java is client.