Slashdot Mirror
Is Client/Server Really Dead?
the-empty-string asks: "Technology fads come and go, but sometimes they do leave behind real systems supporting real business processes. There was a time when 'client/server' was all the rage, and today there are thousands of such systems still in use, happily serving HR departments, providing inventory management, or tracking complex production processes. These days, after 'reusable components', 'three-tier', 'J2EE', and other resume-enhancing keywords, the magic phrase is 'Web services'. Consequently, many companies think they must scrape their existing client/server applications, in order to "move them to the Web". While the advantages of exposing functionality to the outside world are beyond debate, does this mean perfectly good and working applications must be abandoned only because they are client/server, or do they still have a useful role to play? Also, what is the migration strategy you would recommend to your boss or your customer, when these systems have to be replaced no matter what?"
C'mon... anyone who can pull thier head out of thier buzzword-infested ass knows the answer to this - of course client/server isn't going to die. For one, just look at applications like games, irc, etc. to grab a few from the Internet relm.
I think this question is really just shows the limitation of thinking in terms of technology "brand names" - i.e. client/server, webservices, etc. Because what are web services - well, they are services provided by a server over a web (http) client. Sure, they all conform to a certain general format, and they are platform independant, but is this so different from the multitude of 3270-based VM applications that some many places used (and still use?) There is still a workstation client, and there is still a central server and database repository.
In fact, as we get to more complicated web pages (xforms, etc), and more streamlined client machines, we are ironically regressing back toward the days of 3270 dumb terminals that conneted en-masse to big 360 and 370 main frames. Because is there really that much difference between a company Intranet today and thier VM system a decade ago? Aside of useability and flexability, not a whole hell of a lot.
So I argue that client/server hasn't gone anywhere. Yeah, perhaps traditional client/server applications (which lack in flexibility and are more costly - in terms of development and platform requirements - to deploy) are going by the wayside, but they are being replaced by new client/server systems that use a web client rather than a custom built DOS/Windows/UNIX/VM application.
So, I reitterate, get your head out of your buzzword infested ass, and look at technology for what it is, not just the name that people attach to it. Until individual workstations are powerful and reliable enough, and the network between them is fast and flexible enough, and some other system for keeping ata permission based comes along, we're going to need servers. And with servers will come client, in whatever form they arrive.
_sig_ is away
To me there's very little difference architecture-wise between client/server, n-tier, J2EE, web-services and so on. It all comes down to taking a single logical application and splitting it into chunks that can be reused separately and that can sit on different machines. The interesting thing is where you actually decide to split the application, and I think this is where client/server went wrong.
For the large-part, client/server was basically taking an application and putting the database on a central server, using ODBC, Oracle client or whatever to transport SQL over the network. It's the logical progression when you're used to writing VB applications using an Access database and you want to make your existing model work for lots of users.
What we're now seeing, though, is that splitting an application at the point where the business logic talks to the database is one of the worst places to do it, architecturally speaking. You finish up with your business logic bound to the presentation in a way that makes it difficult to reuse, and eventually you have multiple implementations of the same piece of business logic with a single database underneath it, and a whole bunch of inconsistency.
So J2EE, web services and so on are really about trying to make it easy for developers to split their applications into chunks somewhere between the presentation and the business logic, rather than between the business logic and the database.
But this new technology doesn't necessarily mean that people will understand the architecture any better. Just wait long enough and someone will miss the point completely and produce a piece of software that repackages ODBC, JDBC or something similar as a web service.
Are client/server applications dead? No. But you do need to have a migration path that allows you to extract the business logic as distinct software components so that you can re-use them in new applications. Whether you use web services or J2EE to help you do that is of little consequence. You could just write good libraries instead, as long as you get the conceptual architecture right.
A good migration path is one which will allow you to incrementally move business logic from your existing client/server front-end into a reusable middle-tier. Don't try to rip complex applications out and replace them wholesale - it's much more risky.
You're lost in a blizzard of buzzwords with no meaning, and acronyms for acronyms of buzzwords with no meaning. You need a vacation in a log cabin in the woods of Ohio with some deep technical books that they don't sell at Barns and Noble for a few weeks to get your feet grounded again. Your question is irrelevant. The real question you should be asking is, "Why would I ponder such a question?"
11*43+456^2
...or at least one of the points of web services?
web services gives the ability for anything to call it, 'client' programs, or web page generators. the idea is to allow a single backend that multiple front ends can utilize.
so no, i think client/ server is dead. i think it is actually now becoming client/web service.
It does?
Web services != web browsing.
The only connection, aside from a convenient and hypeworthy similarity in the name, is that both use HTTP as the protocol.
As others have noted, web services are just another version of client/server, which happen to use things like HTTP for the communications.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
--Mike--
User interfaces sometimes get downgraded when being confined to the limited set of GUI widgets available in HTML interfaces. At the very least, the roundtrip and render time required to regenerate a screen or page, even when only one item changes, is at best distracting to the user, and also wastes their time.
Where applications need to be broadly distributed, extranet and internet sites for example, HTTP/HTML can be appropriate. But for internal applications, for performance, convenience, sophistication of the UI, a compiled application running on your local desktop -and accessing a central server for shared data- is still gonna be best, imo.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
You are in an open field west of a big white house with a boarded front door.
There is a small mailbox here.
>_
Keep your packets off my GNU/Girlfriend!