Spring.NET versus Indigo for asynchronous messaging

[Tman-az]

We're debating whether to use Spring.NET services or Indigo (.NET 3.0) for an asynchronous messaging platform to support numerous functions on our system (external API for customers, data transformation, centralized messaging for interprocess communication, etc.). We need to start developing this functionality immediately but our goal is to support .NET 3.0 next year. Ideally, we would like to stay agnostic to the underlying technology / mechanism as much as possible. My main concern is ensuring that we proceed with something that is inherently thread safe and supports asynchronous operations. Does anyone have any suggestions / ideas / pointers on this subject? Thanks!

[Mark Pollack]

Hi,

The current technologies supported in Spring.Services are not async in nature, more RPC based (.NET remoting has async features but they are brittle and no substitute for true pub/sub middleware). Spring itself doesn't provide any underlying messaging technology so I'm not sure what your question is exactly. My quick advice would to be create interfaces for your publisher/gateway (See Fowler's description of the gateway pattern) and have any callbacks for subscription immediately convert the specific messaging object to a plain ol' .NET object so that all your business processing depends only on plain .NET objects. By keeping to an interface based design and pushing the details of the messaging data types to the edges of your app, you are well positioned to change technologies. Using Spring to wire all this up makes changing even easier.

As an aside, I'll be finishing development on Spring.Java/Spring.NET JMS based messaging shortly (based on TIBCO EMS). It is the same feature set as in Spring.Java which you can read about here (http://static.springframework.org/spring/docs/1.2.x/reference/jms.html); plus an object<->mapmessage marshaller. Down the road I hope to integrate with WCF and TIBCO.

Are you planning to use MSMQ as the transport? Similar higher level classes to simplify the programming model could be created for MSMQ.

Mark

[Tman-az]

Sorry for the delay in my response to your reply... just switched office buildings and our internet connection has been down for the past two weeks.

Anyhow, I was able to setup the functionality we needed based on the Spring.Examples.WindowsService example and using asynchronous callbacks in the service itself using Interfaces / PONOs with some IoC behavior-specific implementations. We are planning on integrating with MSMQ. In fact, that is our current task. We're kinda on the front end of our migration bubble, so a lot of our current work is prototyping and benchmarking of the various functions that we need. I've personally used Spring heavily in J2EE applications before and I realize the benefits it provides in helping our application remain scalable and maintainable. I'll post any revelations or working patterns that our team encounters as we progress.

Am I correct in interpreting your post that Spring.NET will support JMS messaging (i.e. MQ Broker)? This would be great as we have a requirement to support MQ Series for certain deployments. Is there anything available today that we can download / test regarding Spring.NET <-> JMS (or is it supported in the latest build)?

Thanks!

[Mark Pollack]

Hi,

Just a quick reply. I have done most of the initial work supporting TIBCO EMS for publishing, via JmsTemplate, and async consumers, i.e. MessageContainers. You can grab the code from the modules download page (http://www.springframework.net/modules.html).

I have not added any general purpose interfaces for JMS since there is not a defacto standard/single source of those interfaces. Each JMS vendor ends up re-writing the same Java JMS inspired interfaces. I didn't want to tackle that issue at this point. I think it should be possible to do some simple code generation based off a single implementation to create an ActiveMQ implementation (or BEA etc..) but I haven't tried yet.

In anycase, this doesn't address MSMQ which could also benefit from some higher level abstractions like converters. On the other heand there are far less internal classes/resources to manage in the case of MSMQ as compared to JMS (one of the benefits of using JmsTemplate). Integration w/ the transaction management would be nice with MSMQ, i.e. 'EnterpriseServices' functionality.

Try out the TIBCO JMS stuff and use the docs you can find on the Spring.Java site or other Spring.Java JMS related articles. I have to package the Java examples I used that were a counterpart to the .NET examples bundled in the download but that is only relevant is you want to do some Java/.NET interop. You can download an eval of TIBCO from TIBCO's web site. Let me know how it goes.

Mark