Blitz is an open-source toolkit that sits on Sun's JINI installation, providing services. It's a very workable default installation for use and experimentation with JINI and JavaSpaces, a grid-oriented distribution platform. JavaSpaces are built around the concept of a map, with four basic operations: write, read, take, and notify. Elements in the space extend a marker interface, the Entry. A simple example of interaction with a space follows this pseudocode:

• establish a connection to the space
• create an instance that Entry with some data
• put the Entry into the space
• create another instance, with null serving as a wildcard and non-null properties as specific matches
• take an entry from the space using the second instance as a "template"
• disconnect

JavaSpaces supports the notion of transactions as well, so any failures can be rolled back across the system. Blitz provides a datastore and some tools organized around JavaSpaces, as a simple explanation. It's not required to have Blitz use JavaSpaces; the JINI reference implementation is entirely usable, but Blitz shortens many of the configuration steps and makes JavaSpace orientation far easier. Installation of Blitz is very easy. From the Sourceforge download page, simply grab the installation jar file and run it; this will start up a very simple GUI that asks where the JDK directory is, where to install Blitz, where the JINI installation is, and the runtime HTTPD port. This will create a directory with a number of runtime scripts and examples (and a few libraries as well). The simplest way to run Blitz at this point is simply to run "blitz.bat" (on Windows, of course, although this reviewer can vouch that Blitz runs on other OSes as well, with OS-specific scripts provided.) This will start a number of JINI services, most of which are fairly esoteric and specific to JINI internals. (It's wise to spend time understanding JINI's specific models, although that's beyond the scope of this review.) After starting Blitz, you now have a fully functional grid, although it's not a distributed store yet. It is, however, ready for use by any machine on your network. Another tool provided by Blitz is the Dashboard; this is a simple GUI that shows the number of active transactions, space operations (takes, writes, reads), the number of blocks, the number of instances, and the amount of memory used. This can show you what operations are taking place in your grid as it runs. Writing JavaSpace producers and consumers is quite easy. I used the Lookup.java class from Blitz' examples (specifically, the helloworld example, although any of them would work.) My project added jsk-platform.jar and jsk-lib.jar from the JINI installation, and looked up "jini://localhost:8085"; the Blitz console then showed that a client had registered. At this point, I had a grid client and a service to connect it to. I then created two entry implementations: a Person (with a name and age) and an Article (with a status, a title, and a list of Person references for authors.) I created two instances of each: one article had one author, the other article had both authors. Running the code showed the entries in the diagnostics tool, although it was unable to show the entries cleanly, as it didn't have access to the class definitions. Therefore, it could show their existence, their types, and even some data in them, but it couldn't show the entries themselves. I was then able to store and retrieve entries based on template data. The stores were quick and accurate. JavaSpaces programming requires some different approaches compared to what most enterprise programmers are used to. For example, in the above case, it's trivial to get the first article that matches the criteria - to wit, the first article of a given status - but getting a list of all articles is a little more problematic, involving one of a few patterns. One possibility, for example, is storage of a list containing all of the titles of articles, and then a programmer could use those to look for articles with matching titles and statuses (i.e., by refining the search). That said, JavaSpaces usually are better at working on individual elements rather than lists of elements, in my experience. Therefore, most would set up a loop to process a given template, and consume the matching entries one by one until all jobs were done. This is also how the command pattern is applied via JavaSpaces, a very common and extremely useful pattern for grids. An Entry implementing a Command interface (much like a Runnable, for example) is stored into the space, and consumers look for any available Command, then call the execution method to execute the task, possibly storing a result or another command back into the Space. Most of this isn't necessarily Blitz-related, but it should be noted that Blitz is the implementation being used. It's very easy to run, shows useful data about the Space in question, is open source, and is very servicable in providing an easy on-ramp to space-based programming, and Dan Creswell has been extremely supportive of the product on the lists. Joseph Ottinger is the editor-in-chief of TheServerSide.com, and has extensive experience in server-side technologies ranging from Perl to Cold Fusion to C/C++ and Java.

can anyone compare this to any commercial javaSpace inplementation , and tell us the common points. can blitz used to cluster my application? what about failover and sync. isuues,how it compares to multicasting techniques?... thanks for any comment.. joe

can anyone compare this to any commercial javaSpace inplementation , and tell us the common points.
can blitz used to cluster my application?
what about failover and sync. isuues,how it compares to multicasting techniques?...
thanks for any comment..
joe

Comparison wise, both Blitz and GigaSpaces list their respective features fairly clearly so you should be able to compare and contrast yourself. In respect of using Blitz or JavaSpaces in general to create some kind of clustering back-bone it's going to depend on exactly what your requirements are sometimes it's appropriate, sometimes you want to use JGroups and some times something else entirely (where's Cameron ;).

In respect of using Blitz or JavaSpaces in general to create some kind of clustering back-bone it's going to depend on exactly what your requirements are sometimes it's appropriate, sometimes you want to use JGroups and some times something else entirely (where's Cameron ;).

I am definitely not the Tangosol expert on Javaspaces, but it never struck me as a clustering API. The Javaspaces API seems like a good client/server API for pulling work for staged processing (i.e. the master/worker pattern), and you can easily do that with a farm of machines acting as clients. Our Coherence software is really much different in its approach, where every machine is part of a giant organic "server" (i.e. the cluster is one big server, made up of many individual machines). However, our approach could theoretically work well with the Javaspaces approach. Dan has been working to show us how, and I'm interested in what the result would look like. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

Cameron, I can't see that it would be difficult for Tangosol to implement the JavaSpaces and Jini patterns and APIs on top of Coherence. I'm not quite sure if it's a good idea but I'll leave you guys to decide that one. -John-

The idea of the product being an implementation of a specification (JavaSpaces in this instance) is a powerful one, since it makes it that much easier to sell it to the architects. I think it's easier for people to identify quickly with a "known" API (even though you will eventually need to use the extensions to get any meaninful work done). Additionally, I think this would give it more legitimacy in the "space based architecture" arena.

I would categorize Blitz as a high-quality opensource project and extremely capable JavaSpaces implementation. I believe that the Blitz project is critical for the adoption of JavaSpaces by a wider community and I wouldn't rule out the option that we (GigaSpaces) may contribute to that project ourselves in the near future. GigaSpaces Enterprise Edition today provides much more than a JavaSpaces implementation and therefore I'm not sure that feature list comparison makes real sense. From a position stand point a strong distinction between GigaSpaces and Blitz is that we (GigaSpaces) have extended our product in many ways beyond the JavaSpaces core API to address a much wider spectrum of the distributed applications problem domain. Our goal is to enable the scaling-out (Scaling between machines) of distributed statefull applications. Another goal is to accomplish all that, in a simple manner.

Comparison wise, both Blitz and GigaSpaces list their respective features fairly clearly so you should be able to compare and contrast yourself.

As Dan mentioned above you can find detailed information on GigaSpaces specific enhacments and features on our web site. HTH Nati S.

Hi Joseph, Firstly, thank you for writing up a review and secondly I wanted to add some details here:

JavaSpaces programming requires some different approaches compared to what most enterprise programmers are used to. For example, in the above case, it's trivial to get the first article that matches the criteria - to wit, the first article of a given status - but getting a list of all articles is a little more problematic, involving one of a few patterns. One possibility, for example, is storage of a list containing all of the titles of articles, and then a programmer could use those to look for articles with matching titles and statuses (i.e., by refining the search).

With the standard JavaSpaces interface, these sorts of approaches were necessary however, there is an additional interface available now called JavaSpace05. The JavaDoc is here: http://www.dancres.org/cottage/doc/api/net/jini/space/JavaSpace05.html Both Outrigger and Blitz implement this interface (which extends JavaSpace) and provides a standard method which would help greatly in the cases you've described above called contents() which essentially allows you to do a bulk read via an iterator style interface for a collection of matches. JavaSpace05 is relatively new but is a standard Jini interface and part of the Jini 2.1 release.

Dan Creswell has done a great job with Blitz. For those who might want to play with it under Eclipse, Incax has a community plugin with Blitz support: www.incax.com I like Javaspaces for the most part, but it does take a different mindset to problem solving.

+1 It is great to see that JavaSpaces gaining more traction. BTW:http://www.incax.com/ is not exclusively Eclipse, it provides plugins for all major java IDEs

I like Javaspaces for the most part, but it does take a different mindset to problem solving.

I was quite amazed to see "I created a Person class..." and the discussion about object retrieval in the article: is this JS about persistency? I thought it was about networked computing. (The clustering of Tangosol fits that picture.) It probably is just me, but maybe someone is willing to write a "when to use JINI / Javaspaces / BLITZ" article, maybe comparing a "normal" implementation and the JS version.

I like Javaspaces for the most part, but it does take a different mindset to problem solving.

I was quite amazed to see "I created a Person class..." and the discussion about object retrieval in the article: is this JS about persistency? I thought it was about networked computing. (The clustering of Tangosol fits that picture.)

It probably is just me, but maybe someone is willing to write a "when to use JINI / Javaspaces / BLITZ" article, maybe comparing a "normal" implementation and the JS version.

Well, it's all about where things go and what they do. JavaSpaces implements a model where an anemic domain model is, erm, not wise, which I'll be happy to admit my poor example used. The idea is that what gets transferred to clients who take an object is not DATA, but an actual object, with behaviour, that they can modify at will and store back into the space.

JavaSpaces implements a model where an anemic domain model is, erm, not wise, which I'll be happy to admit my poor example used. The idea is that what gets transferred to clients who take an object is not DATA, but an actual object, with behaviour, that they can modify at will and store back into the space.

Unfortunately, I believe that the exact opposite is true. JavaSpaces contain "entries" (structs of public fields), not objects. The fields must also all be of reference types (no int, long, boolean, float, etc.) I have discussed this with Sun, Dan and others, and I believe that this has been one of the biggest road-blocks to the use of Javaspaces, and it encourages (enforces!) the most anaemic of models, such as an extra class to act as an entry to contain the real application objects. As I wrote to Sun:

The Entry in its use as an object is an anti-pattern. It is neither an application object (e.g. since it is forced to declare the entire world its C++ friend), nor is it an object that is standard part of the space API (i.e. an implementation). It should either be standardized as part of the API (and as such, it should have an API), or it should be definable by the application (e.g. the interface should be dictated by the space API but the application could implement it). By requiring public fields, you cripple both the space implementer's and the application developer's ability to do simple things such as data hiding, deferred operations, etc. As I see it, the current "API" for Entry is simply the exposure of a desired implementation detail, but one that has been imposed on all implementers and consumers alike.

For an explanation of the design decisions behind the Entry, see Ken Arnold's interview on Artima: http://www.artima.com/intv/swayP.html Honestly, I do not understand the suggested rationale at all. For example, I have looked at Hibernate and KODO and other ORMs, and none of them forced me to build all my application classes with public fields, yet the application objects were still completely persistable and manageable by those frameworks. No other framework or API made me use Integer instead of int and Boolean instead of boolean. There's nothing wrong with the Javaspaces API at a high level: The Tuple Spaces concepts of being able to read, write and take. James Strachan used the same concepts as the basis for his own simple ActiveSpace API: http://activespace.codehaus.org/maven/apidocs/ (Unfortunately, it misses the query ability, which means that spaces must be completely uniform.) Before that, IBM created TSpaces on the same Tuple Spaces concepts: http://www.almaden.ibm.com/cs/TSpaces/Version3/ClientProgrGuide.html At any rate, a few minor changes to the APIs (e.g. getting rid of Entry and using Java objects instead, and integrating with the existing transaction infrastructure in Java EE) and I could see the space approach being useful and easy to adopt. For example: interface Space { int count(Filter query); Iterator iterate(Filter query); Object read(Filter query); Collection readAll(Filter query); Object waitRead(Filter query, long timeout); void write(Object o) void writeAll(Collection o) Object take(Filter query); Collection takeAll(Filter query); Object waitTake(Filter query, long timeout); } What do you think, Dan? Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid

Unfortunately, I believe that the exact opposite is true. JavaSpaces contain "entries" (structs of public fields), not objects. The fields must also all be of reference types (no int, long, boolean, float, etc.) I have discussed this with Sun, Dan and others, and I believe that this has been one of the biggest road-blocks to the use of Javaspaces, and it encourages (enforces!) the most anaemic of models, such as an extra class to act as an entry to contain the real application objects.

I can't be sure but I think that Joseph was referring to the in-built ability to have that entry not just be a payload of fields but also methods containing relatively arbitrary code by virtue of the code-downloading ablitity that's built in to the JavaSpaces model. Object probably wasn't the best term to use but well, in at least one sense, one instantiates an Entry implementation (Entry being an interface) and you end up with a Java object so it doesn't seem entirely invalid a word. I'd have to disagree with it being a major roadblock - there are lots of others that get mentioned much more loudly and often :) I'm also not sure what you're thinking when you say "application objects". I have a suspicion I probably don't use spaces in the style you perhaps have in your mind.

As I wrote to Sun:

The Entry in its use as an object is an anti-pattern. It is neither an application object (e.g. since it is forced to declare the entire world its C++ friend), nor is it an object that is standard part of the space API (i.e. an implementation). It should either be standardized as part of the API (and as such, it should have an API), or it should be definable by the application (e.g. the interface should be dictated by the space API but the application could implement it). By requiring public fields, you cripple both the space implementer's and the application developer's ability to do simple things such as data hiding, deferred operations, etc. As I see it, the current "API" for Entry is simply the exposure of a desired implementation detail, but one that has been imposed on all implementers and consumers alike.

Well there's some stuff we ought to talk about in there face to face but in general, it turns out not to be much of a burden in practice because the Entry implementation can also implement interfaces and have getter setter methods etc. Thus it's possible to build factories and stuff to hide this way from your app in many cases. To perhaps make it clearer - one often sees the compute server example where one extends from a Task Entry and that has a generic method run(). There's nothing to prevent the Task Entry from implementing a separate interface which defines the run() method so the low level code deals in Tasks and the higher level code only sees this other interface and uses the methods on that interface to achieve it's needs.

.........a few minor changes to the APIs (e.g. getting rid of Entry and using Java objects instead, and integrating with the existing transaction infrastructure in Java EE) and I could see the space approach being useful and easy to adopt. For example:

interface Space {
int count(Filter query);
Iterator iterate(Filter query);

Object read(Filter query);
Collection readAll(Filter query);
Object waitRead(Filter query, long timeout);

void write(Object o)
void writeAll(Collection o)

Object take(Filter query);
Collection takeAll(Filter query);
Object waitTake(Filter query, long timeout);
}

What do you think, Dan?

I think I could actually build most of that abstraction over the top of JavaSpace and JavaSpace05 without too much trouble if people were interested. It's not that far away from what's available now. I'm less keen on the Iterator thing though because of course in Jini-land we like to make remoteness visible but that's a long subject for beer time I think. There's some subtleties as well like the fact that Filter implementations would potentially need to be downloadable etc which might mean Filter needs to extend Serializable.

At any rate, a few minor changes to the APIs (e.g. getting rid of Entry and using Java objects instead, and integrating with the existing transaction infrastructure in Java EE)

Sorry, forgot to say, I'm not sure but I think the transaction integration thing may have partially been tackled by some stuff in Spring Modules - not sure how generic or complete it is. There's some other stuff also been going on in a separate project from that. There's also a product called Cohesions which provides transaction integration as well. Got it here on my desk for evaluation at this moment and there's at least one significant Jini user out there I'm aware of who's messing with this product too.

I've been following Blitz JavaSpaces (Pure Java Edition) for a while now, I find that although the project is very attractive, the release schedule seems somewhat uncontrolled: http://freshmeat.net/project-stats/view/43777/ Note that there was one release on September 26, one of the 27th and one on the 29th. This raises questions on the maturity of the product. My suggestion to the Blitz JavaSpaces team is to plan releases more carefully, do more testing per release and use a slightly different version numbering scheme, differentiating between major (feature?) releases and minor (bug fix?) releases. At the least this will improve the impression the product gives and -more importantly- is likely to improve the quality of the product.

I've been following Blitz JavaSpaces (Pure Java Edition) for a while now, I find that although the project is very attractive, the release schedule seems somewhat uncontrolled:

http://freshmeat.net/project-stats/view/43777/

Note that there was one release on September 26, one of the 27th and one on the 29th. This raises questions on the maturity of the product.

My suggestion to the Blitz JavaSpaces team is to plan releases more carefully, do more testing per release and use a slightly different version numbering scheme, differentiating between major (feature?) releases and minor (bug fix?) releases. At the least this will improve the impression the product gives and -more importantly- is likely to improve the quality of the product.

The schedule is uncontrolled because it's my spare time open source project. It's no different to many other opensource projects and I do it for free - and because of all those things there's not likely to ever be a "controlled" schedule. As to the maturity of the product as it happens, if you look back at earlier history you'll see rapid releasing as the product grew. Now that it's (from my perspective) basically feature complete, most releases are triggered in response to user issues. Thus I'm saying it is mature and that's why releases are now less regular. Looks can be deceiving can't they? On testing - you obviously cannot know what testing I do nor can you know how long I test or how many users I do pre-releases to. How can you therefore tell me I need to do more testing? And if I am to do more testing (for free of course), what would you suggest I test? As to version numbering - tell me what you think I should do instead. And note that no-one else has complained about version numbering and that freshmeat allows me to define in the release announcement what the core focus of the release is. Finally, on quality, you should talk to my users about what they think rather than make isolated judgements. You're not a committer on my project, you don't appear to be subscribed to any of the mailing lists nor do you appear to have had any direct mail interaction with myself. I'm not sure then, how closely you could have been following the project.

As to the maturity of the product as it happens, if you look back at earlier history you'll see rapid releasing as the product grew. Now that it's (from my perspective) basically feature complete, most releases are triggered in response to user issues. Thus I'm saying it is mature and that's why releases are now less regular.

I upset you, which was not my intention. I shared with you which impression the release schedule gives to some people, or at least to me. Just as feedback, with a positive suggestion on what I would consider an improvement. I give this feedback because I appreciate your effort and find the project very interesting.

On testing - you obviously cannot know what testing I do nor can you know how long I test or how many users I do pre-releases to. How can you therefore tell me I need to do more testing? And if I am to do more testing (for free of course), what would you suggest I test?

What is visible is that you do multiple releases within a week with no difference in the release version level. You could chose to use a numbering scheme to indicate the kind of release. For example: 1.3.0 -- Major feature release 1.3.1 -- Security or bug fix release 1.3.2 -- Security or bug fix release 1.4.0-alpha1 -- Alpha-quality release, interface may change. 1.4.0-beta1 -- Beta-quality release, interface should not change, no new features should be added, memory and performance are profiled. 1.4.0-rc1 -- Release candidate, nothing should change, unless real issues are detected. 1.4.0 -- Major features release, 'guaranteed' to be stable, no memory leaks, good performance and backwards compatible with previous releases except where explicitly documented otherwise. Again, this is just a suggestion. Do with it whatever you want. I appreciate your work on the project and keep it in mind in case I find a project I can use JINI for.

I upset you, which was not my intention. I shared with you which impression the release schedule gives to some people, or at least to me. Just as feedback, with a positive suggestion on what I would consider an improvement. I give this feedback because I appreciate your effort and find the project very interesting.

Ah, I didn't take it that way - I was attempting to ensure we were having a "real" conversation. I've encountered some unethical elements along the way hence the style of my response. Sometimes you can't tell friend from foe without doing a little "calling out" - real friends clarify themselves and provide constructive response as you have below.

What is visible is that you do multiple releases within a week with no difference in the release version level. You could chose to use a numbering scheme to indicate the kind of release. For example:

1.3.0 -- Major feature release
1.3.1 -- Security or bug fix release
1.3.2 -- Security or bug fix release
1.4.0-alpha1 -- Alpha-quality release, interface may change.
1.4.0-beta1 -- Beta-quality release, interface should not change, no new features should be added, memory and performance are profiled.
1.4.0-rc1 -- Release candidate, nothing should change, unless real issues are detected.
1.4.0 -- Major features release, 'guaranteed' to be stable, no memory leaks, good performance and backwards compatible with previous releases except where explicitly documented otherwise.

Again, this is just a suggestion. Do with it whatever you want. I appreciate your work on the project and keep it in mind in case I find a project I can use JINI for.

Cool, thank you. That's obviously a lot more sophisticated than what I'm using :) I'll certainly give it some thought, and thank you for a considered, helpful response.

JavaSpaces is relatively generic model for sharing objects and coordinating distributed processes. Not surprisingly different people has different take on what the space model means and often tend to mix between the conceptual model and specific implementation of that model. Were (GigaSpaces) are obviously strong believer in the space model and like many of you came across those different requirements while working with customers enabling them to build large scale mission critical applications on top of what we refer to as a Space Based Architecture (SBA). In order to bridge the gaps between the current JavaSpaces specification and the different industry needs we started an initiative together with Interface21 and some of large financial organizations that uses space as the technology for driving their mission critical business through the spring modules project. Part of the rational behind that initiative was to open the discussion to a potentially wider specectrum of community member (not limited to the Jini community). You could find Blitz as part of that project as well. A reference to that project can found under the following location: https://springmodules.dev.java.net/docs/reference/0.6/html_single/#javaspaces Some of the first issue that we wanted to address is the use of Entries vs POJO – for that we came with a solution which basically maps between POJOS and Entries through annotation or mapping file in similar fashion to Hibernate. For example you could very easily map the following POJO into an entry using annotation in the following manner.

@SpaceClass (replicate=true,persist=false,fifo=true,converterType="space", indexing-mode="instance") public class Person { @SpaceField(index=true) private String getFirstName() { ... } @Nullable(value="-1") public int getCount () { ... } @Key(autoGenerate=true} private String getLastName() { return lastName; } } See detailed documentation below http://www.gigaspaces.com/wiki/pages/viewpage.action?pageId=9432

Transaction can also be supported in a declarative manner in the following way:

@Transactional(propagation = Propagation.MANDATORY) public void writeMandatory(Person bean, boolean fail) throws Exception { getSpaceTemplate().write(bean, 10000); if (fail) { throw new RuntimeException("operation failed intentionally"); } }

I believe that with this initiative we could get faster to a point in which we could define what's the "right" way to address the POJO, transaction semantics and some of the other requirements mentioned here. Having a wider community including real customer is a key for success IMO. Dan, John, Cameron I believe that the timing is right to open that discussion and turn those different ideas into something concrete. Learning from past experience the challenge is to come to this sort of discussions with open mind. Dan? Nati S GigaSpaces.

Is there a way to configure the persitance of Blitz using ORM such as Hibernate? Great article.

Is there a way to configure the persitance of Blitz using ORM such as Hibernate?

I am not sure we should even try to do it. If I understand SBA correctly then we need to create a service that will listen to space events for objects of certain types and then persist them in RDBMS with using Hibernate, iBatis or anything we like.

Is there a way to configure the persitance of Blitz using ORM such as Hibernate?

I am not sure we should even try to do it.
If I understand SBA correctly then we need to create a service that will listen to space events for objects of certain types and then persist them in RDBMS with using Hibernate, iBatis or anything we like.

Yep - if the reason you want to do this is for additional processing of entry's or archiving them or whatever. The format of the Entry once it's within the space is not useful for applications anymore - it's chunks of binary and search structures. I've not come across any other good reasons for doing this sort of thing as most database type constructs don't cope well with blitz's use of binary arrays etc - it's not very SQL friendly! And in Blitz's case, where it works out of the box, adding reliance on some external database which must be explicitly managed, configured etc by the user would be a backward step in ease of use.