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
Web sites launch all the time, but they also shut their doors. We highlight 15 that bit the dust this year.
Let the debate begin: Was the iPhone more important than iTunes? Was anything bigger than Google finding a great business model? CNET offers its list of the 10 most important stories of the '00s.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to the Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is general manager of the Americas division and vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure.
Add this feed to your online news reader
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.
- by savagedms May 2, 2008 1:10 PM PDT
- Hi Adrian, seems you have the same problem with formatting that I had/have - what's with CNet - how about a preview button or some markup? What century is this anyway???
- Like this Reply to this comment
-
-
- by amcolyer May 2, 2008 11:18 PM PDT
- Hi Dave, It sounds like a library isn't that different to your system document. A library does not *contain* all of the the bundles zipped up inside it. Instead it's a document that defines a library name, symbolic name, and version, and then lists a set of bundles imports (symbolic name and version ranges) for the bundles that make up the library. The bundles are loaded into the repository as is, and the library definition file simply refers to them...
- Like this
-
(10 Comments)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.