Dan Diephouse argues...
Making an RPC application is much easier. This is one of the killer features of SOAP/WSDL. I can take my business service and build a web service out of it with very little effort (I assert that there are non-evil ways to do this, but thats another story). I can then be interoperating with a .NET application in just a minute or two. Or I can take a WSDL, generate a set of objects, and just write some glue code between my internal objects and the web service objects.Sigh. Again with the "ease" argument. There're enough counterarguments to the false sense of security provided by "easy tooling". Heck, I don't even see the dotnet people making that case any longer. (Admittedly, since I work with zero dotnet programmers these days, I don't have to watch those lists.)
Designing with HTTP and related standards is something everyone should be studying right now, even if they're not taking it into production. This will get easier, even with Java, and the results will pay dividends way beyond what the current IDE "tooling" provides for "easy RPC".
If not, I still may have that Word document an SAP consultant sent me, telling me how to hand-edit a WSDL to get SAP's SOAP to interoperate with other SOAPs in Java and dotnet. That may make things *easier* for you.
...and I'm done.
1 comment:
The old "easy" meaning easy to write argument again. Writing the code is the easiest part of programming. Evolving the code is much harder. That's what our tools should be optimised for.
And that's what REST over HTTP is so good at. The standardised verbs are supported by so much infrastructure: caches, proxying, load balancing, etc. Doing everything as object invocations over POST requests throws all that out the window.
Post a Comment