NASA SPG REST and SOAP
Thanks to Benjamin Chartier, I'm finally catching up with Allan Doyle's summary of the NASA SPG's recent session on web services. Benjamin and I disagree with the architecture sketched below [1]:
I like it. I don't interpret the blue border between "SOAP" and "REST" literally as my firewall, but as a horizon of trade-offs involving scalability. Outside (aka "the web") is where you, in the words of Jim Webber, trade latency for scalability. Inside is where you trade scalability for nice tools and the ease of programming with distributed objects or XML wrappers around distributed objects.
Comments
Re: NASA SPG REST and SOAP
Author: Benjamin Chartier
You're right, I misunderstood the border between SOAP and REST. Thank you for this clarification.
Benjamin
Re: NASA SPG REST and SOAP
Author: Allan Doyle
Indeed, the boundary is not the firewall. The idea is that we have to accommodate systems like ECHO that have been under construction for a long time and represent a huge sunk cost, and that we don't simply want to wrap them, but let them continue on for as long as it makes sense. When you're building a real-world system, it's often better to have points of stability than to keep chasing the latest trend.
That being said, those kinds of systems then can form the basis for adding new interfaces in ways that make them more useful beyond the internal enterprise boundary.
I think a side effect of this is that the people working on the big systems are not pushed into a defensive mode where they feel they have to spend all their energy preserving their system. Instead, they can become partners who try out new ideas and follow the ones that show the most promise.
If anyone is interested in another NASA earth science web services meeting, let me know. There's one coming up in October where I could use a speaker or two...