It was with some consternation that I read the Server Side thread on Spring's announcement of a new application platform.
Firstly, the Spring Application Platform, as it's called, is essentially a Spring OSGi integration on steroids. I've voiced concerns on how well OSGi is going to be received by ordinary developers, as against application server vendors. I'm yet to be persuaded that regular
Java developers will be particularly enthusiastic about dealing with the idiosyncracies of OSGi. There is more than a hint of EJB history about it. SpringSource (and application server vendors?) have identified OSGi as the way that we ordinary mortals must now follow.
Spring Application Platform (and Spring Dynamic Modules) are great if you've already bought into OSGi. As a general platform for enterprise application development - at this point I'm yet to be convinced.
Secondly, with its Application Platform, SpringSource has moved squarely into the application server market. This is something which I didn't expect them to do, and I don't think it's a very good idea. It's too invasive, too big a step in one particular direction for me to feel comfortable with. I think of the Spring Framework as a technology which works seamlessly with a broad variety of platforms and application servers. With the Application Platform, they're pinning their colours to a particular mast - a technology stack based on Equinox and Tomcat, and setting themselves in competition with other application servers.
Thirdly, there is the question of the license. For the first time, SpringSource is introducing a major product which is not based on the Apache V2.0 license, instead going for a GPL license. That's a major change that reflects a real difference in the way that the company is positioning itself in the marketplace.
Finally, the question in my mind is where the Spring Framework itself fits into all of this. I've always thought of the Spring Framework as the flagship product coming from the Rod Johnson crew. It didn't matter if SpringSource came up with one or two turkeys in its portfolio, because at least the core framework is solid. But with the Spring Application Framework, they're betting big. They've clearly had some of their best brains working on the project for some time. A failure won't be quite as easy for the development community to brush off.
So what will happen now? Will the Spring Framework become the "poor relation" of the Application Platform? Will new features and improvements go into the Spring Framework, or will this suffer in the future at the expense of the Application Platform. The waters have definitely been muddied.
The Spring Application Platform is the biggest announcement to come out of the Spring team for some time. It also looks like it could be a big mistake. Spring became popular in the first place as a practical, community driven solution to the real problems with Java enterprise applications, with a focus on simplicity. The latest offering seems to be moving in a rather different direction.
10 comments:
I'm not surprised by the observations you've noted. Specifically to your points:
1) Most lightweight frameworks eventually evolve into something heavier than you'd like. It's the price of evolution in a platform attempting to be everything for everyone.
The Spring-DM(K) certainly makes it easier to develop and delpoy.
2) see 1)
3) The licensing issues are confusing to me as well.
To take three components (virtually wide open wrt usage/licensing) and lock them down with GPL seems contradictory to the original licenses. This approach is not contradictory to recent tacks taken by other OS projects; it's just a question of SpringSource attempt to recognize a revenue stream. Please no `sugar-coating! Just acknowledge a black kettle is black; don't call it a pot!'
Longer term, you've identified SpringSource's struggle. DI is no longer black magic; many APIs are adding similar behavior.
Aside from injection, what additional capabilities are provided via the SpringFramework? The OSGi framework provides resolvable, dynamic references to services in the framework.
One issue is determining what set of APIs and services constitute a version of the OSGi offering. For example the current release of the OSGi platform's HTTP service utilizes the Servlet 2.1 release--obviously largely out-of-date.
The real question is: how does the community ensure that the platform keeps in sync with acceptable APIs.
Evolution from lightweight to heavyweight can only be justified if 1) the new features are sufficiently valuable, and 2) if there is no lightweight alternative which can deliver the (most valuable) additional features.
As an example, Hibernate is clearly much more heavyweight than raw JDBC or even, for example, Spring JDBC. However, in many cases the extra features it offers do justify it's heavyweight-ness.
Even if feature-wise Spring Application platform succeeds on 1), in my opinion at least it, does not succeed on 2).
Being a consultant, getting around to many development organizations, I meet people struggling with spring configuration.
Personally, I haven't seen it as a big problem yet, but I also have quite a lot of knowledge about spring, and all the technologies it utilizes.
Not all developers have that. And they shouldn't always need to. They just want to solve business problems *now*.
That said, I welcome a product as S2AP, which makes it dead-easy for developers to build on spring programming model, without all the configuration stuff. At least, I hope this will come out of it.
And I hope to see OSGi solve some of my jar dependencies hell problems too.
Equinox has a solid track record as used in Eclipse - is not like Spring has embraced an unknown technology.
I have a project that has been kicked off recently and is based on using Spring Framework.
We need a module solution for this app architecture. We were pursing our own - Equinox. Now Spring has made the same choice. :-)
I have no problem with Equinox - it's the obvious choice in the OSGi world. The fact that just a single OSGi implementation is supported is more of a problem. To what extent will Spring AP be using Equinox-only features? How much work will be involved for other OSGi implementations to be usable with Spring AP, or indeed, is such a thing possible?
Even for what they are trying to do, are also the issues resolved? Or are Java developers going to be dragged into an OSGi world and find themselves running into all sorts of unanticipated problems which only SpringSource will have the expertise to solve?
Looking forward, SpringSource AP will have a bunch of moving targets to track. Versions of enterprise Java APIs, and now versions of OSGi, Equinox and Tomcat will need to be tracked. The enterprise bundle repository will need to be continually updated. (Who fancies this task?) Useful but obscure libraries won't make it into the repository because they'll be too niche, making them difficult to use with Spring AP. Will innovation in the Spring AP world be limited to libraries that SpringSource thinks are important?
As OSGi itself evolves, users of OSGi will have to choose between the features that they can get "easily" through Spring AP support, and a "go it alone" route for features that Spring AP don't support out of the box.
I'm a big fan of Spring, and a big fan of modularity. I am also a fan of OSGi, at least in theory. It's putting the three together in a way that will enable simple, practical Java application development that's the real challenge. I'm thankful that it's SpringSource and not me whose taking this challenge on.
For me, a simple imperfect solution is better for me than a complex perfect one.
Phil,
To be clear about one thing - the App Platform can hardly be referred to as 'heavyweight'. It's running memory usage is under 10MB and given its modular nature, you can pretty much pick and choose which components you want. If you don't need web support, you can even remove Tomcat.
To answer your question as to whether Spring Framework will become a poor relation to the App Platform - absolutely not! We are continuing our investment in all our portfolio products just as before - in fact in many cases we are *increasing* our investment. Spring Framework is a central part of the App Platform - without continued development there the App Platform could not succeed.
Regards,
Rob Harrop
SpringSource
Phil,
To address your concerns about the bundle repository, I can say that SpringSource won't be making determinations about what's important enough to put into the bundle repository. In fact that this point, we've gotten over 30 new bundle requests that we are working through and more arrive every day. From our perspective it's a matter of when, not if, a dependency makes it into the repository and that is driven by how hard it is to create the closed dependency graph required by the repository charter.
As time goes on we actually expect this to become easier since more and more projects will create OSGi-friendly JARs that we can simply publish with little work on our part.
Ben Hale
SpringSource
Rob,
Good to hear that the Spring Framework will not be neglected. I'd hate to see the best of your new innovations going only into the less open SpringSource offerings.
Regarding the heavyweightness - yes, the Spring AP is hardly heavyweight compared to traditional app servers.
Also, in my view a consideration of what is heavyweight goes beyond memory footprint, and covers aspects areas such as the nature of the build and runtime environment, and tool support. I have a blog half ready on this issue which I'll be posting in the next few days.
Ben,
I'm encouraged also by your comments on this. The bundle repository has the potential to be extremely valuable, even for projects which don't use OSGi, but want better (transitive) dependency management. I can see Impala using the bundle repository, even as before it moves squarely into the OSGi space.
One thing I would personally like to see is the bundle repository opening up to something which is not managed entirely by SpringSource, but becomes more of an independent, joint industry effort. Hopefully, it will evolve in this direction.
My company is an ISV and a Spring Framework user. We do industry specific software solutions.
Basically when I architect our stack, I go only with components that are, say, Apache license and the like. As Bill Gates has practised for decades, I seek to avoid putting royalty items into the stack. So if I use anything open source, it has to be the community variety instead of the "commercial" open source. As such we do participate as committers to open source projects that we make use of.
I'm very keen to embrace OSGi in our server-side stack (which is already infused with Spring Framework). But we'll go with some roll-our-own solution. Or else get involved in a community solution. I think there will be a significant segment of Spring Framework users that will seek to do likewise, and hence there will become this odd situation where there becomes two OSGi solutions within the context of the Spring Framework user base.
If I was creating a solution stack that was just for my company's internal use, then I wouldn't really have a problem with Spring Source's dual licensing approach, and would just use what they're building for OSGi. But I've sworn off putting commercially licensed items in our ISV stack, as in the past that has proved to be problematic in multiple ways. Just can't incur those kind of risk and business headaches going forward.
Post a Comment