Lorenzo Puccetti's Blog

Why is javaspaces technology not as successful as it should be ?

When I got myself a java.net blog I thought I'd have used it to talk about the java technologies I use everyday. Whether it is Spring, XStream or less popular open-sources, the idea was to divulge what I was learning to the benefit of the java community and my own.

Today instead I feel like writing about javaspaces but, not to discuss about some good practice I learnt, but to ask everybody who has worked with it a few questions.

I've been working with javaspaces on and off for the last 12 months and I simply love it.
We have been designing an OLAP solution with javaspaces. We had to deal with large volume of data and high performance expectations and come out with a powerful solution where parallel computations are the core of the architecture.

These days I could not think of solving the same business problem in any other way.

So my questions are, why is that the javaspaces technology is not as popular as I think it should be ? how come there is only one proper open-source implementation (Blitz) and one proper commercial solution (gigaspaces) ? why does it seem that only few patterns have been described to work with spaces ?

Surely I can see that, while the javaspaces API is remarkably concise and simple, it takes some good practice to learn how to design a good distributed solution. The mindset needs to adapt to deal with problems that do not occur in local computation (e.g.: partial failure, network-latency,...). But there must be more than this ?

A colleague of mine told me that is just a "marketing" issue. Sun did a good job in promoting EJB and less of a good job for jini and javaspaces.

Maybe or maybe not... In any case I'd love to hear more...

Comments

• the reason is simple: jini was not open-sourced from the beginning. when jini came out many years ago, i thought it was the coolest technology around. but sun had chained it to a commerical license and that was the beginning of an end, imho. let's hope it's not too little too late to open source it now.

  Posted by: walterc on January 28, 2007 at 08:28 AM

• one of the reasons I've strayed away from it and other clustered VM solutions like tangsol/coherance is that there wasn't much emphasis on pessimistic persistence and reliability upon hardware/network failure. this is why I've stuck to JMS because it advertises the ability to recover and guarantee message handling across a load balanced cluster. I posed the same issue with Jini-- how feasible is the business case for things as important as purchase orders to be reliably handled without duplication or loss if a node could drop from the cluster? maybe it comes down to the fact that we're simply solving a different usecase than javaspaces, but you have to admit, there's some overlap on the architectural decision to pursue either.

  Posted by: jhook on January 28, 2007 at 08:30 AM

• @jhook: actually Jini / JavaSpaces solutions, but also Coherence (even though for this last product I'm just relaying some information, never used it) have a very good reputation about hardware / network failure (consider that one of the most "extreme" architectures that are sometimes proposed with these technologies rely on some massive cluster for data replication with no hard disk backing up... just to say that you can rely on the memory copies of data). Did you have a different experience here?

  Back to the original question: it _is_ a marketing issue. It's not necessarily a opensource thing (I think that opensource is good, but looks like too many people think that it's the only way to to things...) - for instance J2EE was not opensource for several years. Nevertheless J2EE came out from a definition process that involved the major players in the market, including IBM and others, thus "paving" the way for market penetration. OTOH JavaSpaces probably bound its destiny to Jini, another excellent technology that didn't penetrate the market yet - most likely because it was initially addressed to domotics and such at the end of the 90's, way too early. Now Jini / JavaSpaces are excellent and successful stuff for high-reliability and grid computing stuff, but this kind of technology is still a niche in the market. Probably things will change in the close future.

  Posted by: fabriziogiudici on January 28, 2007 at 08:51 AM

• maybe this proves it's a pure marketing failure for the technology-- a couple years ago when I started looking at options for scaling processes out, the people I asked folks in the Jini-space community and even today with the commercial cluster-VM solutions-- they didn't have the answers I was looking for, while there were clear business cases and tutorials/examples in the JMS realm.

  Posted by: jhook on January 28, 2007 at 05:24 PM

• Mentioning gadgets to use Jini got the press to hype it in a coma, as gadgets lacked power and connectivity. Now laptops outsell desktops and mobile phones turn into webtablets, the IT landscape is now more in need of Jini

  When Jini just came out ease of use for the developer was totally lousy and there were some serious bugs.
  You had to be a java coding guru and network admin at the same time.
  While the principles were not too difficult, actually coding a working system together should have been almost as easy.

  just double click something on a web site should be enough to startup some Jini system, like for example JavaSpaces. And if it doesn't work it should tell you exactly why, firewall, etc.
  Some graphical configuration would also do wonders.

  Now ajax is hitting some single-threading bottle-necks, Jini has chances.
  

  Posted by: steltenpower on January 28, 2007 at 07:25 PM

• Since gigaspaces and coherence has been mentioned here, I think it also worth to mention terracotta. The beast part is that there is no API. You basically can write multi threaded app for single VM and use terracotta to distribute it...

  Posted by: euxx on January 28, 2007 at 10:38 PM

• This is really a mixed up set of questions that all inter-relate somewhat so it's difficult to be concise but I will try:

  Yes, Jini was marketed badly but we're getting past that but I'd also say that any engineer that looked past the hype at the API's themselves could clearly have seen that the device story was errr, codswhallop.

  Jini and the JavaSpaces service (which is but one service in the starter kit and no more important than any other) require different patterns and more importantly thinking. You can't treat the lookup service like a JNDI registry and you can't treat JavaSpaces like JMS or a database:

  Jini requires thinking differently from how you do with J2EE et al - that's the biggest hurdle. If you go looking at the API's with your J2EE mindset, you'll mash your brain.

  Due to Jini's focus on network failure and ad-hoc service assemblies clustering is avoided. It can be done but it doesn't work well except in strictly controlled data-centre type environments and Jini is deployed wider than that problem-space.

  Having consulted on a number of Jini systems including highly resilient and scalable ones, I can assure you that clustering under the covers such as offered by some JMS implementations is not necessary. In fact, clustering quite often compromises performance outside of message/event driven approaches.

  @jhook What you describe is how JMS does things - it's not the way Jini/JS does things. Many people ask questions similar to "this is how I do it in JMS why doesn't Jini/JS do it this way?" and the answer is simple, because it's different and Jini does it another way. Continuing on the design pattern/thinking/solutions space - do Tangosol tell you how they do what they do? No, why? Because it's high-value! So, if someone asks me how to do similar things with Jini, do you think I'll give that information away for free? The Jini-Users list is a free (and very good) resource for information but there's a limit to what you can reasonably expect to get for zero-dollar investment.

  @walterrc Given the amount of commercial interest and usage I and others are seeing (and that was prior to the move to Apache) I think we're at a beginning not an end.

  @lorenzo Why are there only a couple of JavaSpace implementations? Because they're damned hard to implement at all, let alone well - I should know because I wrote Blitz.
  

  Posted by: dancres on January 29, 2007 at 03:18 AM

• I've been going on about the benefits of blackboard architectures (the underlying representation that would be JavaSpaces + events) for 20 years at least. Its really the best way to build stuff. Yay, go JavaSpaces.

  Posted by: jacksjpt on January 29, 2007 at 07:53 AM

• I don't see a huge difference between tuple spaces and SQL used in a particular fashions (especially with ORM). Is it just the right factoring of features/simplicity for common use cases? Or am I missing something entirely?

  Posted by: tompalmer on January 29, 2007 at 08:52 AM

• "I don't see a huge difference between tuple spaces and SQL used in a particular fashions (especially with ORM). Is it just the right factoring of features/simplicity for common use cases? Or am I missing something entirely?"

  I think you're missing something - as a starter:

  SQL constructs require fixed schemas communicated to the database in advance. The result is the constant rub of schema migration, code changes all over the place etc. Tuplespaces et all provide better support in this area and reduce impact on code. JavaSpaces go even further and allow for distribution of code alongside or instead of data.

  There's lots more to learn and I don't propose to write it all down as there's plenty of information out there - Google is your friend.
  

  Posted by: dancres on January 29, 2007 at 09:21 AM

• Its been a while since last I looked at JavaSpaces but its not the marketing. EJB 1.0 had no marketing and in fact when you tried to understand it the specs claimed that its not for the general public... It was complicated, relied on serialized objects rather than XML and had no tools or buzz around it. Nothing. Yet it picked up steam and industry demand, IBM incorporated it into WebSphere and WebLogic did the same. From then on it became a hit.
  JavaSpaces came from a different group within Sun and didn't enjoy the marketing, but then Jini did enjoy far more buzz than EJB's ever got... So what went wrong?
  So many different things in so many areas the technology just didn't have a chance since the technology is a hard sell to begin with...

  It didn't have the Java EE features, the concept of a transaction in JavaSpaces was overly simplified and lacked "basic" ideas that Java EE had forever. So todays products such as GigaSpaces integrate with Java EE but then you need to justify using GigaSpaces on top of Java EE rather than Java EE alone.
  Since there was no proper solution for the need of the enterprise the whole technology was badly positioned for small devices (to which it didn't fit at the time)... I'd wager that 99% of Java developers today have no idea what JavaSpaces really is. (yes this can be seen as a marketing blunder but I see it more as a product weakness which marketing didn't know how to handle).
  Its a different way of thinking, developers in the enterprise think about flows and use cases. There might be messages involved but generally they have a very sequential problem space... Sure you can represent every problem using JavaSpaces and many of them quite elegantly (e.g. stock market). But then you have to retrain your developer not just around new language/tools but also for new concepts... This might be possible with existing Java developers but I personally had to retrain COBOL developers, if you break a paradigm you have to show a real benefit and JavaSpaces wasn't there yet at the time.
  Tools and knowledge were completely missing, there still isn't all that much in both departments.
  
  Today Java EE took over everything, is well know and relatively lightweight... JavaSpaces implementations have improved to the point of offering a valid alternative or even a complementary solution. So what is stopping us from picking them up?
  No need. Most of what we do as developers is web/AJAX with a database backend. Maybe a fat client to some reasonably complex backend logic. Sure this logic can fit into JavaSpaces, but whats the benefit?
  JavaSpaces can allow greater scalability/clustering but thats only valid for extreme cases where JavaSpaces is in fact noticed (GigaSpaces does have real deployments), most people just don't really need it.
  Now you could argue about simplicity providing an advantage for JavaSpaces but that would be incorrect. JavaSpaces simplifies some things while keeping the complex portions of Java EE just as complex as they always were so you just get added complexity of JavaSpaces when you choose to go with it.

  Posted by: vprise on January 29, 2007 at 10:09 AM

• One reason: coupling it to Jini.

  I used JavaSpaces back in the beta days and loved it. Tried to use it again recently, and had to abandon it.

  Tying it to the obscure, under-documented, overly clever, overblown Jini mess killed JavaSpaces.

  Outrigger? What does that mean? Why does it have to be involved.
  Discovery? Why do I need discovery? Can I do without it?
  How many agents or daemons need to be running? How reliable are they? How to get persistent spaces? Non-persistent ones?

  Jini adds too much complexity to what should have been a simple idea.

  Posted by: mtnygard on January 29, 2007 at 11:01 AM

• "One reason: coupling it to Jini."

  Without Jini you lose a bunch of benefits like movable code.

  "I used JavaSpaces back in the beta days and loved it. Tried to use it again recently, and had to abandon it."

  Why?

  "Tying it to the obscure, under-documented, overly clever, overblown Jini mess killed JavaSpaces."

  It's not clever, just different.

  "Outrigger? What does that mean? Why does it have to be involved. Discovery? Why do I need discovery? Can I do without it? How many agents or daemons need to be running? How reliable are they? How to get persistent spaces? Non-persistent ones?"

  Outrigger is the stock JavaSpaces implementation that comes with the JSTK. It's a name, that's all. And it needs to be involved cos without it you don't have a JavaSpaces implementation to use. Discovery is the process of locating a lookup service so's you can find a Jini service. You don't need agents or daemons - are you referring to Jini 1.x? How reliable are they? You replicate for resilience to avoid single point of failure, reliable enough? Persistent and non-persistent mode is a configuration option (or not) of an individual JavaSpaces implementation - nothing to do with Jini. That's down to the service implementer.

  "Jini adds too much complexity to what should have been a simple idea."

  You need to explain what you consider complex and differentiate that from what you don't know cos it's new and then we can assess genuinely whether it's complex or not.

  As it happens, Blitz JavaSpaces provides an installer that allows you to start up the relevant bits of Jini (lookup service, transaction manager, codebase server and JavaSpace) all with one script and all running in one JVM. How simple do you need it?
  

  Posted by: dancres on January 29, 2007 at 01:38 PM

• 
  @vprise: I guess I'm a little confused about where some of these "deficiences" are coming from. You say that the transaction model is overly simplified. First off, transactions are a feature of Jini, not a JavaSpace. A space is a service in a jini architecture and you can run a Jini setup without a space if you want to. So I guess one thing to make very clear Jini != JavaSpace. Jini transactions are simple, yes. You can commit or abort them at any time or assign a lease to it in order to auto-abort after a given time (so that in the case of hardware failure, all jini services will automatically be notified to roll back). What more exactly do you expect out of a transaction? If the answer is *anything* my guess is that you're making the transaction, itself, way too complex.

  
  Also, most of us that use JavaSpaces regularly don't try to integrate a space with some Java EE system. We use it instead of Java EE because it simplifies things (we don't usually view the JavaSpace as the part that makes the integration complex). It may be a different way of thinking, but you can't possibly be arguing that standalone services that perform "put" and "take" under the umbrella of a transaction is a hard concept?

  
  And yes, we all work in "flows" and "use cases" but at some point, you have to have code to support it. And even though the paradigm is different, you rarely will code in a space.put() anywhere in your software. You'll be working with some 150 line abstraction class which caters specifically to having one service communicate with another. Training is not an issue. You'll spend all of your time writing services and will completely forget that there's jini and/or a space behind the scenes. Again, it may be a different way of thinking, but it's certainly not hard.

  
  I'll give you that some of the stock documentation is a bit lacking. But as with any community-based project, they came to the rescue with plenty of helpful things to get you started:

  http://dancres.org/cottage/starting_jini.html

  
  And in the instance of Blitz, you can use Dan's installer to create a fully functional Jini setup in about 18 seconds (literally). Also the Jini-Users list is a great source for any documentation or help you may need to find.

  
  So frankly, the reason that you don't hear much about Jini these days is simply because Java EE is the mainstream technology and we're mostly the types of people that stick to what's comfortable. And any time you ask why Jini isn't more popular, you're going to get responses like "well it's too different and hard" which warrants a similar response to the thought that "you shouldn't write your code in Java because it's slow." So basically a lot of people dismiss it without knowing really what it is and what it's capable of... which is fine as long as they're not trying to disuade others from using it.

  Posted by: robsignorelli on January 29, 2007 at 01:43 PM

• @vprise - No marketing? Your recollection is somewhat different from mine - Wikipedia is hardly definitive but checkout http://en.wikipedia.org/wiki/Enterprise_Java_Bean#History. It would be interesting to consult the internet archive as well to look at the websites of IBM and Sun but it's down right now.

  "It didn't have the Java EE features, the concept of a transaction in JavaSpaces was overly simplified and lacked "basic" ideas that Java EE had forever"

  Simplified? In what way? The transaction model for Jini is distributed two-phase commit whereas the early transaction model for EJB was based on nothing more than a thin wrapping around SQL-level transactions. Further, given JavaSpaces simple API, how complex of a transaction would you want anyway?

  "No need. Most of what we do as developers is web/AJAX with a database backend. Maybe a fat client to some reasonably complex backend logic. Sure this logic can fit into JavaSpaces, but whats the benefit?"

  How about, easier deployment, simple upgrading on the fly with no interruption, no need for a myriad of containers or expensive database licenses, or perhaps you'd like the ability to run across lots of blades without needing heavyweight strictly controlled, expensive data-centre type environments.

  Consider also that the simple web/AJAX with a database backend architecture you mention is a lunch being rapidly eaten by Ruby, Rails and the LAMP crowd which suggests that J2EE might not be as good as we all think. Perhaps it's time to try something new?

  "Now you could argue about simplicity providing an advantage for JavaSpaces but that would be incorrect. JavaSpaces simplifies some things while keeping the complex portions of Java EE just as complex as they always were so you just get added complexity of JavaSpaces when you choose to go with it."

  You appear to be complaining that mixing JavaSpaces with J2EE is complex? Take two things, one that is very static, supports no movable code concepts and favours an all in one JVM model and the other which is dynamic, makes heavy use of movable code and favours a multiple JVM, multi-service model. Now mix those two things together - complex? You betcha but you just put yourself between two stools didn't you?

  Posted by: dancres on January 29, 2007 at 01:58 PM

• I think it's because most developers can't write decent concurrent apps, so a framework that requires concurrent design won't be widely used.

  Posted by: tball on January 29, 2007 at 03:27 PM

• EJB 1.0 had no marketing ... Yet it picked up steam and industry demand, IBM incorporated it into WebSphere .... From then on it became a hit.

  That is: IBM did the marketing. :-) EJBs were a joint effort by IBM and Sun. IBM manages most of the IT in world-wide banks and banks are somewhat used to deploy "heavy" systems. That's the explanation of the penetration of EJBs in the market. Yes, I'm saying that without IBM efforts, probably EJBs could have been a failure.

  Posted by: fabriziogiudici on January 29, 2007 at 03:59 PM

• "but sun had chained it to a commerical license and that was the beginning of an end"

  Yes. Correct answer.

  Actually, more that it was the end of the beginning (in that this move helped prevent it from gaining momentum). But I give you full points anyway.

  For extra credit you could also have mentioned that it was extremely difficult to set up.

  Jini + Javaspaces was (theoretically) much more awesome than EJB 1.0. Nowdays however, there are some impressive alternatives.

  Being too expensive for small production projects and too time consuming to install and just have a play around with is a great way to kill a fledgling technology.

  Posted by: rickcarson on January 29, 2007 at 04:29 PM

• @rickcarson: "Being too expensive for small production projects and too time consuming to install and just have a play around with is a great way to kill a fledgling technology."

  Well maybe but it's still around and re: too time consuming to install and play, well:

  "And in the instance of Blitz, you can use Dan's installer to create a fully functional Jini setup in about 18 seconds (literally)."

  and

  "As it happens, Blitz JavaSpaces provides an installer that allows you to start up the relevant bits of Jini (lookup service, transaction manager, codebase server and JavaSpace) all with one script and all running in one JVM. How simple do you need it?"
  

  Posted by: dancres on January 29, 2007 at 05:18 PM

• EJB 1.0 didn't have any marketing, you can argue that IBM/WebLogic did the marketing indirectly but really there wasn't much. I am aware of only one book that covered EJB's at the time (Richard's book) and the spec was hell. The Wikipedia link doesn't contradict that, marketing of EJB's started roughly around the 1.1 timeline and was mostly because people were looking for a direct answer to MS's transaction server.
  
  Deployment of Jini isn't much easier than Java EE, in fact I would argue that Jini has won in a sense since practically all Java EE servers have picked an internal architecture that reminds us more of Jini than classic monolithic servers. JBoss was a trend setter when it chose a microkernel approach that delivers internally many of the ideas and even allows 3rd party developers to deploy such objects. Still few people bothered to check that out, possibly because of the non-standard API. Deployment is less related to the spec and more related to the product, since Java EE has a very wide choice of implementations I would argue its an easier deployment.

  When I discuss transactions I'm talking about a direct correlation to the TP monitors of the past, EJB's allowed a migration path from CORBA and TP monitors to a component model. I notice that when I talk with managers about an EE container they often think of it as a "block" that you can just plug in somewhat like a communication bus. This is obviously far from the truth but thats the perception, JavaSpaces/Jini is just very different and its integration with the legacy systems is at the very least confusing. If it does have native XA 2pc transactions since the very beginning not through Java EE then its just unclear. A couple of years ago I spoke at length with a high ranked official in a JavaSpaces vendor and I didn't understand that XA/2pc was indeed a feature inherent in Jini.

  I'm not arguing that put/take are hard to learn, I'm arguing that the concept of a space and the abstractness of the ideas is hard for some people to grasp. One of the hardest things for new Java EE developers is the fact that they can't use file IO to access data, they don't understand clustering and don't see why that is bad. Same problem holds in JavaSpaces but to a bigger extent, the flow is not as linear and abstractions make some concepts hard. I never argued the fact that when you would write a pure application using only Jini it would be simpler than the Java EE equivalent.

  The success of Spring/IoC and lightweight servers pretty much proves that it is not marketing or the lack of desire to learn new things that has stopped Jini/JavaSpaces from succeeding. After all people adopted some of the these frameworks with no marketing from Sun or anything of that sort, even the more complex aspects of these frameworks.

  Posted by: vprise on January 29, 2007 at 11:34 PM

• May be simply because not much people need parallel computation? And the one work on parallel computation already smart enough and not to ask too many questions in forums which make people think not much people using it?

  In fact, sound like most company need to do parallel computing already use javaspace? http://c24.biz/index.htm release a few white paper about using jini/javaspace with success

  Posted by: carfield on January 29, 2007 at 11:39 PM

• @vprise: "The success of Spring/IoC and lightweight servers pretty much proves that it is not marketing or the lack of desire to learn new things that has stopped Jini/JavaSpaces from succeeding. After all people adopted some of the these frameworks with no marketing from Sun or anything of that sort, even the more complex aspects of these frameworks."

  I disagree - the adoption of Spring and IoC says two things:

  (1) Most people like to imagine they are still writing their whole app in one JVM. All the wiring together of components without showing exceptions etc demonstrates this.

  (2) People are hot on wiring things together with endless flexibility options which they likely never exercise. And they like to do all that in XML because it makes them feel like they save code (a hot topic that also comes up in the endless language extension requests).

  Spring is just the current "integration platform" of choice rather than an app server.

  How much has changed really? A little of the implementation and a choice of product but the mental underpinnings are the same, single JVM, pretend there's no network etc. That's not change, that's mild evolution at best and does nothing in terms of a demonstration of willingness to try something truly new/different.

  Such a demonstration would require that we drop some of our favoured concepts (e.g. Containers, RDBMS, tiered architecture) in preference to some new ones.
  

  Posted by: dancres on January 30, 2007 at 03:07 AM

• @dancres: The question posed was, "Why is JavaSpaces not as successful as it should be." I've answered based on my own experience: that of an experienced Java developer who has worked with many concurrency architectures. I'm a fan of tuplespaces... even to the extent of promoting them in a book that I'm writing. I've used TSpaces and JavaSpaces.

  So, when I relate that I've found Jini to be a difficult technology to approach (obscure naming, outdated or misleading documentation, few books on the topic, little general knowledge in the community) with many moving parts (how many services was that again?) please understand that I am not some ignorant basher who is trashing your favorite technology.

  On a project recently, my team attempted to use JavaSpaces to provide distributed work queue management in small networks. We were going to have hundreds of far-flung networks. We wanted each to be self-discovering and configuring, resilient to single-node failures, and above all, require no administration. That sounds like exactly the prescription for JavaSpaces. Moreover, discovery sounded like a good application of Jini.

  We made a serious effort: an entire iteration spent on this architecture spike. At the end of it, we decided that we would not be able to keep our environments consistent, that startup and clean shutdown was a problem, and that we could not find a way to have the development workstations run their own virtual environments without crosstalk. Moreover, the QA and acceptance test environments would cross-talk into the individual development environments, making isolated testing impossible.

  It's quite likely that we simply didn't know enough about how to configure the environments. It's probable that someone much more intimate with the technology would be able to get better results. On the other hand, when you have eight developers with an average of 15 years experience, and all of them having at least 7 years of Java experience, and they can't get it to work reliably in two full weeks... then there's little chance of turning casual interest into successful pilots, into successful implementations.

  For the vast majority of developers, a technology has to be something they can pick up and get a modicum of results with in a single afternoon. Those don't have to be great results, but they should be able to get something to work.

  One of the reasons for the level of excitement about Ruby on Rails is the immediacy of positive feedback. Within a few minutes of installing Rails, you have a functional application. Changes are quick and the positive feedback keeps coming rapidly.

  There's an old adage that skills won hard are valued highly. It's totally true. That can also make those who worked hard to develop those skills insensitive to those who are still on the learning curve. (Read most Linux newsgroups for illustration.) The fact that you already know all the code names for the components speaks well of your expertise, but don't overlook the difficulty it presents for those who aren't at your level yet.
  

  Posted by: mtnygard on January 30, 2007 at 05:22 AM

• @dancres I don't think you disagree with me ;-)
  I don't like Spring personally, my only point was that people do pick up technologies that they want to use despite lack of marketing or corporate drive. I think Spring is a great example of that even though I agree with both of your points. So I personally think marketing had very little to do with Jini/JavaSpaces limited adoption.

  Posted by: vprise on January 30, 2007 at 06:02 AM

• @mtnygard: did you try to hire an expert Jini consultant just for the inception? I did my first Jini project three years ago, four people (at the time: two experienced persons, one near-senior and one junior), nobody of us has the least experience with Jini. We had the support of a senior consultant for a few days, and after these days we had the system working with Jini /+Rio). I mean, dancres is right when he's saying that Jini requires a different way to think, maybe we can agree that there are not tons of docs, but just a single good consultant can make the difference IMHO - sometimes the problem is just in starting up well.

  Moreover, the QA and acceptance test environments would cross-talk into the individual development environments, making isolated testing impossible.

  Can you further elaborate on this?

  Posted by: fabriziogiudici on January 30, 2007 at 06:04 AM

• ... nobody of us haD the least experience with Jini ...

  Posted by: fabriziogiudici on January 30, 2007 at 06:04 AM

• @mtnygard: "So, when I relate that I've found Jini to be a difficult technology to approach (obscure naming, outdated or misleading documentation, few books on the topic, little general knowledge in the community) with many moving parts (how many services was that again?) please understand that I am not some ignorant basher who is trashing your favorite technology."

  Errr, so your opinion of yourself is that you are not ignorant? Should I expect you to say anything else? If you're working in an unfamiliar technology, do you think you are the best judge of your ignorance?

  "It's quite likely that we simply didn't know enough about how to configure the environments. It's probable that someone much more intimate with the technology would be able to get better results. On the other hand, when you have eight developers with an average of 15 years experience, and all of them having at least 7 years of Java experience, and they can't get it to work reliably in two full weeks... then there's little chance of turning casual interest into successful pilots, into successful implementations."

  7 Years of Java experience - Java's a pretty big topic. Which API's and programming models? What tools are you used to? Much technical experience is only useful if it's applied in the areas it was derived from - there's only so much crossover to other new areas. And given that, how much of your experience do you really believe is applicable to Jini/JS?

  In respect of your segregation troubles between QA etc, it's achieved with groups which is documented in the specs (http://www.dancres.org/cottage/doc/specs/html/discovery-spec.html).

  I certainly understand that you mightn't have looked there straight off and perhaps we need a FAQ for that but note in the list of specs (http://www.dancres.org/cottage/doc/spec-index.html), it's right at the top and only a couple of sections in. I've just done a search of the JINI-USERS archives and open-subscriber for "nygard" and can see no postings. Did you ask how to do this on the list?

  "One of the reasons for the level of excitement about Ruby on Rails is the immediacy of positive feedback. Within a few minutes of installing Rails, you have a functional application. Changes are quick and the positive feedback keeps coming rapidly."

  Instant gratification - much has been written about the merits (or not) of that. In respect of RoR giving you instant results, might it be because it contains a bunch of familiar concepts and tech that you're used to using and it's designed to work on one or maybe a couple of boxes? Jini is naturally about lots of boxes and therefore has different constraints and needs. That's the nature of true distributed systems. Regardless, as has been mentioned several times here and elsewhere (http://www.theserverside.com/tt/articles/article.tss?l=UsingJavaSpaces) there are other options such as the Blitz installer that will help with that.

  "There's an old adage that skills won hard are valued highly. It's totally true. That can also make those who worked hard to develop those skills insensitive to those who are still on the learning curve. (Read most Linux newsgroups for illustration.) The fact that you already know all the code names for the components speaks well of your expertise, but don't overlook the difficulty it presents for those who aren't at your level yet."

  You're making an awful lot of assumptions about my mindset. I am very aware of how hard running up learning curves is which is evidenced by the time I spend discussing things with people such as yourself, posting articles, writing up tutorials, blogging and commenting on other's blogs, consulting and so on. In fact, if you talk to people about me, they'll tell you I won the 2004 Jini Contributors award for amongst other things, my dedication to helping out newbies.

  I'd like to help out but I'm not sure how much use that will be cos my mentors nose is twitching and saying you're too angry right now and not yet ready to move beyond a subjective debate.
  

  Posted by: dancres on January 30, 2007 at 06:31 AM

• @vprise: "@dancres I don't think you disagree with me ;-)
  I don't like Spring personally, my only point was that people do pick up technologies that they want to use despite lack of marketing or corporate drive. I think Spring is a great example of that even though I agree with both of your points. So I personally think marketing had very little to do with Jini/JavaSpaces limited adoption."

  :) There were certainly a myriad or reasons for limited adoption but personally the devices thing is an objection I've heard a whole hell of a lot, though less so recently. Regardless, we each have our opinions and I'm happy for them to differ - variety is the spice of life.
  

  Posted by: dancres on January 30, 2007 at 06:35 AM

• @Dan - I think that technologies and products also need to take advantage of the "network effect". While JINI has a broad range of problems that it can potentially be used to solve, and Javaspaces has a broad range of problems that it can potentially be used to solve, they have (IMHO :-) been largely isolated from the larger body of work occurring in the industry, in terms of application frameworks, IoC/DI frameworks, web frameworks, application servers, etc. The net result is that JINI has remained "pure" but "aloof", and hence largely un-used. My comment is not intended to be either positive or negative, but simply explanatory in nature. With the new licensing terms available on JINI, we are now looking at specific places that we can use JINI to help our customers solve real problems, which _will_ naturally have a network effect due to the thousands of production applications using our Tangosol Coherence software today.

  Peace,

  Cameron Purdy
  Tangosol Coherence: The Java Data Grid

  Posted by: cpurdy on January 30, 2007 at 11:27 AM

• @Cameron: "@Dan - I think that technologies and products also need to take advantage of the "network effect". While JINI has a broad range of problems that it can potentially be used to solve, and Javaspaces has a broad range of problems that it can potentially be used to solve, they have (IMHO :-) been largely isolated from the larger body of work occurring in the industry, in terms of application frameworks, IoC/DI frameworks, web frameworks, application servers, etc. The net result is that JINI has remained "pure" but "aloof", and hence largely un-used. My comment is not intended to be either positive or negative, but simply explanatory in nature. With the new licensing terms available on JINI, we are now looking at specific places that we can use JINI to help our customers solve real problems, which _will_ naturally have a network effect due to the thousands of production applications using our Tangosol Coherence software today."

  I agree re: the network effect needing exploiting. There are of course, multiple reasons why it hasn't happened but there's one that gets run into over and over which is the conflicting requirements in respect of classloader's/classloading. Whilst the problem itself is well understood, hacks/fixes are difficult because many a container doesn't expose the necessary innards. I have had success with GlassFish and Jetty and someone else has got things working on Tomcat.

  On licensing, it's a moot point but the licensing has been Apache V2 for some time whcih would allow Tangosol to get their hands dirty, I guess the big difference from your perspective is that Jini/Apache River is now in "neutral hands" which maybe makes the difference?
  

  Posted by: dancres on January 31, 2007 at 03:15 AM

• After many years working in the industry, solving distributed
  computing problems, sometimes from the ground up, I find this
  discussion to be quite intriguing.

  I agree that Javaspaces and Jini have not had the marketing and press
  coverage that they deserved, and in many cases they were shelved by
  many technologists as new technologies of interest, but not ready for
  prime time. I for one, was one of the people that used to bash this
  technology because it was easy to do so.

  Well times have changed my friends, and the market is now educated
  and eager to adopt such technologies as part of their strategic build
  out of the distributed enterprise. Most folks that that we speak to
  today do not need the educational process that we had to go through
  in the previous years. What you are seeing is the market has realized
  that through the adoption of low cost compute units and fast
  networking, that concepts such as tuple spaces, proactive scalability
  and self healing networking are an essential ingredient of a truly
  enterprise ready distributed platform.

  At the end of the day it is not about the API, it is all about the
  qualities that the platform affords to the implementor, time to
  market, uniform architecture, performance and reliability. JavaSpaces
  is just a specification and outrigger is just an example
  implementation. Whilst Jini has been bashed for its complexity, there
  have been no notable offerings to solve mobility, discovery and
  location transparency available in a public domain.

  It is sad but admirable that the original work done in tuple spaces
  over twenty five years ago has finally found its time, we have been
  through databases, application servers, message buses, Corba, Com and
  now .NET, only to realize that the answer we were looking for to
  solve the distributed, transactional, scalable and portable
  architecture was under our noses all the time.

  Surprisingly enough there is a larger community of expertise
  available in this arena and there are a growing number of ISVs that
  are taking on and building teams in this discipline. The folks that
  adopted this technology in the early days are now reaping the rewards.

  Forget all the minutia surrounding the past history and the
  specifications and embrace it with ernest, the lucky ones who already
  have, do not normally shout about it as they realize they are on to a
  winner.

  Watch this space ( no pun intended )

  Posted by: stevewhite on February 04, 2007 at 02:47 AM

• I agree re: the network effect needing exploiting. There are of course, multiple reasons why it hasn't happened but there's one that gets run into over and over which is the conflicting requirements in respect of classloader's/classloading. Whilst the problem itself is well understood, hacks/fixes are difficult because many a container doesn't expose the necessary innards. I have had success with GlassFish and Jetty and someone else has got things working on Tomcat.

  
  sexe
  sexe
  sexe
  sexe
  sexe

  
  bondage
  blowjob
  blondeblaguesblagueblackblackbizarrebitebisexuelbisexual
  beurettebedbikini
  bebebeautybeachbdsmbbwbang_gangbang
  acrobatbaise
  babeavatarsavatarautoastuceassasiatiqueasian
  ares
  ad_awareanusantivirus_gratuitantivirusanimeanalamatriceamateuramateur
  amateur
  adultedivx_gratuitdivxdivxdirtydildodickdiaporamasdiaporama
  deep_throat
  cumshotcumculcreampiecouplecouplecouillecoquin
  code_jeu
  cockcochonclose_upcloneclitoriscinemacheatcharmechansons_gratuit
  chanson_gratuit
  chaleurcelebritecartooncartescartescartescartecartecarte
  busty
  bukkakebruneboybootyboobfilmsfilmsfilm_gratuitfilm_gratuitfilmfilm
  ffm
  fetishfetichismefetichefessefemmefemmefemmefemdomfellation
  fat
  famillefamilialefacialfacef_rallyeexoticexhibitionnisteetudianteethnic
  erotisme
  erotiqueserotiqueemuleemule_gratuitenfantenfantenculeremule_gratuitemoticonesemoticoneedonkeyecrans_de_veilleecran_de_veille
  ebony
  drunkdownloaddouble_penetrationiconehumourhumourhugehousewife
  hothoroscopeshoroscopehomosexuelhistoire
  hentaihardcorehardhandjobhairygrossegrosgratuitegratuitegratuitegratuitegratuitgratuitgratuitgratuitgrannygaygolfglory_holegirlgaygayfuckingfootjobfootball
  footfonds_d_ecranfond_d_ecranflashingfisting
  first_timefirefoxfingeringmilfmidgetmessenger_gratuitmessengermature
  maturemasturbationmassagemardi_gras
  mangamalemaidlogiciels_gratuitlogicielslogicielslogiciel_gratuitlogiciellogiciel
  lingerielimewirelesbiennelesbianlatinaslatinalatexkazaa_gratuitkazaajeux
  jeuxjeuxjeunejeujeu
  jeujapaneseinterracial
  indianimage_humourimageimageimageicqillusion
  piedphoto
  photophotophotopetitepenispartitionspartition
  paroles_gratuitparole_gratuitpantieoutdoororientalorgyorgieorgasmeoralnudistenudistnudenunoirenero_gratuitneronaughtynaturenaturalnakedmusiques_gratuitesmusique_gratuitemusic_gratuitemuremsn_gratuitmsn
  msn
  mp_gratuitmoviemorpheusmommodelsmodel
  mmfsexysexuellesex_gratuit
  sexe_gratuitsexe_gratuitsexesexesexesexsexschoolgirlsalope
  safarisadorousserimjobredheadrecettes
  recettesrecette
  recettereal_playerrasee
  pussypuffyprogrammeprivatepregnantpps_pptpornstarporno_gratuit
  porno_gratuitpornographiepornopornoporno
  porn_gratuitpornpoitrineplumperpipe
  pinkclip video xxx
  hot xxx gay
  sexe photo porno
  photo and sexe and gratuit
  sexe vieille mature
  rencontre sexe senior
  photo sexe black
  photo sexe homme nu
  sexe porno gratuit photo free
  jeu online gratuit sexe
  sexe extreme dilatation
  hot sexe to brazil
  film porno telecharger gratui
  extrait porno video amateur
  histoire de sexe gratuite
  film xxx forum rapidshare
  photo gratuit galerie tgp sexe
  video demo porno gratos
  video porno gratuit gros vagin
  galerie photo sexe gratuite
  video porno sex gratuit usa
  femme mature porno
  film xxx porno media player
  xxx bd
  sexe gay porno
  epilation sexe homme
  video de sexe extreme
  sexe ultra bizarre
  extrait video film porno
  porno jeu video
  video gratuite porno amateur
  photo gratuite xxx hymens vierge
  video sexe demo gratuite
  plus grand site porno francais
  photo femme sexe gratuit
  video sexe lesbienne gouine gratuit
  photo sexe amateur francais
  mature nylon porno
  humour sexe pps
  liste meilleur site porno mature
  beurette sexe avec voile
  porno asiatique
  black xxx mas
  elisa actrice porno
  sexe femme poilue photo gratuit france
  sex cul porno
  photo beurette sexe
  femme xxx rencon
  teacher sex xxx
  xxx mangas hentai sakura
  beurette sexe amateurt
  clip xxx gratuitt
  sexe mature hardt
  jeu porno shockwavet
  sky blog sexet
  video preview free xxxt
  free gay pornot
  video porno voir gratui san telechargement
  sexe rasee gratuitt
  video de sexe a telechargert
  porno gay transt
  xxx hard xxx videot
  video porno gratuit voirt
  telecharger comic xxxt
  sexe filmes livet
  voir extrait gratuit video porno sans abonnementt
  porno gratuit photot
  sexe et vieille femmet
  casting porno parist
  mini video pornot
  photo sexe amateur gratuit sans connexiont
  sexe homme hommet
  extrait film porno a telechargert
  extrait video sexe blogt
  disney porn xxxt
  gratuit amateur sexet
  hot young couple xxxt
  liste acteur pornot
  telechargement gratuit porno sexet
  webcam live xxxt
  extrait film porno femme soumiset
  cam live free sexet
  porno homme gay gratuitt
  video sexe gratuite femme muret
  photo porno amatricet
  gratuit sexe videot
  cul sexe pornot
  clip video gratuit sexe debutantt
  jouer au jeu pornot
  porno free videot
  pute arabe pornot
  vente film pornot
  larges extrait video porno gratuitt
  film xxx gayt
  sexe gratuit analt
  photo sexet
  sexe porno video gratuitt
  petits extrait video de sexe gratuitt
  photo porno gratuite femme blackt
  i love sexe skyblogt
  arabe pornot
  agnes photo gratuite sexe vieillet
  sexe porno cult
  metz sexe amatricet
  disney xxx sexet
  histoire porno d adot
  video amatrice cul xxxt
  video porno gratuite a visionnert
  sexe shop toulouset
  photo gratuit xxxt
  annuaire forum sexet
  mami salope xxxt
  sexe amateur hard gratuitt
  sexe hard photo gratuitet
  photo salope xxxt
  photo galerie cul latine porno start
  webcam sex adult pornot
  cam frog sexe freet
  comic xxxt
  live show audio sexet
  free sexe moviest
  humour sexe gratuitt
  sexe video freet
  sexe gratuit hard interracial asiant
  galerie porno gratuitt
  gay porno video demot
  actrice film pornot
  sexe gratuit et hardt
  sexe hard cradet
  yasmine and pornot
  video francaise de sexet
  film porno yasminet
  baiser lesbienne xxxt
  sexe xxx videot
  video clip sexe xxx porno gratuitt
  sexe asiatique spermet
  catalogue divx pornot
  pps image sexe sexyt
  extrait porno videot
  divx porno gratuitt
  yasmine lyon pornot
  film de sexe francaist
  jeu en ligne pornot
  sexe asiatique gros seint
  les photo porno du bresilt
  video porno gratist
  image porno simpsonst
  demo virtuelle film xxx gratuit sans connexiont
  sexe amateurt
  video xxx defemme mure gratuitt

  demo virtuelle film xxx
  actrice porno nu
  pps sexe perso
  perso sexe amateur
  sexe tres extreme
  jeu sexe en ligne gratuit
  sex porno film
  photo arabe porno
  video amateur porno
  spanking lesbienne sexe
  blog sur sexe
  free xxx galerie updated daily
  liste acteur porno
  photo sexe hard xxx
  galerie sexe porno
  xxx and gratuit
  mangas porno photo gratuite
  sexe xxx girls video
  porno arabe video
  luna sex porno photo video gratuit
  jennifer gargner sexy xxx
  photo de sex et porno
  photo gratuite de sexe de femme mature
  sexe anal extreme
  porno and gratui
  pps sexe diaporama
  photo porno anal
  xxx gay photo
  video webcam sexe
  pipe porno xxx
  porno video amateur
  star porno photo
  photo de gay porno gratuite
  professeur sexe xxx
  video porno et gratuit
  femme hentai xxx
  video adults xxx free
  hard xxx black gratuit
  extrait video porno gratuit
  porno black anal
  video asiatique et galerie sexe
  sexe amateur gratuit perso
  blog video amateur sexe
  clip film porno gratuit
  extrait free video xxx
  jeu sexe online
  xxx video
  amatrice sexe belge
  hentai xxx
  gay porno poilu gratuit
  video porno etudiante gratuite
  sexe asiatique gratuit video
  photo et dvd porno gratuit
  arabe hetero porno
  film mangas porno
  sexe hot mom
  image porno gratuite
  video porno africaine
  porno gratuit ejaculation anal
  photo video sexe amateur gratuit
  clip porno lesbienne
  sexe crade jpeg
  couple video sexe
  sexe hardcore gratuit extrait
  sexe nu photo
  sexe porno mangas
  devenir actrice porno
  film x gay porno
  dvd sexe lesbienne
  forum sexe amateur
  grosse marocaine beurette sexe
  porno tres mature
  cam and sexe
  sexe image sexe
  forum de discussion sur le sexe
  animation video porno gratuite
  sexe hardcore film
  xxx video movie
  girls sucking men porno video
  demo porno gratuite
  clip de film porno
  sexe entre femme et homme
  porno gay maroc
  telechargement video porno amateur gratuit
  sexe gratuit porno
  couple libertin sexe photo
  blog porno perso
  photo porno et video gratuite
  blonde xxx
  sexe extreme allemand
  sexe ala cam
  image de film porno
  femme mure sexe tres poilu gratuit
  video hard xxx
  clip and video and de and sex
  deviant clip xxx
  dvd xxx gay
  free live sexe
  image porno d homosexuel
  amatrice et sexe et free
  bulle actrice porno
  video ultra hard sexe gratuite
  extrait amateur porno gratuit
  lesbienne porno francaise
  rencontre sexe
  porno gay amateur gratuit
  ado xxx sexe video
  annuaire sexe exhibitionniste
  blog film porno
  histoire porno bas masque
  skyblog paris hilton sexe
  photo sexe amateur contribution gratuite
  sexe avec amateur
  film sexe hard
  sexe amateur gratuis
  video sexe preview hard gratuit amateur perso
  sexe bien poilu
  black girls xxx
  clip sexe gay
  free xxx porn
  sexe black gay gratuit
  sexe star video photo gratuit
  photo and porno and gratis
  mature porno
  xxx totalement gratuit
  sex xxx hard photo gratuit
  xxx shannen doherty video free
  photo sexe masculin
  muscle men xxx hard
  sexe amateur extrait gratuit
  photo sexe homme nu
  demo video sexe gratuit
  sexe photo femme
  video de star xxx
  annuaire de sexe totalement gratuit
  top sexe fr
  sexe mature and boy
  galerie photo et sexe
  pin up toon xxx
  xxx anal sexe pictures
  extrait video sexe grtuit
  video jeune sexe
  photo porno couple gratuit
  sexe xxx trans
  arabe sexe gay
  sexe gay gratuit etranger
  porno gratuit amateur
  annuaire porno couple jeune
  femme sexe video
  xxx porn movies
  xxx extrait transexe
  sexe nipples porno
  lesbienne sexe bite
  pps sexy porno sexe
  photo porno star
  blonde xxx gratuit
  sexe web cam tout gratuit
  porno amateur.x gratuis
  film de porno a telecharge gratuit
  anal porno movies
  sexe video anal
  extrait video xxx son image gratuit
  sexe image
  gratuit xxx pic photo
  download free movies porno mpeg
  video sexe porno gratuit
  image porno gratuit
  free black porno picture
  video porno des star de cinema
  sexe vieille
  free anal porno
  chat cam sexe gratuit
  photo gay sexe
  rencontre sexe vendee
  sexe vieille pute
  jeu java sexe
  lolita tgp xxx gratuit
  actrice porno asiatique
  xxx clip free
  photo xxx gratos
  sexe femme noir
  sexe avec femme mure
  archive sex xxx video
  star photo sexe
  sex lolita xxx
  histoire sexe homme nu
  porno actrice
  femme experimentees sexe anal
  sexe video extreme
  video perso porno amateur
  free sample video porno
  web cam gratuite de sexe
  photo professeur xxx
  sex free porno
  extrait film porno vieille femme
  azzedine acteur porno
  photo sexe bizarre
  sexe mgp clip
  jeu sexe gratuis
  road sexe
  photo porno de naine
  photo porno de naine
  anal sexe video
  hard sexe photo gratuite
  sexe tres crade
  video sexe gratuit sans telechargement
  gay porno gratuit perso
  film et photo porno
  video porno femme mure pauline
  sexe rencontre amateur
  xxx movies jenna
  mangas gratuit sexe
  jeu and de and sexe and gratuit
  telechargement gratuit film porno
  photo porno femme black banlieue
  sexe film x gratuit marre faux site
  histoire sexe cocu
  chatte star sexe
  video gay porno extrait gratuit
  film porno gratuit anderson
  mangas and sexe and hentai and extrait and gratuit
  hard sexe porno
  jeu porno sans inscription
  video xxx sur vieille zt vieux bourgeois

  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  sexe
  <a href="http://minisexe.creablog.com/note_video_gratuite_sex_porno_sexe_gros_plan_vids_so

  Posted by: manuloc on May 29, 2007 at 01:19 AM

This work is licensed under a Creative Commons License.