On Sun, Jul 12, 2009 at 11:14 AM, Steve Comstock <[email protected]>wrote:
> Chris Craddock wrote: > >> Unlurking for a moment... >> > <SNIP> > >> 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. >> >> > Well, that brings up the old "build or buy" conundrum. But either > case, if you have a tool to do multiple pieces, whether you purchased > it or built it yourself, I still don't see a case for setting it > up as a Web Service. That was what I was driving at before. You > don't need to set up WSDL and register the service, then use UDDI > to "discover" the service. You have it, just use it. > There are some subtle assumptions and gotchas in "you just use it". Either the thing you "just use" is bound with the rest of your application (not very flexible, but certainly easy) -OR- you have to locate and bind to it at run time. We have used versions of that since the jurassic era. Dynamic loading, or link, or (much later) DLLs and RPCs. They're all kissing cousins and they all have the same basic issue "who you gonna call?" It gets a lot worse if you plan to call/use the thing in a lot of places. Each of those places need to be individually told in their own way where to look. The point of a web service (or a REST service for that matter) is that there is an architecture for locating and binding to the "who you gonna call" at run time. You don't have to use it. In fact, most people who do use web services don't use a registry at all. However, if you don't use the registry then you have the same problem that has existed since the beginning of time. Somebody has to tell the code (via DD statements, or input parameters, or configuration files) where to look and who to call. That is a fundamental weakness because if you need to change that, you typically end up having to make manual changes all over the place to get the smoke and mirrors to line up again. That configuration effort is a weakness because human beings make more mistakes and take longer to get anything done. Using a registry and a dynamic location/binding protocol eliminates that. Adding the complexity of a registry in one place allows you to remove a lot of configuration in many other places, so while it may look like being an imposition on the "simple" way, it is actually a net reduction in complexity and yields a lot of operational flexibility. > I don't think it's "the height of insanity to just write your own"; > depending on the service, it might be a strategic way to get some > competitive advantage (provide additional features and services > that only your company offers). (Of course, if you decide to build > your own, it might end up being inferior to the one your competitors > use, then you're up a creek. An excellent reason to hire competent > people and keep them updated with training. Ahem.) > Unfortunately for many of us who have made our careers in this business, the economics just aren't there anymore. Nobody does phones in house anymore because there are companies only too willing to do it and hand you a bill. Hardly anybody does their own payroll anymore. Same reason. Pick just about any piece of non-core business processing (i.e. stuff other than what your company does to make a living) and you will find the same thing. A whole slew of outsiders willing to solve the problem for a buck and a half less than you can do it yourself. "Building your own" is pretty much guaranteed to take longer, cost more and be less reliable than buying it from somebody else who does it for a living. The outside providers get to leverage their work across multiple customers so their costs are lower, their quality and profits higher. That's why everyone and their third cousin uses packaged software now. That trend is only ever going to accelerate. Realistically no company in its right mind is going to invest development and maintenance effort in something they can buy and have somebody else on the hook for maintaining it. That's what all the buzz about *-as-a-service is about. We didn't have the software technology, or processor capacity, or network bandwidth to solve the problem back in the day, but we do now. That's why we still have datacenters full of home grown stuff and while that home grown stuff is still hanging in there, most new stuff is in one way or another getting service-ized and eventually getting hosted outside of the traditional data center, even if it is still within the corporate intranet. Folks hate to hear me say it, but just about everything we "know" about IT today is wrong. We're never going back to the home grown development cottage industry and sooner or later the in-house IT function is going to go the way of the dodo too. Our kids and grandkids are almost certainly NOT going to be doing IT as we know it. Pretty scary thought for some, but going to happen nevertheless. -- 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
