Spring is nice and everything, but I don't quite get how/why it fits here. It particularly doesn't make a ton of sense to me with massively dynamic & distributed technologies like Jini/JavaSpaces and Grid. Class loaders anyone?
Perhaps it makes things more approachable. It certainly doesn't make things more open. I choose open over approachable.
8 comments:
It would make more sense if it was possible to alter Spring's configuration dynamically, during run-time. It makes more sense to use OSGi to dynamically assemble the application and use Jini to deploy and manage the application containers.
"It would make more sense if it was possible to alter Spring's configuration dynamically, during run-time. It makes more sense to use OSGi to dynamically assemble the application and use Jini to deploy and manage the application containers"
Exactly!
And that is exactly what were doing with our next 6.0 release.
Nati S.
GigaSpaces
Agreed.
Check out the Newton project at http://newton.codecauldron.org.
Dynamically assembled services described by SCA, assembled from OSGi with distribution / recovery leveraging Jini.
Regards
Richard
Can you explain your classloader comment to me? I'm not sure I understand what you're getting at.
Also, wpbarr, how do you want to modify Spring's config dynamically? Anything you can do today with Spring will work in Appistry's fabric. It doesn't prevent anything, it's a decoupled hosting of a Spring application (today btw Nati). And we don't require you to rearchitect your application like some vendors. You may also combine Spring, Java, C, C++, (and .NET on windows) in one fabric instance as was discussed in a previous blog entry.
Hi Jason,
"Can you explain your classloader comment to me? I'm not sure I understand what you're getting at."
Well perhaps Spring has changed, but when I used it last the DI happens when you start the JVM.
I'm confused at how this works on a grid where things are fairly dynamic? I worry about ClassLoader issues, or more specifically having to restart nodes etc.
I am probably wrong - can you educate me?
"Well perhaps Spring has changed, but when I used it last the DI happens when you start the JVM."
Ah, I think I understand. Basically the design we are following with Spring is to both allow a client app to use DI to send requests via Spring's lightweight remoting. Spring uses this method for RMI, JAX-RPC, etc. So we just follow that same pattern to keep client domian code decoupled from our api, which is consistent with the Spring philosophy in general.
On the "server" our application fabric as we call it supports the deployment of Spring applications via the Spring service exporter syntax. When a task is invoked our software will instantiate an application context and call the correct Spring JavaBean that is exposed as a service. So every machine has a separate JVM running. The classloader for the individual worker's JVM will load up the application in isolation of any other machine.
I hope that answers your question? Our whole idea was to keep both client and server applications isolated from our architecture. We want the ability to scale Spring apps (and POJOs as well) to be as simple as possible and not have hard dependcies on our api. So even though we're not OSS, we are at least OSS friendly. :)
-jasen
Appistry
Jasen,
So you have some form of mobile code?
Mike
I wouldn't call it mobile code. It's like an ear deployment. You package your app and run our deploy command to the fabric as if it was a single machine. Then the fabric spreads it out appropriately using versioning to synchronize all the machines.
So as an analogy, the fabric is like a light weight app server. But insead of using a cluster design, its based on the idea of using commodity linux (or windows) x86 boxes as a grid and scaling to hundreds of machines. But to java client code, it just looks like an async or sync invocation to a single address.
The cool feature is you can unplug any machine and all the transactions will still complete. We aren't based on a hub and spoke like some of the other vendors so we can be reliable and massively scale at the same time.
-jasen
Appistry
Post a Comment