Now SpringSource is an application server, too
I read the news that SpringSource has named itself the "first proper" Java application server product in a decade, and I was left scratching my head. Over the years I've heard just about everyone call themselves an "app server" at some point (Funambol went through a spell when it was a "mobile application server" [PDF] and ActiveGrid was a "grid application server", or something, as just two examples), and the only two times it made sense to me (in the open-source context) were with JBoss and Geronimo.
How did SpringSource become an application server? I thought it was a framework.
So, apparently, does Marc Fleury, who had some blunt counsel for SpringSource's founder, Rod Johnson:
To me this is a VC driven move. Spring is a natural consultancy, being a development framework, but they have been struggling with their sales in the runtime. So voila, we now have a box drawn around an OSGi kernel, the Spring framework and Hibernate/Tomcat, and it has a name: it's an application server. It is the same thing you had yesterday for free, except it is now under the GPL and a proprietary subscription license.
I laugh. SpringSource is trying to monetize its ISV user base. Good for them! I predict this flat-footed license change will have little traction with the ISV community. Why? because getting the ISVs to pay will take more than branding around previously BSD licensed software. Exactly what does an OSGi kernel bring on top of Tomcat? Nothing. What does this bring you if you ALREADY ship Spring and Hibernate/Tomcat (from JBoss?) nothing.
Spring is fantastic technology and perhaps it really is an application server. Or perhaps, as Marc suggests, this is simply a way to market itself into justifying runtime fees. I think highly of the Spring technology and admire Peter Fenton, the leading investor behind it, so all things being equal, I'd prefer to see SpringSource succeed.
I just don't understand why it's an application server. I'm probably too ignorant to appreciate the applicability of the nomenclature, but to me it doesn't fit.
Matt Asay is general manager of the Americas and vice president of business development at Alfresco, and has nearly a decade of operational experience with commercial open source and regularly speaks and publishes on open-source business strategy. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure.
- Topics:
-
Industry news,
-
Startups,
-
Strategy
- Tags:
-
Spring,
-
framework,
-
SpringSource,
-
application server,
-
JBoss,
-
Marc Fleury
- Bookmark:
- Digg
- Del.icio.us
SpringSource is neither an application server nor a framework, but a company which employs many of the best technologists in enterprise Java. The Spring Framework and the many other projects in the Spring Portfolio, plus the Apache technologies we gained deep exertise in following our acquisition of Covalent, are a great basis for a complete platform. That is what we have built and announced.
Indeed, you do not understand. It is an application server because it provides a complete runtime environment that is an alternative to existing application server products. Spring is a part of it.
It's sad to see you quoting the bitter FUD of Marc Fleury. He also doesn't understand the technology enough at this point to comment; he clearly has a vested interest in attacking SpringSource; and he's irrelevant to the future of the industry.
Rgds
Rod
http://tmccune.blogspot.com/2008/04/stop-meshing-with-cloud-computing.html
I thought I was clear. This is not about Spring. The SpringSource Application Platform builds on Spring, but is a distinct product. It's a complete runtime. It is an application server.
Rgds
Rod
It's very early days but having read the announcement it seems the big addition is the idea of Libraries. Unfortunately I think there are some big problems with this area:
Firstly lumping lots of OSGi bundles together seems to miss the point of OSGi which is about fine grained composition.
Secondly the addition of Import-Bundle and Import-Library are initially useful short cuts but in the end they are detrimental to the ability for a developer to refactor their applications in the long term. Import-Package is fiddly but safe, Requires-Bundle/Import-Bundle/Import-Library leads to horrible packaging level interdependencies that will leave developers tearing their hair out. Experience tells me this is so.
I think this is a great announcement by Spring as it will get more people developing OSGi apps and OSGi is one of those technologies that I believe is a complete phase change in the industry, i.e. enterprise software before OSGi and after it.
But I think the market for an OSGi based enterprise solution is wide open at the moment. Developers who may want to consider an alternative view of enterprise OSGi should check out http://newton.codecauldron.org.
Again a runtime, again GPL, again supports Spring-DM. Benefits over and above this, dynamic provisioning and scaling, garbage collection, self optimisation, fail-over, discovery, jmx management.
Ok, ok so I'm biased as I'm a developer and architect on Newton and apologies for jumping on the band wagon. But think it important people at least see all the alternatives when they make decisions.
Grouping bundles together - which we enable both for libraries and for user applications, is a tremendously useful facility. A bundle is a module. And we all know that sets of modules are designed to work together to achieve some end. If I have a domain bundle, application services bundle, web bundle, and data access bundle that are all part of the same application, I want to group them together - the application is a unit of deployment, of administration, and of management. I want to give it a name and see it in an administration console. I want to say "I depend on the JPA API (javax.persistence) and OpenJPA" if I'm using OpenJPA as my persistence provider. That's a more robust statement than listing all of the internals that comprise OpenJPA and matches the developer's expectation much more closely. For my own application modules - the code that I develop and control, import/export package is the much more appropriate level.
But no-one is forced to use Import-Bundle or Import-Library. Import-Package will still work perfectly well if you prefer to stay at that level.
Back on topic, I'm still skeptical of the benefit of jar (or greater) level imports. My feeling is that they're useful in the short term but deadly in the long. Kinda like the nuclear fission of software lots of energy very quickly that you spend a disproportionate amount of time cleaning up way after the original use has past. I could be convinced of their benefit if only there was some way of ensuring they were only used as a tool of last resort and only on legacy code. But there are so many better ways right now that giving developers yet more options to shoot themselves in the foot strikes me as irresponsible.
The identity of a class is defined via the package that contains it, but when you add bundle/library level imports this adds in an implicit connection to the bundle as part of its identity. If you move the package to a different bundle this affects the identity of the class. The distinction is very small except when your application blows up due to spaghetti classpaths that fail in weird an undiagnosable ways in live environments.
We've taken a different view point in Newton - the unit of deployment is a system, a document outside of the bundles, the bundles are loaded into the repository as is and then it up to the system designer to label the top level bundles they need as part of the application. All other bundles are inferred by the runtime based on the imports they require. This achieves effectively the same pattern that you describe as a Library without the need to create an extra layer of packaging and without the need for the developer to worry about the entire classpath needed to satisfy his/her app - he/she defines the apps direct neighbours, the framework handles the rest - and gc's when done. Many systems can sit side by side in the same vm and across the enterprise and reuse each others bundles with no risk of class mismatches.
On other items in your blog, I think the repository is great a major step forward! We thought of doing something similar but the effort has so far been too great for us a small company - glad someone has stepped up and taken on the effort - an OBR view would really make me cheer ;)
As for the tools, I think it's difficult to argue that tools are part of an application server - I won't argue their relevance as they're plainly useful to a developers day to day work but they're not adding anything to the actual runtime - possibly heading off towards semantics again, oh dear...
Regards,
Dave
Regards, Adrian.