On lightweight Java frameworks and service-oriented architecture |
 |
By Jack Vaughan, Editor-in-Chief
29 Oct 2008 | SearchSOA.com |
|
|
Some things that happen in the name of architecture do not exactly pan out as planned. Enterprise Java Beans is one of them. Although many individuals and corporations had a role in establishing this component standard within the larger J2EE standard, EJB is seen in some circles as IBM's major contribution to Java. Sometimes EJB is described as bloated; sometimes, worse.
The thinking behind EJB somewhat predates Java, as it followed on the heels of IBM's code-name San Francisco component effort. EJB, especially as it has evolved, is widely seen as too complex. That may be because it has tried to be fully encompassing.
Narrower, focused frameworks have arisen as alternatives to full-fledged J2EE with EJB. Chief among these is the Spring Framework, which uses Aspect-Oriented Programming techniques to identify overarching design patterns while focusing on the day's most common job, Web-enabling applications.
Preliminary data from a 2008 Java Trends survey by SearchSOA.com sister site TSS.com shows that 76.8% of survey participants have used Spring. Acting as something of a commercial Spring steward is SpringSource, a company dedicated to promoting Spring-style app building. We spoke recently with company founder and president Rod Johnson. He told us Spring and SOA are very complementary.
The portability is key to the drive to Java is not a done deal if services are tied to servers.
"SOA is about integration of different things," said Johnson. "This is where we think Spring is beneficial."
"The models in traditional methods of J2EE with EJBs tended to tie your code very much to a particular environment: the monolithic application server environment. While Spring can be happy [in a monolithic server environment], the Spring container is also inherently portable," he continued.
Able use of Spring can better ensure, 'separation of concerns.' That is one the goals of Spring, and is epitomized by its use of a Model View Controller (MVC).
With Spring, "you may have greater freedom to repurpose your business logic, and to deploy in non-traditional deployment scenarios," said Johnson.
"EJB came before SOA," said Johnson. "It was a component model and distributed technology rolled into one. It also assumed you would use RMI- or CORBA-style remoting. The EJB model is still coupled to an application server."
"The problem was that combining the component model and distribution didn't work in most cases. And it made a lot of assumptions about end services," he continued. "It was a homogenized world where you had Java at both sides of the wire. It doesn't reflect the reality of today."
"The Spring framework philosophy is that you should have a high-quality component model independent of any remoting strategy or distribution model," said Johnson. That breaks the coupling that EJB had with app server, he indicated, and provides more choice for enterprise architects.
Now, the Spring community is working on a Web services project build on the notion of 'contract first' patterns. Spring 3.0, said Johnson, will be providing substantial REST support through the Spring MVC. "The Spring component model will automatically support RESTful communications," he said.
While many successful applications have been built using EJB, it has never become exactly popular. On the face of it, there is something of a 'let's do it' attitude to lightweight frameworks. That does not mean that such approaches cannot co-exist within larger corporate SOA programs – but it doesn't mean they support SOA, either.
Have you any thoughts on the interplay or lack there of between SOA and lightweight frameworks? Let us know.
|
|
|
|
