Slashdot Mirror
Any Experience At Application Service Providing?
gogo asks: "I'm working for a company which intends to provide an end-to-end business solution to the end users over the Internet. This will include complete sales, purchase, inventory control, CRM, financial accounting, etc., for small to medium business. Being asked to look in to this project, I have decided to have a multiprocessor Linux box for the server, and Oracle for the data base. Since the nature of the application is quite complex with all of the business logic that has to go into it, I'm toying with the idea of having the user interface in Java, as applets. But I'm not very sure how the whole thing will turn up. Is there anyone out there with some similar experience? Am I sounding reasonable or outright crazy? I've heard lots of people talking about using things like EJB, and CORBA objects to put the business logic back to the server side. I'm looking for real world experience, here."
I think you'll find that running EJB on the middle/back tiers with an HTML/JSP interface for the front tier.
This method scales well, as HTML is stateless. If you need complex client-side behavior, then an HTML interface won't be sufficient. For this, an applet will work well.
I would not have the applet talk directly to the EJB server. Currently, EJB servers require the exact same JDK version to be run on the client and the server. This is because EJB has heavy dependencies upon Java serialization, which in turn can require the same JDK on each end. This is why you often see EJB used only to talk between the servlet/jsp layer (middle tier) and the persistance layer (back tier).
Solutions like this have proven to be an order of magnitude faster that ASP or Cold Fusion technologies. JSPs tend to run a tad slower than mod_perl or mod_php solutions. They're on the same order of magnitude, though. And JSPs *can* be a lot easier to work with once your code base gets large (assuming you've got good designers, that is). With EJB, you get lots of stuff for free (free logging of transactions, built-in security, and more).
Good luck with the project. It sounds like you're just getting started. May I recommend the E*Boss EJB server? It's free, and it is quite competitive (feature-wise) with the solutions from BEA and IBM. It's fast, and makes EJB deployment really easy.
--Be human.
RMI-IIOP solves the JDK version problem, although it of course is much more limiting than normal RMI.
Most of the stuff I have seen tend to be on the order of "write the app for the server, then telnet in - ssh for the paranoid". While this definitely isn't the most pretty solution, it is one that works. Reporting could be handled by a multitude of options, but an easy one is to send the output to a file, then have the user download and print it on their end.
Not pretty, not pretty at all - but it gets the job done. This solution could be updated somewhat via an HTML interface and some Perl CGI magic, maybe with a little Javascript for client-side verification of data (prior to the "submit"). Build report CGI to spit out web pages, and have the user print those (long inventory reports could be a bitch though, do the download thing here).
Main thing is, the more complicated you make it (and generally, making it "snazzier" makes it more complicated), the more likely it is to break - and you don't want it to break. You especially don't want it to break only on certain clients, where you have to take a trip out to see what is happening. By keeping everything on the server (via telnet/ssh), you nearly eliminate this (except for the crazy client that wants to use ADDS ViewPoint emul for VT220 output - grrr)...
Reason is the Path to God - Anon
You asked for real world experience; I have none in the application server area at all, except for an abortative project that never really got off the ground.
.xinitrc that would launch the application full-screen, so they wouldn't even have to know that they were using unix/Xwindows.
Here's one idea we considered: just write a unix based application with an X windows interface to do what we wanted to, and then use VNC (to see a demo, get an account at workspot.com -- see the slashdot article on them a few weeks ago) to provide the web access side with almost no work.
The idea was that we knew how to write applications for unix well, and VNC would give us a painless web interface for free. We would set up the user's accounts with a
Well, VNC isn't really painless, as you will see if you check out workspot. If I launch it on my cable modem box and attach from work, it is great, but when you have a machine with many users it gets slow and annoying. Plus, don't trick yourself into believing that there is very much you will avoid with this route -- you will still have to solve all the problems with database access, locking transactions, concurancy, or whatever you had to solve before -- you just get to do it in a standard unix application instead of a nasty mess of wired together scripts and stuff.
Just a thought.
This may be slightly off topic, but the biggest ASP mistakes I've seen are of two types.
The first is failing to understand that hardware fails. I've seen many systems designed with multiple SPOFs (Single Points of Failure). The application is only as good as its availability.
The other is making nifty client side applets who then send multiple queries across the Internet whenever the user does something, often in a serialized fashion. It's an easy mistake to make when you develop the applet in sight of the server when your latency is measured in single digit milliseconds. When the latency spikes, the application becomes nearly useless. Try to do all your functionality on the server leaving your 'thin client' a simple HTML page.
--
Some people have a way with words, and some people, um, thingy.