You don’t have to be at the Javapolis event to get informed about Oracle’s ADF-Faces donation to the open source community. Read all about it in this, this , this and probably a dozen of other blogs. A don’t think MyFaces Cherokee, the name of the apache incubation project, is the greatest thing since sliced bread as one of these blogs is calling it. The problem I have is when eating sliced bread, every slice is exactly the same. In other words, sliced bread is disastrous for creative breakfast like using standard JSF components is blocking creative web design. But like sliced bread is speeding up my morning ritual, JSF can speed up web development. And in this context I personally think Cherokee it is a major step forwards! It’s the greatest thing since peanutbutter I would say. Wait for it to show up in the list of incubating apache projects and go wild on JSF in 2006. In the mean time, get creative using Tapestry or Wicket 
The European Java Climax of the Year! With an entry fee of 300 Euro (+ VAT), JavaPolis is to be "the Apache of Conferences, low-cost and high quality!".
 |
 |
8 december 2005
De Nederlandse Java Update Dag (NLJUD) biedt jou de op deze dag de uitgelezen mogelijkheid om je te laten informeren over de nieuwste technologische ontwikkelingen en de meest interessante projecten met betrekking tot Java. Ontmoet je collega’s om bij te praten over interessante onderwerpen en leer dat bijna alles mogelijk met Java development om jouw droom waar te maken. Inschrijven is niet meer mogelijk! |
| Wie: De NLJUD is alleen bedoeld voor medewerkers van LogicaCMG en eventuele sollicitanten (niet voor klanten of externen). Tijd: Waar: |
|
Parkeren:
|
|
| Programma: | Zaal: |
| 17:00 - 18:30 Eten | Bedrijfsrestaurant 1ste etage |
| 18:30 - 18:35 Opening | Auditorium begane grond |
| 18:35 - 19:15 Keynote - Steven Davelaar (Oracle) | Auditorium begane grond |
| 19:30 - 20:00 Parallele presentaties (Track 1) |
|
| 20:15 - 20:45 Parallele presentaties (Track 2) |
|
| 21:00 - 21:30 Parallele presentaties (Track 3) |
|
| 21:30 - 21:35 Afsluiting | Bedrijfsrestaurant 1ste etage |
| 21:35 - 22:30 Borrel + Uitreiking NLJUD Award | Bedrijfsrestaurant 1ste etage |
Heeft u vragen of opmerkingen neem dan aub contact met ons op via [email protected].
SOA, Service oriented architecture, has been the hype for a while. Major vendors are embracing, even hugging, this concept and every so-called IT evangelist is writing tons of columns about it. And somehow I keep asking myself what’s new?? And more important, what is the added value of an architecture, a shared understanding of system design, based on services, based on procedural components that can be invoked remotely?
To answer the question we have to go back into history. Suppose you are a major Internet bookseller during the late 90-ties. You’re selling hundreds of hundreds of millions of books a year by Internet. The bulb is expanding, everybody believes in Internet and everybody invest in internet. And at that right moment, a not to name but very big traditional American book shop who has missed the digital bandwagon wants to jump on the services you are offering. Commercially spoken, within minutes the deal has been signed. Technically some things need to get arranged to make it possible. The only problem, your system was not designed to serve other clients than browser based book buyers. Your local low-payed script-kiddie has the solution! Let the traditional book shop simulate a browser and you can close the deal. After some e-mail discussion between your technical guy and the IT department of your new business partner, a protocol and some server-side handlers were implemented and business to business was a fact. The first web service was born.
Two months later a major television broadcasting company, having a big hit with a cooking show around an over-hyped chef-de-la-cuisine who can only cook an egg in actual life, wants to sell kitchen related books on the website of this particular show. Same protocol, same server side handler and yet another happy business customer. One year later your protocol has become a standard. Two years later a committee of wise men of an independent club with three-double-u’s in their name has asked you formalize it in a too complex and unreadable document and SOAP has been born.
No problem so far. You are running your business, others can make use of it and even exploit the same mechanisms in a complete different setting. And business-to-business communication has never been so easy. Except for the damn protocol your script-kiddie has come up with. But, no CORBA, no EDI, language independent, XML-based, invokable by HTTP and working. Cool!
Until the moment some clever guy, who is happy he will be anonymous for the rest of his life, came up with the idea to use this business-to-business technique for application-to-application communication. Still okay when both applications are written in a different language, are running on a different platform, and somehow need to communicate. But not okay, or better said not the most ideal solution, when both applications have a similar nature and the only reason to use web based services is for future openness. This guy denominated it as application integration and the industry has prefixed it with the word enterprise.
And then, the design pattern gang came along. And one of their ideas was to introduce facades. Great, love the pattern, use it every day, but somehow applications that are being used by other applications need a service-oriented facade to hide implementation. And somehow the facade pattern introduced composite applications. And somehow this pattern in combination with your popular million selling e-shop has become SOA. And nowadays we are facing the problem that every elementary function of every possible application in an IT landscape can be normalized into a web-service.
So ignore the idea of a service oriented architecture? On one hand yep! On the other nope! There are good things about the idea. Distribution of loosely coupled components focused on re-use instead of re-invention for example. Modelling of business processes into these kind of components is another. But I realize when you walk the way of component-based development, no matter if you use Web services, EJB’s or something similar, you walk directly into maintenance problems. Once a hardly visible dependency network has been twisted around (or within) your applications, it is hard to change something. You cannot blame your SOA, you should blame the way you have set-up your SOA. When chosen for web services, you have chosen for a procedural approach. Your customer service is nothing more than a bunch of old fashioned C functions (or Pascal procedures) sitting in a module called ‘Customer’. And from the procedural world we have learnt at least one major lesson: do not wire to much! Maybe it is time for object oriented web services or is this a contradictio in termino?
Knock knock. Web services are OO! Look, I have my customer definition and then I have a CRM-customer, An ERP-Customer, a BI-Customer and a whatever more customer. Using SOA I send a ‘create customer’ message to the back and I don’t care what all these customers are doing. Implementation has been perfectly hidden from interface and I can even produce polymorfistic behaviour. That’s not OO, that is procedural multiplexing. And again, SOA has some good ideas and multiplexing is one of them also. But do you need a SOA to multiplex your calls?
So, implementing a SOA, an architecture driven by procedural calls, will drive you into maintenance problem. And even worse, everybody knows SOA’s are unmaintanable but nobody is telling. Instead, to solve your maintenance problems, the big players are selling SOA solutions. You have to go or even think liquid to quote just one. When there is a book in your system, you need a book service, when there is a customer in your system, you need a customer service and when you have to many services and wires between services, your facade can’t be managed by a bunch of developers. You simply need tooling. Because you can’t change anything without predicting the impact. Guess who sells the tools? And when we call this added value, I’m lost.
So what is new? You did not have a problem until someone told you to arrange things in such a way only his tooling can help you to get out of the mess, Nothing new, everyday IT industry business where problems do not exist but get created. Why can’t we go back to the old days, when web services were used to glue business together instead of applications? Forget your SOA, go ahead, develop the applications you need, implement a message broker when a message broker has reasons for existence within your architecture, and when you are in the need of interfacing with a third party, look at protocols like SOAP. But remember, in house nobody (new) is a third party by default!
I did a short investigation into the AppFuse project, to establish if this is a tool Consultants working for the LogicaCMG Java Competence Center can use in their projects.
What is AppFuse?
AppFuse is an application for “kickstarting” J2EE web application development. It consists of a set of libraries, jsp’s, templates and several build scripts. Running the ant new target in the AppFuse root directory will prompt for a few parameters of the target application, like database and package names. AppFuse then generates and copies a deployable web application that can serve as a starting point for further application development.
How well does AppFuse work in practice?
To find out how well AppFuse really works, I followed the QuickStart Guide, the Creating new DAOs and Objects in AppFuse, the Creating new Managers, the Creating Spring Controllers and JSPs and the Adding Validation and List Screen tutorials. I then tried to port the generated code to another RDBMS (Cloudscape 10.1). I also had a go at replacing the default two column page design with a three column design.
These are my findings.
Strengths
- Short startup time - I had a deployable, database driven, tested, 3-Tier J2EE application supporting authentication, authorization, logging, click through tracing etc. in less than 3 hours. Even taken into account that I already had a complete Java environment installed on my machine (JDK, Eclipse, MySQL, Ant), this is fast … very fast.
- Choose between IBatis and Hibernate - for persistence, AppFuse lets you chose between a DAO layer implemented using IBatis or Hibernate.
- Choose between Spring MVC, Tapestry, Webwork orJSF - for the Web Tier, you can chose between two Component based (Tapestry and JSF) or two Request based web frameworks (Spring MVC, Webwork).
- Support for Test Driven Development- apart from DAO, Manager and Web classes, AppFuse also generates Test Cases and the ant targets to run them, either individually or in logical groups (test-dao, test-web, etc.).
- Build script - the Ant build script consists of 1200 lines and 65 targets and covers everything from dropping, creating and populating the database to deploying to Tomcat and fixing CRLF for Unix Machines.
- Integration with Sitemesh - the JSP’s are build up using the the Sitemesh templating library, providing for clean separation between content and layout directives. Compared to for instance Tiles, Sitemesh is more powerfull and flexible.
- Released under the Apache License - it lets us freely use the software for company internal and commercial purposes and does not require us to submit changes that we make to the software back to the Apache Software Foundation.
- Documentation and community support - the tutorials and JavaDoc are quite good, and there is an active developer community using the software.
Weaknesses
- MySQL only - the generated code is targeted at the MySQL database system. AppFuse does not support other RDBMS out of the box - manual adaptations of the generated code are necessary to achieve this.
- No clean dependency management - AppFuse relies on ant build scripts and properties files to configure its (50+) dependencies. Usage of a tool like Ivy, a simple to use but powerfull dependency manager would be nice instead.
- Heavy reliance on XDoclet for code generation - this leads to code that belongs in the Integration Layer (i.e. Hibernate mapping definitions and column names) being part of the Domain Layer.
- Large build scripts - although they do provide a lot of functionality, the large build scripts are difficult to understand and maintain. It is also not always clear what the different targets do and how they depend on each other.
- Usage of Business Keys as PKs - in general, when using Hibernate, it is a best practice to use Surrogate Keys as PKs for database tables representing Business Objects (”User”, “Car” etc.). AppFuse ignores this and uses the Business Keys as PKs.
- Small committer base - it is unclear to me how large the developer base is that actively maintains and develops the AppFuse project. This is something to investigate when planning any long running projects.
Conclusion
AppFuse does what it promises to do, which is always nice: it kick starts a J2EE project in a very short period of time. In my opinion, this makes it a very good tool for Consultants that are assigned to small to medium sized, Proof of Concept like projects. Here AppFuse really shines and should be used to its full extent, meaning including all XDoclet code generation features and ant targets.
For larger projects, that will be running over longer periods of time, that have to integrate with other RDBMS like Oracle and need a clean dependency management, AppFuse can serve as a starting point. In that case though, one really has to invest the time to refactor the generated code.
