James Strachan of ActiveMQ, Groovy, Geronimo fame (we won't mention Jelly!) talks about his idea of ActiveSpace, a JavaSpaces like abstraction which sits on a high performance message bus for high performance streaming.

Unlike JavaSpaces, ActiveSpace doesn't require Jini and hides transaction demarcation.

Features:
1. SQL based query support
2. Persistent and transient
3. Fully transactional
4. Supports space hierarchy
5. Both queue and pub/sub mode
6. Message priority support

Read more about ActiveSpace

_Now_ spaces are beginning to make some more sense ..

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

_Now_ spaces are beginning to make some more sense ..Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!

:)

I think part of the problem I've always had with JavaSpaces is that they're trying to do lots of different things and so they suffer a little of the Jack-of-all-trades problem.

Folks who use JavaSpaces use them as a cache + database + message system + grid middleware etc. If you need caching or a clustered store of state, then we think JCache is a better, simpler & more powerful abstraction.

What we tried to do with ActiveSpaces is to just focus on the core part of what JavaSpaces offers thats different to JCache/POJO persistence - a simple programming model for messaging & grid processing, allowing messages to be put into spaces and removed from spaces (with or without filters) along with leases and so forth in as high performance & scalable way as possible - allowing reuse of industrial grade messaging middleware under the covers rather than reiniventing the wheel.

So ActiveSpaces doesn't do 100% of what you can do with JavaSpaces, but it should hopefully do the common 80% of what folks really need - the grid type stuff- for the rest there's JCache. (JCache has a bunch more use cases too I might add :-)

James
ActiveMQ

Just wondering, do people like the EventObject type pattern made famous in AWE and then discarded with swing where they switched to a typed event interface, i.e. the listener rather than having an onEvent(Object) now had onWindowOpened(Window w) etc.

Personally, I like the latter as it make it a lot easier to document and it becomes type safe. I took this approach with the EventSource API in WebSphere Enterprise rather than my original plan which was a JMX notification type approach.

I noticed that ActiveSpace SpaceListener is of the AWT variety rather than having typed event listeners. I know they could be added with an adapter which demuxes the event, but what do people want? The single method with the vague object or the typed listener or both?

Billy

And yep, they used a typed interface after spending more than 10 seconds in the javadocs but the question still applies in general, what kind of notification APIs are people most comfortable with? typed or untyped or both?

Thanks

And yep, they used a typed interface after spending more than 10 seconds in the javadocs but the question still applies in general, what kind of notification APIs are people most comfortable with? typed or untyped or both?Thanks

Agreed - some folks may wish to use a typed interface.

Its trivial to add a typed facade to ActiveSpaces or we should be able to use JDK 1.5's generics to provide an easier way to create a typed facade automatically...


Space<PurchaseOrder> space = ...;
PurchaseOrder order = space.take();
if (order.getAmount() > 1000) {
   ...
}


Another option could be to use an object broker framework like Mule to bind ActiveSpaces to your APIs.

James
ActiveMQ

Just wondering, do people like the EventObject type pattern made famous in AWE and then discarded with swing where they switched to a typed event interface, i.e. the listener rather than having an onEvent(Object) now had onWindowOpened(Window w) etc.Personally, I like the latter as it make it a lot easier to document and it becomes type safe. I took this approach with the EventSource API in WebSphere Enterprise rather than my original plan which was a JMX notification type approach.I noticed that ActiveSpace SpaceListener is of the AWT variety rather than having typed event listeners. I know they could be added with an adapter which demuxes the event, but what do people want? The single method with the vague object or the typed listener or both?Billy

I think I prefer the typed version better. I'm interested in hearing arguments for the more generic form but I feel that better documentation and strong typing will make the API easier to use.

Another concern:
A lot of the J2EE/J2SE stack historically, in my opinion, seems to have been developed with flexibility over ease of use as a guiding principle. I think that is why we are seeing a backlash with non-standard alternatives for persistence, UI, etc. If I were going to develop a new framework today, I think I'd switch the concerns and make ease of use more of a factor.

Maybe a way to do this is to simultaneously design the wide-open flexible spaces engine and a special purpose facade that would be used 80% of the time?

Just to make it clear that this wasn't just James, we both come up with the idea in a pub last week. There was some on-going discussion last night but the beer got the better of us. James driving it from the JMS side, me from the JavaSpaces side.

We were talking about the similarities between JavaSpaces and JMS and how JMS could in fact be implemented by JavaSpaces. The idea was simply to look at some sort of API that fitted between the two, i.e. part Space, part JMS.

JavaSpaces uses an interface based selection, this is because it was originally designed for services based on an interface. JMS uses message selector (based around SQL 92), this is more data-centric. Now, if we can combine the two in such a way that the some of the services become active (hence ActiveSpace) then we might be able to leverage a JMS with some sort of active node.

We were thinking of ideas like complex selectors where you provide the selection service and fire it off to be executed in the ActiveJMS (ActiveSpace or whatever). That and a lot of other ideas of course.

James is in an excellent position to implement this into ActiveMQ, I think it's going to be a little JMS centric at this point but it's a good start. If Cameron's finally understood something then that's an even better start. :-)

By the way, the other name we came up with was ARE (Active Rules Engine I think), the idea of putting ECA rules into the ActiveJMS and having them executed by the "thing" (space, JMS or whatever).

-John-

Just to make it clear that this wasn't just James, we both come up with the idea in a pub last week. There was some on-going discussion last night but the beer got the better of us. James driving it from the JMS side, me from the JavaSpaces side.We were talking about the similarities between JavaSpaces and JMS and how JMS could in fact be implemented by JavaSpaces. The idea was simply to look at some sort of API that fitted between the two, i.e. part Space, part JMS.JavaSpaces uses an interface based selection, this is because it was originally designed for services based on an interface. JMS uses message selector (based around SQL 92), this is more data-centric. Now, if we can combine the two in such a way that the some of the services become active (hence ActiveSpace) then we might be able to leverage a JMS with some sort of active node.We were thinking of ideas like complex selectors where you provide the selection service and fire it off to be executed in the ActiveJMS (ActiveSpace or whatever). That and a lot of other ideas of course.James is in an excellent position to implement this into ActiveMQ, I think it's going to be a little JMS centric at this point but it's a good start. If Cameron's finally understood something then that's an even better start. :-)By the way, the other name we came up with was ARE (Active Rules Engine I think), the idea of putting ECA rules into the ActiveJMS and having them executed by the "thing" (space, JMS or whatever).-John-

:)

Agreed. FWIW my original coverage of the lunch which set this whole thing moving is here.

Adding ECA rules inside ActiveSpaces or to inside a message broker / JMS provider would be very interesting and wouldn't require a different API change to the end user, since the ECA stuff would be deployed inside the ActiveSpace / ActiveMQ fabric.

We need a better name for such a thing though :)

James
ActiveMQ

Though James did implement a similar(ish) spaces concept into SpiritCache (which uses JMS) a year ago.
Hopefully James will release ActiveTimeTravel under the Apache licence soon :-)

Rob
SpiritSoft

I thought you'd find the information on GigaSpaces Platform 4.0 beta release highly relevant to this discussion as it already incorporates much of what James Strachan is proposing with his ActiveSpace concept, except that it is built on top of clustered JavaSpaces with JMX monitoring and provisioning tools:

The GigaSpaces 4.0 release will include:
- Fully featured JMS provider with ultra-fast performance
- JDBC API
- JMX API
- JavaSpaces with ability to provide SQL queries
- Advanced SSI Clustering options
- Advanced Notifications options
- Hibernate , JDO Cache plug-ins
- Plug-ins for Dynamic Grid provisioning and managements tools for various vendors
- Many more examples
- more...

We are offering the beta version to a limited number of companies.
If anyone would like to participate in our 4.0 beta program, please send me an email.

Best Regards,
        Shay
----------------------------------------------------
Shay Hassidim
Product Manager, GigaSpaces Technologies
Email: shay at gigaspaces dot com
Website: www.gigaspaces.com