Michael Nascimento Santos's Blog

Business Archives

Why is everyone talking about grid computing? And what are you doing about it?

"Grid computing" - though it was quite an unknown concept till a few years ago, now everyone is talking about it. Some are saying it is everything we were missing, the next big thing. Others, as some java.net bloggers, are simply skeptical and uncertain about its practical use. But the fact is many huge companies, such as Oracle and IBM, are investing a lot of money on that - and that's a good reason to take a closer look at it.

To begin with, what is grid computing? Grid computing is about spliting your work in small pieces - or jobs, as you prefer - and assigning those pieces to different computer on the network. After they have been processed, you get them together and your main task is done. But what is the big advantage of applying grid computing?

Have you ever thought about reducing the time your Ant builds take to run? What if you could use other developers' machines to run it in parallel while they are having coffee or are out in a meeting? Wouldn't that be great? And what if you could perform parts of a specific transaction in some machines available in a cluster instead of loading one box for a minute when the user could get the response in a few seconds? Those are the kind of things that may be accomplished with grid computing in an easier way.

So, what is the Java standard for grid computing? None. Soon, there will be one and then we will have to accept it, whether we agree with the way it will be or not. If you are among the ones who hate EJBs - I don't, just gave my own suggestions previously here -, or that think that JSPs are a big mistake, stop complaining! Get involved. Talk to the ones who are defining the standard. Go to grid forums, talk to the guys at Sun One Grid Engine, move! Download one of the many implementations available, such as Globus or Sun One Grid Engine, use them, share your thoughts about it! Tell the community what you like and what you don't and why.

Grid computing will be very useful to many people in the future, but if it is not useful for you tomorrow, well, maybe that's why you didn't try to shape its future when you had the chance...

Are you using JSTL as you should?

"Java is indeed very powerful, flexible and scalable, but it is pretty hard to do simple things with it!" " is far more practical to this job than Java" "We should only use Java to more complex tasks" "There is no point in using Java if your product is going to be small" Have you ever heard any of these sentences before? You probably have. And I have to agree some things are just too hard to do using plain J2EE out-of-the-box web components - I mean, using JSP/Servlets only.

When it comes to most web applications requirements, it is been just unnecessarily too difficult to implement simple stuff. But this dark era has come to an end with JSTL.

JSTL is a set of tag libraries, some validators and a cool feature that also is going to be part of JSP 2.0, the Expression Language - EL - which will improve your productivity considerably. Accessing complex bean structures, handling logical expressions, looping through arrays, collections etc., processing XML, executing SQL instructions in transactions and more - all those things are made easy by JSTL. Although some features are debatable - tags that allow you to execute SQL code inside your JSPs, for example - they can be used for some useful purposes - prototyping, for example.

For example, a few weeks ago, someone asked me how hard it would be to connect to a URL, forward a few parameters, read back the result stream and display the data returned to the user. My first thought was to say it would take a few lines of code and a couple of minutes to write and test, but then I remembered the tag from JSTL. Well, it took seconds to write and test! That is a productivity boost! Writing reliable, tested Java code in seconds - that is something your IT manager would like to hear :-)

So, if you don't know JSTL, go to URL above or visit http://java.sun.com/products/jsp/jstl/ if you want to know more about it. Believe me, you should :-).

Another paradigm change is taking place right now...

A few weeks ago, Tesla, the company I work for, sent all its employees to a non-techie workshop. One of the videos that was presented there contained the following sentence: "When paradigms change, everyone gets back to zero". That sentence got stuck into my mind because it reminded me of the OOP-to-AOP transition we are experiencing right now.

The first article I read about AOP and Java was published in 2001. It talked a little about AspectJ, the only (known) implementation at that time. Lots of things have changed since them, but AOP is still being defined. I didn't care much about AspectJ because, sincerely, I didn't like its approach: YALSTR (c) (yet-another-language-syntax-to-remember). And though I kept on reading everything I could about AOP and its intriguing terminology (aspects, pointcuts, joinpoints, introductions, concerns etc.), I really didn't take it seriously. To me, it was just another hype, as webservices are today - unless you are integrating J2EE and .NET, you are probably using the wrong technology to do the job :-) (yes, I am expecting to start a flame with this sentence).

However, through the past 2 years, AOP has being effectively applied. JBoss has been using it for its EJB implementation - and everybody copied them after (don't try to pretend you didn't, application server vendors!). And their implementation is reasonable: no cumbersome syntax nor strange concepts. Pretty simple, useful, straightforward - characteristics difficult to combine. Then some people I know started to use it extensively - especially my friend Carlos Villela. Though I think sometimes my friends are overusing it in their projects, most of the time they're doing things that would be too hard or complex to achieve using a different approach. Carlos introduced me to AspectWerkz, which is a very good implementation of AOP concepts, with a nice and clean approach.

This entry's point is: AOP is a reality. It is useful, but we have to carefully consider when to apply it and when to rely on our old OOP. There are no right ways to use AOP - yet :-). So, before you become a dinosaur and can only find jobs in companies that "still" use the "plain old Java" you are used to, get familiar with AOP. We all got back to zero. Do you wanna lose your senior status? I am using AspectWerkz right now :-P

EJB 3.0 is not ready yet! That's your chance!

If you could change EJBs, what would you do? If you had full power to add features or redesign the old ones, what would be different today? Well, in fact, you have the power to do it, but you need to be fast! JSR-220 is in its early stages and during JavaOne Linda DeMichiel, the spec lead, made it clear she wants to get input from the community.

I attended her session about EJB 2.1 just because I wanted to ask a few questions - which I did -, but close to end of her presentation, I was nicely surprised to see a few slides about what EJB 3.0 may look like. And it looks prettier than today! Her idea is to simplify EJB development by using metadata to automatically generate deployment descriptors and providing superclasses that developers can extend in order to override only the methods they actually want to change. That was great!

Also, she presented a BOF called EJB 3.0 Specification Features Input. I made a lot of comments about it, but here are some suggestions and points I criticized:

• Access to the actual Subject returned by the JAAS login mechanism: OK, we can use JAAS in J2EE. JAAS is great, because it gives you enormous flexibility regarding login mechanisms, credentials, principals etc. But how is it supposed to be useful if you can't access the credentials and principals after you have authenticated the user? That's how it works now. Hope it changes, really.
• Instance-based security: I've never been able to make any meaningful use of the security features provided by the current EJB spec. It is impossible to do it if your only option is declarative security - and I am not using it in the sense the spec uses it, but I am referring to static security. You need to be able to restrict access based on what values instance properties hold. That is how real world systems work. Interceptors - or advices - would be a good way of implementing this.
• Dynamic security: In real world enterprise systems, there is no such thing as this role will access these functionalities. Users want to define new roles and new security mappings without having to call the developers and redeploying the application. It is a fact and it is reasonable, but not supported by the current spec. It should be.
• Paging facilities: If your application server does a good job when it comes to its CMP engine implementation, then probably the only JDBC code you have to write for your application is in order to provide paging facilities. If that's so, why don't we have paging facilities as part of the spec? Why aren't they supported? A solution would be to have finders that return Lists. Then, you would be able to take a slice of it and your container would know you are going to use only this little piece. So, it could load a page, instead of the whole Collection.
• Threading facilities: If know something about the EJB 2.1 draft spec, you may argue that we already have these as Timers. Really? Don't think so. Take a look at the latest proposed final draft for the JCA new spec. That's support for multithreading! We should have some kind of thread pool provided by the container or a Work-like interface. Linda didn't quite like this suggestion, though. What do you think?
• Meaningful names for commit options: Do you know what commit option A means? Those who have some experience with EJB unfortunately do. Why couldn't it be named container-exclusive-database-access or something like it? According to Linda, the commit options were supposed to be just an example, but nearly every application server uses the terms commit option A, B or C as if the difference between them was so clear as between Entity Beans and Session Beans.

The others made some very relevant comments about basic table mapping support and other issues, but all the above were suggested by me. So, if EJB 3.0 happens to have these things, blame me! :-) But that's not the main point in this entry; the point is: make your suggestions and make them now! Take a look at the URL above and send an email to the expert group with your own suggestions. You can still shape EJB's future if you do it now.

A few words about Brazil, Java technology and myself

If you have been to the last edition of JavaOne, then you probably have seen me :-) I was one of the crazy, shameless Brazilian guys who attended the conference this year. No, I wasn't the "Brazilian superman", as one guy who works for Sun named Bruno Souza, our Javaman. :-) But, getting back to the point, there is a lot more about Java development and Brazil than you might know.

To begin with, as Manoel Lemos and Beatriz Leao mentioned at their session, we speak Portuguese - yes, we don't speak Spanish and we are more than 50% of Latin America, what means most latins speak Portuguese! We are the 12th largest world economy and our capital city is Brasilia, not Rio de Janeiro, Sao Paulo nor Buenos Aires (that last one would make some of us really angry :-P) And some national wide projects are entirely or mostly Java technology based. Oh, probably the most surprising fact: our JUGs are the largest of the world! The #1 is SouJava, which I am glad to be part of and help to coordinate.

As this is my blog let's talk a little bit about me: currently, I am working on a application that is going to be used by one of the main industry players here and it's going to control nearly everything they do. My Ant builds are taking ages - ok, 5-7 minutes, but that's ages from a Java developer perspective :-P - and I think our code base is still going to get 5 times bigger! That is what motivated my java.net main project, called AntG. Its main purpose is to make Ant builds run faster by using threads and taking advantage of grid computing. If you are interested, check it out! Give your suggestions and join the project. We are still limiting its scope and deciding how to begin to implement it, so all of you are welcome. Right now, we are discussing everything in Portuguese, since we are all Brazilians, but if you join, identify as a non-Portuguese speaker and we'll do our best to write in a language you understand - as long as it is English or Spanish. :-)

I intend to publish some useful and practical tips here and also to talk about my other projects, so keep checking my blog out.

Regards,
Michael "MisterM" Santos

This work is licensed under a Creative Commons License.