tag:blogger.com,1999:blog-9203557.post3809467911591960490..comments2023-09-27T14:38:58.735+01:00Comments on Mark Little's WebLog: REST, SOAP, WS-* and SOA: Oh My!Mark Littlehttp://www.blogger.com/profile/15072917010265365428noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-9203557.post-63897931995871247782008-01-06T19:03:00.000+00:002008-01-06T19:03:00.000+00:00Many good points.Just a couple of remarks:> "Now w...Many good points.<BR/>Just a couple of remarks:<BR/><BR/>> "Now we all know that Web Services uses HTTP as a transport protocol."<BR/><BR/>When there is a need for firewall crossing, HTTP is the only practical transport option. Otherwise, Web Service messages can be transported using TCP or even UDP or any other transport protocol.<BR/><BR/>> "Maybe I can handle cacheing within the application anyway?"<BR/>> "And this has nothing to do with putting the human in the loop, i.e., the fact that most people interact with the Web through a browser has nothing to do with this: REST/HTTP is just as useful when there are no human tasks involved in the system."<BR/><BR/>There are a few things you might do when there is a human in the loop that make little sense in a pure machine-to-machine interaction scenario. Cacheing is one such thing. When an application responsible for monitoring the status of some remote entity sends a GetStatus message, it expects to obtain the current status, not the one that was cached three days ago.Harm Smithttps://www.blogger.com/profile/13640212266340984779noreply@blogger.comtag:blogger.com,1999:blog-9203557.post-89237335545702224452007-12-30T20:06:00.000+00:002007-12-30T20:06:00.000+00:00Hmm. Good stuff! One does wonder what happened to ...Hmm. Good stuff! One does wonder what happened to the "...and SOA:..." bit noted in the title:-)<BR/>Perhaps we should all have another go at defining what we believe SOA is and leave the "debaters" to it?<BR/>A lot of the writing at present is concentrating on "future" projects, using all sorts of fancy new languages and technologies.<BR/>Fact is, though, that at least 70% of the world's code is still in COBOL and, the amount of it is _growing_.<BR/>A hobby horse of mine? Probably, partly due to having been in IT for quite so long; also due to working with clients that have tons of this code and no time, money, let alone people, to go and write it all again in one fail swoop!<BR/><BR/>Cheers, and all the best for 2008!<BR/>Johnjohn d appshttps://www.blogger.com/profile/13009296879505481064noreply@blogger.comtag:blogger.com,1999:blog-9203557.post-50121538187830353622007-12-28T12:00:00.000+00:002007-12-28T12:00:00.000+00:00Ganesh, there are a lot worse evils in the world o...Ganesh, there are a lot worse evils in the world of computer "science" than RPC. I spent a lot of time working on various systems back in the 80's and 90's that were all based successfully on RPC. (As I said, I also helped implement RPCs so I do know quite a bit about them, thanks!) Don't look at CORBA or DCOM as shining examples of what's possible either. Distribution transparency is good for many, but distribution opacity is not always bad either (and yes, you can do some interesting things with pass-by-value as well as pass-by-reference to make them appear local too - read up on the literature).<BR/><BR/>But the important thing is that you should use the right abstraction at the right level for your project and needs. Don't over use these things, and definitely don't use them where they weren't intended.<BR/><BR/>RPC is a simplification. As with most simplifications (and abstractions) it comes with a certain set of assumptions (rules if you like): if you can live with them, then it can help. If you can't, then don't use it. But don't complain that it doesn't work in areas where those assumptions are silently ignored.<BR/><BR/>Your comment about message passing is wrong too. As Mic pointed out, it's been around a long time and had nothing to do with the remoteness of participants. Just because you're using a system that is based entirely on message passing does not suddenly give you more rigorous applications either. It takes a heck of a lot more than RPC, message-passing etc. to do that!<BR/><BR/>A couple of final notes: it's entirely possible to have an RPC system that still makes it clear that there are distributed entities around (again, look at the literature please). And message passing does not constrain you to pass-by-value semantics either! If you've got a product that does that, then fine: it's an implementation issue. But that's all it is.Mark Littlehttps://www.blogger.com/profile/15072917010265365428noreply@blogger.comtag:blogger.com,1999:blog-9203557.post-69444760344425864822007-12-28T11:47:00.000+00:002007-12-28T11:47:00.000+00:00Mic, yes I agree. My first foray into MP was with ...Mic, yes I agree. My first foray into MP was with Smalltalk-80. But I tried not to digress too much in the post ;-)Mark Littlehttps://www.blogger.com/profile/15072917010265365428noreply@blogger.comtag:blogger.com,1999:blog-9203557.post-58150900222634273772007-12-28T11:46:00.000+00:002007-12-28T11:46:00.000+00:00Stefan, I think the REST (or WS-*) gods are angere...Stefan, I think the REST (or WS-*) gods are angered: they killed my disc just after I posted ;-)Mark Littlehttps://www.blogger.com/profile/15072917010265365428noreply@blogger.comtag:blogger.com,1999:blog-9203557.post-30836838235501862962007-12-27T21:39:00.000+00:002007-12-27T21:39:00.000+00:00Mark,I'm glad to see this issue becoming important...Mark,<BR/><BR/>I'm glad to see this issue becoming important enough to discuss again. I was influenced in my thinking by your old friend Jim Webber, who opened my eyes, so to speak, to the possibilities of the messaging paradigm during a consulting engagement with my employer.<BR/><BR/>I would add one piece to your comments on RPC. It's not just a benign "constrained correlation between two messages", as it seems to appear from your post. The philosophical underpinning of RPC is the idea that remote objects can be made to look local. This is a fallacy and an unachievable goal, because we run up against the pass-by-value/ pass-by-reference differences that cannot be bridged.<BR/><BR/>The philosophical underpinning of messaging, on the other hand, is that _all_ systems are made to appear remote, and only pass-by-value semantics are supported. Although it may seem to be wasteful in the case of local access, it is in fact more rigorous in terms of system integrity.<BR/><BR/>That's the real reason why RPC is "evil", and I <A HREF="http://wisdomofganesh.blogspot.com/2007/11/why-rpc-is-evil-and-soap-rpc-is-doubly.html" REL="nofollow">blogged about that</A> at some length :-).prasadgchttps://www.blogger.com/profile/00179696156998026173noreply@blogger.comtag:blogger.com,1999:blog-9203557.post-9327464511019353232007-12-27T21:06:00.000+00:002007-12-27T21:06:00.000+00:00Wow - had a nice quiet Christmas? I think "message...Wow - had a nice quiet Christmas? <BR/><BR/>I think "message passing" is beyond even distributed computing, Alan Kay originally intended OO to be all about message passing in smalltalk. <BR/><BR/>Perhaps the CORBA or DCOM style distributed objects came from taking that idea (perhaps) too far.Michael Nealehttps://www.blogger.com/profile/14670410000512777421noreply@blogger.com