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.
Related
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?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am a long time Java developer on JBoss(and Tomcat). In the last year I had to develop over WebLogic and I have to say - I really miss JBoss.
Since my experience with WebLogic is pretty shallow, I am asking the more experienced guys out there:
Is there a reason for spending money on WebLogic?
Isn't JBoss giving you all that you need?
I suspect the reason Weblogic gets chosen is a pleasant sales person comes to visit a manager with money to spend, gives him the sales pitch and hey-presto, the company is using Weblogic. I don't know if the JBoss support contract comes with a sales force, but would be surprised if it did and that the playing field has leveled in that respect.
In my experience, other than the pretty console you get with Weblogic (which isn't worth forking out the license fees for) there's not much between the 2. I suspect these days JBoss has market share (just guessing that), which in my book that translates into more help available online, etc when you're stuck on something.
It's also worth considering that the Weblogic licenses (last time I saw them) where the usual server-side terms - per-processor, per-box, etc. This will limit you in scalability terms because with JBoss you can keep adding hardware without occurring extra cost, while with Weblogic your licenses will need upgrading too.
Whichever you choose you're going to be able to build your system on top of them without too much trouble, but my preference would be JBoss.
I really like WebLogic. I'll suspend the licensing cost for the moment and just say that in their heyday they were the best Java EE app server on the market, hands down. BEA had a lot of extremely talented people developing their code, and it showed. If money was not part of the equation, and I had an employer that insisted on spending money that wasn't mine, I'd still choose WebLogic over WebSphere or JBOSS or Glassfish or anything else on the market.
I'm saddened by Oracle's purchase. I think that the talent has leaked away, and Oracle has no clear idea of what they want to do with WebLogic. They've been stuck on version 10.1 for a few years now.
<prejudice-ahead>
Glassfish sounds like it's a much better effort from Sun, but their history says they write great standards and lousy implementations. I don't consider Glassfish to be a viable alternative.
</prejudice-ahead>
WebSphere is a typical IBM project: twice the cost, half the functionality, poor documentation, and you have to buy all their nonsense (e.g., Eclipse based IDEs) to use it.
JBOSS isn't bad, but only because the price difference is so strongly in its favor.
I'd rather recommend Spring, Tomcat and ActiveMQ as an excellent alternative. If EJBs are absolutely required, add OpenEJB to that mix.
2018 update: My affection for Java EE as a standard and its app server implementations has cooled in the last nine years. I think a better answer is to go with Spring Boot. Deploy an executable JAR on a JVM and never worry about a Java EE app server again.
I'm saddened by Oracle's purchase. I
think that the talent has leaked away,
and Oracle has no clear idea of what
they want to do with WebLogic. They've
been stuck on version 10.1 for a few
years now.
There are a couple of problems with the above comment. First, Oracle only purchased BEA 1.5 years ago, and even then that wasn't a DOJ approved transaction. The final sale was not approved until something like 12 months ago.
Secondly, Oracle has made three releases of WebLogic since acquisition. They are now on version 10.3.1 (or "11g").
Lastly, I think Oracle is - surprised to say that I am - moving in a clear direction. With the recent acquisition of Sun, Oracle is now the primary provider of Java technology and has what many consider to be the leading Java application server. They would not have invested in these companies and technologies without a clear plan to dominate the market. I think Oracle's recent movements in the Java EE 6, WebLogic, and JDeveloper spaces show that they are pushing extremely hard to become the Java leader.
I'd still prefer JBoss; it's simple and just works. I'm having loads of problems converting a Seam 2.x app from JBoss to Weblogic, but I'm hopeful that I will be successful at some point.
Personally I would choose JBoss (community version) over Weblogic (Server) because it's free (you know, like in freedom). But that isn't answering the question, so...
I can see two main reasons for choosing Weblogic:
Weblogic is a well integrated product with a single configuration mechanism/file (easier* to configure and maintain).
Integration with Tuxedo.
*) The term easier is subjective. Most things are easy when you know how to do them.
I've done 3 evaluations of WebLogic, JBoss, and WebSphere. WebLogic won every one of them, hands down. Having said that, my simplistic guidance is this: use JBoss if you are NOT worried about scaling past several thousand concurrent users. However, if you intend to scale beyond that, you're going to need something with proven horsepower and robustness - that's WebLogic.
Note: app server vendors generally sacrifice technical features for stability. In other words, robustness is in dynamic tension with technical features. If you want new features, you get more bugs along with it. It surprises me how many technicians don't get that. But, if you think about why you don't rush out and buy the first new Windows OS version when it comes out, you'll understand perfectly why this is so.
HTH
I had worked on jboss for a year and on weblogic for more than a year now, my experience with the web logic is good compared to jboss as weblogic is more stable and robust, it can handle more than 3000 concurrent requests without throwing a single exception where jboss failed to do so and admin console for the weblogic is excellent, but I think weblogic is more complex then jboss. As far as client is investing money on application server, my choice will be weblogic for sure.
Well, i'd recommend using Spring+Tomcat and would introduce a full-blown JavaEE Application server only if i absolutely have to.
regarding Weblogic and JBoss, i'd prefer JBoss as Weblogic is more complex.
I developed Java based application for JBoss 4.x and 5.x for two years. After that i had to work with Weblogic 11. It wasn't easy to change my mind but now i think, WL much better. More stable, faster and the Admin Console...like a dream..very easy to do settings and monitoring.
So, my choice is Weblogic.
I would think you guys should consider TC Server, its a variant of Tomcat from Vmware. Might be good in an enterprise environment, since most of them should be able to work it out, as part of there virtualization deals.
http://www.vmware.com/products/vfabric-tcserver/
PS - I have used WLS extensively. For some applications it might be good. For some you really do not need it. So its very much driven by use case, scale etc.
You need to consider the TCO Total Cost of Ownership
You must take into account these costs when using JBoss:
Annual support subscriptions
Higher on-going management and administration costs
Impact of outages on cost
Impact of product’s performance on cost
Higher cost for interoperability testing and integration of the disparate OSS projects
Complexity and cost of supporting an integrated OSS solution
Insurance policy for indemnity protection
Cost to support and maintain modified code
Extra time and effort to deal with a myriad of open source licenses
JBoss (Red Hat) has yet to release a commercially supported 100% Java EE 5-compliant container*. There is a beta of JBoss 5 out. Hopefully they won't be 3 years behind for Java EE 6.
JBoss is more concerned with their microcontainer than Java EE x because that's what they say their customers are more interested in. I have never met any of those customers. But it does mean that Java EE is a second-class citizen in their world. As proof, their containers don't even ship in compliant mode; you have to tweak some config files to make it spec-compliant.
If Sun wasn't about to be consumed by the blackhole that is Oracle, I would recommend Glassfish.
Red Hat does have a commercially supported 90% Java EE 5-compliant container. JBoss 4.3 is their "stepping stone" to Java EE 5 version.
It depends.
Do you happen to be in a company who likes to buy support from other companies like "Oracle" and don't really care about the money spending as long they are covered by the manufacturer ( Yes, I know Redhat sells the support also but some companies don't like to buy from them )
Anyway , this is a rather subjective question, I don't think there would be a correct answer.
IBM released their BETA version of Java EE 6 server. So in case of Java EE 6 I think IBM would be the leader. Also JBoss is a good server but under heavy loads my experience shows it's not fully reliable compared to WebLogic and WebSphere.
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.
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.