On 11/12/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > > > > > > On Mon, 2006-12-11 at 10:34, Steve Jones wrote: > > On 11/12/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > I've worked with both kinds of toolsets (HTTP+XML and SOAP/WS) and I > > > don't see a material difference, except that WSDL generates an RPC > > > style interface typically... > > > > Which is easier for the 80%+ of developer out there. > > That doesn't mean it's the right thing to do, it just means that that's > what most people out there understand. Compare the stats of procedural > vs. OO knowledge at various points in industy history.
Ahh but the difference there was that procedural was provably wrong, the same hasn't been done for generative tools against hand crafting. In fact there was been quite a bit of research demonstrating that generative approaches (e.g. MDA) can save quite a bit of effort and maintenance costs. Doing something blindly is always dumb, but that doesn't mean that tooled approaches aren't preferable to hand-coding for the vast majority of IT "professionals". > > > > > > > > > 3. One uses an HTTP stack to access the URIs. > > > > > > > > Manual step v automatic > > > > > > Again, I'm completely at a loss as to how this is any more manual than > > > invoking an operation on a SOAP web service. > > > > In one I'm coding in Java/C# to make the call on another object > > (automatic) and its parsing all the XML for me (automatic), in the > > other I'm calling a port (manual) and doing the XML work myself > > (manual). > > > > Now for some developers the later could be quicker, but for the > > majority the former will be much simpler. > > But then why not do it in CORBA or any other previous technology? If > you have automatic code generation and automatic data binding, then you > have defeated the flexibility offered by XML messaging in the first > place. You might as well use byte offsets--they'd be more efficient. Doing it with RMI-JRMP would allow the flexibility with the ease of use. Just getting that in for Greg and Dan :) > > I'm not saying that your system won't work. We've lots of proof that it > does, but I don't believe that it will be as flexible or easily evolved > over time--especially if you don't treat XML as anything other than a > verbose data encoding format. My argument is that the problem in evolution is in the people not in the technology, the trick is to make the guys in application support able to evolve things in a simpler way, this 100% means getting them out of XML and into a simpler programming and development environment. The problem I have with REST is that very smart people are seeing benefits, but I'm not seeing benefits for the majority. Its like the reason I was against JAX-WS in JavaSE 6, its just plain dumb to add something as dangerous as async into a client environment. Delivering something that has dynamic evolution in will be great, but it also has to have a very simple programming model, which is a little bit tricky. > > ast > -- > Andrew S. Townley <[EMAIL PROTECTED]> > http://atownley.org > >
