Does Axon 4.0 support active mq integration?
I understand that it has got amqp-extension, however, it seems to be based on rabbit mq (com.rabbitmq » amqp-client).
Not able to find any examples either.
The Axon-AMQP module supports AMQP 0.9. The 1.0 specification isn’t supported yet.
The fact that Axon yses the RabbitMQ client doesn’t make it dependent on AMQP. It’s just an implementation that speaks AMQP 0.9.
It should be fairly easy to integrate Axon with other nessaging systems, taking the AMQP module as an example.
There might already be community-built modules out there. It’s worth doing a quick search on Google/Github to see if there is anything that suits your needs.
Related
So begins from 0.75.1, Rebus no longer supports ASP.NET 4?
My question will be:
Is 0.75 a stable release for .NET 4 project?
Are we going to continue get bug fixes (if any) for .NET 4 target project?
Thanks
As of 0.75 Rebus has targeted .NET 4.5, which was a requirement to support the usage of async/await in the library.
I'm not an expert on ASP.NET and whether the version follow the versions of .NET, but Rebus will work as long as your host process targets (at least) version 4.5 of the framework. If ASP.NET 4 is only available for projects that target .NET 4, then that implies that you cannot use versions > 0.72 of Rebus.
And then an answer to your questions:
You should pick the latest version of Rebus, but that requires that you target (at least) .NET 4.5. If that is not an option, you should pick Rebus 0.72 (which is the last version available that targets .NET 4).
No (*)
As for the (*) above, I'd like to make the following fairly long and elaborate point: Generally, you can't count on getting bug fixes for the free, open-source software you have downloaded and are using, freely, without having paid a cent - at all!
If you want to be able to reliably count on getting bug fixes for your free software, I suggest you get a support contract with a company that is willing to provide that service. My employer provides that service for Rebus in case you're interested.
With that said, I'll add that I am a pretty helpful person, and I do a lot for people to have a nice experience with Rebus, but I am sure that you can understand that I cannot promise to provide bug fixes for the old versions.
I will be around for helpful advice if you run into something, but - as I am developing Rebus mostly in my spare time - you can probably understand why I need to concentrate my efforts on the current version.
Since I've known about Node.js, I've always been a fan of it. But today I found about SignalR, which provides an alternative asynchronous - scalable - realtime model for ASP.NET.
As far as I know, the main advantage of Node.js over SignalR is sharing code between client-server (another advantage should be that it is cross-platform), and the main advantage of SignalR is a much more mature framework and far better tool (IDE) support. So I wonder: if SignalR is here, do we need Node.js on Windows anymore? Are there any advantages of Node.js I don't know?
SignalR is a viable alternative to Socket.IO and Node.js. There are other reasons to use javascript on the server however.
It flattens the stack. Almost any website these days has to have javascript on the browser, and if you use it on the server as well, you can cut one language out of the batch that you'll have to be proficient in.
Message passing is very natural. JSON Everywhere! Especially combined with a document database which uses JSON, all message passing just becomes JSON objects. This makes reduces the amount of message brokering that has to happen throughout the system.
It's not Microsoft. I personally love what Microsoft has done for the development community. They make fantastic tools and one of the best frameworks and languages around. That being said, some people just love to hate Microsoft.
Cost. There are many good ways to get Microsoft tools for free or very cheap (Express editions and Biz Spark). There is still a higher cost associated with working with Microsoft tools. I believe this cost is worth the productivity gains in most instances, but not everyone agrees.
In addition to the above, there is still the story going around that you can't scale long polling requests on IIS due to the threading model. This has some truth to it, but with good code design, and some server tweaks, you can mostly get around these problems.
We are using Adobe LCDS 2.1 and thinking of Upgrading it to a higher version.. can someone tell me a brief Comparison of the LCDS versions available (3.1 , 4.1....) ????
The last version is 3.1 You need to read the documents from this url in order to understand what are the new features (the release is good but is not enough), and after that it would be good to try building a prototype (if you plan to use the data modeling for example) to see how they will fit into your current architecture.
I wouldn't do any upgrade unless there is a business reason (bugs, poor performance, luck of productivity) - for any product.
I don't know why you'd need a comparison for 'all versions' if you can only purchase the latest one. I suggest you look at the latest version's whitepaper so that you can see what's been added. The biggest thing IMO is better integration for all clients, different messaging protocols and well as much needed bug fixes (I remember 2.1 had some fairly obvious bugs).
Looks like the choice is "should we upgrade or not?"
I'd say it may also be worth considering what you're doing with LCDS -- if you're only using it for things like Flash Remoting, is it possible that you could go the other route and 'downgrade' the the open source BlazeDS? It has a lot fewer features, but might do what you need, and be a lot cheaper.
Here's a comparison of BlazeDS to LCDS ES2: http://www.adobe.com/products/livecycle/dataservices/compare.html
I'm not familiar with prior releases of LCDS, so I can't offer any better advice about comparing versions than the previous respondents. Basically: Check the release notes =)
I whould like to know some opinions about OpenEJB: we are considering to use it on a new project, but really didn't found many opinions about it.
So, here is my question: how about it? Does it perform well? Is it stable enough for a production environment?
We switched to OpenEJB (deployed embedded in our app on Tomcat). Performance tests showed better or not worse results processing our transactions compared to JBoss (transactions include data access, JMS, and servlets). We use ActiveMQ within OpenEJB for JMS. There are no stability problems as of yet - we are still in staging (pre-production) environment though. The documentation is definitely lacking, but not as poor as other embedded choices. Overall, we consider this as a good choice if you run on Tomcat. Deploying it on other application servers turned out to be much more difficult (JBoss, Weblogic, Websphere) but there are not many reasons for this usually (we had few but dropped this after several attempts basically failed).
And as in all open source products: expect lack of support (documentation, troubleshooting, bugs, etc.) to be compensated by free access to sources.
We've had experience with Oracle OAS and JBOSS before. We decided to give OpenEJB a try. We've found out that it is not only very fast but it also much easier to setup and configure, and it has much better defaults.
Currently we implement our own failure measures in the client, so we don't know how they compare for clustering, or other advanced features that we don't use.
We we have to go back and deal with JBOSS in the developer side, we see a drop on productivity, because it takes too long to bootstrap.
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.