There is a bit of technology in there in the reason (I wouldn't recommend using Dutch as an encoding and shipping messages using cheese for instance) but beyond the basics of 1) Must be over http(s) 2) Must have a clearly defined contract then I'm always finding that the cultural and business decisions are much more important and drive TCO much more than specifics of execution context.
And if its purely about technology the Eiffel as a language for most stuff, LISP when dealing with complex processing on large sets of data, and as a mechanism for transfering information accurately and at speed... teenagers using SMS :) All choices are a compromise, Java, C# and Ruby are far from ideal languages (but heaven in comparison with Perl, PHP, VB and their bastard kin), dumping ASCII or Unicode over ports so two binary environments can communicate is also a poor choice from a engineering perspective. As you say, we all have to swallow our pride sometimes and recommend what will _work_ for a given environment, not what we consider to be perfect. Steve On 25/11/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > What you're telling me is that *all* of your reasons are non- > technical. If so, I agree that without a doubt WS-* is the "safe" > option. If I am consulting for one of my clients, I'd possibly use > similar or even the same arguments. Similarly, I often recommend Java > and J2EE/Java EE (with a good conscience) even though I consider Ruby > on Rails to be far superior. > > As I said before - it all depends on the discussion we're having ... > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ > > P.S.: I mentioned Indigo/WCF's REST support, and Microsoft is hardly > a minor vendor. I'd just *love* to see Don Box's 2006 opinion on REST > vs. SOAP ... > > On Nov 25, 2006, at 7:29 PM, Steve Jones wrote: > > > On 24/11/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > >> I agree with the notion that business is more important than IT, and > >> many, many IT folks should work to learn a lot more about the actual > >> business value and their part (or lack of) in it. > >> Whether or not REST vs. WS-* or Java vs. Ruby or C++ vs. Smalltalk or > >> Windows vs. Linux vs. OS X is relevant or not depends very much on > >> the topic of the discussion we're having. When we're talking about > >> business strategies for a telecommunications company, Java vs. Ruby > >> doesn't play a big role. That doesn't mean that they're the same — > >> even if they're both "just programming languages". > > > > And neither of them can hold a candle to Eiffel as a decent > > programming _language_ IMO. Java is a poor language from a syntax and > > readability perspective and doesn't how the power and control that > > Eiffel had. > > > > I'd never recommend eiffel though as it doesn't have the commercial > > weight that Java has. > > > >> > >> Similarly, I refuse to agree with the assertion that when I look at > >> the technical, architectural properties of a system landscape, it > >> doesn't matter whether its architecture is built around DCOM/MTS, > >> J2EE, WS-* or REST. > > > > Of course it matters, and that includes the skills of the people that > > are around, the support contracts you can get and the viability of the > > platform in 5 years time. If you custom build everything then its > > going to be a pig to maintain. > > > >> > >> But that's all beside Steve's original point, which IIRC was "even if > >> it's cool, it doesn't matter because the vendors don't do it". I > >> disagree: Witness the inclusion of (admittedly bad) REST support in > >> Indigo/WCF and Axis2, or the Systinet 2 repository's REST interface, > >> or the fact that Google's Nelson Minar now asserts he'd never choose > >> SOAP and WSDL over REST again … on the Internet, it seems to me that > >> SOAP/WSDL has clearly lost, and this does not bode well for its > >> future in the enterprise. > > > > Odd how you've picked minor vendors and one ex-Google person, XML-RPC > > could make bigger claims! I'd use the examples of the vertical > > standards like the forestry guys in OASIS or the meat packers > > association of Australia, all of whom are using WS-* as the basis. So > > while REST has the hype in the developer community, this isn't matched > > in the architectural or business communities. > > > > REST is _nowhere_ in terms of commercial standards. > > > >> > >> I will continue to help build good WS-based architectures — I'm not > >> as principled as Mark Baker :-) Whenever I can get someone to listen, > >> I will try to convince them of the REST alternative, though, and I > >> expect this to get easier over the course of the next few years. > > > > Until there are major industry vertical standards, and major > > enterprise software support, around REST its very hard to justify it > > as a commercial or architectural decision, and its deeply frustrating > > that IT continues to try and improve on a bit of the architecture that > > actually isn't very important at all. If the effort put into REST was > > put into something important, like service modelling or decent > > business SLA management then everything would move forwards, instead > > we are arguing about the best wrapper to use for chocolate... when all > > anyone cares about is the chocolate. > > > > > >> > >> > >> > >> Stefan > >> -- > >> Stefan Tilkov, http://www.innoq.com/blog/st/ > >> > >> > >> > >> > >> > >> > >> > >> On Nov 24, 2006, at 4:55 PM, Anil John wrote: > >> > >>> > >>> <SteveJones> > >>> The problem isn't the technical standards IMO, its the modelling of > >>> the business and what a service should _be_ that is the biggest > >>> challenge to successful SOA adoption and implementation. > >>> </SteveJones> > >>> > >>> +1 > >>> > >>> I would add, if Steve does not already have it as part of his > >>> interpretation of modeling the business, that semantic > >>> understanding and agreement on the information that the business is > >>> working with, as well the cultural/organizational aspects are also > >>> a critical challenges to SOA adoption and implemenation. > >>> > >>> Regards, > >>> > >>> - Anil > >>> > >>> :- > >>> :- Anil John > >>> :- http://www.aniltj.com/blog > >>> :- > >>> > >>> > >>> > >> > >> > >> > >> > > > > > > > > Yahoo! Groups Links > > > > > > [EMAIL PROTECTED] > > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
