A Generic Concept
["Service-Oriented Architecture"
by Ted Farrell, Vol. 9, issue 4]
This article clearly explains the need for a service abstraction layer for building robust applications in an SOA-enabled environment. As Ted Farrell points out, SOA is a generic concept that goes well beyond Web services and extends to include EJBs, other XML-based communications, JMS, database access, JavaBean objects, and so on. Essentially, the best practice for accessing the service boils down to defining a unified service interface that is instantiated and executed by the client in the same fashion regardless of the underlying source of the business service.

-Arun Candadai

AOP Involves a Leap of Understanding
["Investing in ‘Professional Open Source'" –
An interview with David Skok, Vol. 9, issue 4]
AOP is definitely a revolution along the same lines that OOP was a revolution. Like OOP, it will only simplify development for expert programmers who learn it well, not for the less expert audience. Like OOP, poorly written AOP will be even more difficult and error-prone than poorly written J2EE.

Even today, I know many people who misunderstand OOP and, heck, OOP has been mainstream for 10 years. AOP involves a similar leap of understanding and it will take years for the majority of programmers to accept it. Even then, like OOP, most programmers will not dedicate themselves to become experts in it and, thus, only gain limited benefits.

It is highly doubtful that AOP will do anything to help that 60%, ever.

-Daniel Howard

Will This Become a Minefield?
["The Commercialization of Open Source"
by Kirk Pepperdine, Vol. 9, issue 4]
Two-tier licensing sets one clear difficulty – how does the community deal with selling freely donated code? I suspect that this may be a minefield in the future. Another more general issue is that some form of funding may be necessary to sustain projects in maintenance mode – not many people will do maintenance programming for nothing. You can already see this on Source Forge, which has a fair number of stalled projects. Perhaps this is a Darwinian trait but I do think it will become a feature of many open source projects where sexy new features will be added but annoying bugs and poor documentation will not be fixed. There is also the frequently raised argument that if everything is open source, who pays the developers who write open source – what do they do as their day job?

-Ken

Open source has always felt like an extension of grad school for students/programmers who can't seem to break away. Some day the open source programmers/hobbyists are going to get a life and wonder why they've been programming for free in their spare time after a full day's work. An infusion of cash can only feed the development and make it grow. The open source model is an anomaly in the business world and the better projects will inevitably become commercialized software. Paying the programmer isn't a sin; neither is buying commercial software. Programmers have to eat too.

-JP

Ensure Portability Through Standards Compliance
["Scalability of J2EE Applications"
by Stefan Piesche, Vol. 9, issue 4]
I recently investigated several open source and commercial caching products and hit somewhat of a brick wall with the J2EE and EJB specs. I needed a cache to serve read-mostly data in a clustered EJB application. The application runs on several app servers, so portability was a key requirement.

In my experience, the key element to ensuring portability is standards compliance. The J2EE and EJB specs forbid EJBs from using certain APIs, namely those that create threads, block on socket operations, etc. They go even further by explicitly naming forbidden APIs, such as JMS's setMessageListener(). However, pretty much all the caching products I investigated were using these APIs.

In one example, I queried the vendor (who shall remain nameless!) about the use of setMessageListener() in their product. They replied by stating that (1) it works and (2) it was fine to use those APIs in classes that the EJB uses, just not in the actual EJB bean class.

My feeling on (1) was that if it contravenes the spec, then working on AppServer version X doesn't guarantee it will work on version X+1. It also doesn't mean it will work on any other app server. On (2) I don't see that it makes any difference whether the call is in class A or in class B, which gets called from A (in the same thread)?!… The vendor in question had only recently started marketing their product as a J2EE cache (previously it had been best known as a servlet cache). I don't know if those restrictions apply to the Web tier.

In the end, due to portability concerns, we decided to roll our own. Our invalidation strategy was simple and was achievable using JMS and MDBs (no spec contravention required).

-John Segrave

ULC vs Droplets
["UltraLightClient by Canoo Engineering AG"
reviewed by Peter Leitner, Vol. 9, issue 4]
UltraLightClient reminded me of Droplets, which were reviewed in the February issue (Vol. 9, issue 2). So I tried to figure out what the differences are. Here's the result: (1) ULC integrates into J2EE servers while Droplets need their own application server; ( 2) ULC uses Swing on the client while Droplets uses AWT; (3) ULC's server-side API is Swing-like while the Droplet widgets come with their own API; (4) the ULC client is pure Java while the Droplet client has some native code; and (5) ULC uses J2EE communication infrastructure (HTTPS or RMI and IIOP) while Droplets use tunneling.

-Richard Ballestero