Advantages of Java Remote Techniques - Webservice Alternatives?

As a junior developer I've designed, implemented and consumed web services quite a few times. But I am growing increasingly suspect of the und开发者_Go百科erlying SOAP\XML used to transport data over the wire. Given this, I've been wondering about a few other remote technologies such as RPC and REST. I know little about alternatives to webservices - but I've been starting to learn . Finally, none of the webservices that we do in our organization talk outside of our network - they are mainly used as service endpoints.

With all of this in mind, are the alternatives to webservices viable solutions? Is there something else I might be missing?

Thanks!

Short Answer:

The alternatives are worse than the current SOAP/XML mess. Yes it could be done but it wasn't pretty.

Long Answer:

I've written COM/DCOM, CORBA, RPC, EJB, even sockets, and from my perspective, the approach you are questioning may have rough edges but still beats the older techniques hands down.

There is a reason for the boom in web services using SOAP/XML/WSDL/etc. They reduce the pain of managing them in several dimensions.

1. declare a endpoint and having plumbing generated - not new (RPC)
2. platform neutrality - not new (CORBA)
3. language neutrality - not new (CORBA)
4. service location - not new (COM/DCOM)

Being able to declaratively define a service and then having all the plumbing generated isn't new, RPC has tools that can do that as well. Even with those tools, though, RPC still requires a lot of manual coding to connect all the plumbing between the client and server ends. Not to mention that RPC really doesn't address how you locate the service.

Those older technologies could all get it done in their own way, but between being difficult to develop, brittle to maintain, and not having a standard way to providing service location, none of them really provided a complete solution.