Unlurking for a moment... On Thu, Jul 9, 2009 at 6:50 AM, Steve Comstock <[email protected]>wrote:
> Timothy Sipples wrote: > >> Nobody so far has mentioned another factor: as you increase the "distance" >> (latency) between applications and databases, CPU and memory >> consumption increases on both sides. I call this phenomenon "proximity >> effects." These proximity effects can be extremely large in many cases. >> > I would buy "Large in some cases but by no means all". Once you have to undispatch work and dispatch something else in the interim it matters a whole lot less whether the thing that the interrupted work is waiting on lives on the same processor or on Mars. As soon as two or more pieces of your application are no longer in the same memory, it doesn't matter a whole hell of a lot how far apart they are - particularly if you don't control the whole thing. > I'm also observing more and more organizations finally figuring out that >> dis-aggregating existing architectures is exactly the wrong direction to >> head. The management costs and service quality dimunition, in particular, >> are just not worth it, and they're getting more costly every year. I find >> I'm getting more and more enthusiastic about not making things more >> complicated than they need to be, as a general rule -- indeed, to seek >> opportunities for simplification. And more and more people seem to be >> coming to the same conclusions nowadays. >> > You seem to be presuppose some innate rightness of having all of the work in one big box, when in fact, there are huge benefits in scalability and managability from breaking up and distributing work. That's pretty much the point of sysplex after all. You're also presupposing that there are inherent service and quality impacts when you disaggregate. That may often be true in practice, but there's no underlying law of nature that makes it so. To-wit, the previous point about sysplex. Rather than adopting a "complexity is bad" position, it would be more apt to paraphrase Einstein... "A system (theory) should be as simple as possible, but no simpler." Sysplex is more complex than single instances of plain old MVS, but the benefits far outweigh the complexity. The same is true of distributed systems. Not all complexity is bad. > > Well, yes. That's why I have trouble getting excited about Web > Services. Talk about complicated. > > Write the service code > Describe in WSDL > Register in some repository > When someone looks for the service, negotiate a price > Once accepted, let the requestor run the service > Bill me later > > For goodness' sake: write your own subroutine and be done with it. > well in fairness, only the first two are actually requirements for a web service. The first one you have to do no matter whether you're doing web services or CICS/Cobol so I don't see it being relevant to complexity and the WSDL-related tasks are largely done by tools, not by humans. Publishing web service endpoints in a registry is a good thing to do because it allows for run-time binding which makes the applications a lot easier (not harder) to manage and makes them more resilient and flexible. You can move application parts around without changing any code or parmlib-like configuration data. I don't know of anyone doing the "negotiate a price/bill me later" thing with web services but I guess in theory it could be done. So boiling the meat off the bones here, the only real extra work is the (tool-assisted) WSDL processing and service registry stuff. I will admit they can look a bit intimidating but, in return you get flexibility that you can't even dream about if you "just write your own subroutine and be done with it". If what you're trying to accomplish looks like a simple subroutine call, then it probably is simple enough to be one. OTOH if you're trying to juggle data from multiple places to buy stuff online, pay for it, arrange shipping etc. then it would be the height of insanity to just write your own. Those tools have not become pervasive because they are complex and hard to use. They are pervasive because they are powerful and useful. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
