Steve Jones wrote: > This is my point, not that REST is rubbish or SOAP rocks, but that the > implementation of the execution context is of NO VALUE at all to the > business, and having multiple approaches and multiple arguments > reduces the value available, increases the complexity and reduces the > focus away from solving the NEXT problem onto re-solving the current > one.
This is a very powerful statement from my perspective. I'd like for there to be one programming language, one transport protocol, one application interface to the network and a lot of other non-variation on a theme. For decades now computer scientist have cast the same old paradigms into new representations, and then tried to breathe life into them with proud statements of purity and flexibility or reliability. Then, we've gone through years of fixes, upgrades/enhancements that have not really made a big differenence. For me, Java is the one difference. Because of the "Java Platform", we have standard APIs that I don't have to build into my distribution. The Java language spec provides some powerful things. It lacks many things that I'd enjoy using. But, because of the overall power of the platform, I don't worry about all those things, because they aren't keeping me from solving the problems I want/need to solve. The big issue for me is that once I am using Java and talking to other Java applications, why would I want to use anything but RMI programming? In the past, I did create abstraction layers to allow me to switch from RMI to something else. But now days, with JERI in place, I don't worry about that. I just leave the exercise of providing the proper invocation layer to those who want to talk to some other mechanism. They can write the code and plug it in by changing the configuration file to use the appropriate bits. If I program to just use HTTP, I'm stuck in a different rut. If I design my systems to be restful, that doesn't preclude the use of RMI, at all... I'm with Steve on the "Where's the value" thing, and how do we make the "users experience" best. As Jim Waldo has said time and time again. Wire protocols shouldn't matter any more. I'd add that in the end HTTP in order to be used arbitrarily as a replacement for another application protocol would generally only appear to be a wire protocol in use. Gregg Wonderly ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
