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--
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
I don't think that client/server architecture is going anywhere anytime soon. If nothing else there are still allot of things that you simply can't do with a web based solution that you can with a dedicated client. One of the big drawbacks to real applications is the Post/reply communication of web based services, you can't get a constant stream of information. The widget options on the web are also not nierly as dynamic as what you can get in a dedicated app.
Not to say that the web does not have its place, it most assuredly does. It just not quite ready to completly replace dedicated clients yet.
I'm a programmer, I don't have to spell correctly; I just have to spell consistently
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.
Heck, go futher. Go on vacation and REALLY get your head out of the clouds.
Take a REAL vacation with family & friends. No technical books, no computers, no shop talk; just cabin life, hiking, reading novels, fishing, playing, drinking, eating, sex, whatever.
Get far, far outside the box, where you can see the big picture and gain a real perspective on your life/project/job/whatever.
Then come back, with the perspective of an outsider, but still with enough knowledge to make an informed decision.
You might be suprised by the ideas that come into your head after a real vacation.
"Can of worms? The can is open... the worms are everywhere."
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.
The client/server relationship is one that has existed a long time before computers, and it was doubtless that computers would come to be used in such a manner also. Just think about it, do we not engage in client/server activites daily? There're televisions, radios, newspapers, teachers/students in a classroom environment, etc etc. Furthermore, these models I mentioned only apply to the propogation of information, just as computer programs function, but for the distribution of other things, there are many, many more examples to be found in the real world.