Terracotta DSO: Open Sourced

Discussions

News: Terracotta DSO: Open Sourced

  1. Terracotta DSO: Open Sourced (59 messages)

    Terracotta has announced that they are releasing their clustered VM technology, Terracotta DSO, under the Terracotta Public License, similar to the Mozilla Public License. Terracotta has already begun work with application server communities such as Geronimo and Glassfish to integrate DSO as a potential clustering option. From the press release:
    "Terracotta's move will have a tremendous and positive impact on the Java open source community. The Terracotta open source project has the potential of being one of the most meaningful Java open source projects," said Jeff Genender, CTO and Chief Architect of Savoir Technologies and active committer and Project Management Committee (PMC) member for Apache Geronimo. On the topic of deeper integration with Geronimo, Jeff said, "The decision to open source Terracotta using an Apache friendly license, allows for the potential of better integration between Geronimo and Terracotta, and good cooperation and interaction between the communities. It is completely feasible that Terracotta could become the clustering agent for Geronimo. I am very excited about open source Terracotta and am looking forward to making contributions to our integration."
    The Terracotta Public License requires that Terracotta be given visible credit for the clustering technology when it's embedded; a commercial license that doesn't carry this restriction is also available. (See the license for precise details.) Terracotta has started up a community site, http://www.terracotta.org/, where developers will be able to download the clustering code and get community support. Ari Zilka, speaking to TSS, said that this move was made for a number of reasons. Terracotta wishes for the technology to be beneficial for the entire Java community, and sees open sourcing it as a way of extending its reach and usability. Integration with Spring means that Spring users can nearly transparently cluster applications already; the open-sourcing of DSO means that other applications (including application servers) can leverage the technology as well. TSS asked about efforts already underway to embed clustering in servers such as Glassfish. Glassfish has a project underway to provide cluster support already, for example, and DSO might be seen as a "quick solution" for such clustering. However, Ari said that Terracotta had no intention or consideration of replacing or even competing with those efforts; DSO is offered simply as an alternative to existing clustering packages. DSO also does not replace functionality specified by JSR-88 (Java EE Application Deployment). DSO would only manage the distribution of requests and, potentially, application data of Java EE applications. Ari also reemphasized clustering POJOs, which has been discussed multiple times here on TSS. Open sourcing DSO means that anyone who can comply with the license can cluster a Map, for example, across multiple servers. This would make DSO much like JavaSpaces, except without the need for a set of interfaces and an external JavaSpace container. Clustered POJOs also make testing of clustering far easier, since a developer doesn't have to run DSO in order to test; his Map would work the same way on a clustered VM as it would on a non-clustered VM. It's important to emphasize that adding clustering via DSO isn't entirely transparent, although it can be in some cases. Geronimo, for example, had DSO embedded in "one day," Ari said, which isn't the same as 'no effort at all,' but to add functional clustering to an application server (including EJB clustering) in one day is impressive nonetheless. This is another entry in a wave of open sourced products, and an excellent contribution on the part of Terracotta.

    Threaded Messages (59)

  2. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Wow - this is fantastic news. These guys have a great product that deserves an audience. Releasing it as open-source will help others kick the tires and explore these technology without having to wait for a sales engineer to come in. It will also help adoption if a community grows around DSO and other Terracotta technologies that can nurture the product and its adoption. Congratulations, Ari, Iyer, Gino, and everyone else at Terracotta! After reading the press release and the license, there are a couple of things that I see as roadblocks. Selling an open-source product to a large corporation is hard because some of the troglodytes in upper management fear open-source because of their lack of understanding; some of those fears are perceived, some are real. Getting the legal department to review a given license may become a huge project in itself, and coming out of the gate with Yet Another License, even if the changes are minor, creates a hurdle because the legal department will want to review the whole thing anyway. The other issue (hopefully an oversight in the press release) is the lack of indemnification. Indemnification is a keyword that big corporations like when dealing with open-source software. What are Terracotta's thoughts in that direction? Congratulations again guys, and let me go to download the latest copy of DSO. Cheers, Eugene
  3. Re: Terracotta DSO: Open Sourced[ Go to top ]

    I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
  4. Re: Terracotta DSO: Open Sourced[ Go to top ]

    I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
    Or they are making an pre-emptive strike against people thinking about moving into their space.. Probably not a bad move if name-recognition and market-penetration are the goals.
  5. Re: Terracotta DSO: Open Sourced[ Go to top ]

    I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
    I think that's a little unfair to Terracotta. The product is very good; open sourcing it mainly lowers the barriers to places whose policy towards open source is more liberal than toward closed source, which might need internal criteria met.
  6. I think that's a little unfair to Terracotta. The product is very good; open sourcing it mainly lowers the barriers to places whose policy towards open source is more liberal than toward closed source, which might need internal criteria met.
    Why is that unfair? The product is certainly good but business-wise they sold out. It's not even challenger marketing against a market leader. -- Andreas
  7. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Hard maybe but not unfair. A significant part of the value of a company like Terracotta (or Tangosol) is in their protocols, algorithms, their intellectual property. One of the prime reasons for me considering such a product is that it is way cheaper for me to do that than to try and build it myself (if I could...). Going open source effectively makes that information public and thus the value is largely lost whatever the license may say. From where I am sitting you would not do that unless you had your back against the wall, well I certainly wouldn't anyway. Having said that, I wish the people at Terracotta good fortune for the future.
  8. Re: Terracotta DSO: Open Sourced[ Go to top ]

    ...A significant part of the value of a company like Terracotta (or Tangosol) is in their protocols, algorithms, their intellectual property. One of the prime reasons for me considering such a product is that it is way cheaper for me to do that than to try and build it myself (if I could...). Going open source effectively makes that information public and thus the value is largely lost whatever the license may say....
    You will have to understand and further evolve these algorithms, which means that it still can be cheaper for you to get support from the source...
  9. Re: Terracotta DSO: Open Sourced[ Go to top ]

    ...A significant part of the value of a company like Terracotta (or Tangosol) is in their protocols, algorithms, their intellectual property. One of the prime reasons for me considering such a product is that it is way cheaper for me to do that than to try and build it myself (if I could...). Going open source effectively makes that information public and thus the value is largely lost whatever the license may say....
    You will have to understand and further evolve these algorithms, which means that it still can be cheaper for you to get support from the source...
    Lets hope that they dont plan to stop evolving the product just because they open sourced it. Also, not quite sure if evolving algorithms is a typical support issue either? But I am a little bit curious about the "enterprise edition", is it the same software+support contract, or is there a enterprise edition software package with add-ons?
  10. Re: Terracotta DSO: Open Sourced[ Go to top ]

    But I am a little bit curious about the "enterprise edition", is it the same software+support contract, or is there a enterprise edition software package with add-ons?
    There is no difference in functionality with regards to the Open Source version. The only difference is the Terracotta Enterprise Edition includes professional support (5x12, 24x7), certified software patches and updates, support tools and perhaps discounted professional services and training. Terracotta Enterprise Edition also includes a license key manager to help facilitate managing software compliance. Cheers -- Iyer.
  11. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Hard maybe but not unfair. A significant part of the value of a company like Terracotta (or Tangosol) is in their protocols, algorithms, their intellectual property. One of the prime reasons for me considering such a product is that it is way cheaper for me to do that than to try and build it myself (if I could...).
    Wouldn't that be the case for something like JBoss also?
  12. I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
    I think that's a little unfair to Terracotta. The product is very good; open sourcing it mainly lowers the barriers to places whose policy towards open source is more liberal than toward closed source, which might need internal criteria met.
    I don't think it's unfair. I think the engineering idea is impressive, but unfortunately impressive does not equal great market penetration. It's not a reflection on the people who wrote TC. It will still be used by people who know what they are doing and who decide that this type of transparent clustering is perfect for their workload characteristics.
  13. Re: Terracotta DSO: Open Sourced[ Go to top ]

    I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
    Namely Coherence, I guess... For me this is the typical behavior of a VC-backed company. They want money, fast. If that (fast) doesn't work they throw everything out for less and hope for market penetration. To live from support? Dream on. -- Andreas
  14. Re: Terracotta DSO: Open Sourced[ Go to top ]

    I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
    Namely Coherence, I guess... For me this is the typical behavior of a VC-backed company. They want money, fast. If that (fast) doesn't work they throw everything out for less and hope for market penetration. To live from support? Dream on.
    While VCs can make a mess of a lot of things, they also have played an important role in our industry. A number of great companies (like Google) got their start from venture investment, and while the graveyard of VC-backed companies is huge, you have to look at it as a darwinian system in which all those companies (successes and failures alike) got a chance. Andreas, as you know from your own business, building a software company is difficult work. In Terracotta's case, they have a lot of work ahead of them to transition to a support business, but they have some VC cash to do it with, and others like JBoss have shown it can be done. And hey, you know that the VCs are looking at the JBoss sale and wanting a piece of _that_ action. This is a wise move for Terracotta, and good luck to them. And maybe this will make it easier for them to add support for Coherence now ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  15. Re: Terracotta for Coherence[ Go to top ]

    This is a wise move for Terracotta, and good luck to them. And maybe this will make it easier for them to add support for Coherence now ;-)
    Cameron, I have even better idea. Since it is open source, Tangosol can build such support (with little help from Terracotta) and deliver Terracotta's transparency to its own customers. ;-)
  16. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Eugene, Thanks for the words of encouragement - we're all psyched here at Terracotta. (I work as Terracotta's in-house counsel.) To answer your question about whether we offer indemnification: yes, we do. We have always offered indemnification to our customers and will continue to do so. Terracotta is now under a dual-license business model, and our commercial license includes complete, standard indemnification and warranty provisions. The open-source version of our software is licensed "as is," under a standard "Mozilla Public License + attribution" model. As for the issue of the license itself, we wanted to use a "tried and true" model, to make sure that the license review process was simple and quick for our users' legal departments, and for users themselves. So, we put a list of the few changes that we made to the MPL on our site at http://www.terracotta.org/confluence/display/orgsite/Description+of+Changes+from+the+MPL ) Thanks for the feedback. best, Tim
  17. Re: Terracotta DSO: Open Sourced[ Go to top ]

    questions, questions... Does open sourcing is the only way of getting out ? What is the first suggestion that comes out when a VC ask for $$ perspectives on a cloudy winter ? Clustering technology for everyone , for free ? Software licence for free at a time where Oracle or IBM are stronger than ever ? How to make clustering technology a commoditie, but what gains for Terracotta ? Necessary (mandatory?) first step to an acquisition? kind of a "we'are not aligned with our $100m business plan... so ...let's open source our code! and see how the market reacts ?" opinions... Terracotta guys.. welcome.. Stephan
  18. Re: Terracotta DSO: Open Sourced[ Go to top ]

    I would imagine they are doing this because they are not succeeding in getting sufficient market penetration against the market leaders.
    What market leaders? Are there more products like Terracotta DSO available? S.
  19. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Not in terms of how they achieve what Terracotta does, but there are other, and in my view better, ways of achieving the same end.
  20. Awesome[ Go to top ]

    This is awesome news! I've been secretly hoping for this and now Terracotta DSO is free. Small initial request though, would it be possible to also create a download package for MacOSX? Thanks!
  21. Re: Mac OS X[ Go to top ]

    Thanks Geert. For Terracotta on Mac, just : * download and untar the Linux kit * delete the JRE * set TC_JAVA_HOME to point to your Mac JRE * rebuild the Terracotta boot jar - invoke the bin/make-boot-jar.sh script Done.
  22. where is Terracotta JDBC[ Go to top ]

    congratulations on the move i think it 'll be a great move for the whole java comunity to have a such an offering as it is really a product with a real added value i think that when u begin the company u announced and marketed something called terracotta JDBC ,where it is now,did it retired or merged into DSO thanks
  23. There's a great presentation on Google Video by Ari Zilka, the founder of Terracotta. He talks in depth about how the DSO works and touches on the reasons for open sourcing it. http://video.google.com/videoplay?docid=7660457673499305140&q=Google+engEDU
  24. There's a great presentation on Google Video by Ari Zilka, the founder of Terracotta. He talks in depth about how the DSO works and touches on the reasons for open sourcing it. http://video.google.com/videoplay?docid=7660457673499305140&q=Google+engEDU
  25. actually my download manager cannot deal with https so please provide http or ftp mirror
  26. great news[ Go to top ]

    For those who haven't watched the google tech talk by Ari, I would suggest it. If I understand the approach correctly, it sounds pretty sweet. Does anyone know of another product which solves the object identity issue the similar to how Terracotta handles it? peter
  27. How the server to be clustered[ Go to top ]

    It's great job. However, how the Terracotta server be clustered or state sharing. Otherwise, the Terracotta server will be the point of failure in the backend.
  28. Re: How the server to be clustered[ Go to top ]

    Terracotta servers can be deployed as an active-Primary plus a passive-Secondary (i.e. 1 or numerous hot-standby(s)) - the hot-standby shares disk with the primary Terracotta Server. On failure of the primary, client-JVMs transparently connect to the standby. Other deployment architectures are possible as well. Check the deployment guide on the Open Terracotta site at http://www.terracotta.org/confluence/display/docs/Deployment+Guide Cheers
  29. Re: How the server to be clustered[ Go to top ]

    So the whole edifice depends on one server which will eventually become overloaded. And to have a hot backup it also has to persist everything to disk synchronously. Scaleability anyone?
  30. Re: How the server to be clustered[ Go to top ]

    Terracotta servers can be deployed as an active-Primary plus a passive-Secondary (i.e. 1 or numerous hot-standby(s)) - the hot-standby shares disk with the primary Terracotta Server. On failure of the primary, client-JVMs transparently connect to the standby.
    For reference, this is one of the primary differences betweent Terracotta clustering and Tangosol clustering. Terracotta can cluster two servers (one hot, one standby) while Tangosol can run a couple thousand servers as "hot" (active + active + active + etc) in an n-way fully-connected mesh (virtual channels). Our server throughput in a 100-server system is 50x that of a hot+hot 2-server system, and (in a fully switched fabric) our throughput in a 1000-server system is 10x that of a 100-server system. And failover time (automatic, without data loss or interruption of application flow) is still typically sub-second. Regarding the connections between the application servers and the Terracotta server, it is a TCP/IP client/server connection (no fundamental differences at the wire level from a Telnet session, JDBC connection or RMI). It is analogous to our free Data Client or our low-cost Real-Time Client. Speaking for me personally, I would evaluate plugging Terracotta in through the TCP/IP connectivity (ours, theirs, whatever), because Terracotta has focused on the programming model (AOP, Spring, etc.), and it could be a good addition for working with data in a Data Grid. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  31. Re: How the server to be clustered[ Go to top ]

    Hi Cameron, have you guys considered a similar hands off approach for your product? Transparent heap replication without reliance on a hub sounds very sweet ;-)
  32. Re: How the server to be clustered[ Go to top ]

    Terracotta servers can be deployed as an active-Primary plus a passive-Secondary (i.e. 1 or numerous hot-standby(s)) - the hot-standby shares disk with the primary Terracotta Server. On failure of the primary, client-JVMs transparently connect to the standby.
    Terracotta can cluster two servers (one hot, one standby) while Tangosol can run a couple thousand servers as "hot" (active + active + active + etc) in an n-way fully-connected mesh (virtual channels)
    This is not a tit-for-tat response and I am sure Cameron's intention wasn't to mislead anyone, but I have to clarify the ambiguity in his statement above. The Terracotta server is distinct from an application server and our customers (including one of the top 10 web sites and one of the top gaming sites) have clustered hundreds of application servers with the Terracotta server. Best Regards, Kunal Bhasin.
  33. Re: Terracotta DSO: Open Sourced[ Go to top ]

    What these guys expected, to open source one of the bigest inovations in the Java space and not suffer from the "you've been slashdotted" thing ? You've been javadotted guys :-D Your license page suffers the bigest downtime of the site I suppose :-)
  34. Re: Terracotta DSO: Open Sourced[ Go to top ]

    To rephrase it, it seems that Java becomes a platform with transparent grid computing capabilities ?
  35. Fanboys, shame on you[ Go to top ]

    Its kinda sad seeing usually rational people get sucked in to yet another one of Terracotta's marketing gimmicks. If they were selling a bunch of licenses, they'd never be allowed to open source their software. The only reason they're doing so is because their current approach is very, very far from profitable. I know and respect a bunch of engineers there, they're all very smart (and expensive!) developers. The company though thinks that they can build a behemoth out of a niche product, and have developed an exceptionally stupid (and expensive) marketing plan to go with it. They're leaking money like nobody's business, and the OSS move, while great for the rest of us when they finally do die, is a sign of impending doom, not a sign of healthy growth or natural evolution. Still, good luck to them, they have a bunch of very smart guys working there, and there's hope that whoever has been in charge of marketing will get fired and they can scale down their goals to something vaguely approaching reality. If they don't, well, it'll make a hilarious blog entry for me.
  36. Re: Hani[ Go to top ]

    I will reserve my technical evaluation of whether Terracotta can succeed through open source for more experienced readers who can discuss the potential scenarios of success or failure. But you sound like an old-school, WebLogic apologist looking for readership of a blog that is inflated due to your ability to work the system as a JCP member. Marketing is what makes the world go around, and you should know that: what is the difference between Tangosol and Terracotta? I don't know but Cameron and Co. do a good job of educating us through his style of marketing, why shouldn't Terracotta choose their own methodology? I don't understand your p.o.v. at all, and honestly can't believe you are a representative of the Java community when you knock potential entrants in to the new-school of open sourced Java clustering, what else could you want? I think it is an adroit move, and one that will play out without you having a chance to write that highly anticipated blog entry, as we wait on pins and needles... douglas dooley http://douglasdooley.blogspot.com/
  37. Re: Hani[ Go to top ]

    I believe Hani is correct although I have no knowledge of a hugely expensive marketing plan. The difference between Terracotta & Tangosol's Coherence is vast, may I suggest you have a look in detail.
  38. Is opensourcing really an option?[ Go to top ]

    Frankly speaking I liked the idea of transparent clustering. Yet, I agree with the point that commercial software going open source first of all means failure to make money from licensing [and professional services]. Which means that market doesn't see value, at least not after looking at the given price tag. I am note sure if comparing with JBoss and RedHat would be correct because that guys have spent years building community around a free product before going the commercial support route. While I don't think it is impossible, building a services company around a product that has already failed to sell seems to be a long way to go. I'd guess execution of such a plan would greately depend on the ability company's CEO to convince VCs not to pull out the plug. Just my 2c. Regards, Slava Imeshev www.viewtier.com
  39. Re: Hani[ Go to top ]

    Personally I am grateful that no animals were sacrificed and offered up to the gods which would have been the equivalent marketing approach in previous times. Seriously though I really have some grave concerns about this announcement and other trends within the industry. We appear to be moving further away from standards based API's or frameworks that OPENLY support competition and innovation amongst many vendors including commercial vendors who might have access to extremely useful & applicable patented technology as well as other more established open source vendors. Looking around I see many projects (with underlying commercial motives) using "open source" as a means to introduce proprietary APIs and frameworks into an organization in order to obtain the de facto standard status. Once established it becomes nearly impossible to supplant them with better implementations because of the issues with licensing and ownership, the lack of specification & documentation, and the poor separation between contractual capabilities and implementation details. This also applies to solutions that transparently introduce component dependencies or data grid like capabilities. In fact I would say that such transparency has an even higher associated dependency than any API based approach because there is no explicit contract to allow other implementations to plug-in possibly via a facade which most professional architects would introduce for improved risk management. Spring is a popular framework but how many projects have been able to abandon the framework (maybe because of corporate policy) without nearly rewriting a significantly large part of the application just to provide the same component/bean/pojo construction capabilities (ignoring the obvious API dependencies in the wrapper like APIs). The dependency is there within the architecture no matter how transparent Spring or Terracotta are. This is not necessarily a bad thing (if you can still conceptualize your runtime across multiple disjointed software artifacts) but lets not be fooled into believing that it is anyway better than having an explicit contractual dependency on a standard API such as EJB3. Terracttoa DSO might be wonderful addition to an enterprise stack but the touted "transparency" is overrated if not insulting. We really need to encourage the cleaner separation between the interface/contract and the actual implementation/runtime in all open source projects to ensure that innovation can at least exist at one level - implementation. Otherwise we are going to left with many poorly implemented but free open source technologies. Yes, we someone could rewrite some parts but I think most of us would prefer to start from a much clear code base - the interface contract (if it even exists and is document). Aside, how many commercial companies turned open source & commercial support organization have generated sufficient revenues to fully sustain their initial development plans. Kind regards, William Louth JXInsight Product Architect CTO, JInspired "Java EE tuning, testing, tracing, and monitoring with JXInsight" http://www.jinspired.com
  40. Re: Hani[ Go to top ]

    Seriously though I really have some grave concerns about this announcement and other trends within the industry. We appear to be moving further away from standards based API's or frameworks that OPENLY support competition and innovation amongst many vendors including commercial vendors who might have access to extremely useful & applicable patented technology as well as other more established open source vendors...
    I beg to differ. Just look at all the trouble that JDO/EJB/Hibernate fight gave. Finding the ideal API for some functionality will always be troublesome, I am sure any JCP participant can tell us so. And usually the market ends up with more than one standard, which sometimes is even worse. I think we should look at "transparency" not for transparency sake itself (as there isn't complete transparency for a start as you pointed), but for the benefits it brings: easier testing, lower impact on design, faster learning, lesser coupling. Of course there are cons, like you pointed, but this is what we should evaluate: do the pros overcome the cons? IMO in most situations they do, and Spring and other "transparent" or POJO-based frameworks adoption rates are a compelling sign of that. Regards, Henrique Steckelberg
  41. Re: Hani[ Go to top ]

    In the case of Spring with its current focus and high quality there is probably not much of a need or incentive to offer an alternative runtime implementation though it would have been nicer and much more agreeable to have at least attempted to standardize on the bean dependency injection capabilities (markers/annotations) so that it could be applied in many other areas and contexts (existing application servers) without explicit Spring runtime requirements. At this moment the Spring XML configuration (application context) could not easily be ported to another runtime as many of the element entries explicitly reference particular bean factory implementations instead of defining a possible standard "concern" tag that could be implemented natively within the container/runtime/platform. There has been some cases where a particular concern has been expressed independent of implementation but is this being promoted enough amongst the Spring designers or community to allow greater adoption of the concepts and not implementation elsewhere? I do hope that Tangosol and GigaSpaces have adopted this type of extension in their Spring add-ons which by the way looks to be a potential area of commercial growth for interface21. Regards, William
  42. Re: Fanboys, shame on you[ Go to top ]

    I have to agree with Hani, I'm not sure this is just a marketing gimmick but it does smell a little that way. It is true that if this was selling they would have upset a lot of clients by open sourcing it but as many of us know Terracotta is not getting the uptake I imagine their VCs would have hoped for. This is a busy market place and it's obvious that if you're not there at the start you're not going to make it. Tangosol, GigaSpaces, GemStone, DataSynapse and Platform have been around for some time, they're all hanging in there but even $13.5 million is not going to get you in as a late comer. The larger vendors (Oracle, IBM etc.) have a good chance but not the small guys. So, why did they open source it? I don't know for sure but I can guess what's been discussed as I'm often involved in the same discussions as a CTO myself. I can imagine there are a few people who genuinely want to provide free software to the world. I'm always trying to get my fellow directors to open source a part of C24 but firstly we'd really piss off a lot of clients who've recently paid good hard cash for it and secondly I've got a guy who's response to most of my ideas is "Show me the money!". Taking out the competition is good when you're large enough to make a difference but it's not the case with Terracotta, if Tangosol were to open source Coherence (wait for 1st April) then it would really stir things up. I can only assume that my first reason was not a problem for them, i.e. they have no customers. Goldman Sachs said they weren't using it last time I spoke to them (some while ago) and they're an investor for not a "real" customer, I know a lot of banks in the work I do and I've never seen Terracotta involved in RFIs, the companies mentioned above are in every one. If I had something that worked reasonably well but wasn't selling due to the competition then I'd open source it. What are the other choices? Sell it to someone else (good if you can find a buyer), invest more money to develop new features (very speculative), invest in more marketing (they've tried that) or shelve it (throw it away). When all these options have failed then do the gentlemanly thing to do is to open source it. Of course there are plenty of other reasons we have open source but given the path this one has followed I really can't imagine it's just a marketing ploy, it's probably their only remaining option. Either way this is good new to the community, it will be interesting for me to see whether this gets Terracotta on the radar of the investment banks, if it does then they have done well, if not, then they've failed and we're just going to be left with a little more code to sift through. Interesting news, -John-
  43. Re: Fanboys, shame on you[ Go to top ]

    I have to agree with Hani, I'm not sure this is just a marketing gimmick but it does smell a little that way. It is true that if this was selling they would have upset a lot of clients by open sourcing it but as many of us know Terracotta is not getting the uptake I imagine their VCs would have hoped for.

    This is a busy market place and it's obvious that if you're not there at the start you're not going to make it. Tangosol, GigaSpaces, GemStone, DataSynapse and Platform have been around for some time, they're all hanging in there but even $13.5 million is not going to get you in as a late comer.
    I hope people recognize that revenues and runrates have nothing to do with the relative distruptiveness of a new solution. If money made a difference, Microsoft would have lost to IBM, Google would have lost to Yahoo, Walmart would have lost to Sears.
    The larger vendors (Oracle, IBM etc.) have a good chance but not the small guys.

    So, why did they open source it?
    Simple answer: 1. Partners wanted to bundle and customers wanted to see inside to know how it works. We oblidged. It was good for us to do so as it makes our product easier to use for end users. Furthermore, OSS has a strong track record of coopetition and while TC is not going to stop other clustering solutions it can really help framework vendors spend less time on the headaches around clustering and they wanted that ease of use. 2. Something like this takes _months_ to execute. Companies like Hyperic announced open source w/o OSS infrastructure in place. Not that they were wrong and we are right, but we obviously did the opposite (check out terracotta.org). As a corollary, customers have been paying for software in line w/ a subscription model. BTW, dealing with messaging to a semi-captive audience such as customers is the least of an OSS company's challenges.
    Either way this is good new to the community, it will be interesting for me to see whether this gets Terracotta on the radar of the investment banks, if it does then they have done well, if not, then they've failed and we're just going to be left with a little more code to sift through.

    Interesting news,

    -John-
    I do think this is good for the community. And we plan to invest in the community, almost exclusively. We are making a call for "clustering projects". Stay tuned to terracotta.org. If you are willing to host your project under the TPL at terracotta.org and it has SOMETHING to do with clustering and it uses DSO, then we are all ears. Thank you all for your feedback.
  44. Re: Fanboys, shame on you[ Go to top ]

    I have to agree with Hani, I'm not sure this is just a marketing gimmick but it does smell a little that way. It is true that if this was selling they would have upset a lot of clients by open sourcing it but as many of us know Terracotta is not getting the uptake I imagine their VCs would have hoped for.

    This is a busy market place and it's obvious that if you're not there at the start you're not going to make it. Tangosol, GigaSpaces, GemStone, DataSynapse and Platform have been around for some time, they're all hanging in there but even $13.5 million is not going to get you in as a late comer. The larger vendors (Oracle, IBM etc.) have a good chance but not the small guys.
    I can understand why people may believe Hani’s position however I find the analysis naïve in that it just assumes TT is failing. Is this really the case or is this a better way for a very young company to reach its target market? You know yourself that there are many ways of satisfying the demands of VC. I don’t know what Ari et el. have done to convinced their VC that open sourcing the product is a better route to their anticipated payoff but it is evident that there is money to be made with OSS and the VC are certainly active trying to find the secret formula to success. If we look at the industry say 20 years ago, even 10 year ago, companies made significant amounts of money by charging for developer seats! How many companies are doing this today? Certainly the VCs at that time needed to be convinced (or had the vision to see) that development licenses were a barrier to entry and that eliminating this barrier would be better for their concern, return on investment. And, they did this when there were other companies all around them making money from these fees. Having developers be able to download product at whim was one that many companies shunned. Certainly one of the reasons for high rate of adoption for BEA Weblogic has to be, it was easy for developers to get and use. Today, most people wouldn’t even think about putting up this barrier. So, the overall historical trend in the industry is the elimination of barriers to adoption. In the current climate, it appears as if the next barrier that is starting to fall is the charging of licensing fees. The question is; what will the new revenue models look like. I could cite many examples of companies experimenting with new revenue models that includes various mixes of open source and paid for software. One of the more compelling stories in the Java space has to be that of JBoss Group. Like them or not, they have managed to get it done and all the time while resisting the pressure for them to adopt licensing fees. The VCs who invested in Marc’s vision have now had that decision validated. Of course this example is very different than many of the others. However you have to believe that with this type of success out there, VCs are now more open to looking at "non-traditional" (as apposed to historically what has worked for us) business models to invest in. Clearly there are some bold experiments going on out there and only time will tell where it will stabilize. That said, the historical trends seems to say, lower the barrier to adoption and you have a much greater chance of winning. -- Kirk
  45. Is anyone aware of any decent comparisons of the various clustering technologies? A brief google search didn't show much that compared the various options. I am most interested in Tangesol vs Terracotta, although I would also be interested in comparisons with JavaSpaces and JBossCacheAOP. I, for one, welcome any new entrants to the open-source Java world. It can be tough to get management to accept expensive software, even if you and I know that said software will result in large cost savings and improvements to operations. Thank you, Terracotta!
  46. I like open source, so more open code is good :) That said, I have two questions : 1) Will you be taking this license to the OSI to have it certified as an Open Source license? The change that I am curious about is the addition of "new files" to the defintion of "Modifications", and the implications of that change. 2) How will attribution work when the presentation layer is loosely coupled to some portion of an application (say a SOA). For example, if I have a portal that uses some arbitrary set of web services, some subset are implemented using Terracotta DSO, what are the burdens on the developer? Thanks geir
  47. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Hi Geir. We wanted a license that was as close to possible as "MPL + attribution." As you may know, the OSI hasn't yet evaluated any of the "MPL + attribution" - style licenses that are gaining in popularity (for example, Zimbra, MuleSource, Alfresco, SugarCRM, Qlusters and others all use MPL + attribution). However, in just the past couple of weeks, the OSI has been working on a generic attribution clause that could be tacked on to any other OSI-certified license. Terracotta is watching these developments closely as they unfold, and participating in the discussions. To answer your other questions: 1) We tweaked the definition of "Modifications" (section 1.9) to cover any files that a developer *chooses* to make available under the terms of the TPL. So, if you're mixing Terracotta code with your own code, you can *choose* to either make your own code available under a license of your choice, or you can license it under the TPL. We made this edit purely to give the developer greater freedom to choose how to license his/her own code. 2) Attribution only applies if you redistribute Terracotta code (or modifications to it) to other users. So, if you have a portal that uses an arbitrary set of web services, and some subset are implemented using Terracotta DSO, but you aren't actually distributing any Terracotta code to users who visit the portal, then there's no attribution requirement. Hope that helps and have fun coding :) /Jonas
  48. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Hi Geir.

    We wanted a license that was as close to possible as "MPL + attribution." As you may know, the OSI hasn't yet evaluated any of the "MPL + attribution" - style licenses that are gaining in popularity (for example, Zimbra, MuleSource, Alfresco, SugarCRM, Qlusters and others all use MPL + attribution). However, in just the past couple of weeks, the OSI has been working on a generic attribution clause that could be tacked on to any other OSI-certified license. Terracotta is watching these developments closely as they unfold, and participating in the discussions.

    Thanks - I was just wondering if you were going to ask OSI for an opinion on your license. I'll follow license-discuss to see what happens...
    To answer your other questions:

    1) We tweaked the definition of "Modifications" (section 1.9) to cover any files that a developer *chooses* to make available under the terms of the TPL. So, if you're mixing Terracotta code with your own code, you can *choose* to either make your own code available under a license of your choice, or you can license it under the TPL. We made this edit purely to give the developer greater freedom to choose how to license his/her own code
    I guess I find it confusing because I would think I can do that anyway. I didn't think I needed specific permission to include under your license. OTOH, maybe requiring the use of your trademark isn't something someone could do without your permission, and thus you are giving it. Interesting - I never thought about this.
    .

    2) Attribution only applies if you redistribute Terracotta code (or modifications to it) to other users. So, if you have a portal that uses an arbitrary set of web services, and some subset are implemented using Terracotta DSO, but you aren't actually distributing any Terracotta code to users who visit the portal, then there's no attribution requirement.

    Hope that helps and have fun coding :)

    /Jonas
    Yes - sorry. I somehow had it in my head that attribution was required when being used by a recipient of your code. Thanks for the response. geir
  49. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Nice to see so much interest in Open Source Java clustering. I think that the community, our partners, and Terracotta will be able to better collaborate on solutions to the widespread need for clustering as we progress. This is exciting stuff. As I mentioned on Infoq, we are doing some kewl things in the near future: 1. Active / Active Terracotta servers 2. Wide Area asynch replication 3. more transparency (always more transparency. I hear one of our engineers has a mockup of DSO-ized threads migrating around the cluster that I want to wrap my head around) 4. Continued tuning. Although we have succeeded recently at scaling for a use case under EVERY PAGE REQUEST for one of the top 10 websites in the world, we have to do more. 5. More OSS bundling announcements are forthcoming 6. More tools for our community and partners around hosting their own clustering projects and use cases. I want to also make sure people's expectations are set correctly. Terracotta can scale for most applications because it is fine-grained. What I mean is only the bytes that change in your objects get sent to us, and thus our throughput is extremely high. Some of our most satisfied customers are so because they were able to achieve scale with simplicity. That said, don't focus on drop-in...focus on impact to the development model. Whether or not we drop in in a particular use case, we have found that our technology helps applications become more stable and more scalable because our runtime tooling helps people find bottlenecks they never knew they had. The most successful use of Terracotta is in returning control of state back into the hands of the Java developer. Clustering HTTP sessions, singletons, (and factory-pattern internals), clustering certain Spring Beans, etc. Terracotta affords a developer control over state in a non-repository fashion and use cases that rely on "durable / clusterable" heap--meaning they just leave POJOs as such--will find the most benefit. --Ari http://www.terracotta.org/ http:/www.terracottatech.com/
  50. Re: Terracotta DSO: Open Sourced[ Go to top ]

    Congratulation Ari for that move. I wish you all the success. These are interesting days in the middleware world. It is interesting to follow the different approaches for the same problem domain. I do see value in the abstraction that the Terracota model provides. I think that this is where its main value is and not necessarily with data distribution. I therfore think that open ing the interface and enabling plugging of different data distribution providers could work well with this move. Nati S. GigaSpaces Write Once Scale Anywhere
  51. DSO is the shit[ Go to top ]

    All this speculation about whether it was a wise or a desperate move on Terracotta's part to open source DSO rather misses the point. DSO is revolutionary. As author of WebLogic's first JMS implementation, and later manager of the EJB, Web Services, and Core teams at BEA, I have a thorough knowledge of the J2EE specs. Well, I used to anyway... who can keep all that crap in their heads? DSO provides a far simpler way to program distributed java applications. Forget RMI, EJB, JMS, JNDI. Just use POJOs with DSO. The model is so superior that I am surprised that it has not been embraced by the java community. Perhaps by open sourcing DSO, Terracotta has removed a major barrier to adoption. I think it was a wise move. Viva DSO. Disclosure: I had the good fortune to work at Terracotta for several months, and am a huge fan of DSO, but have no vested interest in the company.
  52. Re: DSO is the shit[ Go to top ]

    Hi Don, I think you really need to re-read the specifications. You might find out that these specifications address many more concerns than just the distribution of object state. Yes, it is exciting technology to open source but statements like "Forget RMI, EJB, JMS, JNDI" really "is the shit" (your own words) unless of course you are going to show me how to replicate a managed resource across a grid while keeping the transaction model semantically correct which by the way is a hard problem in most enterprise applications where aspects of the persistent & transient (session) state is mapped onto a data grid solution. Today even the simplest of web applications can have business transactional to resource transaction mapping issues. Testing Web Applications: Transaction Analysis http://blog.jinspired.com/?p=31 What is going to happen when data changes and movements are transparently injected via external configuration which is inherently tied to the underlying class files (object roots, class fields, synchronized blocks....). Honestly can this sort of technology be used outside normal use cases (session replication, work managers) without shooting oneself in the foot. If the architects of the product have hard enough time getting their head around possible "kewl" scenarios what awaits the mere mortals desperately trying to deal with the shift away from playing with technology to delivering useful user centric benefits. I can definitely see the potential consultancy revenue streams around certifying various architectural usages and configurations of DSO. Adding in a transparent state distribution model that moves many small field state changes around ignorant to the transaction context is surely a recipe for disaster (making security concerns pale in comparison). Maybe I am spending too much time with operations staff and my concerns regarding possible unmanageable side-effects (such concurrency, testing, management, and diagnostics) is heighten unnecessarily. regards, William
  53. Re: DSO is the shit[ Go to top ]

    Hello William, Yes, I understand very well the transaction and security model of J2EE, and I agree that I was being overly glib in my enthusiasm for DSO, but I still assert that there is a broad class of applications where DSO can provide tremendous value. The ability to have synchronization on distributed objects apply across a cluster (including wait and notify) can obviate the need for transactions. In cases where the transaction is needed to ensure a consistent view of state for the duration of the transaction, and to prevent updates to that state, a synch lock on a distributed object can achieve the same effect. But programming in DSO does require a different way of looking at distributed application development, and in that sense you have a point: intermixing the transactional model of J2EE with DSO's model for state replication could be messy. Perhaps DSO could be made to honor JTA transaction semantics. If you haven't done so already, I would encourage you to spend a few days playing with DSO. It's strangely addictive. -Don
  54. Re: DSO is the shit[ Go to top ]

    Let me clarify the point about DSO obviating the need for transactions. DSO provides transactionality, but doesn't do it through JTA. The transaction boundaries are implied by synchronization on shared objects, not on explicit creation of a transaction context. -Don
  55. Re: DSO is the shit[ Go to top ]

    Hi Don, The exciting aspect of the DSO solution is also its most dangerous aspect. Today there are many server applications that have debatable thread safety design and implementation issues still waiting to be discovered (incident) and classified (problem). I would speculate that the occurrence of such incidents in a production environment has been limited due to the lack of thread concurrency through various shared (and collocated) parts of the code as a result of the push in many IT department to use many smaller boxes to form a cluster. It would appear from what has been stated about how this technology works is that introducing it into such environments described above has the strong potential to multiple the concurrency and thus increase the incident rate as shared data is now accessible from many collocated and non-collocated threads - while keeping everything transparent. Extremely powerful stuff but incredibly risky and fraught with road blocks that will be created by developers to protect their creditability and operations staff desperately trying to limit change especially change that is not easily understood and estimated. With the hardware getting cheaper and developers becoming more accustomed to writing concurrent applications then this might change but for now this technology looks a little bit early for adoption by the general population. regards, William
  56. Re: DSO is the shit[ Go to top ]

    Hi Don,

    The exciting aspect of the DSO solution is also its most dangerous aspect. Today there are many server applications that have debatable thread safety design and implementation issues still waiting to be discovered (incident) and classified (problem). I would speculate that the occurrence of such incidents in a production environment has been limited due to the lack of thread concurrency through various shared (and collocated) parts of the code as a result of the push in many IT department to use many smaller boxes to form a cluster.
    It's true that DSO requires an understanding of java synchronization, and that threading and concurrency are poorly understood by a lot of people out there. It is certainly possible to write bad code using DSO, and the deadlock conditions can become trickier (think distributed deadlock). But the bytecode instrumentation also helps the developer by: a) Alerting the user to non-synchronized access/update to shared objects. b) Helping to detect deadlocks. c) Providing a management console to track activity pertaining to the state. But the real value to transparent clustering is allowing developer to concentrate primarily on the logic and data structures pertaining to the application, with fewer cycles devoted to thinking about clustering. Yes, you still have to understand what state is shared, and all that that implies, but you don't have to code the application to the specific APIs (JMS, EJB, etc) that accomplish that goal. Clustering becomes orthogonal to the code, not an inherent part of it, if that makes any sense. -Don
  57. Re: DSO is the shit[ Go to top ]

    While Don's post is 100% accurate, I feel it necessary to add (I always do, huh?), that most people using DSO do not end up having to do multi-threaded programming. 1. If you write web apps or J2EE (still can't get myself to call it JEE), the container manages threading for you. 2. If you use 1.5 util.Concurrent API's we cluster those at runtime. 3. If you want to do distributed computing types of applications, you can use our clustered CommonJ container that leverages util.Concurent + a callback / event-driven interface so that we spawn all the threads (ExecutorService) and you provide the callbacks to routeWork() and doWork(). For those intrepid few who wish to build their own container, as Don points out, Terracotta has managed to help them find bugs simply because it protects networked data from mistaken unprotected access. It is not a true debugger, but it has found errors for folks in the past. --Ari
  58. Great[ Go to top ]

    More competition, more options and more open source. This is great. Specially when serious companies release production ready products as open source. This is what makes the business community adopt open source. Way to go! Cheers, Paul C. Sr. Developer jBilling - The open source enterprise billing system
  59. Offline mode support[ Go to top ]

    I would venture a guess that Terracotta would be a good start to easily build "offline" mode support into Java rich clients. I believe someone mentioned the future development of wide area async support. This coupled with a protocol that could tunnel through HTTP could potentially provide rich clients with a high speed local cache and offline mode support.
  60. The forum is broken[ Go to top ]

    I'm trying to post to the terracotta forum but I'm always greeted by the following: java.lang.NullPointerException net.jforum.JForumExecutionContext.enableRollback(JForumExecutionContext.java:272) net.jforum.JForum.service(JForum.java:209) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) net.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59)