开始使用黑森州

发布于 07-06 12:59 字数 680 浏览 13 评论 0原文

我有一个新项目需要一个好的二进制协议。

我正在考虑使用 Hessian,除非有人有更好的想法。

我正在阅读他们的一些文档,它并不像我想象的那么简单,所以我有几个简单的问题。

主页有一个标题为“文档”的部分,其中包含以下文档:

* Hessian Documentation
* Hessian 1.0.1 spec
* Hessian 2.0 Serialization Draft
* Hessian 2.0 Web Service Draft
* Taxonomy explaining Hessians relationship to CORBA, SOAP, RMI

1)这些文档之间有什么区别? 我假设 1.0.1 后来变成了 2.0,并且今天使用 2.0 是正确的,但我不确定。

2)您希望有人使用 2.0 序列化或 2.0 Web 服务吗? 看起来 Web 服务只是应该作为创建新实现的参考,但我还是不太清楚。

3) 使用 PHP 实现一个支持 Hessian 的服务器怎么样? 您是否需要使用 Caucho 服务器,或者您可以在 Fedora Core 上用 PHP 实现服务器并使用 Java 客户端进行连接吗?

I have a new project that needs a good binary protocol.

I was thinking of using Hessian, unless anyone has any better ideas.

I was reading through some of their documentation and it's not as straightforward as I thought, so I have a couple of quick questions.

The home page has a section titled "Documentation" that has the following documents:

* Hessian Documentation
* Hessian 1.0.1 spec
* Hessian 2.0 Serialization Draft
* Hessian 2.0 Web Service Draft
* Taxonomy explaining Hessians relationship to CORBA, SOAP, RMI

1) What is the difference between these? I assume that 1.0.1 later becomes 2.0, and that it is correct to use 2.0 today, but I wasn't sure.

2) Would you expect someone to use 2.0 serialization or 2.0 web service? It looks like the web service is just supposed to be a reference to create a new implementation, but again it's not totally clear to me.

3) What about implementing a server that supports Hessian using PHP. Do you need to use a Caucho server, or can you implement the server in PHP on a Fedora Core and connect using a Java client?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

掌心的温暖2024-07-13 12:59:17

是的,可以使用 Hessian 2.0。 该协议指定了数据结构如何表示二进制,规范很简单。

Hessian Web服务建立在Hessian协议之上,它​​指定了许多Hessian格式的标头来描述例如Hessian协议中的请求/响应格式。 它定义了请求的内容、应该调用的方法等。 它并不是严格需要的,因为没有人使用它。 您可以通过创建最适合您的“Request”类和“Response”类来自行定义它,并使用 Hessian 协议对其进行序列化。

Hessian 是 Java 序列化的替代方案,它速度较慢,因为 Java VM 不直接支持,但它比 XML 解析快得多(!)。 它可以以跨平台的方式使用,尽管您必须调整现有的实现以使它们一起工作,但规范已经到处改变(例如长度规范),因此实现往往会有所不同。 另一方面是它不是人类可读的,您总是需要一个工具将 Hessian 转换为文本。

我在一个大型企业应用程序中使用了 Hessian,其中 Java 富客户端与后端进行通信,以使客户端 JVM 版本独立于服务器 JVM 版本。 它就像一个魅力。

查看实现 Hessian4J。 它是开源的,因此您可以完全控制它。

Yes, Hessian 2.0 is the one to use. The protocol specifies how a data structure is represented binary, the spec is simple.

The Hessian web service builds on the Hessian protocol, it specifies a number of headers in the Hessian format to describe e.g. the request/response format in the Hessian protocol. It defines the content of the request, the method that should be called and so on. It is not strictly needed because nobody uses it. You can define this yourself by creating a "Request" class and a "Response" class that suits you best and serialize this using Hessian protocol.

Hessian is an alternative for Java serialization, it is slower because not directly supported by the java VM, but it is much (!) faster than XML parsing. It can be used in a cross platform way, although you will have to tweak existing implementations to make them work together, the spec has changed here and there (e.g. length specs) so that implementations tend to differ. The flip side is that it is not Human readable, you always need a tool to convert the Hessian to text.

I have used Hessian in a large corporate application where a Java rich client communicates with a back end in order to make the client JVM version independent of the server JVM version. And it worked like a charm.

Have a look at the implementation Hessian4J. It is open source so you can have complete control over it.

怀里藏娇2024-07-13 12:59:17

我过去没有使用过 Hessian,也不打算在将来使用它,我的论点如下:

对于 Web 服务,我会尽力将其保留在普通的旧 XML 中。 如果我选择二进制 XML 表示,我可能会使用 Fast Infoset - 其中是一个标准,很可能受到更多 Web 服务客户端 API/库/框架的支持。 我知道 CXF 人们已经在他们的邮件列表上讨论了快速信息集,并且应该支持它,尽管他们还没有在他们的维基上记录这一点。

如果速度是首要因素,我可能最终会使用协议缓冲区

I have not used Hessian in the past and I don't plan on using it in the future either, and my arguments are these:

For a web service, I would try really hard to keep it in plain old XML. In the event that I would choose a binary XML representation, I would probably use Fast Infoset - which is a standard and most likely supported by a much larger set of web service client APIs/libraries/frameworks. I know that the CXF people have talked about fast infoset on their mailing list and it should be supported, even though they have not documented this on their wiki.

If speed is the primary thing, I would probably end up using Protocol Buffers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文