On 5/19/06, patrickdlogan <[EMAIL PROTECTED]> wrote:

> Mike's note was saying that the Amazon case is pretty strong proof
> that here's something to this SOA thang.

Mike's note was saying developers like shortcuts without
thinking much. Unless we did not read the same note.
 
 
Umm, it was Werner Vogels (not me) who said "we find that developers really just want to build their applications using the easiest toolkit they can find."   They presumably are *thinking* about their applications, not about the arcane distinctions between resources and representations, or transfer vs transport protocols.
 
My main point is that the value in all this stuff is that it asks architects to think about services as a unifying abstraction, while allowing developers to use the tools that they understand, both web-based and API-based as the task requires.The hard part with the most payoff is coming up with solid, empirically based guidelines for the architectural parts.  Unfortunately, the discussions focus on "my tool can beat up your tool, nya nya" nonsense. 
 
Think back to the early days of OO, those who lived through them.  What matters 15 years later isn't the perpetual "Smalltalk rox, C++ sux" (or vice versa) discussions (of which the SOAP vs REST permathread reminds me), but the actual design principles that can still be applied in C#, Java, Ruby, etc.

 


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to