By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Developers must, in short, be willing to adapt to changing features, APIs and protocols, and they must not be forced to write everything using a narrow set of tools, whether they toe the official Java EE party line or not.
The answer for whether to use a particular API or platform must be based on the merits and the situations the developers are faced with. To be fair, in Part One of Spring to Java EE Migration, the author makes this same comment. I am aware of the bias involved in my selections and try very hard to debate the merits of all options.
We must not forget this when designing greenfield applications or upgrading existing ones. Certainly greenfield applications have their choice of options, Java or no, and often these choices are dictated by the makeup of the development team, existing applications and where the company sits between conservative, stay-the-course technology selections and remaining on the cutting edge.
Would it be wise to gut a legacy Spring model-view-controller user interface built with Spring Beans in order to move to Java EE's JSF and EJB on the existing application? How unstable would that make the new design until the migration effects settle down? Developers make choices to stay with an existing platform in some cases because the expense and stability risks to the applications don't make up for the risk of the change. On the other hand, when an existing platform becomes too bloated to work with, then more drastic action may be required, and we've done that as well.
It's about innovation and choice
Open source development is about choice. It is about the meritocracy of innovation, not about following one corporation's "way." If someone comes along with a better, sleeker, easier platform for Java EE to test, configure and deploy than Spring, I would like to see it. And I might use it.
But as I look at Spring vs. Java, these three facts remain: Spring is indispensable because it provides code that can be run on any Java platform, it separates business logic from enterprise platform abstractions and doesn't impose a terrific amount of complexity on developers.
The Spring community is not tethered to a multi-vendor community process, so it can move quickly and try new things. Sometimes these attempts fail: Witness the attempt to build an OSGi-based application server. The SpringSource dm Server was highly innovative, but, internally, it was a commercial failure. Rod Johnson spoke about this publicly, admitting that they were either early or had bet on a horse that just wasn't ready for the market. However, that didn't stop SpringSource from trying. In fact, the company donated the dm Server codebase to the Eclipse foundation, where it became the Eclipse Virgo project, which is still being developed today.
Another SpringSource product, which is gaining in popularity, is tc Server. This server was developed at roughly the same time as the dm. It has since become a key part of VMware Inc.'s vFabric product line.
Non-Java EE innovations
SpringSource also built APIs that go further and abstract more complex processes. Their Spring Integration API has building blocks that build enterprise service bus or integration projects. The components are based on Gregor Hohpe's Enterprise Integration Patterns, and can be configured in Java, Scala or XML.
Another integration tool built by SpringSource is Spring Batch, which attempts to handle chunked data-loading processes. Batch can handle data from a variety of sources and write that data using a number of APIs.
SpringSource also purchased a non-JMS queuing tool based on the AMQP API, RabbitMQ and a NoSQL database, Redis. SpringSource developers are building a set of data management abstractions, the Spring Data APIs, to handle a variety of NoSQL and SQL database APIs, even implementing the NoSQL REST Data project to handle a RESTful website as if it is a database.
None of these APIs sit behind a pay wall. None of them require developers to purchase support. Development teams are free to download them, set them up and run them on company servers without penalty. If management wants support, they can pay for it. If they would rather support the applications internally, the team still has full access to the source code.