TIBCO EMS Support - Several classes have been added which provide increased productivity and a Plain Old C# Object (POCO) based programming model for TIBCO EMS messaging - this is identical to Spring Java's JMS support, and complements the previously-existing ActiveMQ and MSMQ support

Explaining the VS.NET Solution Templates in more detail, Pollack indicated that each template consisted of several projects, including the "main" business logic project and the testing project. For each of the solutions above, the appropriate boilerplate configuration to get Spring.NET going is provided. The ReSharper templates which are included also ease many common coding and configuration tasks such as bean type completion and adding properties to bean definitions.

Pollack also described how Spring.NET compares to other .NET frameworks:

More than a Dependency Injection (DI) container - Although Spring.NET is normally compared to other DI containers like Castle, it is really an application framework due to the wide range of APIs that can be used across the application, including data access, web development and integration testing

ASP.NET framework - The Spring.NET ASP.NET framework is NOT ASP.NET MVC-based, and it provides productivity benefits as a result - searching for an ASP.NET framework is actually the most common way that new users discover DI and Spring.NET

Message-oriented middleware integration - Integration with Apache ActiveMQ, TIBCO EMS and MSMQ ease the development burden of working with these frameworks by abstracting away low-level thread safety issues and using a POCO-based programming model

Planned code-based container configuration - Currently Spring.NET only supports XML-based configuration, while Castle supports both XML and a "type-mapping" API style. In the next release of Spring.NET, a code-based configuration style similar to Spring JavaConfig (which was incorporated into Spring 3.0) will be introduced

Future plans are to develop Spring.NET 2.0 and also to branch out into other areas based on feedback from our users. There has been great progress on Spring Threading for .NET by Kenneth Xu. These are general threading utilities in the spirit of what is available in Java's 'util.concurrent' package, for example, custom thread pools, PriorityQueues, IFuture<T>, and for something outside the 'util.concurrent' mold, an implementation of .NET 4.0's Parallel class you can use in .NET 2.0. Contributors are also working on .NET versions of Spring Security, and there has been good progress on Spring Integration for .NET by Andreas Dohring.

One of the most important features for us to provide in Spring.NET 2.0 is the option for code based configuration of the DI container. A more general theme is to sync up the core DI container code with the recently released version of Spring Java 3.0. This also means providing an attribute based way to configure DI as well as more use of generics in the Spring APIs, the majority of which are internal to Spring itself. Other areas are ASP.NET MVC integration, at least for DI, and increased ability to monitor and manage operationally Spring.NET based applications. Tooling inside Visual Studio is a common request, for an example of the features you can look to our eclipse plug-in for Spring Java, but we have not yet committed to delivery that functionality. We are also looking at a variety of ways in which we can make it easier to provide interoperability between Spring.NET and Spring Java applications, across a range of distributed technologies such as messaging, web services and REST.

Milestones and release candidates are expected during Q1/Q2 2010, with a final release to follow shortly after that. The similarities between the structure of the Spring.NET and Spring Java codebases make it straightforward (albeit time-consuming) to move over new features and refactorings. An initial release and scope of Spring Integration.NET was also discussed:

The areas we will focus on are the same core areas that the Spring Java project provides, namely providing a programming model to support the well-known Enterprise Integration Patterns, for example Channel, Router, Filter, Splitter, Aggregator, and Transformer. It provides what amounts to an embedded message bus that can be used within a Spring based application and integrates to external systems via adapters. As would be expected with Spring, it provides a POCO based programming model that is essential for producing maintainable and testable code. The adapters that will be provided in an initial release are similar to those in the current Spring Integration 1.0.3 release, such as file, messaging, email, and web services. However, we will also provide more specific .NET adapters such as the Windows Event Log and WCF P2P channels. As we get past a first release, the use of more specific .NET framework features, such as lambda expressions, extension methods, and features available in .NET 4.0 will be added.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.