At The Spring Experience yesterday, SpringSource (the company behind Spring) announced their commercial software subscription strategy as well as Spring Integration. Included for subscription customers will also be Spring Tools suite & management suite, and Oracle RAC integration were also announced today. Certification on Spring will also be offered early next year. InfoQ video interviewed Spring founder Rod Johnson & SpringSource COO Neelan Choksi to get the news from the source.
Spring Integration is an EAI framework offering simplified ways to solve EAI tasks such as message transformation and routing. Architect Mark Fisher wrote about the project & Rod described it in the video) as an implementation of several EAI patterns from Grgor Hophe's book. The project is currently in 0.5 but 1.0 final will be released in Q2 & support:
SpringSource will be building a number of value-ad tools on top of it's free and open source programming models & frameworks. The initial product set include the SpringSource's Application Management Suite, Tools Suite, and Adanced Pack for Oracle Database.
The Application Management Suite, built jointly with Hyperic, and will offer:
The Spring Tools Suite was covered by InfoQ before and builds on the Spring IDE & Eclipse Mylyn in order to ease the development of large Spring applications, and incorporate other key features, ranging from issue tracking to code quality, in order to better support a Spring application’s entire lifecycle.
Starting Jan 15th certification on the Spring framework will be available, with certifications on "Web Technologies”, “AOP Methodologies”, and "Enterprise Application and Information Integration” coming later in the year.
On Thursday evening, Forrester analyst John Rymer keynoted on application platform trends, in which he mentioned that while in the past we had commercial vendors & committees of vendors innovating in both runtimes & programming models - open source projects such as Struts & Spring were successful examples of programming models that emerged driven by open source. Going forward, John predicted open source will take on the role of providing the programming model, while commercial vendors provide the runtimes those programming models run on or are improved by.
This trend was echoed by Rod in the video interview above when asked about how they will maintain their open source culture now that they also have pure-commercial offerings. Rod pointed out that Spring itself and the Spring portfolio is Apache licensed and will remain so; in addition, new programming models such as Spring Integration will also be done as open source:
Spring Integration is an EAI framework offering simplified ways to solve EAI tasks such as message transformation and routing. Architect Mark Fisher wrote about the project & Rod described it in the video) as an implementation of several EAI patterns from Grgor Hophe's book. The project is currently in 0.5 but 1.0 final will be released in Q2 & support:
Another message routing & transformation framework that integrates well with Spring is Mule ESB, which was present at last year's The Spring Experience.multiple configuration formats (XML, namespace, and annotations), point-to-point and publish/subscribe channels, and several adapters (minimally: JMS, RMI, HttpInvoker, Hessian/Burlap, File, EMail, JDBC, stream, and Spring ApplicationEvents). It will also work seamlessly with Spring's transaction management and dynamic language support.
SpringSource will be building a number of value-ad tools on top of it's free and open source programming models & frameworks. The initial product set include the SpringSource's Application Management Suite, Tools Suite, and Adanced Pack for Oracle Database.
The Application Management Suite, built jointly with Hyperic, and will offer:
- Auto-discovery of Spring-managed applications and components and the platforms and application servers that they run on
- Monitoring of Spring applications, components and runtime
- Custom alert configuration and corrective actions
- Performance and service-level report generation
- Automatic calculation and updating of baselines for metrics
- JConsole support
The Spring Tools Suite was covered by InfoQ before and builds on the Spring IDE & Eclipse Mylyn in order to ease the development of large Spring applications, and incorporate other key features, ranging from issue tracking to code quality, in order to better support a Spring application’s entire lifecycle.
Starting Jan 15th certification on the Spring framework will be available, with certifications on "Web Technologies”, “AOP Methodologies”, and "Enterprise Application and Information Integration” coming later in the year.
On Thursday evening, Forrester analyst John Rymer keynoted on application platform trends, in which he mentioned that while in the past we had commercial vendors & committees of vendors innovating in both runtimes & programming models - open source projects such as Struts & Spring were successful examples of programming models that emerged driven by open source. Going forward, John predicted open source will take on the role of providing the programming model, while commercial vendors provide the runtimes those programming models run on or are improved by.
This trend was echoed by Rod in the video interview above when asked about how they will maintain their open source culture now that they also have pure-commercial offerings. Rod pointed out that Spring itself and the Spring portfolio is Apache licensed and will remain so; in addition, new programming models such as Spring Integration will also be done as open source:
SpringSource's business strategy going forward however will be to provide value-added runtimes for commercial subscription customers to complement their open source programming models. Rod emphasized that their new business model will allow them to grow in a way that will enable them to contribute even more to open source.We really think that open source is the only way to define programming models today, we are not in the business of creating proprietary programming models.
How might we improve InfoQ for you
Thank you for being an InfoQ reader.
Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.
Community comments
Spring Messaging Roadmap - MDPs to EIS Patterns
by Srini Penchikala,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Baron Davis,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Rod Johnson,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Steven Devijver,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Rod Johnson,
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Spring Messaging Roadmap - MDPs to EIS Patterns
by Srini Penchikala,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is very interesting development in the Spring Portfolio components. With support for Message Driven POJOs (MDP) introduced in v2.x, it was only matter of time for Spring folks to support the popular EIS patterns that Gregor and Bobby documented in their book.
Is the video uploaded yet? I don't see on the web page.
-Srini
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
How does the management pack stack up against JXInsight's 5.5 support for Spring which includes performance monitoring and runtime problem diagnostics support of the Spring core runtime itself as well as offering a complete visibility into all aspects of the runtime up and down various technology layers which Spring + HyperIt cannot do.
Monitoring Spring Applications
blog.jinspired.com/?p=167
It seems strange that the openness of the Spring team did not extend beyond one management vendor who has a very narrow focus on one particular part of the application life cycle - ops. I would have thought the company (SpringSource) would have at least published an open management integration API and then allows other much better solutions to innovate around the API instead of tying customers into a solution that again offers a limited system management view with very little contextual data mandatory for effective performance management and problem diagnostics.
Maybe there is a very simple answer to all of this that is largely void of technical analysis. SpringSource and HyperIt are both funded by the same VC company - Benchmark Capital.
Why could the SpringSource (the commercial software company) not take a similar approach to management integration as GridGain has done.
blog.jinspired.com/?p=139
Then they could have offered a much better solution that target performance and problem diagnostics across all life cycles with powerful visualizations and not just primitive metric bar charts and correlation.
blog.jinspired.com/?p=142
William
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Baron Davis,
Your message is awaiting moderation. Thank you for participating in the discussion.
@JXInsight
Why should we care? You are commercial vendor anyways.
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
We are a commercial vendor just like SpringSource but there is a difference in our offering in that we provide a FREE development edition that can be used during development and testing whereas the SpringSource + HyperIt solution requires a PAID subscription (is not commercial) to obtain access and the solution that is really only applicable to the final application stage - pretty late in the day.
But really this is not about how commercial software company X is but more so on why this management solution was not opened to others (commercial or not). SPI?
You cannot have you cake and eat it.
William
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
William
This was a high level announcement. We are doing a huge amount of work in instrumenting Spring internals, as well as the specific Hyperic integration. The data produced from that instrumentation will likely be exposed as an SPI. You are welcome to approach us to discuss that--I think at present you are jumping to conclusions.
Note: SpringSource is a company that overwhelmingly produces and maintains Apache License open source software--millions of lines of it. So saying that JXInsight is a "commercial vendor just like SpringSource" is a bit misleading. (Not that I am criticizing you for being a commercial vendor.) You make a valid point regarding access to SpringSource management features being largely (not entirely) applicable to production. However, our management suite is just one part of a broad range of benefits across our subscription products that span development through production.
This was a high level announcement. There likely will be an SPI. The deep instrumentation of Spring internals we're doing will enable us to expose one.
Rgds
Rod
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rod,
I am not sure how much communication happens internal regarding such initiatives but I personally have had talks with Adrian regarding runtime diagnostics and performance monitoring of Spring. I do not think I am jumping to conclusions.
I would have expected that after our open discussions that the information flow would have been both directions especially if you do indeed plan on delivering a SPI which to be honest I find hard to believe after the fact. If I was * not * a performance expert but an application framework expert I would consult with a few performance management vendors first about a possible SPI design. This is what BEA did. Consult here is not singular or uni-directional.
I look forward to seeing the SPI API published and made available to us.
William
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Steven Devijver,
Your message is awaiting moderation. Thank you for participating in the discussion.
Having profiled a big Spring application with Quest's Performasure I don't see what the fuss is about. Actually, we tried to get performance statistics with AspectJ as well and found that this approach worked very well too.
So, even if SpringSource doesn't provide an SPI - and if such a thing would be useful for Spring users - I don't see how hard it can be to provide this as an alternative to what SpringSource would be offering.
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Steven,
If you looked at the links I referenced in my initial posting you would see that we already provide comprehensive performance monitoring and problem diagnostics for Spring based applications. We also provide 300+ AspectJ extension packs for many standards based technologies. And to be honest the Spring runtime itself rarely appears on the radar in a standard business application (once initially loaded and initialized) because the overhead in accessing remote resources (database, mq) dwarfs most other things and the typical Spring bean is singleton. That said this is very likely to change with greater usage of scopes and the move to event driven architectures (Spring Intg is an initial step in this direction). When that happens there is tremendous value in contextual tracing (which by the way quest does not readily support) across process and component (spring bean) boundaries. Making this available via a standard mechanism would benefit all and reduce the duplication of effort by performance management vendors and developers building their own home grown solution.
It would be great to see Spring offer a specification and reference implementation of a Spring specific monitoring solution as this would drop the traffic on the AOP list significantly as most seem to be re-inventing the tracing/loggin wheel again and again.
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rod, I agree but the same could easily be said for claims by a framework that it powers +80 million tx/day without stating clearing how much execution is driven and executed within the core runtime and how it actually contributes to the reliability and scalability of the runtime. Such a statement seems to grossly understate the contribution of the other systems and middleware components involved. Would you not agree?
Stating the number of lines of code is not reflective of the value of the software - this certainly under sells the value placed on the spring framework by its own user/customer base. JXInsight has more than 3,000 classes but whether they are all loaded into the runtime is dependent on what is requested and required to do the job and not what type of license is used. Note: Our free development edition is identical to the server edition license and our console can be freely installed on any number of machines for offline snapshot analysis.
At the end of the day (and in the normal world outside of product fan clubs) the main point is that a platform (binaries) adds value during the runtime execution. SpringSource seems to recognize this in their selection of commercial subscription based product/framework add-ons.
When the SpringSource team decides to standardize (JCP?) certain parts (API) of its open source product portfolio then we are talking about a much different contribution and cleaner separation between specification and implementation but maybe by that time we will have our own JSR (lets hope).
William
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rod,
I do not want to come across overly negative about this announcement as I think it is a natural step in the evolution of the commercial business behind the Spring Framework. The Spring team was always going to have to match the capabilities found in standards based application servers especially after leading a large developer base away from the component framework which had this support practically out of the box with most management vendor offerings.
I am somewhat disappointed in how you have initially approached this problem, excluding vendors who already have much more comprehensive support for Spring that spans the complete life cycle. I am not sure why but I thought there would have been more open dialog on the proposed design which allowed alternative implementations (runtimes and tooling). Maybe you could take a leaf out of the Java EE book and work with a number of vendors in formulating extension points and allowing for innovation (and competition) to foster in the implementation.
By the way the following statement seems completely out of touch with reality even when one takes out the Spring Framework reference. There are tools today that work and do much more than what is being proposed and will be eventually delivered.
William
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
William
Frankly I think you are coming across as negative and defensive. That's a pity, as I've already indicated that we are open to working with you (and other vendors) in future, and we've made no negative comments on your products or company. We believe that the SpringSource team has a unique understanding of the Spring runtime and that it's a logical extension of our desire to provide the best solution to our customers to gather and expose management information. That does not "exclude" other solutions (which can surely compete on merit), and does not preclude our information being exposed via an SPI, as I've already mentioned. We certainly envisage that Hyperic will not be the only other product used in conjunction with our offering.
Rgds
Rod
Re: Spring Messaging Roadmap - MDPs to EIS Patterns
by William Louth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Rod
I accepted that I might have come across "negative" for those that do not know me but defensive I think not. Maybe the Java EE reference caused you to skip a line or two in my posting above but I actually called for there to be increased level of competition by clearly separating the specification (interface) from the actual implementation and for their to be prior dialog with other vendors so as to ensure any ** instrumentation ** would not be prematurely handicapped by the initial management back end you have decided to run with (initially?).
The specification of Java SE and Java EE management and monitoring API's had contributions from a number of different management vendors which has ensured customers have various options today in selecting tooling for managing Java EE Web applications. The details of the tooling was left to implementors. So tell me what is so hard to understand.
All I have asked is for a company offering an alternative "open" enterprise Java platform to do likewise. You can offer whatever management solution you wish but at least consult first with others on the approach that bridges the gap between your instrumentation points and the management back end. Basically I would like to able to ensure that our unique approach to resource metering (JXInsight Probes) would be able to extend the basic measurement performed by the Spring instrumentation points.
Again I have openly talked with Adrian on possible approaches to performance management and problem diagnostics that could be offered across the complete life-cycle and free of charge for development usage that did not preclude other solutions as it was based on an open SPI approach.
I am sure you are aware of this but most application servers do ship with management solutions created by their own team built on instrumentation within their own runtime but yet a significantly large number of customers still buy management and problem diagnostics solutions from external vendors that also use and extend this instrumentation.
Frankly I think you are playing a "Pied Piper".