NMS Nighty builds?

[Flozano]

Hello

There are only builds of Tibco EMS integration, but not for NMS...

Anyone knows what's the real status and roadmap for this?

[Mark Pollack]

Hi,

To address this issue (and others) there is going to be a formal Spring Extensions project (covering both Java and .NET) and have procedures in place along the lines of what you might be familiar with for apache projects that start off being incubated and then grow into top level projects. In this case the NMS will be 'seeded' this week (at least svn) and along the course of the next 2-4 weeks time we will have a proper project structure around it, its own forum, jira, repository, download section, continuous integration, etc. The plan is that it will have 1 or 2 of its own releases and then be incorporated into Spring.NET 2.0, which at that point would be more of a packaging convenience than anything else. No time frame for Spring.NET 2.0 atm, there will be a 1.2 with some minor feature improvements (attribute driven DI for example).

Hope this helps, sorry for the confusion.

Cheers,
Mark

[Flozano]

Yes, it's clear now, thanks :)

[Flozano]

Any news on this?

[Mark Pollack]

Hi,

Near the middle of the month this should be ready, thanks for your patience. It is also quite likely that I'll add the NMS in the next spring release once I verify that the MSMQ and at least one other binding (say for TIBCO) work well. I presume you are using ActiveMQ as the messaging provider?

Cheers,
Mark

[Flozano]

I'm using right now ActiveMQ in my Java projects and MSMQ in my .NET projects. I'd really like to test both.

By the way, do you plan to provide global transaction support (TransactionScope) for MSMQ? that would be a huge improvement...

[Mark Pollack]

Hi,

Good to know, thanks. If you use the TxScopeTransactionManager then MSMQ operations will automatically participate in a distributed transaction. Do you mean for the case when wanting to group mutliple MSMQ operations within the same msmq 'local' transaction?

Cheers,
Mark

[Flozano]

I mean that a commit in the database does commit in the MSMQ, and that a rollback in the database does rollback in the MSMQ, and that this behaviour can be trusted and no compensating actions are needed.

[Mark Pollack]

Hi,
This case is handled well by using System.Transactions (TxScopeTransactionManager) and either standard MSMQ .NET API or with a NMS wrapper.
Mark

[Flozano]

OK, thankyou!

Still waiting for NMS :o)

[Flozano]

We're ending April and no news on this... any update?

[steinard]

Hi!

What is happening to NMS? I just pulled down the source from https://svn.apache.org/repos/asf/activemq/activemq-dotnet/
and it appears to be renamed to Apache.NMS. I need to recompile and sign all assemblies as I just updated to Spring.Nets head. This forces an update in the Spring.Messaging.NMS integration project...

Cheers,
Steinar.

[Mark Pollack]

Hi,

Once I get this 1.1.2 release out (today seems good..), all the code is going into a new SVN repo (public accessible) and the code that is in NMS integration proejct will be brought up to the latest versions of things and included in the main trunk. It will then be available in standard nightly downloads, with the WCF bindings for NMS going into an extensions project (separate svn, jira etc.). At the moment I don't see anything blocking this from occurring tomorrow or the day after. Thanks for hanging in there on this, there has been much demand around NMS functionality and I'm quite happy to see that there are TIBCO bindings out of the box now.

Cheers,
Mark

[steinard]

Hi!

Thanks for the quick responds, seems like you're on top of things!

Just to get things clear, will the complete source I pulled down today from SVN (link in previous post) be maintained somewhere else? And what is going to happen to the naming conventions? I just renamed the namespace back to NMS together with assembly name, it seemed the quickest fix for now.

Cheers,
Steinar.

[Mark Pollack]

Hi,

The spring svn repo will be maintained outside SourceForge but will allow anonymous access. I don't think there will be another svn location for NMS, seems like there are several active contributors to the project now which is good. What is needed is a place to download a specific release, which is probably why they feel free to make changes like renaming namespaces. I'll ping James Strachan later this week on it once I go through the integration task myself and get up to speed on the issues.

Cheers,
Mark

[Flozano]

any news on this?

[mdownes]

I've recently spent quite a bit of time trying to get going with NMS for MSMQ and Spring.Net Messaging. In principal, I would like to pursue this route but there are still quite a few areas where it is obviously unfinished (both Spring.Net Messaging and NMS/MSMQ). Some of this we can work around (Just to get started, I had to modify Spring.Messaging.Nms and switch the dependency from NMS to Apache.NMS) but other things are more important.

The main issues are:

I can't find a way to configure the NmsTemplate with an alternative Apache.NMS.MSMQ.IMessageConverter implementation. I can configure the Spring.Messaging.Nms.Support.Converter.IMessageCon verter which goes to/from Apache.NMS.IMessage but still need to get these to/from System.Messaging.Message (the MSMQ message). Part of the problem is that the Apache.NMS.MSMQ.DefaultMessageConverter only supports IBytesMessage. I have worked around this for the moment by modifying the NMS.MSMQ DefaultMessageConverter to support ITextMessage instead.
The transaction support seems limited. Is there a way to use Spring.Net Messaging with NMS/MSMQ and distributed transactions? When using the SimpleMessageListenerContainer, how is the transaction controlled? It would appear to me that all messages are received within a single transaction.


We are on the brink of abandoning both Spring.Net Messaging and NMS. Can anyone help with the issues identified above or has anyone made any progress with these libraries?

Cheers - Marcus

[Mark Pollack]

Hi Marcus,

Apologies for the lack of progress in this area and I hope to pull you back from the brink. The source code has moved to svn, and you can access it at https://anonsvn.springframework.org/svn/spring-net This doesn't solve your immediate concerns you raised but the trivial one, i.e. it compiles against the last activemq, is done.

The points you raise are good, thanks for taking the time to report it. The holes regarding the message converter look pretty straightforward to fix, I suspect that most people have simply been using the ActiveMQ/TIBCO bindings and the MSMQ one hasn't got much attention as of yet.

Distributed transactions for MSMQ will be supported. The approach, not surprisingly, will be similar to that in Java in using the DefaultMessageListenerContainer, which will effectively start a new System.Transactions TransacitonScope, then do a MQ operation as well as database work (presumably) in the same transaction.

(Note that more often than not you can avoid distributed transaction though the tracking of message id's and thus remove some complexity in the impl as well as increase performance. This link (http://activemq.apache.org/should-i-use-transactions.html) has some general comments on the matter.).

I would like to button this up asap, at least get hello world working, so just hang in there a bit longer, we are quite close and I will work on this during this week.

Cheers,
Mark

[Mark Pollack]

Hi Marcus,

I've gotten a minimal example working with NMS/MSMQ/Spring.Messaging. The state of the NMS binding for MSMQ is not complete, I had to make a few minor additions but there will be more to come. At the moment the NMS libraries that are in the Spring lib directory are modified versions that have not been fed back into the main trunk of NMS. I'm working on getting the nightly build back online, one that is done, I'll ping back here so you can download it and give it a try.

Cheers,
Mark

[Mark Pollack]

Hi,

If you pick up the Spring nightly build here (http://www.springframework.net/downloads/nightly/Spring.NET-20080616-1151.zip) and use the attached solution you will have a minimal example using MSMQ with NMS. Working on the example I see that the NMS MSMQ binding is missing several features, some of which are necessary to be added before I would consider it production ready. Examples are more control over the properties set when creating the MessageQueue instance, portable acknowledgment modes, and support for more message types (not just bytes). Topics and message selectors are not supported, though they might be though the use of multicast configuration as well as use of the simple selector messages based on the ReceiveByXXX family of methods.

After this simple experience using NMS MSMQ binding, I feel that the value of the NMS abstraction for MSMQ is questionable since the programming model for MSMQ is extremely different than the JMS. This presents significant obstacles for MSMQ savvy people to benefit from Spring's messaging features. The JMS style is the standard used by all other .NET messaging vendors (IBM, TIBCO, ActiveMQ, Sonic, etc.), so in these cases understanding the programming model isn't a big issue. The only other exceptions to JMS programming model I'm aware of is RabbitMQ, thought it is still more similar to JMS than MSMQ, as well as the TIBCO Rendezvous product.

Assuming that some of the features mentioned above can be provided, using NMS for MSMQ would still seem to be of value for those 1) who don't or can't use WCF MSMQ bindings, 2) are already familiar with the JMS messaging API/semantics and in turn how they map onto NMS abstractions, and 3) who value API portability very highly as they anticipate switching messaging vendors.

I will be developing a prototype of messaging functionality specific to MSMQ this week and post back. Also, as I experiment more extensively with the NMS TIBCO binding this week, I'll see how well the NMS abstraction holds up. If it doesn't hold up well, perhaps an alternative approach is to provide parallel versions of the Spring infrastructure (based on code generation to reduce the maintenance burden) for each vendor.

Cheers,
Mark

[Mark Pollack]

Hi,

Just to give an update. I've been working on MSMQ functionality within Spring and it does not follow the NMS 'mold'. There are quite a few 'rough/non-obvious spots' in MSMQ as well as semantics that don't cross over well, in particular for creating a multithreaded server as well as poison-message handling. (NMS/JMS you can do a sync recieve w/ a timeout and it won't throw an exception where has in MSMQ it does, and MSMQ 3.0 doesn't have any 'redelivered' flag (though 4.0 does).

The goals are to support as much of the 'queued components'/wcf programming style, as possible (which matches well with Spring's overall approach of coding to interfaces and abstracting away transport details). This means that you can write a plain class that has a method like this


public OrderResponse ProcessOrder(OrderRequest or)
{
...
}


and it will be called from from a multithreaded message listener container. This of course assuming the message body contains a body that can be converted to the order request. Also the return value is sent back to the response queue.

The listener container supports distributed transactional receive as well as the important 'mixture' of local database and messaging transactions, as well as non-transactional. (see here (http://activemq.apache.org/should-i-use-xa.html) for a high level explanation). I've added support for poison-message/error handling in each case. There is also a 'Queue' class that provides thread safe access to a MessageQueue as well as other non-thread safe classes in the MQMQ library (notably MessageFormatters), RecieveAndConvert as well as SendAndRecieve methods ensure proper use of non-thread safe components.

Ok, I hope to get a first code preview up tomorrow, if not early next week.

Cheers,
Mark