Everyone I talk to who knows (knew) about it claims it was the greatest thing since sliced bread. Why did it fail? Or, if it didn't fail, who's using it now?
Check out GigaSpaces. It's a quite successful Jini/Javaspaces implementation.
I think Jini has a great model, but it is stuck with Java. Web-services is more appealing because it works with standarized protocols, even though Jini service discovery is more natural.
Things have definitely quited down for the idea. Which is strange since you'd think its goals are even more relevant now.
http://www.jini.org/wiki/Category:News
old question, but JINI was given to Apache and became Apache River project. However, that project is now retired.
Zeroconf and other discovery protocols are similarly referred to as the greatest thing since sliced bread; it's just that the flavor keeps changing.
My two cents... Jini was/is nice, but I think it tried to be a Java-centric CORBA back in the day when corporations were beginning to be reluctant regarding paying the big bucks for what CORBA brought to the table. WS-* specs began to acquire the "accepted-solution" mind-share in the industry. I think there was a small window where Jini could have grabbed substantial market share, but it never happened. Sun wanted too much money for what Jini brought to the table compared to other alternatives. I would love to hear from folks that disagree! My opinion is that Jini is sound tech, but business-wise has no future in the enterprise. It may find a niche elsewhere, depending on what Oracle decides to do with it.
Jini was an amazing technology. The only reason pushed EJB systems was that it allowed Sun to sell more hardware as EJB ran best on highpowered machines (due to shared state and database access). At the time (1999) Jini allowed much better scalability which ran well on commodity hardware, so it made sense for Sun to not promote Jini. Its a shame as I kept wondering when someone would release an Open Source easy to use Jini server like JBoss did with J2EE. I did however save companies alot of time and money by using the Jini techniques (based on Linda TupleSpaces) and applying them to writing software systems by using Tuple Spaces implemented in other ways.
The jewel in the crown of Jini was it's JavaSpaces service IMO. Sad that Sun seem to have abandoned it. It still exists as Apache River, but is now retired.
Related
We are currently using MICO to establish the communication between a server and a client, where the client is a simulator written in C++ and the server is a java program displaying an animation of what happens in the simulation. It seems that the developemt of MICO has slowed down to an almost halt and bugs that only allow us to hack around them (as we don't have the time to first figure out which parts of MICO are responsible for codegeneration and so on) keep us from making real progress.
So, does any one of you know of a good drop-in replacement? We would like to have the following:
The compiler can generate both C++ and Java-Code from the idl.
The project should still show considerable support.
The implementation should be open-sourced (GPL or BSD, or something alike), as we use our programs to teach students as well.
The migration from MICO should be as easy as possible. (This is not a hard requirement, but would be a good thing)
I found some other CORBA implementations, e.g. TAO, but I didn't find any of which I could
say that they are still supported. Correct me if I am wrong here.
The Free CORBA® Downloads page might be of interest to you.
Just naming:
orbit2 1, also pyorbit etc.
omniORB
TAO (has already been mentioned)
1 On my Ubuntu box, apt-rdepends -r liborbit2 returns 5530 lines...
I don't know where CORBA or MICO in particular has gone in the last 5 years, but back then a drop in replacement was not really possible, since differences between vendors where still there.
Not necessarily API differences (POA, etc.) but
in implementation behavior,
in custom extensions which were required to make it work in a real-world environment (threading, load balancing, security, etc.),
in how the development tools worked
and also about the whole deployment or runtime story.
We had Orbix ASP/2000/Whatever and ORBacus which were interchangeable having a small compatibility layer, some Makefile framework to hide differences in tools (e.g. the IDL compiler) and some scripts for wrapping ORB specific processes.
Unfortunately, ORBacus has long been bought by (then) IONA, which already make Orbix. IONA itself has been bought by someone else (I forgot). The original authors of ORBacus, plus some devs from IONA Orbix, changed their ways somewhat and produced Ice, which is not CORBA but somewhat alike - of course without the glitches ;-)
Concerning TOA, I think it would be the "best" choice concerning still being developed as it is driven by research on the Washington University. But last time I looked, they didn't have Java implementation but people seemed to use JacORB.
Maybe all this helps you little, unless it brings even more confusion :-)
TAO as C++ ORB is still actively supported and developed (see http://www.cs.wustl.edu/~schmidt/commercial-support.html). For Java I would propose JacORB.
On http://www.orbzone.org there is an overview of available corba implementations.
Two Java programs have to communicate with each other, To do that I found two possibilities
Using Sockets
Using JavaSpaces
After looking into the description, I found out, that JavaSpaces is apparently the better solution. Sadly, I can't get it to run. Ever totourial roots me to another installation process, to other files and so on.... :(
How to install JavaSpaces, where to download them etc?
If someone offers me a better solution for it I'll be thankful to (JavaSpaces seems to be from 2005)
this are the websites I found so far:
http://www.jroller.com/matsh/entry/intreagued_by_javaspaces_try_blitz
(Installation description, not working...)
http://www.jini.org/wiki/Main_Page
(Download links are broken)
http://www.jarvana.com/jarvana/inspect/com/sun/jini/jini-starterkit/2.1/jini-starterkit-2.1.zip?folder=jini2_1/
(Download of jini starter kit)
For one quick start using GigaSpaces, a commercial JavaSpaces product (with a community edition available), see http://www.gigaspaces.com/wiki/display/XAP8/Data+Grid+Quick+Start
Also see http://replay.waybackmachine.org/20070202031207/http://www.theserverside.com/tt/articles/article.tss%3Fl%3DUsingJavaSpaces and http://www.theserverside.com/news/thread.tss?thread_id=42164 and http://www.enigmastation.com/?page_id=425
JavaSpaces is great, IMO (I'm biased, as I work for GigaSpaces... but then again, I work for GigaSpaces because I think the underlying technology is great.) - it's got a very simple API but the transaction model is actually pretty strong, and it's very fast. It's simpler and stronger than JMS, and has a simpler deployment/connection model.
If you're GigaSpaces-averse for some reason ("yikes, someone makes money from this") you can look into Blitz as well.
In Feb 2009 another user on SO mentioned, that GigaSpaces is a mature version of JavaSpaces.
Looking at that older question, I start believing that JavaSpaces is dead..!?
Have you considered also using something like RMI where it becomes transparent the fact that you are invoking a method on a remote system?
Or JMS where you just send and read messages -- and the infrastructure routes them to the right place/process?
Or how about another approach where you have a network cache (e.g. memcached) where both processes can put and get items to/from the cache -- thus allowing for inter-process communication to a certain extent?
It seems that JINI is pretty much an abandoned project. The latest release from the Jini.org site is from last year, and there has been no news since then.
JINI appears to be very useful to provide services in a completely distributed minor. What happened to this technology? Also what has replaced this technology?
The thread that I linked to claims that web services have replaced this technology. However, web services are strictly a client and server setup, not meant for dynamic distribution for jobs. [It can but it doesn't have the framework to do this] I find it difficult to believe that this technology just disappeared due to a lack of need.
Jini didn't fail due to a lack of need. There were problems with:
oppressive licensing when it was first released
all-Java solution based on RMI
complexity
By the time the licensing was sorted out it was too late. The moment had passed.
It's a brilliant idea, and Bill Joy's a genius, but like a lot of great technologies it simply didn't catch on. The marketplace didn't adopt it.
Jini didn't disappear. As you've noted, it's still available. The adoption rate hasn't been high because it isn't scratching anybody's itch.
From what I see the last Jini release actually was in October 2005 (Check here). What you maybe referring to is the news entry for the Rio project on the jini.org site I guess.
The wikipedia page on Jini tells us
Originally developed by Sun,
responsibility for Jini is being
transferred to Apache under the
project name "River"
The latest release for Apache River (2.2.1) is from last year. There still seems to be some activity on the svn repository. So maybe not completely dead but also not very much alive too.
Web services becoming synonymous with SOA killed the buzz for Jini. Although Jini probably was a better fit for distributed computing as well as SOA at a intra-company/enterprise level, web services and the (highly misused) XML integration was pushed by the major software providers, primarily IBM. Of all the derivatives of RMI/Jini, Javaspaces seems to have survived somewhat. Rio was certainly a early version of Cloud computing, especially when it came to dynamic provisioning. I even wonder what happened to the promise of JXTA and its co-existence with Jini.
I guess radio killed the TV star in this case :(
I believe that this technology just disappeared due to a lack of need. On the simple end, web services take care of distributed needs. On the high performance end, clustering and networking with lower overhead takes care of most needs.
One chapter in Pragmatic Programmer recommends looking at a blackboard/space-based architecture + a rules engine as a more flexible alternative to a traditional workflow system.
The project I'm working on currently uses a workflow engine, but I'd like to evaluate alternatives. I really feel like a SBA would be a better solution to our business problems, but I'm worried about a total lack of community support/user base/venders/options.
JavaSpaces is dead, and the JINI spin-off Apache River seems to be on life support. SemiSpace looks perfect, but it's a one-man show. The only viable solution seems to be GigaSpaces.
I'd like to hear your thoughts on space based architecture and any experiences you've had with real world implementations.
Why do you regard Javaspaces as dead, beyond the fact that the Jini 2.1 release was some time ago (October 2005) ? Having used that, I'd suggest that it indicates a mature and complete technology set rather than something abandoned and defunct.
For another implementation of Javaspaces, take a look at Blitz Javaspaces. That's maintained and enhanced more regularly (latest release July 2008) and offers a more performant and manageable Javaspace implementation than the default outrigger supplied by Sun.
Gigaspaces is a successful commercial implementation of JavaSpaces -- so, I wouldn't say JavaSpaces is dead.
You might take a look at Java Shared Data Toolkit (also this article) to see if it meets your requirements.
Space-based architecture is a distributed-computing architecture for achieving linear scalability of stateful, high-performance applications using the tuple space paradigm With a space-based architecture, applications are built out of a set of self-sufficient units, known as processing-units.
Ex: Gigaspaces
here I attached the reference for gigaspaces.
https://docs.gigaspaces.com/latest/overview/space-based-architecture.html
While it doesn't support the JavaSpaces API, I'd suggest looking at Oracle Coherence for a distributed and reliable "live" data store that can drive event-based workflow. Deutsche Bank, for example, successfully replaced a "SBA" (Space Based Architecture) with an event-driven system built on Coherence for their FX trading, because of both reliability and performance issues.
For the sake of full disclosure, I work at Oracle. The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
Does anybody have experience using the open source offering from Terracotta as opposed to their enterprise offering? Specifically, I'm interested if it is worth the effort to use terracotta without the enterprise tools to manage your cluster?
Over-simplified usage summary: we're a small startup with limited budget that needs to process millions of records and scale for hundreds-of-thousands of page views per day.
I am in a process of integrating Terracotta with my project (a sensor node network simulator). About three weeks ago I found out about Terracotta from one of my colleagues. And now my application takes advantage of grid computing using Terracotta. Below I summarized some essential points of my experience with Terracotta.
The Terracotta site contains pretty detailed documentation. This article probably a good starting point for a developer Concept and Architecture Guide
When you are stuck with a problem and found no answer in the documentation, the Terracotta community forum is a good place to ask questions. It seems that Terracotta developers check it on a regular basis and pretty responsive.
Even though Terracotta is running under JVM and it is advertised that it is only a matter of configuration to make you application running in a cluster, you should be ready that it may require to introduce some serious changes in you application to make it perform reasonably well. E.g. I had to completely rewrite synchronization logic of my application.
Good integration with Eclipse.
Admin Console is a great tool and it helped me a lot in tweaking my application to perform decently under Terracotta. It collects all performance metrics from servers and clients you can only think of. It certainly has some GUI related issues, but who does not :-)
Prefer standard Java Synchronization primitives (synchronized/wait/notify) over java.util.concurrent.* citizens. I found that standard primitives provide higher flexibility (can be configured to be a read or write cluster lock or even not-a-lock at all), easier to track in the Admin Console (you see the class name of the object being locked rather then e.g. some ReentrantLock).
Hope that helps.
At the moment, the Terracotta enterprise tools provide only a few features beyond the open source version around things like visualization and management (like the ability to kick a client out of the cluster). That will continue to diverge and the enterprise tools are likely to boast more operator-level functionality around things like managing and monitoring, but you can certainly manage and tune an app even with the open source tools.
The enterprise license also gives you things like support, indemnification, etc which may or may not be as important to you as the tooling.
I would urge you to try it for yourself. If you'd like to see an example of a real app using Terracotta, you should check out this reference web app that was just released:
The Examinator
You may want to take a look at JBossCache/PojoCache which is an in-memory distributed caching solution. The difference is it uses a simple API to propagate objects across your 'cluster' of caches, where as Terracotta works at the classloading/jvm level.
(They don't actually have their own JVM, but they modify classes as they are loaded to allow them to be 'clusterable')
Our company had a lot of luck with JBossCache, I'd recommend checking it out.
Update
What I see in the OP message is "well, I don't really know what we need (thus the lack of detailed requirements), but may be some enterprizey tool will magically solve all our problems, known and unforeseen? That would be awesome!"
With an architectural approach like this it's not gonna fly. No success stories from Teracotta would change that.
OSS is beneficial when the community around it can replace the commercial support. Suppose the guy have a problem in production. Community cannot help -- it's too small for the obscure product like this. Servers are down, business is in danger. You see? You need a commercial license up-front. No money? Well, then you're not a business, and probably not gonna become one (if nobody's willing to invest into it).
Sorry for interrupting your day-dreaming.
IMHO:
Terracotta is a clustering solution. Clustering is required for large, enterprise-grade applications. Large applications mean big budgets. Big budgets mean you can afford commercial license from Terracotta.
To put it in another way: if you don't have budget to buy it, it's probably not beneficial for your project.