Web Services framework versus a custom XML over HTTP protocol?

Question

Hi,

I am looking for specific guidelines for when to use Web Services frameworks versus a well-documented custom protocol that communicates using XML over HTTP.

I am less concerned about performance than I am about maintainability and ease-of-development both for client-side and server-side code. For example, I can develop a custom protocol that talks XML without writing tons of descriptor files that Web Services frameworks seem to require.

Please list specific features that Web Services bring to the table.

Answer 1

RESTful web services are very low-ceremony. If something like the Atom Publishing Protocol works for you, that's the route I would take.

Answer 2

The benefit of WS is typically derived from tooling support to generate the clients, server stubs and descriptors, and pipeline benefits such as security, encryption, and other extensibility. Without the tooling the burden to roll and process WS requests is high, and the value to your outcome is relatively low.

IMO if you don't have tools - both approaches seem to be pretty high maintenance. Pick the shortest path. If you do have tool support, go the WS route and let the tools do the heavy lifting.

Answer 3

Why do you consider to reinvent the wheel, if you're not having performance-Issues or other doubts that a WS won't do the job?

For the client this will (in most cases) be the easiest way to consume your service.

The descriptor files should anyway (at least in the .NET world) be handled from the server.

Answer 4

This is the classic build vs. buy question. Even if the framework is free, there is an investment in learning and configuring. There is the economy of scale for an acquired framework, as it will gain enhancements from the entity that maintains it, but you aren't driving that process. It may add features you want, or features that break your code, you can't tell in advance. Building yourself means startup time and later maintenance. Depending on your workforce the experts may move on and as the code becomes stale, so will the knowledge to maintain it. There are a multitude of pros and cons to this question, all of which you should consider prior to choosing your direction.

Answer 5

I would say it's a good idea to design the business logic with the ability to plug in different access methods or frameworks at a later time. It is not unheard of to have different end users that want/require different access methods (say SOAP, REST or some other technique that hasn't been invented yet).

Answer 6

We make heavy use of internal web services between our production systems, and they are all vanilla XML-over-HTTP, no SOAP in sight. We found that the cumbersome nature of WS stacks, even the better ones like XFire, just wasn't worth it.

Answer 7

I've been on the client side before of a web service that was just XML sent over HTTP. I found it pretty straightforward to work with. I used JiBX to create my XML requests from a Java object and unpacked the XML response to a Java object using JiBX too.