Comments on: You can’t keep a good idea down http://blog.markturansky.com/archives/77 software architecture & engineering, code hints, sometimes philosophy, photography, life, etc. Sun, 20 Jun 2010 07:51:38 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: David H http://blog.markturansky.com/archives/77/comment-page-1#comment-718 David H Sun, 04 May 2008 15:42:37 +0000 http://blog.markturansky.com/archives/77#comment-718 We're lucky in that our system is pretty much all-new development where every service is being built by us, so that we can enforce lifecycle control and notifications. I'm looking into using annotations that our classloader can introspect when it loads a service - both for pattern conformance and also to possibly generate/map the necessary subscribers and callbacks to the bus, leaving the developer free to just write business logic. We’re lucky in that our system is pretty much all-new development where every service is being built by us, so that we can enforce lifecycle control and notifications. I’m looking into using annotations that our classloader can introspect when it loads a service – both for pattern conformance and also to possibly generate/map the necessary subscribers and callbacks to the bus, leaving the developer free to just write business logic.

]]> By: Peter Svensson http://blog.markturansky.com/archives/77/comment-page-1#comment-717 Peter Svensson Sat, 03 May 2008 21:38:04 +0000 http://blog.markturansky.com/archives/77#comment-717 Every paragraph I read I thought, Well, yes, that's great.. but we've been doing that in scripting languages for ages. It is good, though, that Java gets a short-cut to using less life per app. This really is very good. Still, should you become inclined to look, there are are similar treasures further out, for free. Every paragraph I read I thought, Well, yes, that’s great.. but we’ve been doing that in scripting languages for ages.
It is good, though, that Java gets a short-cut to using less life per app. This really is very good.

Still, should you become inclined to look, there are are similar treasures further out, for free.

]]> By: Dan http://blog.markturansky.com/archives/77/comment-page-1#comment-716 Dan Fri, 02 May 2008 21:20:07 +0000 http://blog.markturansky.com/archives/77#comment-716 More ClassLoader fun: http://bugs.sun.com/view_bug.do?bug_id=4950148 More ClassLoader fun: http://bugs.sun.com/view_bug.do?bug_id=4950148

]]> By: Dan http://blog.markturansky.com/archives/77/comment-page-1#comment-715 Dan Fri, 02 May 2008 20:36:18 +0000 http://blog.markturansky.com/archives/77#comment-715 As a member of Mark's team, let me say: good luck with cleanly un-deploying services developed outside of your control. A good summary of the problems you might face: http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 It's harder getting classes to unload than you might think, even if you control the classloader in which they were instantiated! As a member of Mark’s team, let me say: good luck with cleanly un-deploying services developed outside of your control.

A good summary of the problems you might face:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

It’s harder getting classes to unload than you might think, even if you control the classloader in which they were instantiated!

]]> By: Kiet Ly http://blog.markturansky.com/archives/77/comment-page-1#comment-714 Kiet Ly Fri, 02 May 2008 16:14:48 +0000 http://blog.markturansky.com/archives/77#comment-714 Spring-integration has queuing & routing like ESB but I don't know how easily it would be integrated into spring-ap. Perhap it must be an OSGI modules first? Spring-integration has queuing & routing like ESB but I don’t know how easily it would be integrated into spring-ap. Perhap it must be an OSGI modules first?

]]> By: David H http://blog.markturansky.com/archives/77/comment-page-1#comment-709 David H Fri, 02 May 2008 06:04:06 +0000 http://blog.markturansky.com/archives/77#comment-709 I've just implemented a version of this message bus, built a service loader using a classloader-per-service (going to enhance to be closer to the bootstrapping design you mention), and will be enhancing the service loading to support hot-deploy-undeploy of service jar files. Of course, without Terracotta, it doesn't make sense to do it because you can't scale it without adding a lot of complexity for distribution - but thanks to Terracotta and your post about the message bus you did, we have stripped all J2EE out of our architecture making it much simpler for service developers, much faster, and much more scalable. What has us so excited about this approach is exactly what you said about developer productivity - that is Right On! So thanks for putting two and two together so easily and pointing the way - this should be the standard architecture for any pure Java distributed system. I’ve just implemented a version of this message bus, built a service loader using a classloader-per-service (going to enhance to be closer to the bootstrapping design you mention), and will be enhancing the service loading to support hot-deploy-undeploy of service jar files.

Of course, without Terracotta, it doesn’t make sense to do it because you can’t scale it without adding a lot of complexity for distribution – but thanks to Terracotta and your post about the message bus you did, we have stripped all J2EE out of our architecture making it much simpler for service developers, much faster, and much more scalable. What has us so excited about this approach is exactly what you said about developer productivity – that is Right On!

So thanks for putting two and two together so easily and pointing the way – this should be the standard architecture for any pure Java distributed system.

]]>