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?"
One of the major problem's we've found is the next version of windows can cause problems for some clients for client-server based applications. We currently have a custom application written using Oracle forms in which the printing is unreliable and crashes the client.
With a browser based soloution you can then assume the browser at the client end should be able to work properly across different versions as long as the platform has a suitable web browser
You just then need to work on making sure the server works properly and generates standards based output that any browser is able to render. As long as you can do that you've then eliminated a number of client headaches.
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
Some exchange members may effectively put a web server at tier 3 (Member interconnectivity server) and a browser on tier 4, but that is their problem not the exchange's.
If we were writing the application again, maybe we would move non-performance critical stuff off to the web. Already the front-end is written in Java, but a mixed architecture would be verycomplicated (how to support a web-server tied intimitely with the exchange interconnection software).
The main win that a web-based solution would bring is that it would make a client much easier to update. At the moment, the exchange has to coordinate the rolling out of new releases over 550 organisations with many thousands of workstations. Painful, eh?
And then on the browser side, which do you support? If you work at the sharp end, there are many incompatability issues. If you role out your own tested/debugged browser, you may as well roll out a dedicated client.
For use as a dedicated application clients, most browsers are awefully fat (big and slow with unwanted functionality) and the extra they bring make them less easy to support when some bozo calls up to say that their trades are being garbled or lost.
Technically it's the same thing. A browser is the client and the web server, well, the server.
A better question would be if proprietary client-server solutions, that require proprietary clients are doomed.
The web services model has a client already installed in most OS's, runs in most platforms, so it has a clear advantage.
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.
Um... No. The advantages of exposing systems currently implemented in some in-house client-server way to the outside world are far from proven in most cases.
Exposing things to the outside world guarantees only one thing in itself: you will be subject to more security vulnerabilities than you ever had before.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
--Mike--
Last time I checked /. was a server....
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!
Certainly, there are a variaty of ways to distribute an application, when you start to have real compute power at the human end of things, but they're all variations on a distributed processing theme, conveniently placing a "tier" at an architectural point with clean, simple, and few interactions with components at another tier. Hence, three-tier and n-tier applications: they're just particular distributed "sweet spots" particularly appropriate for certain large classes of applications.
In the old days, if we even considered such distributed systems (requiring a PC on a desk, instead of just a terminal), we coded all the protocols, marshelling schemes, and so forth ourselves -- it was an in-house thing. So, yeah, all such distributed applications look the same, from that perspective, the way that all large C or C++ applications "look the same", if well-designed.
But, as particular distributed mechanisms meet large "sweet spots", such as a web browser/server split, they're pushed as the definitive "answer" to man-machine interaction.
And, just as quickly, or shortly thereafter, the shorcomings of a particular popular distributed architecture split become apparent, and the next "model" is pushed as the definitive "answer". The fact that it is tuned to a different class of problems is generally lost on those flogging it, and those buying it. The rest of us just kind of look at it and say, "yeah, so?" -- after filtering through the buzzword muck.
Now it is true, that, as client-server models (and all of these are just that, really) mature and are pushed into use, they are strained to the limits of their scalability, and two-tier architectures give way to three-tier architectures, and so on. So the new tunings offered by the "latest" architectural split does serve to solve new problems, but that in no way invalidates the fact that the "old" architectures did a splendid job of serving to solve the "old" problems.
The frustrating thing, from the perspective of someone like me, having worked with all sorts of distributed systems for close to 20 years, is the notion that one such architecture is sufficiently different from another that the "old skills" are now obsolete: client-server techniques do not transfer to three-tier architectures do not transfer to, what's the buzzword?, oh, yeah, "Web Services".
While the interfaces are new, and the implementations of the various components need to be picked up, a seasoned architect will look at them an say, "yup, that should scale the way we need". However, there is this notion that this can not happen quickly, and new "experts" need to be hired to replace the "old" experts.
Funny, most places don't get rid of their "if statement" C++ programmers when they need "while" statement-, or golly gee, "function call"-programmers. Understanding of standards particular to a given architectural model may be important, but it's such a small part of rolling out a working system, that any competent software engineer can deal with them.
Don't make the mistake a former employer of mine made: contracting out some servlet code to "Java experts"... that had no clue about threading issues because, while they "learned Java", they knew nothing about multitasking issues. Hint: those that understand the latter generally adapt to a different language faster than those that know a single language adapt to other than basic computer concepts. And so it is with buzzwords designed to obscure the obvious.
You could've hired me.
Client/Server or 2-tier implied you had a client which interacted directly with the database.
.NET, ActiveX, Java, etc. which communicates directly with the application server.
N-Tier development means you have a minimum of 3-tiers... Client, Logic and Database. The Logic can be broken into other parts such as business or data-access, etc. N-Tier development does not imply web server. It can, but you can also build a "fat client" using
One of the advantages of n-tier development is the abstraction between UI and logic. This allows for somewhat more rapid development on larger projects as you can divide the work up between several groups.
But the chief advantage is one of security. In order for client/server app to work, the user needs direct access to the database. With n-tier you can authenticate/authorize at the application layer, which gives you finer granularity of control than at the table layer. With the client/server model you need grant the user rights to an entire table, but with n-tier your app server has rights to the table, but the user may only have rights to the individual records that they should be able to see.
In a larger enterprise you also run into issues where once people have direct access to the database, they start running ad-hoc queries from reporting apps. It's nice to be flexible and convenient this way, but in larger environments, if those queries are not tuned they can consume a large amount of resources. So instead you keep the users out of the OLTP environment, and replicate the data to a data-warehousing environment that they can use for reporting. While you could possibly do this with training, you leave yourself at risk that your employees are all smart enough to understand. Better to just design the system to prevent potential issues.
Anyway, there's a lot of advantages in this model and there are books written on the topic. I just point out a few obvious ones that I've seen based on my experiences.
-- ;-)
Kuro5hin.org: where the good times never end.