2008/8/11 RMMM <[EMAIL PROTECTED]>: > > > James.Strachan wrote: >> >> >> I'd be tempted to hide the middleware from your application code; then >> use something like Camel's bean integration to integrate the >> 'messaging' into your business logic in a kinda invisible way - then >> you don't have to spend a while figuring out how to use the JMS APIs >> properly etc. >> >> > > Thanks for the suggestion. I appreciate the explanations and all the links. > I've > browsed some of the materials at the Camel site and it does look like a > compelling option. > > Let me just reiterate my question about complexity and overhead though. > From what I gathered in a quick look, using Camel to manage the messaging > looks pretty easy. Camel seems to hide a lot of the details. In fact, even > using > JMS/ActiveMQ directly doesn't seem all that complicated ... at least, at > first > glance. So my question is, is there going to be a big burden of complexity > that I may not be seeing yet
>From your application code no; though there are things to learn about all middleware; whether its some home grown stuff, in JVM SEDA, JMS or some database etc. Each have their own particular strengths and weaknesses. If you don't care about concurrency (e.g. you've mostly just 1 single consumer thread) and you've a very low volume, using a database / JPA / hibernate is fine. If you want to implement a big compute grid with loads of JVMs and/or loads of threads per JVM reliably processing requests in parallel - then JMS is awesome. Databases are much slower and don't do load balancing of consumers at all really - but they are simpler to use if you're already using a database. The biggest costs of middleware is usually, learning the APIs and using them properly - and the admin/operational cost. Clearly Camel makes the first issue a non-issue; making it super trivial to switch from any middleware technology to any other as your requirements change (particularly around concurrency, load balancing and performance). The only real downside with JMS/ActiveMQ is there is some learning to do about how it behaves (e.g. how the load balancer works in relation to lots of threads if you use concurrent consumption) and how to manage an ActiveMQ broker etc. But its always good to delay decisions until you absolutely have to make them - so you could start today with in-JVM messaging (which is non-persistent, so if the JVM dies you loose all in-transit messages) - then upgrade to JPA/Hibernate/iBatis if you need persistence with low volume and no load balancing of consumers - then move to JMS as and when your requirements match the sweet spots of JMS (e.g. concurrent consumers & high performance). > (over writing a simple asynchronous messaging/ > event system from scratch)? I'd definitely not recommend doing that :) Given the zillions of messaging systems that are ready to use and are already heavily tested, I don't see much value in writing a new one from scratch - unless you've some truly wacky requirements :). Though feel free to hack a new Camel component if ever that becomes an issue - its really easy to do! http://activemq.apache.org/camel/writing-components.html > Also, is there going to be a major memory/cpu hit, considering the light > use I'm expecting from this system? We don't have a server farm with state > of the art hardware. The hope is that the software can run on cheap, low > end PCs that the stores already own from years back. Camel, ActiveMQ and hibernate/mysql can all run on modest cheap hardware. > Finally, just to be clear, I'm using plain Java. I've judged that going all > the way to Java EE and an application server would open a lot of > unnecessary complication. (Does that sound reasonable?) Definitely. Lightweight is where its at. Maybe Tomcat - Spring and Camel/ActiveMQ is pretty much all you need these days - maybe a web framework here or there too and some XML/JSON binding stuff like xstream/jaxb -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
