Spring is going Webservices! Or a bit more specific, Spring is going SOAP. Arjen Poutsma has sent this message to the world during the last NL-JUG J-Fall conference. On his blog you can find the nitty gritty details.
Personally I think it is a good idea to build a Spring based framework and not be dependant on special web service containers. But I can’t see the point of focusing on SOAP only. I know SOAP is the de-facto standard for building message based remote services. And I also see the point he’s making about the difference between message based and rpc-style invocation. But I do not see the reason to ignore other protocols. To express this, REST is mentioned in one of Arjens blogs: REST services seem to have very little common functionality that cannot already be captured with Java classes like the HttpServlet.
Okay, agree. But so what? Maybe I need to publish my beans as both SOAP and REST service? Maybe I’m stuck with a legacy message format? Maybe, for performance reason, I do not want to use SOAP? Maybe I’m not running on a servlet container but behind my own socket? And maybe I can come up with a lot more maybe’s? Both SOAP and REST are message driven protocols that share some common similarities. And those similarities can be expressed in a common interface or abstract set of classes. Loose coupling is one of the paradigma’s lite weight application design has been build upon! So, either convince me I’m wrong or extend your horizon in order to do remote invocation beyond SOAP.
By the way, a little side-step into API design. Suppose you have two interfaces specifying a method with the same name but a different return type, how on earth are you going to implement it in one class? So SOAPMessage invoke(SOAPMessage request) throws Exception in MessageEndpoint and Source invoke(Source request) throws Exception in PayloadEndpoint is maybe not a good idea. I know chances a rare in this case but you’ll never know how the dices will be thrown when you start playing.
[editorial note, I need to re-pass Sun certification. Please visit the comments section for clarification]
But, no matter if the people behind Spring-WS are going to change the previous mentioned points or not, I think Spring-WS is a good addition to the stack of available Spring modules. And definately worth the try!
Ten year ago my programming tool of choice was VI, the well known unix editor for mentally scattered and dazled software engineers. When making the jump from C/C++ to Java, Vi was still my tool. In combination with make scripts it had everything a programmer want. Yep, it had syntax colouring, auto-completion, yep it had javadoc lookup, and indeed using the right set of macro’s there were even wizard-alike ways to construct new classes and interfaces. Of course it was not the original Vi anymore, I was using the still available improved version of Vi.
Somehow something went wrong. And I do not know exactly why and when but around five years ago I found myself using a blown up ‘Integrated development environment’ instead of my favourite good old editor. When looking back it was like waking up in hell. Memory consumption and processor speed were disrupting my programming effort. The good old commandline was replaced by a repetitive strain injury causing device called mouse. And I liked it? Things got even worse. I started jumping from IDE to IDE. My first was Kawa (an ide nobody can remember anymore, not available anymore but found this year 2000 dated article about it that brings back nostalgic feelings). I did some things with JCreator, started using Netbeans and finally after two years of struggle ended using Eclipse. And Eclipse was good! Eclipse was God of IDE’s. Okay IntelliJ was better but Eclipse was free and the gap between the two wasn’t worth the money. Eclipse was the first IDE that never gave me arguments to sneakily still use my oh so beloved old fashioned but very powerful vi. And the reason for this can all be expressed in one word: refactoring!
Refactoring is re-arrenging your code all the time. Introduce new interfaces, move classes from package to package, promote methods to be part of a super class, delete classes, change method signatures and so on. It’s a way of programming, once adopted, can’t be left anymore. And eclipse was the only free tool supporting this way of engineering. Untill this autumn. Untill Netbeans released the beta version of their new 5.0 IDE. And the new netbeans has all those nifty refactor options inside. So I decided to give it a testdrive.
Using both netbeans and eclipse I’ve been doing some simple code editing the refactoring way. All coding done by netbeans, I also performed using eclipse and vice-versa. So I actually coded everything twice just to find out how both IDE’s differ on refactor options. I don’t want to give a one to one transcript of my activities but to share the impressions I’ll provide simple examples.
I started with the creation of a simple Circle class. The basic polymorphism example you find in every OO book. Give it some members to store coordinates and a radius and add setters and getters. No problems of course for both IDE’s altough the getter/setter generation wizard of eclipse can not be found in Netbeans. At least not by me but since I found out getters and setters can be generated by code completion (type setR Ctrl -Space) I use the eclipse wizard only occasionally.
After the Circle class I did the same for a Square class and while coding I discovered, how trivial, both classes share the common member to hold coordinates. Time for a super class. For this task, Netbeans provides a ‘Extract superclass’ tool which does exactly what I want. In eclipse I create the superclass by hand and use the ‘Pull up’ tool to move common members and their corresponding getters/setters. This option is also available for Netbeans but their is a slight difference: The Eclipse way of doing this is through 4 wizard screens (instead of only one) and one of those screens is asking to remove redundant members. Neat! very neat. Worth the three extra mouse clicks. Not available in netbeans. But netbeans has a very slick preview window that makes previewing the concequences of your changes a breeze.
Okay, let’s introduce som jdk1.5 features. I’ve added a ShapeGroup class wich holds a reference to List<Shape> and implements the Iterable<Shape>interface. First thing both IDE’s come up with, Netbeans after an explicit compile, are the regular compile error referring to unfound symbols. Fix imports does the trick. Eclipse comes up with a wizard per unfound class, Netbeans uses one wizard to fix them all at once. I’m still runing into compile errors because my shape group class does not implement all abstract methods. I’m missing public Iterator<Shape> iterator(). To solve this, Eclipse provide a ‘implement/override methods ‘ wizard. This wizard shows all methods of all super classes and interfaces. Simply select and go. Netbeans is missing this wizard (or again, I could not find it) but netbeans has, just like eclipse, quick fixes. Press Alt-Enter on the class definition and Netbeans comes up with the suggestion to implement the abstract methods. Works! Almost!
This is what eclipse was generating:
public Iterator<Shape> iterator() {
// TODO Auto-generated method stub
return null;
}
And this is what Netbeans generated
public Iterator<T> iterator() {
}
See the sligth dfifference! Yep the eclipse generated code does compile while the netbeans generated method does not. More important, eclipse applied generics correctly and netbeans not (see the return type). A bug I hope (or do I need to some free wrestling with code generation templates??).
I can go on with these examples, I’ve renamed classes, moved them deleted them (Netbeans has a ’safe delete’ option giving you control over the delete proces, very handy) but the results are constantly more of the same. Both IDE’s do their thing, each on its own way, but at the end I can refactor all day long without any problems.
So my conclusion is simple: the absence of refactoring tools is not an argument anymore to ignore Netbeans. They finally did it. And finally there is a good free alternative for eclipse. The next question is whether I wan’t to change IDE or not? And I have to agree, I’m hesitating. Netbeans has a lot of other pros. To name just two, very nice web development support (really love the HTTP Session inspector) and projects backed-up by generated ant files (no more build.xml coding). These things really make me happy. But on the other hand, after coding for years with eclipse, eclipse has become some kind of second nature. Difficult! On a very powerful development box (read a lot of mem) you can use both at the same time on the same project. Works! I tried it. A bit of an overkill but a provisional solution for the dilemma to netbeans or not to netbeans.
During a java meeting about the use of (open source) frameworks there were a number of interesting conclusions. Frameworks are not used for the following reasons:
- Lack of knowledge by the team members.
Most projects are fixed date. To minimize risks, projects use the known solutions (based on experiences of the team). There is no time to select and test a possible (open source) framework and estimation is already based on a known solution. Besides all that selecting a framework is not an easy task, see what-is-the-best-java-web-framework. - Dependency of a framework on other frameworks.
Some frameworks depend heavily on other frameworks. This can make configuration management a nightmare specially when having multiple frameworks that use different versions of a common dependency. - Frameworks will be outdated in a few years.
This �feeling� is based on the rapid changing java-world. A framework like Struts is now history.
When open source frameworks are not used, what is? Most projects define there own solution and depending on the size of the project this will turn out to be a project specific framework. This has one big disadvantage: new project members need to learn this framework. For this framework the same rule applies as for open source frameworks: they will be outdated within a few years.
Is there an advantage using an open source framework? YES!
There is a good chance that your project is not the only project using the framework. When new colleagues on a project have knowledge of a framework they will be productive in no time. This works best as framework selection is done on a corporate level.
Are there more advantages ?? let me know!!
Bruce Tate, speaking at the guru4pro session on the 3th of november at TU Delft released a new book Beyond Java. You can visit the IT observer to read more about this new book.
Do we need to explore Ruby or should we wait until there is something completely new that will make our lives easier?
This week I’ve spend one full work day gaming. Doesn’t sound special, I mean, there have been times when I was a student I gamed for a full week and even in the days I started working, I spend saterdays and sundays behind my console. So what’s the point. The point is, I did it while at work! And I even did it with permission!
This week I had to teach a group of graduated youngsters, new coworkers , the fundamentals of the Java programming language. But currently every student from a computer sience related university already knows how to write Java. Java has replaced the old days of Pascal and C. Two days I’ve been busy boring them with the nitty gritty details they need to know when trying to pass the Sun certification and I had one day left to get them so bored they would run away and find themselves another employer. That’s the point where the idea of gaming came to mind. Forget the boredom of shift operators, casting floats to integers and around, subclassing innerclasses and more of the stuff that make you wonder why Java is such a great language. Forget the exam, let’s have fun! Let’s play Java!
I remembered IBM once released a java based engine that you could use to let home brewed tanks fight eachother on a small battlefield. In this game you had to program the tank yourself. You could instruct the tank to move forward, backward, fire and so on. All by programming. Once the tank was submitted to the battlefield there was nothing more left than just watch how your algorithms were performing. Great concept for the java classroom! In 2004, IBM released CodeRuler. The same idea but within a different context and, a very important aspect, available as Eclipse plugin! Read all about the game in this article.
I haven’t heard my students the whole day. Some even did not take the time to eat some lunch. Never ever had a class that silent. The only thing you could hear were the clicks of the keyboards and the sights when a bunch of knigts had kicked the enemy out of his castle. During the day I’ve been programming my own code ruler (with the beamer still on so my students could see and learn what I was doing). This way I still could do some teaching by explaining the tricks I found out myself while still enjoying the fun of professional gaming.
At the end of the day, we’ve filled the arena with all code rulers and played some quick games to see if there was a winner. And there was, and it was not me! I have to admit, some of my students have beaten me terrible. To stay within the CodeRuler context and by quoting Quintin Tarantino’s Pulp Fiction, they really went medieval on my ass! So what did it prove? Well, I’m probably to old for gaming and we have hired some damn good java engineers!
P.S. By the way, here’s a nice interview with the creator of CodeRuler. Not really indepth but just enough information to give a bit of insighs how to construct such a game engine yourself. Maybe one of my students can give it a try?
I’ve previously used CVS on a few projects. It is the defacto standard for version control, stable and works very well. At this point of time i have to make a decision on using CVS again or moving towards the buzzed Subversion.
It is a though decision for someone who is not fully aware of the nitty gritty things CVS and Subversion both have to offer. That is why i am calling for help!
What is Subversion?
According to the Subversion site, it is meant to be a better CVS
That looks promising! Subversion was designed from the ground up as a modern, high-performance version control system. In contrast to CVS, which had grown organically from shell scripts and RCS, Subversion carries no historical baggage.
Subversion takes advantage of a proper database backend, unlike CVS which is file based. The Subversion team have tried to make the new system similar in feel to CVS, so users are immediately at home with using it. Most of the features of CVS including tagging, branching and merging, are implemented in Subversion, along with host of new features:
- versioning support for directories, files and meta-data
- history tracking across moves, copies and renames
- truly atomic commits
- cheap branching and merging operations
- efficient network usage
- offline diff and revert
- efficient handling of binary files
Links:
- Using Subversion on Windows (tip!)
- Subversion for CVS Users (tip!)
- Experiences with Subversion/a>
- Subversion for CVS Users
Any comments on choosing Subversion in favour of CVS are highly appriciated 
This week together with three collegues (Simon Peter Haverdings, Martin Jaspers Focks and Robert Berg) I’m folowing a BEA Portal developers course. The course is given by a BEA trainer from the UK at the LogicaCMG office in Rotterdam. The course gives a nice overview of the BEA Portal product including BEA’s own Workshop IDE and the portal administration console. To give a rough idea the course handles the following subjects: - development installation of BEA Portal inclusing the Workshop IDE - how to set up a basic portal site that consists of a desktop (with header and footer), (sub) books, pages and portlets inside the pages.
- how to customize and override the look and feel and themes of the portal and porlets
- customize the layouts in witch portlets are placed inside a page
- Working with Java Page Flows (JPF for short) including the nifty Workshop graphical editor
- Portlet state management and user profile / property management
- Easy webservice and database integration inside JPF’s
- Integration of content management systems (CMS) inside your portlets
- Personalise content based on simple rules
- Events
- How to create ad compain based on events or user profile
The BEA Workshop IDE can’t match with the Eclipse IDE for pure Java development, but it contains nice wizards and graphical editors to support for BEA portal development. In simple situations it’s simple a case op opening an editor, drag some items from a (data) palette and make some changes in either the property editor or a dialog. In almost all situations the data displayed in the graphical editors is in fact a XML file with a XML Schema attached to it. So using Eclipse 3.1.1 with WTP 0.7 and custom ANT scripts might be an option to kick out the BEA Workshop 
A really nifty graphical editor inside the Workshop is used for the Java Page Flows (JPF for short). It draws a diagram for the JPF classes with the JSP pages and the actions between theme. You can easily drag JSP pages (new or existing) and new actions onto the JPF diagram and also adding simple form data is a super easy. Looking under the hood it appears that the Java Page Flows are implemented using struts. From what I have seen during the course and the labs of the course, BEA Portal handles a lot a portal related stuff that you would normally have to arrange yourself in a struts application. But then again the Lab exercises in the course a quite simple, and in the real world most customers want to have features that a not standard
Today the last day of the course… And after that I will probably not be involved with BEA portal for quite some time, since I have to round up my assignment at NS Reizigers and after that it’s some serious time off until the 24th of november for a large (well deserved ) holiday.
The last year (or maybe even years) I’ve been living in two completely different worlds. The first world is the well known world of java, j2ee, open source, nice discussions about technology and every month a different approach. As one can see, a pretty nice diverged environment that’s inspiring to get creative. The other world is the world of SAP, dominated by the vision of small town german Walldorf. Legacy and slowly moving targets are the keywords in this world. Both worlds seem to be pretty opposite of eachother but I always thought these two worlds get together pretty well.
How wrong I was! My goodness! Yep SAP is breathing Java all over the place. They have a J2EE server, the have a java based enterprise portal, the have an eclipse based development environment and they have a Java API for every product they sell. Sounds nice, doesn’t it. Nope, not at all. Two simple reasons: SAP refuse to adapt any standard except those needed to pass marketing technical interesting certifications (they have their own strange portlet api, strange deploy and manangement models, strange UI solution and so on). But this reason is acceptable (hey, SAP wants to make money and making money is way more simple when you lock in your customers as much as possible, every big player tends to do so). What’s not acceptible is the fact their API’s are designed and written by monkeys! And worse, the same bunch of german bonobo’s are using these API’s to write the their own merchandise. And we, the simple straighforward java developers, are required to either adjust their products or rewrite solutions from scratch using this mixture of rotten bananas and lines of java code. And for the worst (yep we’re diving deep in the bile called SAP), whenever you’ve written a nice solution using their API because the standard products/packages they provide are not sufficient enough to meet business requirements, you are facing (one year later) the invincible fact they have both changed the API and have written their own solutions. Meanwhile the SAP marketing army has overflown your customer with useless ideas and your home brew solution is kicked out for not being visionary enough.
Okay, I have to admit, I’m exaggerating a bit, and indeed this frustration driven (nope, it hasn’t happened to me yet, I’m just trying to figure out how disclose SAP XXX, in this case MDM, through SAP EP) blog is not the complete truth. And yep, those nice german guys sometimes have brilliant ideas and sometimes they even express real vision but keep in mind, this blog is not far away off the truth either! So, whenever you decide, for whatever reason, to do some tailor-made SAP based java development, think twice! Sometimes it’s better to wait a year or two or three (the so called Sit And (do not) Program strategy).
We can discuss frameworks probably till we die but somehow some frameworks reach the status of being a ‘defacto’ standard. And somehow this standard keeps changing more frequently than a formule-one driver can drive its laps on the Monaco circuit. That’s life, take it, leave it or be stubborn. And the last approach has driven me lately into a nice, convenient but not so ‘defacto’ stack of libraries/frameworks to develop webapplications. Warning, what will come is not enterprise, not widely used nor supported but just an experiment that proved me there are alternatives. Do not try this at work, your fellow web engineers might kill you for being obstinate. But here’s the recipy for small quick but nicely designed web-apps:
Let’s start at the bottom. The data. The famous persistence layer. All we normally use are relation databases, tables, maybe views stored in Oracle, MySQL or whatever (HSQL, Derby) RDBMS. Throw it away! The reasoning is simple, we’re living in an OO world with an OO language dealing with Objects not dealing with non OO data and heavily depending on mappings from the old world to the new world. No Hibernate, no Toplink, no Ibatis but just a a plain simple OO database. DB4O is our bottom. And yep, our bottom is going to be hit by more than one religious clan (indeed no need for EJB3, no need for DBA’s and no need for industry marketed standards, instead we simply fill in the needs to store and retrieve objects, not data).
Let’s move up to so called business logic. Nowadays business logic is living in a container. I’m from Rotterdam and the concept of containers is well known in this area. And I agree with it. Containers are great. Throw your logic inside a four by four by two meters dimensioned room and there you go. But do we need endless XML descriptors? Do we need declaretive assemblage? Not realy, I just want to program the content of my Container. So no Spring, no SEAM this time. Just a plain simple IOC container I can fill with my needs. Pico was born before Spring (and after the well forgotten Avalon framework), has a five minute introduction to explain the concepts and still works perfect.
Now, move up to the top. The presentation layer. The area where the framework war finds its real trenches. Struts has lost the war two years ago (can post a seperate blog on this issue, wont do that). There is Wicket, there is Spring-MVC and Spring Web Flow, there is JSF, somewhere there is Tapestry and of course the full pile of homegrown JSP, velocity, or whatever template based presentation frameworks. Oops, forgot to mention Cocoon in case you’ve driven into (or gets driven by) XML. And, last for not least we have to deal with the concept of rich clients (still think OpenLazlo is a fairly good option to create bling bling applicatons). AJAX is on the move and all previously mentioned frameworks are doing the best they can to support this technology. But why not use an ‘AJAX-native’ framework? Echo2 is using AJAX and supports the ‘Swing’ way of developing rich internet applications. A perfect match in the search for an alternative stack.
So, No RDMS and ORM but DB4O, no Spring or SEAM but Pico and Echo2 on top of it. Why not? Well, I can bring up plenty of reasons not to go for this stack. DB4o and Echo2 do not have real friendly licenses. Pico is coming from codehaus and not from apache. It’s a pain to cluster this stack, Echo2 eats up your HTTPSession (just like Wicket by the way) and DB4O is not Oracle. And finally it’s not standard so developers are facing a steep learning curve and first must go through a bunch of unforseen pitfalls to use it efficiently.
But, after playing for a while with this stack, I have to say its working. It’s working pretty damn good. It’s doing its job: It’s simple, It’s wel designed (pattern wise), and it boost up your performance (development wise). So why not give it a try? The last few days I’ve been experimenting with the DB4O-Pico-Echo2 stack. And to show you this stack has perspective, in the upcoming weeks (months ….) I’ll try to share some code snippets to make it clear.
By the way, before ending up in another war of flames, this post does not try to attack enterprise development using whatever framework. My previous post about SEAM still stands up! There is room for enterprise frameworks but all I would like to express is there is room for more simple approaches also! And all I like to show is that a simple approach might lead to unexpected results. The fact those results are far away from the ideas behind unreable JSR’s or other ’standards’ is no argument for not learning from it. At the end there’s a chief architect who decides and who we’ll follow. But maybe (desperate cry from a man falling of the cliffs), the same chief architect realizes he’s not doing enterprise but just small business.
So, maybe only to see what I’m talking, follow some of the tutorials that can be found on the net (db4o, pico, echo2), download the packages (db4o, pico, echo2) and give it a try to decide for yourself if this technology is applicable or not.
