IBMs new Method Scheduler for Java (MS4J) is a scheduler component that allows developers to execute methods on Java objects asynchronously and/or repeatedly. MS4J can increase Web application page response times by performing certain input/output (I/O) operations (such as database updates) asynchronously, in parallel with or after page delivery to the client.
We implemented something similar using JMX under WAS, because the only other way to get this working under WAS is to purchase their Enterprise Version. Funny that they are now giving it, or at least possibly part of it, for free. Hope no one bought the Enterprise version of WAS for this functionality 🙂
is Java for web development like using a 10lb sledge hammer to drive a small nail?
Maybe I just haven’t caught onto the Java craze or something, but for some things it seems like overkill. Sometimes it just seems like too much work to get something small done. I’m just wondering if I’m the only one that believes this.
We tried to see if we can use Java and JSP to replace RPG in our iSeries enviroment and it seemed like more work and trouble to do so. Not only that, but the IBM development tools were so sloooow to work with. At the time (maybe 2 or 3 years ago) we tried Visual Age for Java. I think they have a different product now. Visual Studio or something, I’m not sure. IBM also has the Eclipse thing too. I haven’t tried that yet.
I’m just wondering if there was something I wasn’t gettting. I hoped maybe I could be enlightened. It seems like the JDBC interface to the iSeries is what IBM is really pushing for data access.
Complex web applications are essentially complex applications with web frontends instead of windowed frontends. Java, with its large set of libraries and OO software design paradigms, is well suited to the task of building large business applications. Servlets and JSPs (with the appropriate MVC frameworks) provide a decent way to tack on a web interface.
Howdy
You should try Java again, in the two or three years since you last looked it has grown in leaps and bounds.
10lb hammer? hardly, Java/JSP/Servlets is easy to learn and allows you to make good decisions as to stick what code where and keeps it at a reasonable level of abstraction (somewhere between ASP.NET and CGI).
Although I do like PHP for little websites and anything not to complex.
err php is not only for little websites, jsp tends to be a resource hog regarding server performance, well thats my experience, right now am porting jsp to php.
Actually, Java itself isn’t bad for doing useful work, if you take care not to over-complicate things. It continues to amaze me how some people tend to turn simple tasks into giant complicated messes, often in an attempt to either “be creative” or just impress people with their brilliance. Projects fall behind schedule, costs skyrocket, and not very much useful work gets done. It’s depressing. Given that kind of bumbling, I can see why people in management might consider outsourcing as an alternative. At least the long drawn-out fumbling around costs less, although it still costs orders of magnitude MORE than it would if people would just get their work done!
As far as the IBM tools go, you’re right, they’re very slow. I’m currently using the newest crop of IBM tools (WSAD, WebSphere, etc.) and they’re a mess as well. WSAD is based on Eclipse and is not too bad, but some of its plugins (the JSP editor, for example) are pathetically slow. One thing you can always count on IBM for is tools that will turn even the fastest machine to mush.
The best approach is to keep it simple, but no simpler than it can be. Dispense with the fancy tools, and learn how things work by doing them manually. Use Eclipse as the IDE, Ant as the build tool, define some standard ways of doing things, and STICK WITH THEM.
is Java for web development like using a 10lb sledge hammer to drive a small nail?
I know it seems that way, but that’s simply because there is so much available on the platform designed for the task. It CAN be overwhelming.
But as Moose says, JSPs and Servlets are easy to learn. For basic pages, I think PHP and ASP are probably easier to learn, but JSPs are dramatically more difficult IMHO.
But the beauty of the platform is that if you take that little extra step to go the Java route, you will be rewarded later as complexity grows. The reason is simply because nowadays, you almost never have to “leave Java” to do most anything at all. Java can adopt most programming paradigms.
This is a simple example. Now, I don’t know anything about PHP or ASP, so I don’t know how easy it is or not to asynchronously run a piece of PHP/ASP code. But these guys wrote a cool little reflective wrapper around that process, to make it easier to run a method in the background.
So, say you wanted to send a email to your 20000 customers in the database. You write a routine to do the mail merge and feed the message into JavaMail. Typically, most browsers don’t behave well with long running processes. You don’t want to hit the “Send Mailing List” button and see the little Explorer globe spinning for 10 minutes.
Using this utility, you can simply run your method in the background as a thread within the JSP/Servlet server, and return to a page “Mailing list being sent”. No forking processes, no shells, no whatever-you-do for Windows. Just all Java, all the time. And it will work on both Unix and Windows.
Easier to maintain, easier to support, one toolset to learn.
It should say “JSP AREN’T dramatically more difficult to learn”.
Bother.
Wouldn’t it be simpler to use the already built in java.util.Timer with a corresponding Task instead of using reflection based approach ?
I think its preferable to rely on compile time checking, than run-time checking (consider the case of changing the scheduled method name)