3 months ago, the day SpringSource announced their acquisition of Covalent, the company behind Tomcat, I knew they were up to something. I even talked about it with Andrew Glover for JavaWorld. And now it’s real: SpringSource has just announced SpringSource Application Platform.
First off, a few links around this announcement:
- The initial announcement of InfoQ
- An introduction to what is SSAP on SpringSource Team blog
- The official web page with other links, where you can register for the beta program and get your hands on the beta version
- A very interesting interview of Rod Johnson on DZone
Now this is very exciting. That’s the kind of inspiring technologies that make me think of tens of ideas for new projects, new tools that were just impossible before and that could now become reality. Adobe Flex had the same effect of unleashing my software artist imagination. Now I’m starting to think about combining the user experience of Flex applications on top of the ease of management, deployment and extensibility of OSGi with SSAP. Jeez, we’re living an incredible period!
4 Comments
Bouiaw · May 2, 2008 at 2:11 am
Hi,
Interesting subject !
We have begun to think about an extensibility mechanism that can be used for a multilanguage (Java and Flex) application like Igenko : http://groups.google.com/group/igenko-dev/browse_thread/thread/7783aa7dc6613842
OSGI and SpringSource Application Platform are one of the ways we are thinking about, but they are specific to Java, even if there is a beginning of Flex OSGI solution with Solstice (http://www.arum.co.uk/solstice.php).
Previously (https://sebastien-arbogast.com/index.php/2008/04/03/my-thoughts-about-osgi-on-javaworld/), you wrote that you began to think about these subjects. Could you give us more details on you thought on this domain ? This could be really usefull for us !
Sébastien · May 2, 2008 at 11:45 am
CMS’s and eCommerce platforms like Igenko are traditionnally something very difficult in Java because they need this extensibility that only purely interpreted languages like PHP or Python could provide until now. But now OSGi is coming to the server side and I think it would really be a big advantage for Igenko. And there is another kind of applications that would really benefit from this modularity and extensibility: teamware, tools that can help a project team to collaborate remotely.
Collaborating involves so many different tasks: communicating, writing documentation, planning, supporting users, etc. And some of these tasks are specific to some types of team projects, like source versioning for software teams, or marketing surveys for business teams, etc. And that’s where modularity comes into play because you could create different distributions based on what a team really needs.
Until now, collaboration tools have been specialized, offering support for some but not all of the tasks mentioned above. Trac offers a wiki and an issue tracking system, but that’s all. Of course Subversion integrates with Trac, but what about integration with Alfresco, which is an excellent content management platform.The problem is that amongst all these available tools, you have to build your own infrastructure for each project and sometimes you choose tools not because they are best for the job, but because they integrate not too bad with some of the tools that you already have. And then your team has to cope with all the idiosyncrasies of this tinkered solution. Wouldn’t it be great if we could have a consistent collaboration platform, modular and extensible? I think so, and by the way that’s precisely what the Eclipse Foundation is working on with Jazz. But I’m thinking about something using web technologies like Flex.
And since it would be the foundation of all your team work, it shall be called Basement. ;o)
What do you think?
Bouiaw · May 2, 2008 at 1:42 pm
I agree, OSGI could be a good way for us to acheive extensibility.
Our current main problem is that a third party module should be composed by some Java + Flex code.
Having both OSGI and interpreted languages seems to be really powerfull, as it has been demonstrated by Sling project (http://incubator.apache.org/sling/).
Flex could be considerated as interpreted language since the compiler could be used from a servlet to compile Flex code at deploy or run time. I am thinking about a way to use power of Java tooling (OSGI, Maven, JCR) to deploy hybrid Flex/Java bundles.
Do you have some ideas on this multilanguage aspect ?
Sébastien · May 5, 2008 at 8:23 pm
I don’t know, I don’t feel like mixing to many things in an OSGi bundle. The way I see it, the same functional module (Spring+Hibernate) should be accessible via several access interfaces, including a BlazeDS+Flex UI, webservices, other functional modules, etc. Hence for one functional module, let’s say a User Management module, I would deploy 3 OSGi bundles:
– one with the core functionality and a few services exported with Spring DM
– one with Flex and BlazeDS that would connect to the first one and expose it via a web module
– another one for exposing core functionality via SOAP webservices for example.
That’s why I think that OSGi granularity is too small and to maximize the interest of reusability and extensibility, we have to find a higher level of granularity. SSAP’s PAR archives can be a solution :o)