Getting started with Hessian - hessian

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?

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.

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.

Related

How to implement a SignalR client in Delphi

I look like having a requirement to access a SignalR hub with a Delphi client.
How do I implement a basic SignalR client in Delphi?
More generally, where can I find an up to date description of the protocol?
Traffic load will not be high, so it doesn't have to be extremely clever or anything.
[Edited to make it less of a "recommendation" question.]
Partial answer to question: I found useful, low level version of the documentation in a legacy zip of version 1.3
It has since vanished from the signalr git repository, and I've been unable to find a newer version online anywhere.
I have popped it here for convenience.
http://www.mithril.com.au/SignalR%20Protocol.docx
This document describes the protocol at a suitably low-level for me to feel confident I can construct a partial implementation of SignalR using existing components, sufficient for my purposes anyway.
If a more up to date version of this exists anywhere, I'd appreciate a link.

Can Google Protocol Buffers be serialized/parsed between different languages?

The official site as well as some other sources describe one of the benefits of Google Protocol Buffers as being highly inter-operable. I know the technology supports different language bindings out of the box, and many more as third party implementations, but what does that mean exactly?
Is my understanding correct in thinking that as long as I have a common schema file, I can run the protoc compiler and generate code for multiple languages, and then write a program in one language using the generated code, serialize some data to a file, and then parse it in another language in another program?
For example, could my client-side application running in Java serialize a Google Protocol Buffer and send it over the wire to a server implemented in C++ which can then parse it and use it readily as long as both sides were generated from the same schema file?
If that is correct, what allows that to happen - is it that their serialization/parsing logic adhere to a common/consistent wire format detailed here?
Yes, you can, and yes, it is because the wire format is fixed (i.e. the same for any language binding).

how can i get data from sharepoint userprofiles in xcode

I am trying to get the data of UserProfiles from SharePoint 2010 site using Objective-C within xCode.Now I am using the SOAP service in my project. Is anyone able to point me in the right direction here? Thank you....
You probably mean "iOS" or "Cocoa" instead of Xcode.
If possible, avoid SOAP. It's much easier to access a web service via REST and using JSON as transport format - and in 99.8% of all use cases, a RESTful web service and JSON will fulfill all your requirements up to 100%.
What you need to accomplish your task can be summarized into "networking development", which involves NSURLConnection (and related friend classes), and NSJSONSerialization and a few other system classes depending on your needs.
Unless you stay with a RESTful web service and JSON and moderate requirements, networking may become quickly complex. And it becomes unnecessarily complex when using SOAP. Possibly you may want to utilize a third party library which may help here.
I'm assuming you are already familiar with the basic major principles when programming in Objective-C and for Mac OS X and iOS. So, I would suggest to start with reading examples from the Apple docs involving networking and utilizing NSURLConnection (e.g. MVCNetworking).

Moses - Online Integration

We're actually looking to integrate Moses into our localization workflow. Our application is in Java and we're looking at using Moses' functionalities using xml-rpc calls.
Specifically, we're looking at APIs for:
Incremental training (i.e. Avoid having to retrain the model
from scratch every time we wish to use some new training data)
Domain-specific training (i.e. It should maintain separate
phrase tables for each domain that the input data belongs),
Decoding
The tutorial says that these can be achieved via xml-rpc calls. But, I don't find any examples or clear ways to do them. Can someone please provide some examples?
Also, I would like to know if the training and decoding phases can be done in a
distributed manner.
Thanks!
this question is perfectly suitable for moses mailing list:
http://www.statmt.org/moses/?n=Moses.MailingLists
moses server documentation (via xml-rpc):
http://www.statmt.org/moses/?n=Moses.AdvancedFeatures#ntoc28
However, I have better experiences with: moses/contrib/web/bin/daemon.pl which makes server as well, and you communicate via tcp stream.
General examples are harder to find(everyone has different enviroment,...), but make your question more specific and send it to moses mailing list. (e.g. someone had a problem with server installation: http://comments.gmane.org/gmane.comp.nlp.moses.user/7242 )

Difference between Apache CXF and Axis

What are the advantages of using Apache CXF over Apache Axis and vice versa?
Keep in mind, I'm completely biased (PMC Chair of CXF), but my thoughts:
From a strictly "can the project do what I need it to do" perspective, both are pretty equivalent. There some "edge case" things that CXF can do that Axis 2 cannot and vice versa. But for 90% of the use cases, either will work fine.
Thus, it comes down to a bunch of other things other than "check box features".
API - CXF pushes "standards based" API's (JAX-WS compliant) whereas Axis2 general goes toward proprietary things. That said, even CXF may require uses of proprietary API's to configure/control various things outside the JAX-WS spec. For REST, CXF also uses standard API's (JAX-RS compliant) instead of proprietary things. (Yes, I'm aware of the JAX-WS runtime in Axis2, but the tooling and docs and everything doesn't target it)
Community aspects and supportability - CXF prides itself on responding to issues and making "fixpacks" available to users. CXF did 12 fixpacks for 2.0.x (released two years ago, so about every 2 months), 6 fixpacks to 2.1.x, and now 3 for 2.2.x. Axis2 doesn't really "support" older versions. Unless a "critical" issue is hit, you may need to wait till the next big release (they average about every 9-10 months or so) to get fixes. (although, with either, you can grab the source code and patch/fix yourself. Gotta love open source.)
Integration - CXF has much better Spring integration if you use Spring. All the configuration and such is done through Spring. Also, people tend to consider CXF as more "embeddable" (I've never looked at Axis2 from this perspective) into other applications. Not sure if things like that matter to you.
Performance - they both perform very well. I think Axis2's proprietary ADB databinding is a bit faster than CXF, but if you use JAXB (standards based API's again), CXF is a bit faster. When using more complex scenarios like WS-Security, the underlying security "engine" (WSS4J) is the same for both so the performance is completely comparable.
Not sure if that answers the question at all. Hope it at least provides some information.
:-)
Dan
Axis2: More ubiquitous on the marketplace, supports more bindings, supports other languages like C/C++.
CXF: Much easier to use, more Spring friendly, faster got support for some WS-* extensions.
One more thing is the activity of the community. Compare the mailing list traffic for axis and cxf (2013).
Axis user 50-100 mails per month
CXF user 400-500 mails per month
So if this is any indicator of usage then axis is by far less used than cxf.
Compare CXF and Axis statistics at ohloh. CXF has very high activity while Axis has low activity overall.
This is the chart for the number of commits over time for CXF (red) and Axis1 (green) Axis2 (blue).
The advantages of CXF:
CXF supports for WS-Addressing, WS-Policy, WS-RM, WS-Security and WS-I BasicProfile.
CXF implements JAX-WS API (according by JAX-WS 2.0 TCK).
CXF has better integration with Spring and other frameworks.
CXF has high extensibility in terms of their interceptor strategy.
CXF has more configurable feature via the API instead of cumbersome XML files.
CXF has Bindings:SOAP,REST/HTTP, and its Data Bindings support JAXB 2.0,Aegis, by default it use JAXB 2.0 and more close Java standard specification.
CXF has abundant toolkits, e.g. Java to WSDL, WSDL to Java, XSD to WSDL, WSDL to XML, WSDL to SOAP, WSDL to Service.
The advantages of Axis2:
Axis2 also supports WS-RM, WS-Security, and WS-I BasicProfile except for WS-Policy, I expect it will be supported in an upcoming version.
Axis has more options for data bindings for your choose
Axis2 supports multiple languages—including C/C++ version and Java version.
Axis2 supports a wider range of data bindings, including XMLBeans, JiBX, JaxMe and JaxBRI as well as its own native data binding, ADB.
longer history than CXF.
In Summary: From above advantage items, it brings us to a good thoughts to compare Axis2 and CXF on their own merits. they all have different well-developed areas in a certain field, CXF is very configurable, integratable and has rich tool kits supported and close to Java community, Axis2 has taken an approach that makes it in many ways resemble an application server in miniature. it is across multiple programming languages. because its Independence, Axis2 lends itself towards web services that stand alone, independent of other applications, and offers a wide variety of functionality.
As a developer, we need to accord our perspective to choose the right one, whichever framework you choose, you’ll have the benefit of an active and stable open source community. In terms of performance, I did a test based the same functionality and configed in the same web container, the result shows that CXF performed little bit better than Axis2, the single case may not exactly reflect their capabilities and performance.
In some research articles, it reveals that Axis2′s proprietary ADB databinding is a bit faster than CXF since it don’t have additional feature(WS-Security).
Apache AXIS2 is relatively most used framework but Apache CXF scores over other Web Services Framework comparatively considering ease of development, current industry trend, performance, overall scorecard and other features (unless there is Web Services Orchestration support is explicitly needed, which is not required here)
As per my experience CXF is good in terms of configuring it into Spring environment. Also the generated classes are simple to understand. And as it is more active, we get better support in comparison to AXIS or AXIS2.
Another advantage of CXF: it connects to web servers using NTLMV2 authentication out of the box. (used by Windows 2008 & up)
Before using CXF, I hacked Axis2 to use HTTPClient V4 + JCIFS to make this possible.

Resources