An Open Letter to BEA WebLogic Customers - From GigaSpaces

Home

News: An Open Letter to BEA WebLogic Customers - From GigaSpaces

  1. Editor's note: This isn't an endorsement of the sentiments offered in this open letter; TSS understands GigaSpaces' point, but isn't willing to commit yet to any "final nail" in Java EE's coffin. :) Dear BEA WebLogic Customer: As you probably know, Oracle just announced it is acquiring BEA for $8.5 billion. Independent industry analyst Vinnie Mirchandani said about the deal: "Customers, unlike investors, do not have much to cheer." You are now facing a vendor that will put you in one of two situations:
    • They will discontinue the WebLogic product line forcing you to rip-and-replace with Oracle Fusion middleware
    • They will continue the WebLogic product line, but will drive very little innovation. After all, as many industry experts have noted, Oracle is buying BEA mainly for the continuous maintenance and support revenue stream from its large customer base (that's you!)
    Either way, you're not in a very strong bargaining position. Perhaps more importantly, this acquisition is the final nail in the coffin of what was the motivation for J2EE in the first place: to have an open standard that allows easily switching from one vendor's product to another. The reality is that there are now two mega-vendors, Oracle and IBM, each with what is essentially their proprietary, bloated middleware stack, which requires complex integration of multiple components (and surely Oracle or IBM professional services will be happy to perform this work - for a fee). We have a better proposition for you: turn this predicament into an opportunity; an opportunity to free yourself of J2EE altogether, reduce costs, increase the agility of your enterprise and significantly shorten your time-to-market for new products and services. You can do that by leveraging a truly open middleware stack -- parts of which you may be using already, such as Spring , Hibernate and Tomcat - and a new kind of application server, one built for the "cloud". Unlike a J2EE application server it is:
    • Built from the ground-up for a scale-out computing model, allowing your applications to easily and dynamically scale across a virtual pool of low-cost commodity servers, just like Google;
    • Built from the ground-up for Service-Oriented Architecture, enabling you to easily add and change software services, and re-use existing investments in software development;
    • A single product that handles messaging, business logic and transactional data through an open-source, commonly used programming model, so your developers can focus on what they do best: quickly deliver new applications and functionality to your business, without having to deal with the complexity of writing and integrating infrastructure software.
    GigaSpaces XAP is that application server, and it is already in use today by some of the world's leading organizations such as Lehman Brothers, Dow Jones, Nortel Networks and Virgin Mobile. GigaSpaces adds the core layer of middleware virtualization that will enable you to be independent of J2EE, while remaining compatible with it. With this approach, you can significantly reduce costs by:
    • Increasing server throughput which reduces the amount of servers and software licenses required to handle the same volumes
    • Shorter time-to-market of new software products and services:
      • Reduce deployment complexity - To scale, simply drop in more processing resources with no code changes.
      • Avoid development complexity -Simple, open-source and commonly used development frameworks
    • Increasing reliability through better testability and self-healing
    • Utilizing a single platform for Java, .Net and C++
    To find out more visit http://www.gigaspaces.com/no-j2ee

    Join us in a live webinar on Thursday, January 24, 2 PM EST/11 AM PST, in which we will the alternative stack and GigaSpaces. Register Here . Sincerely, The GigaSpaces Team

    Threaded Messages (67)

  2. open MARKETING letter?[ Go to top ]

    GigaSpaces XAP is that application server, and it is already in use today by some of the world's leading organizations such as Lehman Brothers, Dow Jones, Nortel Networks and Virgin Mobile. GigaSpaces adds the core layer of middleware virtualization that will enable you to be independent of J2EE, while remaining compatible with it.
    This sounds much more like a cheap marketing attempt than any real concern of Java EE's state. I give GigaSpaces -1 for writing this, and our humble editor -2 for publishing it. /Henri Karapuu
  3. Re: open MARKETING letter?[ Go to top ]

    This sounds much more like a cheap marketing attempt than any real concern of Java EE's state.

    I give GigaSpaces -1 for writing this, and our humble editor -2 for publishing it.

    /Henri Karapuu
    Fair enough. I posted it because it's a reaction to the acquisition of BEA by Oracle, and I personally think the idea that Java EE is ready to replaced is a little immature; I felt that the TSS community should have an opportunity to respond.
  4. Re: open MARKETING letter?[ Go to top ]

    Fair enough. I posted it because it's a reaction to the acquisition of BEA by Oracle, and I personally think the idea that Java EE is ready to replaced is a little immature; I felt that the TSS community should have an opportunity to respond.
    You are overall doing a great job, but this particular article was only cheap marketing -- it's not really about the death of Java EE, it's about getting free publicity. /Henri Karapuu
  5. Joseph... come on... you lead an openspaces project, sponsored by Gigaspaces. http://www.openspaces.org/jira/browse/BRR
  6. Sorry... I missed my signature. Brian Oliver | Architect | Oracle The opinions expressed here are my own and don't necessarily reflect those of my employer.
  7. Joseph... come on... you lead an openspaces project, sponsored by Gigaspaces.

    http://www.openspaces.org/jira/browse/BRR
    I haven't ever said I don't (although I'll take issue with the "sponsored by" bit. They haven't sponsored a freakin' thing with that project. It's been me, pretty much all the way, committing time and energy to architecture and implementation.) I should also point out how many projects I have that use "traditional Java EE" - a bunch - or how many I write that use DSO, or how many use technology X... In all honesty, I don't think my personal projects matter here. If they do, then we should point out ALL of them, so that it doesn't provide an artificial bias. I make a point out of using a heck of a lot of different technologies; GigaSpaces is one, and I don't consider myself a shill for them - and hopefully they don't consider me one for them either.
  8. Hey Joseph, Perhaps it would be simpler for the TSS community if you *did* point out the products you work with and support so there is no confusion. Perhaps also the projects/products you disagree with? That way no one could ever imply that you're in anyway biased ;) As a community member, I'd expect the same from anyone involved with TSS, or any other community-based site. (Hence why I made it explicitly known to everyone that I work for Oracle, though that has nothing to do with my posts as they are my personal opinion). Regarding gigaspaces sponsorship of openspaces.org, and indeed the underlying infrastructure for your project; 1. Openspaces is an (marketing) initiative by Gigaspaces. Read more here: http://www.openspaces.org/display/OS/About+OpenSpaces.org 2. A reverse DNS lookup shows that it is hosted under gigaspaces2.inetu.net domain... owned and paid for by Gigaspaces. More information is here: http://toolbar.netcraft.com/site_report?url=http://www.openspaces.org 3. While being marketed as "open" the source code for openspaces is not available for 'open' contribution. There is no SVN or other source code repository where people an contribute. None. Zip. Nil. It's in no way like Spring or Hibernate or any other REAL open source project and should not be compared or aligned with such. 4. As documented by Gigaspaces themselves; "Is Open Spaces and Open Source Project? Not Exactly". What? Why call it "open" if it isn't? Marketing? If it's for the "community" and not "open" why isn't is called "community spaces"? Why isn't the namespace called "CommunitySpaces" instead of a "Gigaspace"? All marketing. You can read more here: FAQ It's essentially some source code you can get in a zip but not contribute towards and you require a license for a commercial product to use it. Talk about 'hijacking' the term 'open'. I guess this is the "marketing" we're all seeing. Whether you receive a free license for the underlying binary does not make your work open. Imagine Microsoft doing this... you can get the source code for .NET etc, your not allowed to contribute to it, but you must LICENSE/BUY Vista to use it! The industry would simply laugh. If you seriously want to host an truly "open" source project based on Gigaspaces or any other proprietary technology, why don't you use one of the major open source sites - like sourceforge? Less restrictions. Less marketing non-sense. It's pretty clear from the posts thus far, marketing is the game here, not technology. So you don't get the impression I'm attacking you or anyone else, simply seeking the truth, I'll borrow a line from Cameron Purdy. Peace. -- Brian Architect | Oracle PS: The opinions expressed here are my own and don't necessarily reflect those of my employer
  9. Perhaps it would be simpler for the TSS community if you *did* point out the products you work with and support so there is no confusion. Perhaps also the projects/products you disagree with? That way no one could ever imply that you're in anyway biased ;)
    Well: I work with a lot of things. I don't do much with Echo2, or ZK; I haven't done much more with Wicket yet. My web toolkit tends to the Struts 2, GWT, JSF (plus Icefaces, Richfaces, Seam), and Rails camps. Let's see... I haven't done a WHOLE lot with Perst; very little with iBATIS, although I understand it, I think; Db4O, CocoBase, Toplink, Hibernate are all pretty familiar. Spring 2.5 rocks; also I use EJB3 all the time. WebLogic, WebSphere, JBoss, Geronimo, Glassfish, Tomcat 6, Jetty, and Resin are all installed on my machine. I tend to use Glassfish a good bit because it's the RI for Java EE. That said, I certainly rotate the others on a regular basis. I use DSO and JavaSpaces (Blitz, Gigaspaces) fairly often. GridGain's on my list... as soon as I get an extra fourteen hours a day. IDEs: Eclipse/MyEclipse/GWT Designer/JBoss IDE, IDEA, NetBeans, JDeveloper. Like the app servers, I rotate on a regular basis between them, although I have to admit that JDev probably gets less desktop time than the others, mostly because its paradigm is so different that I have less time to get into it. I use Ruby, Java, Perl, Groovy, Python, and C on a fairly regular basis. Java gets most of my time; hey, I work for an Enterprise Java site. I'm sure there are things I'm forgetting offhand. I use a lot of projects along the way, JackRabbit and CRX included; also Lucene, and a host of other libraries like SiteMesh, DWR, etc. So which ones do I disagree with? Erm... I don't think I'm in a place where I can say I disagree with any of them. I have my own requirements. I can't say that just because a given project doesn't fit my requirements that the project is worthy of being disagreed with.
    As a community member, I'd expect the same from anyone involved with TSS, or any other community-based site. (Hence why I made it explicitly known to everyone that I work for Oracle, though that has nothing to do with my posts as they are my personal opinion).
    Understood. That said, I don't think I could adequately offer appropriate disclaimers without a book on every post, and plus when I'm posting as "me" - i.e., a community member rather than as editor of TSS - I think it's fairly obvious. At least, I hope so.
    Regarding gigaspaces sponsorship of openspaces.org, and indeed the underlying infrastructure for your project;1. Openspaces is an (marketing) initiative by Gigaspaces. Read more here: About OpenSpaces.org

    2. A reverse DNS lookup shows that it is hosted under gigaspaces2.inetu.net domain... owned and paid for by Gigaspaces. More information is here: http://toolbar.netcraft.com/site_report?url=http://www.openspaces.org

    3. While being marketed as "open" the source code for openspaces is not available for 'open' contribution. There is no SVN or other source code repository where people an contribute. None. Zip. Nil. It's in no way like Spring or Hibernate or any other REAL open source project and should not be compared or aligned with such.

    4. As documented by Gigaspaces themselves; "Is Open Spaces and Open Source Project? Not Exactly". What? Why call it "open" if it isn't? Marketing? If it's for the "community" and not "open" why isn't is called "community spaces"? Why isn't the namespace called "CommunitySpaces" instead of a "Gigaspace"? All marketing.
    Um... OpenSpaces is a project managed by GigaSpaces, referring to an integration point between Spring and GigaSpaces. This kind of thing is pretty common: see icefaces.org for another example.
    If you seriously want to host an truly "open" source project based on Gigaspaces or any other proprietary technology, why don't you use one of the major open source sites - like sourceforge? Less restrictions. Less marketing non-sense. It's pretty clear from the posts thus far, marketing is the game here, not technology.
    Well, I hosted BRR on OpenSpaces.org because they asked me to take it for a spin. I don't care whether OpenSpaces itself is going to fit the open source definition du jour; to me it's just a toolkit. The project in question is mine and where I host it isn't something I really consider as a talking point. It's there; so what? If I put it on my servers, or SF.net, or java.net, or codehaus, or wherever, that doesn't change the nature of BRR, as being under ASL.
  10. Hey Joseph,

    Perhaps it would be simpler for the TSS community if you *did* point out the products you work with and support so there is no confusion. Perhaps also the projects/products you disagree with? That way no one could ever imply that you're in anyway biased ;)

    As a community member, I'd expect the same from anyone involved with TSS, or any other community-based site.
    Maybe it would simpler if you'd just let Joe do his job and stop asking stupid questions. What gives you the right to expect total disclosure from Joe anyway? You don't sign his checks. Shouldn't you be writing code for Oracle anyway?
  11. It's essentially some source code you can get in a zip but not contribute towards and you require a license for a commercial product to use it. Talk about 'hijacking' the term 'open'. I guess this is the "marketing" we're all seeing. Whether you receive a free license for the underlying binary does not make your work open.
    Brian what gave you that idea? OpenSpaces is an opensource initiative meaning that it is a work in progress towards making GigaSpaces fully open. I think that the site makes it very clear. If you followed our announcements recently you would notice that this initiative is very high in our priority and were putting lots of resources to back it up. Its severs as the GigaSpaces community site pretty much like MuleForge and others community projects sites. Correction: You can contribute code to OpenSpaces today see note on that regard here We will soon make it aviliable as an OpenSpaces project which means that you'll have access to SVN, JIRA etc. Patient man! Now i have no idea what do you suggest with your comment about Joe's project - he is doing a project out of his own will for that matter he could have used oracle as part of his projects and most likely he did. If anything i think that its something worth looking at. Nati S.
  12. It's pretty clear in the about page what openspaces is, and no one says to take this news as "truth". Truth is subjective. ...All marketing crap coming from software vendors, and day after day less vendors, more open source frameworks going nowhere due to lack of financial support and economic interests. TSS is the stage for marketing, hipocrisy and poor developers going with the stream of huge frameworks and soa suites...
  13. Re: open MARKETING letter?[ Go to top ]

    +1
  14. Average point crappily made[ Go to top ]

    I agree with the redundancy and issues around JEE. EE5 imho basically copies some ideas from Spring and Hibernate (obviously as GK was heavily involved copy might be the wrong word) without really being as powerfull / flexible as the Spring/Hibernate combination. My 2p for the future is that JEE will even more try not to be JEE in the future - so why use it in the first place? The point of the 2 remaining vendors might not be fully factual, however looking at larger companies it's not fully wrong either. Saying all of the above why this all should make you go to Gigaspaces and take their non-standard product is above me, too. To be frank the hype blogging of Gigaspaces (mostly by the Gigaspaces people) is indeed starting to do them more harm than good.
  15. Re: Average point crappily made[ Go to top ]

    [snip!] Saying all of the above why this all should make you go to Gigaspaces and take their non-standard product is above me, too.
    To be frank the hype blogging of Gigaspaces (mostly by the Gigaspaces people) is indeed starting to do them more harm than good.
    Erm... Gigaspaces has a set of nonstandard extensions to the JavaSpaces API, but they also have standard bridges (i.e., JDBC, JMS) to standards, and they implement the JavaSpace API itself, of course. In addition, Spring can be considered a standard in and of itself. I don't think it's quite fair to say they're "nonstandard" any more than any other vendor is.
  16. Re: Average point crappily made[ Go to top ]


    I don't think it's quite fair to say they're "nonstandard" any more than any other vendor is.
    I didn't - that was the point. They are as standard or non-standard as other vendors inclusive Oracle ...
  17. What makes a standard?[ Go to top ]

    [snip!]In addition, Spring can be considered a standard in and of itself.

    I don't think it's quite fair to say they're "nonstandard" any more than any other vendor is.
    Since when did 'standard' mean 'popular'? I don't deny that Spring is a great product, but that doesn't make it a standard.
    By that reckoning, almost any popular framework becomes its own standard, which kind-of destroys this entire discussion.
  18. Re: What makes a standard?[ Go to top ]

    [snip!]In addition, Spring can be considered a standard in and of itself.

    I don't think it's quite fair to say they're "nonstandard" any more than any other vendor is.

    Since when did 'standard' mean 'popular'? I don't deny that Spring is a great product, but that doesn't make it a standard.
    By that reckoning, almost any popular framework becomes its own standard, which kind-of destroys this entire discussion.
    One of the characteristics of a standard is that there are multiple, independent implementations of its programming model APIs. How many implementations of the Spring API set are there? Even .NET has the "Mono" implementation being done independently from Microsoft, yet whether .NET is a "standard" is certainly under debate. Some will answer that having multiple vendor impls doesn't matter because you have access to the source code. Maybe, but there's a difference between switching to another vendor, and taking over the source code yourself if you're unsatisfied with the performance of your current vendor. I worked with a large online auction site who found this out firsthand.
  19. Re: What makes a standard?[ Go to top ]

    Some will answer that having multiple vendor impls doesn't matter because you have access to the source code. Maybe, but there's a difference between switching to another vendor, and taking over the source code yourself if you're unsatisfied with the performance of your current vendor. I worked with a large online auction site who found this out firsthand.
    I think that were missing the point. We need to remeber what is the main motivation of behind having standards in the first place. The main value IMO is to keep our business logic and our application independent of a specific underlying implementation i.e. avoid vendor lock-in etc. Having multiple implementation of that same standard didn't always prove to be the best way to achieve that. Most standard implementation got broken quite often when you switched from one implementation to another. It also came at a relatively huge cost since you where forced to avoid using any enhancement outside of the spec - this led to more development effort and complexity since the standard is always lagging behind our current needs. I lived through various cycles of standards (CORBA, J2EE,.. ) to develop a more pragmatic view on this matter then i originally had and I'm sure I'm not the only one. 1. I think that there are better ways to avoid vendor -lock-in then agreeing on a certain API - for example with Mule you can plug-in various protocols to the same business logic without agreeing on specific API - the event source can be JMS, REST,... This model gives more freedom of choice then trying to stick with JMS. 2. In many cases i prefer to take a risk with a project/framework that is highly adopted, have large community behind it that i know who is driving it (i normally get direct access to the development team) and knowing that what motivate them is to keep up with the market then a standard or a spec that was developed by a certain interest group that may change. Now I'm not necessarily saying that standard are dead - they have and will have their place in our world. What i'm saying is that standard are one of the options to manage risks, there are more options and standard is not always the best tool for that purpose - using popular OSS frameoworks are just as good or even better. I also believe that a good standardizations process would be to simply adopt those highly popular projects just like Hibernate evolved to JPA and that is basically what i suggested in earlier post: Who needs standards anyway? One of the interesting observation i had by looking more closely at the consumer facing sites (web 2.0) is that they seem to be more pragmatic in the way the approach standards - I believe that it is this level of pragmatisms that enabled many of them to come with more innovative solutions (I would say that Amazon seem to take the lead in that area). Being in Enterprise Java world for quite some time i think that we can benefit a lot by learning from those guys. Nati S. Nati S.
  20. Re: What makes a standard?[ Go to top ]

    I also believe that a good standardizations process would be to simply adopt those highly popular projects just like Hibernate evolved to JPA
    That's not at all how it went. What actually happened (I was a member of that expert group) was that the EG members looked at the characteristics of a number of popular persistence frameworks and products (the main ones being Hibernate, TopLink, and JDO, plus others -- definitely not just Hibernate) and incorporated, through consensus, the best characteristics from those products into the standard being written. It was absolutely not as simple as adopting Hibernate.
  21. Re: What makes a standard?[ Go to top ]

    Since when did 'standard' mean 'popular'?
    By definition? http://dictionary.reference.com/search?q=standard
  22. Standard == popular?[ Go to top ]

    So, that would presumably be the definition:
    12. a musical piece of sufficiently enduring popularity to be made part of a permanent repertoire, esp. a popular song.
  23. Re: open MARKETING letter?[ Go to top ]

    You can do that by leveraging a truly open middleware stack -- parts of which you may be using already, such as Spring , Hibernate and Tomcat - and a new kind of application server, one built for the "cloud".
    I like GigaSpaces. We are in the same field, competing in a good spirit and probably seeing each other in every customer by now. But this is really odd… I have no idea why they did it including obvious “cheap marketing” slander of it but if you really want to free yourself why would you use proprietary closed-source expensive software – i.e., GigaSpaces - that is pretty far from being “open”? You have plenty of options in open source field (JBoss Cache, ehcache, JPPF, GridGain). Mentioning the “cloud” is really grasping for air at this point, in my opinion. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  24. Not really competitive[ Go to top ]


    You can do that by leveraging a truly open middleware stack -- parts of which you may be using already, such as Spring , Hibernate and Tomcat - and a new kind of application server, one built for the "cloud".


    I like GigaSpaces. We are in the same field, competing in a good spirit and probably seeing each other in every customer by now.
    While I'm sure that GridGain would like to portray itself as a competitor to GigaSpaces, that's not the reality. I see a lot of GigaSpaces' customers and prospects. Two or three have mentioned GridGain recently, but only as part of their due diligence of checking out possible "free" solutions. GigaSpaces provides a full Space Based Architecture (SBA). The map/reduce functionality provided by GridGain is one simple use case for GigaSpaces, and is easily implemented using GigaSpaces' out-of-the-box capabilities with no need to integrate additional products. Without the co-location, scalability, and resiliency of the underlying SBA, map/reduce by itself is of limited value.
    You have plenty of options in open source field (JBoss Cache, ehcache, JPPF, GridGain).
    Caching, like map/reduce, is another simple use case for GigaSpaces. Those products are competitors only if the requirements are limited to caching. That's rarely the case in the short term and never the case in the long term. It is not uncommon for a customer to use GigaSpaces initially for caching and soon after begin using more of the SBA features. That kind of future-proofing is of real value.
    Mentioning the “cloud” is really grasping for air at this point, in my opinion.
    GigaSpaces was supporting the cloud before the cloud was cool. Patrick May (Working for, but not necessarily speaking for, GigaSpaces.)
  25. Re: Not really competitive[ Go to top ]

    GigaSpaces was supporting the cloud before the cloud was cool
    Clouds lead to rain, rain leads to unhappiness. Keep your buzzwords to yourself, some of us aren't impressed by them.
  26. Re: Not really competitive[ Go to top ]

    Clouds lead to rain
    Sometimes snow. Sometimes nothing.
    rain leads to unhappiness.
    Only if you get too much.
  27. Re: Not really competitive[ Go to top ]

    GigaSpaces was supporting the cloud before the cloud was cool

    Clouds lead to rain, rain leads to unhappiness.
    Keep your buzzwords to yourself, some of us aren't impressed by them.
    Actually, the term "cloud" isn't a creation of GigaSpaces. Amazon, Google, IBM, and Dell, among other little companies, are advocating cloud computing. This is a vindication of what GigaSpaces has been saying for years. The ability to turn a POJO into a service and run multiple instances of that service on a pool of machines, with support for dynamic scalability and high availability meets a lot of customer requirements. Making those services accessible through a single proxy that handles routing of methods to the appropriate instance and that seamlessly fails over to a hot backup in case of a failure or service relocation allows those benefits to be gained with minimal intrusion on existing systems. Anyone interested in how this can be done can see real examples on GigaSpaces' website. A good starting point is here. Note that this particular GigaSpaces capability allows the call to be executed synchronously or asynchronously, on a single instance or in parallel, all without writing any extra code. Whether or not you consider "cloud computing" to be a buzz phrase, Space Based Architecture works.
  28. Re: Not really competitive[ Go to top ]

    While I'm sure that GridGain would like to portray itself as a competitor to GigaSpaces, that's not the reality.
    I will let customers decide :) GridGain 2.0 comes with a full support for data replication over any DBMS caching product be it JBoss Cache or ehcache or home grown cache plus affinity map/reduce that is miles ahead of what GigaSpaces provides at this time. Plus AOP-based grid enabling, zero-deployment with P2P class-loading, advance topology and scheduling management… I can go on for pages. I will take this bet anytime: non-free, proprietary closed-source data grid-only solution vs. fully open-source full-stack grid computing platform with support for all major caching products. All the best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  29. Re: Not really competitive[ Go to top ]

    While I'm sure that GridGain would like to portray itself as a competitor to GigaSpaces, that's not the reality.
    I will let customers decide :)
    Thank you, that will be very good for GigaSpaces.
    GridGain 2.0 comes with a full support for data replication over any DBMS caching product be it JBoss Cache or ehcache or home grown cache plus affinity map/reduce that is miles ahead of what GigaSpaces provides at this time.
    That's simply not the case. If you had sufficient experience with GigaSpaces you would know that. GigaSpaces has supported co-location (affinity) of business logic, data, and messaging for years. Map/reduce, with far more flexibility than GridGain's single technique, is one simple use case for GigaSpaces. Further, GigaSpaces eliminates the need to integrate multiple products because the space provides the shared data. Given the high cost of integrating and maintaining so many moving parts, GigaSpaces' single packaged solution is very appealing. All that combined with the maturity of a product that has been deployed in production at major investment banks, telcos, government sites, and more for years makes it clear why GridGain is trying so hard to be seen as remotely comparable.
    Plus AOP-based grid enabling, zero-deployment with P2P class-loading, advance topology and scheduling management… I can go on for pages.
    Of that I have no doubt, but the fact remains that anyone can go to GridGain's website and GigaSpaces' website, download the products, and see the vast difference in capabilities.
    I will take this bet anytime: non-free, proprietary closed-source data grid-only solution vs. fully open-source full-stack grid computing platform with support for all major caching products.
    It's too bad for your bet that GigaSpaces is far more than a "data grid-only solution." Even with your limited exposure to the product, you should know better than this. I love the smell of FUD in the morning.... Don't get me wrong, it's nice to have a toy implementation like GridGain around. It gets people thinking about how they can use map/reduce in their environments. Then, when they're ready for an enterprise quality solution, GigaSpaces is there for them. Patrick May (Employed by, by not necessarily speaking for, GigaSpaces.)
  30. Re: Not really competitive[ Go to top ]

    Without the co-location, scalability, and resiliency of the underlying SBA
    Hi Patrick, It is interesting you have mentioned it. When we evaluated GigaSpaces for our integration efforts we found that underlying SBA was the biggest limiting factor for this product. It really pins you in the corner as far as extension of this architecture and rather imprisoned otherwise interesting product. Whenever you pick such a narrow technology as JavaSpaces as your only foundation you are inevitable running the risk of limiting your design and architectural choices – and that is what apparently happening to GigaSpaces… Just my 2 (undoubtedly biased) cents. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  31. Re: Not really competitive[ Go to top ]

    Nikita I think that you touched on the right point. There is a general confusion between what GigSpaces/GridGain does, so i thought it would be worth while if I'll put more clarity on that regard rather then responding to the (many) individual responses from GridGain. First you are right to say that we do have a different approach then most other caching products. Were seeing Caching or Data Grid for that matter as a component in a broader distributed architecture. It is our believe that when it comes to scaling of stateful applications i.e. trading applications, e-commerce, billing or real time analytics as well as web2.0 applications it doesn't make sense to separate between parallel distribution of the business logic and the data associated with it (This is the core idea behind SBA) since they are tightly coupled in any case in terms of latency, affinity, high availability etc. If you do treat them separately you'll end up with integration (bundling) of two separate clusters two high availability models, complex affinity schemes (i.e. mapping between the parallel distribution affinity and data distribution affinity), inconsistency of behavior especially if you take into account that the integration is not something you do in one point of time but its continues through the life cycle of both products and are not always inline with one another. From a runtime perspective you'll need to use something like distributed transactions to ensure that when a message is sent that needs to update a state they both succeed or fail at the same time. The complexity, testability and maintainability of deploying two integrated product is by definition more complex then having them both under the same runtime. Now with GigaSpaces if you have a POJO service and you want to deploy it over a pool of machines, execute a method on it synchronously or asynchronously as well as associating the operation with the same transaction as the data that is very simple since its all done declaratively outside of your POJO code including support for Map/Reduce Futures semantics etc. The interaction with the space is totally implicit i.e. you don't need to write code for it rather then your original POJO. We use the same underlying runtime and cluster for the distribution of the POJO service and the data therefore affinity is pretty much built-in you don't need specific integration to support it. This is only a glimpse of what you can do with it. You can read more about it here This include our new support for Map/Reduce pattern, enhance parallel query and Dynamic Language (Groovy, Rubby) distributed invocation support. To be clear with this approach your not really limited to a specific architecture and not even to a specific API i.e. if your used to write POJO's, invoke remote calls using RMI, define your domain model as pure POJO, run query using SQL, send messaged via JMS, wire your services using Spring, then you'll find that all that is supported natively with GigaSpaces i.e. we basically change the underlying implementation of that API rather then force you to change your code to benefit from SBA. We also provide tools for implementing this model in classic tier based application thus turning tier based applications into the scale out model fairly seamlessly or at most with little change in code. The following presentation covers that in more details: Three Steps to Turning Your Tier-Based Spring Application into Scalable Services. To sum that up i think that the main difference is that were aiming at two (very) different problems. - Were aiming to scale-out stateful applications (transactional services in most cases) where the data and the business logic associated with it are tightly coupled (from a runtime perspective) and your aiming at Compute Grid applications (Monte Calro,..) that are often considered stateless in nature or if they handle stat e its not at the same level of consistency, integrity or latency requirements as with transactional applications etc. I do see how your product can be complementary to our Data Grid (XAP-EDG) edition where you can serve as the Compute Grid provided that you do what DataSynapse and alike i.e. handle large number (x1000) of agents, provide smart scheduling schemes as well as advanced resource monitoring and distribution - I'm not sure if you do all that but most users would expect to get all of the above from products that aims to provide compute-grid functionality. I believe that if you'll focus more on the Compute-Grid end of the story we may end up having fruitful relationship. Nati S. More clarification here..
  32. Re: Not really competitive[ Go to top ]


    Without the co-location, scalability, and resiliency of the underlying SBA


    Hi Patrick,
    It is interesting you have mentioned it. When we evaluated GigaSpaces for our integration efforts we found that underlying SBA was the biggest limiting factor for this product. It really pins you in the corner as far as extension of this architecture and rather imprisoned otherwise interesting product.

    Whenever you pick such a narrow technology as JavaSpaces as your only foundation you are inevitable running the risk of limiting your design and architectural choices – and that is what apparently happening to GigaSpaces…

    Just my 2 (undoubtedly biased) cents.
    More than biased, completely baseless. This post is content-free and appears to be nothing more than a simplistic attempt to spread FUD. If you've got specific, logical reasons to back up your claims, let's see them. Otherwise, the experience of GigaSpaces' customers who have used SBA to build highly flexible, scalable, resilient, and performant systems is a far better indicator of the power of the product and underlying technology. Patrick May (Employed by, but not necessarily speaking for, GigaSpaces.)
  33. Re: Not really competitive[ Go to top ]

    While I'm sure that GridGain would like to portray itself as a competitor to GigaSpaces, that's not the reality.
    GridGain competes with GigaSpaces in one very narrow area of Master/Worker which is a drop in the ocean compared to the full set of features that come with GridGain. But even that I can hardly call competition, as doing Master/Worker on GridGain is by far much simpler and at the same time more advanced and feature-rich. Just take a look at our zero-deployment approach (or watch our Grid in 15 minutes screencast which I am sure you haven't). As far as distributed cache, or partitioned cache for that matter, our customers really like the freedom that GridGain gives them. Unlike the Lock-In that users get with a Commercial and Very Expensive cache vendor, like GigaSpases, with GridGain, you can take any caching technology (commercial or open source) and turn it into Grid in hours, if not minutes. For example, our upcoming 2.0 release will have examples on how to turn JBoss Cache into Distributed Partitioned Cache in about 10 lines of code. And last but not least - GridGain is Open Source and FREE for anyone, including upgrades, documentation, and whatever else you can think of! By the way, once you remove all this *open* fluff, how much does GigaSpace charge for a license? I am sure I won't get a number here ;-) Best, Dmitriy Setrakyan, GridGain - Grid Computing Made Simple
  34. Re: Not really competitive[ Go to top ]

    While I'm sure that GridGain would like to portray itself as
    a competitor to GigaSpaces, that's not the reality.

    GridGain competes with GigaSpaces in one very narrow area of Master/Worker which is a drop in the ocean compared to the full set of features that come with GridGain.
    Really? From the GridGain website and demos, I get the impression that master/worker is essentially all that GridGain does.
    But even that I can hardly call competition, as doing Master/Worker on GridGain is by far much simpler and at the same time more advanced and feature-rich.
    Have you developed a master/worker system on GigaSpaces? If you had, you'd couldn't in good conscience write the above. See the GigaSpaces Remoting capabilities for just one example of how master/worker is very simply addressed.
    Just take a look at our zero-deployment approach (or watch our Grid in 15 minutes screencast which I am sure you haven't).
    Check your website logfiles. ;-) This would be the "15 Minute Introduction" that lasts 19 minutes, correct? The accuracy of the claims you're making is even worse than that of your stopwatch.
    As far as distributed cache, or partitioned cache for that matter, our customers really like the freedom that GridGain gives them. Unlike the Lock-In that users get with a Commercial and Very Expensive cache vendor, like GigaSpases, with GridGain, you can take any caching technology (commercial or open source) and turn it into Grid in hours, if not minutes. For example, our upcoming 2.0 release will have examples on how to turn JBoss Cache into Distributed Partitioned Cache in about 10 lines of code.

    And last but not least - GridGain is Open Source and FREE for anyone, including upgrades, documentation, and whatever else you can think of!
    Free can be very expensive. The cost of integrating multiple different products and maintaining the integrated system as versions change is high. Support costs are high. Enterprise customers understand that commercial software can be cheaper when all costs are considered. I realize that is heresy on The Server Side, but it's true nonetheless.
    By the way, once you remove all this *open* fluff, how much does GigaSpace charge for a license? I am sure I won't get a number here ;-)
    This statement is not entirely wrong, which is a significant improvement on the rest of your post, because instead of posting our price list here I will simply direct you to GigaSpaces' website where that information is readily available. Patrick May (Employed by, but not necessarily speaking for, GigaSpaces.)
  35. Re: open MARKETING letter?[ Go to top ]

    Well, this has turned into a marketing bashing :). Here are a few of my thoughts on the matter: First, the question raised here is a valid one. As someone who used Weblogic and loved it out of all the other Application Servers out there, it is a valid concern as to what will happen now. OCJ vs Weblogic, OpenJPA vs TopLink (or is it EcliseLink), and the list goes on... . I think that this is a very valid (and interesting ;) ) discussion to have on TSS. One major thing to think about as well, especially with the recent acquisition of MySQL by SUN (which validates a certain standpoint from SUN), is whether Glassfish has now got its tipping point. Second, the question of JEE as a whole is a bit misleading. Certainly the web container is here to stay. The main question is the programming model that goes behind it as well as the deployment model. We need something better as we see more and more propriety solutions and heck, why can't all of us use the same architecture that Google, Amazon and Yahoo use. I want an application server that is built to scale and has integrated support for all the prominent Open Source frameworks out there such as Spring and Mule. It is much simpler, and most times, we hope our websites will need to face the scaling needs that they do ($$$). Last, a personal note on GigaSpaces. Being a GigaSpaces employee, I also develop Compass at my free time. When I wanted to have distributed support for Compass, I went ahead and did it with GigaSpaces, but then I did it with Oracle Coherence as well. I, as well as my company, believe in choice and power to developers. So, putting the marketing aspect aside for a minute, this is exactly the type of attitude that I would also want from a vendor (not implying anything on any other vendor). Cheers, Shay Banon Compass and GigaSpaces
  36. Re: open MARKETING letter?[ Go to top ]

    This sounds much more like a cheap marketing attempt than any real concern of Java EE's state.

    I give GigaSpaces -1 for writing this, and our humble editor -2 for publishing it.
    Yes, some of our staff were pretty upset when they saw this, until I reminded them that Oracle marketing has pulled similar stunts before -- albeit using a professional writer and a proof-reader ;-) Anyhow, you can't blame Gigaspaces for trying to get some marketing in at the expense of Oracle and BEA, and the cynical side of me says that I hope Gigaspaces sells a lot more, since it seems like most of their customers end up upgrading to Coherence ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  37. Re: open MARKETING letter?[ Go to top ]

    Anyhow, you can't blame Gigaspaces for trying to get some marketing in at the expense of Oracle and BEA, and the cynical side of me says that I hope Gigaspaces sells a lot more, since it seems like most of their customers end up upgrading to Coherence ;-)
    Be careful, Cameron. GigaSpaces are now going to come out and say that they don't compete with Coherence either because they are not a Data Grid - they are XAP ;-) Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  38. Standard or non-standard[ Go to top ]

    Just wanted to comment on one aspect that I would agree with Nati: importance or non-importance of standards. Although standards-based products should always be preferable there are many areas where standards either don't exist, inadequate or it doesn't make any sense to create one. Spring, Apache Commons, Hibernate (before JPA) and many other frameworks just prove that point. So it's always going to be a case-by-case decision on what matters most to your project and for your organization. Regards, Nikita Ivanov. GridGain - Grid Computing Made Simple
  39. Sounds interesting[ Go to top ]

    Sounds Interesting. I will have to try it out. http://www.programmersbible.com - Online resource for programmers
  40. Re: open MARKETING letter?[ Go to top ]

    Hi Patrick (Nati, Geva), Well, I guess we can't be further apart on some of the ideas and I think it's rapidly getting into irrational discussion. I won't be posting on this thread and instructed everyone on the team not to post anymore here as well. I think we are both avid proponents of our respective products/projects and this kind of content is better suited for company or personal blogs. Good luck, Nikita Ivanov. GridGain – Grid Computing Made Simple
  41. Not open standard[ Go to top ]

    I wouldn’t use open source product like spring, hibernate and etc or any product that is not based on the standard, rather use open standard based product. If the open source product is based on the open standard, like JBoss or Tomcat, then you have an option to switch different implementation in case of - performance /scalability issues - maintenance issues - no support from open source community As an architect, I have seen many organization use lots of open source stuff based on hype and without understanding its limitation. When you use products like weblogic and IBM, they always give you added features to make things better; this is where you need an architect if you don’t want lock into one vendor. Gigaspaces is not based the standard and it is layer on top of set of open source products. Standards like JEE and SOA takes years to get matured, this is lifecycle by itself. Instead of coming up product like this, you should be providing better solution based on these standards or help improve these standards. This is what BEA, IBM, SUN, ORACLE, MICROSOFT, TIBCO and JBOSS are doing.
  42. Re: Not open standard[ Go to top ]

    Siva
    Gigaspaces is not based the standard and it is layer on top of set of open source products.
    I'm not sure what gave you that impression. Let me be clear on that once again: GigaSpaces core value-add is the runtime, not the API - that makes us very different then other Application Server providers that own both the development framework and the runtime implementation. In our case since we need to support multiple development frameworks (Spring, Mule,J2EE .net, CPP) we have built-in motivation to provide seamless integration. In addition to that we provides the following means to avoid vendor lock-in: - Standard implementation support (JMS, JDBC,…) - Abstraction (Declarative transactions, Remoting) - Dependency injection (Event containers) - Annotations (Specify meta data on the domain model) - Open source development framework where standards are lacking - Provide integration with existing J2EE (keeping your app compatible but independent) JCA, XA,.. HTH Nati S.
  43. Re: Not open standard[ Go to top ]

    Siva
    Gigaspaces is not based the standard and it is layer on top of set of open source products.
    I'm not sure what gave you that impression. Let me be clear on that once again: GigaSpaces core value-add is the runtime, not the API - that makes us very different then other Application Server providers that own both the development framework and the runtime implementation. In our case since we need to support multiple development frameworks (Spring, Mule,J2EE .net, CPP) we have built-in motivation to provide seamless integration. In addition to that we provides the following means to avoid vendor lock-in: - Standard implementation support (JMS, JDBC,…) - Abstraction (Declarative transactions, Remoting) - Dependency injection (Event containers) - Annotations (Specify meta data on the domain model) - Open source development framework where standards are lacking - Provide integration with existing J2EE (keeping your app compatible but independent) JCA, XA,.. HTH Nati S.
  44. Certainly GigaSpaces provides an interesting approach, but I think marketecture gets confused with realities at times. Certainly the statement
    an opportunity to free yourself of J2EE altogether
    Is somewhat ill-informed, as I'm sure GigaSpaces will acknowledge, what they are trying to say is you dont have to get wrapped up with EJBs, other approaches made popular by Spring (and others) may be your best bet. To this I think we can certainly agree. Certainly EJBs != JEE, and GigaSpaces I hope would recognize the need for JDBC, JMS, JNDI, JSPs, JAAS, JCA ... (etc...). Additionally, and IMHO, I think the field is a little larger then 2 vendors, certainly GlassFish looks promising. Lastly, and I hope GigaSpaces will also attest to, the scale out model made popular by Jini technology based systems can be readily achieved through a number of active and completely open source projects available through the Jini community. Just my $0.02 Dennis
  45. Since when is an ad news??[ Go to top ]

    I agree with Henri, what was the point to even posting this advertising. The marketers at Gigaspaces have very little knowledge of what Oracle's plans for WebLogic are. And to pronounce that there are only two JavaEE vendors is to loose site of JBoss, Sun's offerings and small vendors like Caucho (why are they always ignored?). Come on, if your IT department is really going to consider deploying on Tomcat, take a serious look at what options are out there - you might be surprised at how large a playing field it really is.
  46. Re: Discredit[ Go to top ]

    How to embarrass your company in 500 words or less: reflecting on the supposed demise of JEE, i have one thing to say to Gigaspaces' product management team: bahahaha... I always get a good laugh at SOA marketing, please explain to me what u write the services in if not Java? Or r all needed services already in play, so u just have to 'integrate' them? Beyond that, I don't fault Joe for bringing this to the attention of a wider audience, as it is clear that my previous defense of this company was off-the-mark - - it is a service to point out when a "middleware" vendor has a religious ax to grind, this time against JEE... One question: after 8 years of investment in WL, in keeping (4 the most part) with standards assumed by the vast majority of the enterprise development community, why abandon in favor of a proprietary "cloud"? I'll await the argument of Gigaspaces impending self-standardization as de facto, and their ability to deliver the scalability of resources from developers, SIs, app vendors, and support models that would leave a mission-critical operation (perhaps such as 'Google') to think that leaving JEE for an unproven platform would be in their best interests... a. Glassfish/MySQL b. JBoss Linux clusters c. WebLogic RAC d. Geronimo fail-over all of these options would leave me feeling a little desperate, as well...get back on message, guys, and work within the multi-billion dollar system that has thrown off the gorilla head-lock of MSFT...
  47. Self-contradicting[ Go to top ]

    Perhaps more importantly, this acquisition is the final nail in the coffin of what was the motivation for J2EE in the first place: to have an open standard that allows easily switching from one vendor's product to another. The reality is that there are now two mega-vendors, Oracle and IBM.... [instead, we want you to be] leveraging a truly open middleware stack -- parts of which you may be using already, such as Spring , Hibernate and Tomcat - and a new kind of application server....
    Translation: "Rather than continue with a standard that has implementations from two large vendors and a number of smaller vendors, we suggest you switch to a stack made of single implementations each from a single vendor." Sheesh.
  48. Re: Self-contradicting[ Go to top ]

    I do not believe there is only two Java EE vendors left. There is at least 4 options still viable depending on the the scale of the application deployments and the workload characteristics. So customers have at least 4 options though some might be painful but at least there is an option. Question: How come a BEA customer still has an option (if the elected to jump)? Answer: Java EE is a standard designed and implemented by more than one organization. Now contrast that with a commercial open source framework company. William
  49. Re: Self-contradicting[ Go to top ]

    Translation: "Rather than continue with a standard that has implementations from two large vendors and a number of smaller vendors, we suggest you switch to a stack made of single implementations each from a single vendor."

    Sheesh.
    Finally someone who sees the real picture! Spring, Hibernate and Tomcat are nothing but products, and basing your systems on specific products instead of standards means that your system pretty much lives and dies with the lifespan of these products. And voila! - vendor lock-in was resurrected from the beyond where we hoped it was safely contained... Only a fool would base a system on a specific product implementation when a freely available standard exists.
  50. Re: Self-contradicting[ Go to top ]

    Spring, Hibernate and Tomcat are nothing but products, and basing your systems on specific products instead of standards means that your system pretty much lives and dies with the lifespan of these products. And voila!
    John - i think that your represent and important view which i'd like to address. Here are some points worth thinking when making such statements: What is the value of standards if 80% of my code is based on frameworks outside of the standard developed by frameowrks that are meant to help be more productive in my work?. Should i stick to somone standard just because its part of certain specification? but what if doesn't make sense, what if it produces no real value? weve seen that with EJB in the past and we all know where that ended. Should i drop those frameworks even though they could save me 30%-40% of my development effort? Is that less risky? Were missing the real point here. The important thing that we want is to keep our business logic abstracted from a specific implementation, Spring and Mule helps you a great deal in that regard through the declarative approach and dependency injection. The fact of life is that if we want to write an application that will run on webshpere/weblogic, tomact or JBoss we have better chance to achive that if we use Spring/Hibernate then relying on any other standard. There is also an interesting checks and balances in this type of model - those framework wouldn't succeed if they wouldn't do a good job in supporting all the other platforms as well. From this reason they have built-in motivation to move faster and respond to community needs(unlike standard bodies), they are also driven by developers which means that there is a higher chance that they will know our problems well and address it as we expect since they often don't need to compromise on a least common denominator. Now is that risk-free choice - if your looking for a risk free option your in the wrong business. In many cases the biggest risk is not taking a risk and yes i wouldn't argue that there isn't a risk going with the Open platform stack but i would argue that its lower then any other alternatives. If your interested i wrote more of my thoughts on that interesting topic in one of my recent blogs Who needs standards anyway? which was triggered by a discussion on the JCP process as a mean to drive standard. Its something of personal interest to me as i'm not sure there is a *right* answer here. It is also clear to me that going the standard route the way things are is not such a *safe bet* either.
  51. hmmm[ Go to top ]

    I see many fools then. Many, many, many companies rely on specific products for their information needs. When a product you rely on dies and you need to extend it, you simply plan to migrate to this new product. Usually this becomes one of the quarter objectives to one or a group of the line IT workers at your enterprise. If their is anything I can stress, always require and demand a documentation of the datamodel of any application your enterprise buy. This for me, what really help you migrate whenever you need too! Migration mainly becomes an ETL process (more or less). The bigger and more demanding enterprises, they just bet on one of the big vendors, MS, Oracle, IBM, Sun etc ... And if they ever migrate they migrate to another big vendor who help them extensively in the migration. And its works! maybe painfully!
  52. Re: Self-contradicting[ Go to top ]

    Now is that risk-free choice - if your looking for a risk free option your in the wrong business. In many cases the biggest risk is not taking a risk and yes i wouldn't argue that there isn't a risk going with the Open platform stack but i would argue that its lower then any other alternatives.

    If your interested i wrote more of my thoughts on that interesting topic in one of my recent blogs Who needs standards anyway? which was triggered by a discussion on the JCP process as a mean to drive standard.
    Its something of personal interest to me as i'm not sure there is a *right* answer here. It is also clear to me that going the standard route the way things are is not such a *safe bet* either.
    I beg to disagree. Indeed, it is a risk-free choice to stick with JEE standard and make the app portable between various implementations by avoiding proprietary extensions as far as possible. It is a no-brainer here. It is higher risk to go with new potentially innovative products. But the rewards can also be higher since if the product succeeds it can mean a good payoff for early investment. Like Hibernate succeeded and now is sort of a standard in some sense within the JEE. But there is a risk that if the product fails, it will wipe out the investment.
  53. Re: Self-contradicting[ Go to top ]

    And voila! - vendor lock-in was resurrected from the beyond where we hoped it was safely contained...Only a fool would base a system on a specific product implementation when a freely available standard exists.
    Couldn't agree more; I have spoken on this forum a long time ago that the best standard and the framework to code your application is the Java stack, don't go beyond it because it gonna kill you soon. We should have learned that lesson then when JBoss betrayed us by capitalizing the hard work of community that the only purpose of these open source projects or should I say products is to acquire by some big shark and then they slice and dice you at their will. Plus who gives me a guarantee that Gigaspace wouldn't be bought by Oracle or some other big vendor soon? As they say "fool me once shame on you, fool me twice shame on me" By saying that I don't have any doubt though you can fool developer community much more than twice:-) Common open source projects/products vendor we are waiting for you, come and fool us again.
  54. Re: Self-contradicting[ Go to top ]

    I have spoken on this forum a long time ago that the best standard and the framework to code your application is the Java stack, don't go beyond it because it gonna kill you soon.
    Rashid - what makes you think that this approach is less risky? Are you going to develop your own O/R mapping or Application container? or clustering? at some point you'll need to make a choice of either developing your own framework or use some other framework that does the work for you. Which one is a safer bet? Now standard API can help you just a bit - as you probably aware not all standards are adopted and many of them fail to make our life easier or keep up with our requirements. Beside what makes a standard that is developed by a small/medium interest group *safer* then a project that has big community behind it and have people of all kind voting/rating it almost on a daily basis by choosing to download it? We faced similar questions in GigaSpaces when we chose to invest in Spring and later Mule and other frameworks - the reason we went that route is simple - value vs effort. We managed that risk by implementing our integration in a way that if a new *Spring* will pop up will be able to support it as well (not without effort). So the argument is not if there is a risk-free alternative but which one will be less risky - sticking to standard is only one option, abstraction is another option, bytecode manipulation is also another option relying on highly adopted and supported OSS framework is also another option. Obviously the answer as to which path to choose should be measured on a per case basis, i can tell you that were using all of the above. I don't see how one can come with recommendation such as *stick to java* as the answer to that question.
    plus who gives me a guarantee that Gigaspace wouldn't be bought by Oracle or some other big vendor soon?
    Your not asking that seriously are you? What i can tell you though that were aiming to go public in two years and so far were making consistent 300% growth per year few years in a row. I can also tell you that we bet our success on our ability to plug-ourslefs into existing frameworks with as little intervention possible to avoid vendor lock-in. How do you know that it's not just a marketing statment? If you will also follow our development in the past few years you'll see that we consistently investing in that area through our support for standard api (JMS/JDBC/SQL) when it makes sense, or support declarative (Spring) abstractions on the messaging layer and on the data layer support declarative transactions,XA, Hibernate-plug-in as well as DAO. In addition to that we launched OpenSpaces as our opensource initiative designed to open our framework for external users. If you'll compare that with alternatives you'll see that were quite unique in that area. Now were not 100% there yet but were pretty close. Were going to publish papers and examples showing best practices on how to write code that can run with GigaSpaces as well as WebLogic, JBoss without changing your code and get the runtime benefits that GigaSpaces offers in terms of scaling, latency, simplicity etc. Knowing that were heavily invested in keeping this level of transparency and compete on the runtime capabilities (performance, scaling,latency,deployment) rather then API should give you the comfort level that your looking for more then anything else. So at the end of day if scaling, performance, continues availability and simplicity is of no real value to you, or your already happy with what you've got, then by all means GigaSpaces is probably not the answer for you. HTH Nati S.
  55. Re: Self-contradicting[ Go to top ]

    Are you going to develop your own O/R mapping or Application container? or clustering? at some point you'll need to make a choice of either developing your own framework or use some other framework that does the work for you. Which one is a safer bet?
    Nati no we never needed any thing beyond Java/J2EE standard API at least for 90% of the time. What happened to the motto learn once and apply every where, the biggest strength of Java. I am more than happy to use application server and O/R mapping if it is part of standard Java API as it is the case for (Servlet/EJB) container and now JDO/JPI, but I refuse to use 100's of different open source frameworks to persist data, to log data and render my GUI's . Plus application container and O/R mapping are the most over hyped word in Java. I mean have an example of .NET, they still don't have any concept of O/R mapping in their technology stack; and not many .NET applications are using any O/R mapping tool, instead they use the plain ADO.NET code to write Data Access Layer; and the last time I checked with .NET folks they are doing great. So if they can survive now, I would have easily survived the last 5 years of hype just writing plain JDBC code:-) Please don't get me wrong, of course there are many facets of application development and at some point you have to use tools and technologies beyond Java, and if that would be the case I would of course go and invest on the technologies like GigaSpace, Toplink etc. Again if I were running a business, my company main motto should be to make my development team productive on investing standard API's; instead of them downloading every day a new open source tool and don't deliver any thing for my business needs.
  56. Re: Self-contradicting[ Go to top ]

    I mean have an example of .NET, they still don't have any concept of O/R mapping in their technology stack;
    They don't? So I guess LINQ isn't an O/RM. And it's predessor (although it was never "released") wasn't either.
    and not many .NET applications are using any O/R mapping tool, instead they use the plain ADO.NET code to write Data Access Layer;
    I've been using NHibernate for a few years now. When I was looking for a .Net O/RM back then, it seemed there were more .Net ORM frameworks than Java ones. Until recently, Java ORMs were not widely used. Look at the job trend for Hibernate for an indication - http://www.indeed.com/jobtrends?q=hibernate&l= Anyway, if you look at code, whether it is Java or C#/VB, you will see many people attempting to write their "own" O/RM or at least incorporate the concepts.
    and the last time I checked with .NET folks they are doing great.
    I guess. Depends on your definition. I can crank out an NHibernate/Spring.Net app very quickly, compared to a bare ADO.Net one. Sure, a one page CRUD "app" can be done quickly with ADO.Net and databinding and a simple query. But I am talking a full application.
    So if they can survive now, I would have easily survived the last 5 years of hype just writing plain JDBC code:-)
    If it was so great, why LINQ?
  57. Clarifications[ Go to top ]

    Hi All, Apologies for the late response – just came back from a long flight. Anyway, I fully accept the criticism that has been made here about this post. We should have probably done a better job. I wrote my personal view on my blog during the flight back home, which should clarify many of the questions raised here and what does the Oracle-BEA acquisition mean WRT to the J2EE application server (note the use of application server and not J2EE API which are two are different things). I’ll try to cover the “what's next” part and obviously the GigaSpaces angle - you can read the full details here There are three things worth emphasizing from this post– 1. The claim to fame of the J2EE application server market was the ability to define a standard platform for running business applications, and then have multiple vendors competing on providing the best implementation of that standard. Oracle's acquisition of BEA marks an end of an era in that regard. Let's face it, there is no real open market out there. Both Oracle and IBM are now trying to push their bloated solution packages, which have very little in common with each other. 2. So what are the alternatives? The good news is that the alternatives are not just IBM or to a lesser degree JBoss, the alternatives is based on open source and new platforms geared for SaaS, a-la-SalesForce, Amazon and Google as noted in another analysis here: 3. Where does GigaSpaces fit in? For GigaSpaces this announcement has great timing. Many organizations are already building their own open middleware stack as a strategy – we basically help them to go all the way with that strategy by complementing those frameworks with runtime capabilities that address scalability, high-availability, performance, latency, deployment management, monitoring and more. The combination of GigaSpaces and the open frameworks, creates and Open Application Server alternative that is compatible, but independent from, the existing application servers. It is not necessarily bounded to a specific standard, but is still compatible with different platforms that support those same open frameworks, thus avoiding vendor lock-in. Specifically, users that build their business logic using Spring would be able to run that same application on top of WebLogic or GigaSpaces. At the end of the day, GigaSpaces' value is measured on our ability to improve performance, scalability and simplicity, not on the API itself. I hope that this clarify things better. Nati S. GigaSpaces
  58. Re: Clarification[ Go to top ]

    Nati, You must be joking: your so-called "clarification" is even more comical then the original Gigaspaces 'open letter', using terms like "plug in", "open", and "seamless" confuses the marketplace to a certain degree, but many of us have seen this before, particularly from WebSphere and occasional WebLogic proprietary extensions...so in that regard u have a point... But the marketplace has spoken and apparently deriding JBoss as a passing fad gives you the opportunity to speak of "Open Application Servers" as if this term means anything to anyone at Gigaspaces, because it means nothing to anyone outside of your red-faced company...many a person/company have predicted/called 4 the demise of the J2EE/JEE platform and all have been wrong... why would the pool of Java customers/developers/implementers work with Gigaspaces? Perhaps your answer is the ability to use any 'framework', and not be tied in to an 'API', as I think is how it reads, well, we shall see how that works for u, u have apparently chosen Spring over EJB, Hibernate over JPA, and Tomcat over Glassfish, all at a time when all of these are converging to bring more value to the developer community to which u speak... with all due respect, maybe it is time to sit down with your product management team to discuss standards 101, which includes upgrade mechanisms that do not force vendor lock-in, and come back to TSS with a different type of clarification, and then maybe some could get behind your "open" efforts, until then you have ostracized the application server market for a new (and admittedly growing) framework community that guarantees nothing but point-in-time popularity not specifications... there have been other build-your-own middleware threads on TSS, this may be the most audacious, and in that sense good marketing, i just believe the approach will result in a more limited market for Gigaspaces, and a more restricted shelf-life for your efforts...IMO...
  59. Re: Clarification[ Go to top ]

    Douglas Putting GigaSpaces aside for the sake of the discussion i wanted to ask for your opinion on the following, maybe that will help me understand better the point that your trying to make and more specifically your comment below.
    ..new (and admittedly growing) framework community that guarantees nothing but point-in-time popularity not specifications..
    I've been looking carefully at different applications architecture both from the financial world as well as web world (You can see a summary of what i observed from eBay, Yahoo, ..here). What became clear to me especially after hearing eBay, Yahoo, Amazon is that all of them had to develop their own and often huge framework to drive their application business logic, come up with different transaction semantics and consistency semantics, different approach to address scalability as well as security all the things that you would expect from an App Server right? Now if everything was so great then why would they have to develop all this huge middleware stack on their own? Very little if any of the things that they are dealing with seem to be even on the radar of the API spec that you refer to. Now its not just about API its also the entire Tier based approach that is broken. If you watch closely to all the services that is comming from Amazon/Google to drive thire SaaS initiative you'll realize that the gap from what the current set of specs has to offer is much bigger then what you think. An indication for that is an entire track dedicated for that topic in one of the upcoming events entitled The Cloud as the New Middleware Platform dedicated for that topic. So were talking on a potentially mega shift not jut "point-in-time popularity" Oh and BTW I'm not sure that you need all those superlatives to make a point. Nati S.
  60. Re: Nati[ Go to top ]

    I really don't see how my post has any ambiguity in it: i think your death knell for JEE is ridiculous, and it must be universally assumed to be in the very least premature, considering the data point of SpringSource's participation in the JCP on JEE6, which is what you have bet a major component of your 'architecture' on... Pointing out that a couple of "Web 2.0" companies have gone with something in addition to Java to run their operations does not a proof point make, and i would be highly suspect of an investment opportunity that promised to deliver on a standardized framework for Web 2.0 when there is widespread adoption of a competing platform in JEE... I really dont have to make my point, it is made for me by the likes of the ongoing success of Geronimo, Glassfish, JBoss, and the like...betting against this is what even the Spring guys have not done, and judging from your limited answer to this board's community and the skepticism that you have received to put on a flame campaign, I am counting the days for a retraction, that potentially may never come... a couple of questions: what do you think of Clustra and Glassfish' high-availability? what do you think of JBoss Cache? why wouldn't you work within the marketplace, instead of trying to 'create' your own on a theory that is kind of a straw-man right now?
  61. Re: Nati[ Go to top ]

    Douglas
    Pointing out that a couple of "Web 2.0" companies have gone with something in addition to Java to run their operations
    If you call eBay, Amazon, Yahoo, LinkedIn, Orbitz, ....couple of "Web 2.0", and if you think that what they developed is only few pieces of infrastructure on top of java - then i guess we have to define what you mean by "a couple" and a "something..". Just go through some of their slides in the last Qcon conference to see the vast investment and development they made on their architecture. We definitely are not wandering in the same circles. I understand that I'm not going to convince you in this thread, but I also suggest that you read what Vivek Ranadive, CEO and founder of Tibco has to say in an interesting interview: Is Enterprise Software Failing The Innovation Test?
    There has been really very little innovation because in the last 20 years we’ve been locked into extortionist database architecture. The mother of all databases, the relational database, is at the center of everything, which is why prices of databases have stayed the same. Then we’ve got these silos on top of the database — the enterprise resource planning (ERP) silos — which is just more extortion because you need a $100 million SAP implementation to make it work. Then you’ve got this tool called “business intelligence,” sitting on top of the ERP, which is oxymoronic because it’s only a reporting system – meaning it delivers information about what’s happened to your business after the fact, when it’s too late for you to do anything about it, so it’s not really “intelligence” at all. And then you’ve got these incredibly expensive service and consulting companies who try to make this legacy stack work. Put it all together and you’ve got a three-layered conspiracy of aligned interests to extort money from your company, which prevents incentives to innovate. It’s almost like a communist regime!
    I can also point you to hundreds of references that speak about a more fundamental change that is happening starting form the role of data bases, the *right* consistency semantics, and the scale-out model as an alternative to classic tier based approach. All are core aspects that have fundamental impact on the way we design our systems. Most of the current specs were simply not designed for these changes and that's why they fall short. Here are some of the additional references: See below quote from Michael Stonebraker in his post: One size fits all: A concept whose time has come and gone:
    "What I see happening is that the large database vendors, whom I’ll call the elephants, are selling a one-size-fits-all, 30-year-old architecture that dates from somewhere in the late 1970s. Way back then the technological requirements were very different; the machines and hardware architectures that we were running on were very different.
    As well as the reference from Pat Helland: Life Beyond Distributed Transactions I would also suggest that you will read what Werner Vogel CTO of Amazon had to say on Eventually Consistent. Failing to see this mega shift is not going to change the fact that the forces driving it are much bigger then what you and i agree upon - it's happening, it's real and it's not related to this or that spec (or even to this specific GigaSpaces announcement :)) As a side note I can't avoid the fact that this discussion reminds me of the old CORBA days when J2EE was first introduced, and of the EJB days before Hibernate and Spring approach became popular. Nati S.
  62. Re: potential final reply[ Go to top ]

    Nati, I understand what u r going 4, and it probably would be a lucrative market if u can get your hands on it, and i do agree with you that those web 2.0 companies are going to invest in off-the-shelf products sooner-rather-than-later...so u should feel empowered to try and make Gigaspaces attractive to those types of companies: at the expense of the JEE market, I am not so sure... I am a marketing person by background, so who am i to disparage an attempt to drum up business, even on TSS, so like i said, it is part of Joe's responsibility to bring these things to our attention, even those that fall outside the scope of this board... The EJB/Spring thing has been covered nearly ad nauseum here, so it does little to bring that up, from my p.o.v., they both appear to be doing well, from all anecdotal evidence... all the best, let me know if you ever would like an explanation of JEE's value prop. if Gigaspaces decides to go back in to that marketplace, douglas dooley douglasdooley.blogspot.com p.s. thx for the links, i'll wade through them later on...
  63. Re: Nati[ Go to top ]

    Nati, The Vivek Ranadive quote is sad reality been living behind for many years. In addition, to my chosen health care domain, which is in a phenomenal anemic state. Funny, the recent discussions how "Electronic" health records could be a good idea!
    There has been really very little innovation because in the last 20 years we’ve been locked into extortionist database architecture. The mother of all databases, the relational database, is at the center of everything, which is why prices of databases have stayed the same. Then we’ve got these silos on top of the database — the enterprise resource planning (ERP) silos — which is just more extortion because you need a $100 million SAP implementation to make it work. Then you’ve got this tool called “business intelligence,” sitting on top of the ERP, which is oxymoronic because it’s only a reporting system – meaning it delivers information about what’s happened to your business after the fact, when it’s too late for you to do anything about it, so it’s not really “intelligence” at all. And then you’ve got these incredibly expensive service and consulting companies who try to make this legacy stack work. Put it all together and you’ve got a three-layered conspiracy of aligned interests to extort money from your company, which prevents incentives to innovate. It’s almost like a communist regime!
    The above quote could also be the mission statement for the "Regional Health Information Organization" (RHIO) projects, which is suppose to integrate clinical information. The failure of CDC's National Electronic Disease Surveillance system (NEDSS) could be attributed with the quote as well. Will argue that politics is core of these demises along with the "Oracle" fixation. Anyway, regarding GigaSpaces, have to agree with Douglas:
    But the marketplace has spoken and apparently deriding JBoss as a passing fad gives you the opportunity to speak of "Open Application Servers" as if this term means anything to anyone at Gigaspaces, because it means nothing to anyone outside of your red-faced company...many a person/company have predicted/called 4 the demise of the J2EE/JEE platform and all have been wrong...
    I know what is was like before JEE, so today looking back, we have something "viable" to displace the database universe. It's politically correct to have a JEE stack, again - sad but true, politics has to be dealt with. Nevertheless, J2EE/JEE platform provides technical value to application projects along with thriving community participation. The facts: Spring's Rod, GigaSpaces and the other usual suspects chant JEE bashing and FUD to promote an agenda. Of course, nothing wrong with having an agenda, business models are behind many open source software projects. But, for example, with JBoss and GlassFish their promotion and implementation on standards provides comfortable-levels of adoption. Consequently, Red Hat (JBoss) and SUN (GlassFish) will benefit from services revenue because of value proposition not "lock-in" entrapment. Furthermore, as an consultant, the ability to freely explore "open" technologies without disclosing who and why is often understated. Take a look on how SUN is taking the SeeBeyond integration stack to open source Open ESB (JBI). Developed HL7 integration/clinical system with Open ESB without SUN. The point? Don't see any evidence of GigaSpaces participating in the standards community. Do see GigaSpaces making choices on my behalf saying what I should use and not use - a la Rod. JavaSpaces is great, We can really use a real "open" JavaSpaces leader that can enhance and promote standards JEE, JPA, JBI, JMS, JMX, BPEL, etc., and frameworks like Ruby on Rails, even Spring. This would help other software vendors, like "dbMotion" build capable products...
  64. Re: Nati[ Go to top ]

    Hi George
    Of course, nothing wrong with having an agenda, business models are behind many open source software projects. But, for example, with JBoss and GlassFish their promotion and implementation on standards provides comfortable-levels of adoption. Consequently, Red Hat (JBoss) and SUN (GlassFish) will benefit from services revenue because of value proposition not "lock-in" entrapment.
    Let me clear few things from all my previous statements: 1. I believe that there is fundamental architectural change that is undergoing toward tierless i.e. scale-out architecture. This will include changes in the way we handle transactions, persistencey and how we build and deploy our applications. 2. I believe that most of the application servers of today and their implementation of the J2EE API (JMS, JPA, ...) is not geared for that transition since they where not built for this type of deployments, they where primarily designed for taking our legacy to the web and served that purpose very well. 3. I believe that most of the new acronyms i.e. SOA/EDA/Grid suggest patterns that can take us to the promise land but no one is really answering the question on how we move from the existing tier based world to the promise land without complete re-architecting our entire application. GigaSpaces primary focus is to answer that question. We propose a gradual and evolutionary approach (Three steps..) and use virtualization techniques i.e. middleware virtualization (data +messaging) and deployment virtualization (through SLA driven container) both enable you to write the same code to a single machine and to a pool of machines and abstract the way you handle fail-over, scaling from the application code. Our claim to fame is our ability to do that relatively seamlessly - seamlessly since we provide API facade (JMS, Map, JDBC,..) that enables you to write code using your existing API over a totally different tierless implementation. We also use abstraction and injection (This where Spring fits in) to abstract your code from the way we deliver events, handle transactions etc. We provide tight integration with popular development frameoworks (Spring, Mule and even J2EE:) ) - I expect that you will consider GigaSpaces if your using any of those frameworks and you need to add scalability, performance,high availability latency without complete re-design or if you want to automate the way you deploy and scale your application using our SLA driven container. You would also consider using it if you need to provide that same level of capabilities and interoperate with .Net or CPP. Meaning that our value is not so much on the API but on the runtime and simplicity of development and deployment capabilities in fact if we could avoid dealing with API and just focus on the runtime area's that would have been our ideal scenario. Unfortunately the reality is that the standards are lagging behind that's why were forced to bridge that gap ourselfs and keep this part of our development open sourced. It is this position that makes us very different then most of the existing Application Servers i.e. the motivation NOT to lock-you in and integrate with existing popular development frameworks is core part of our business model. Our ability to do that well will determine our ability to grow. So to be clear my criticism on J2EE Application Server (less on the API) is on two parts: 1. The current Tier based approach and Server/DB centric implementations is simply too complex and doesn't scale. Most AppServers became such a bloated environments with very little value behind it hence why your seeing the raise of all this new frameworks. With the recent acquisition this became even more apparent then before. 2. The standardization process and the failure to realize that were facing such a change and slow paste in which we adopt innovation to meet that change put IMO the entire process in question i.e. i'm now questioning whether it will/can evolve to meet that change. Right now this is questionable and so far i have seen very little that will make me feel comfortable that this is moving in the right direction - again the recent acquisitions makes me feel even less comfortable then before since the biggest forces behind all this process is no focused on selling their non J2EE extended platforms. As i mentioned above were basically helping users to bridge this uncertainty period by allowing them to stick to tomact/spring/hibernate (i'm using those names just as an example) as alternatives and complement them with our (GigaSpaces) runtime capabilities to provide a real enterprise level alternative application server platform. Because of all the things i mentioned above this application server platform is also geared to take you to the next level of scale-out/EDA/SOA architecture in gradual manner. Since its very hard to capture all this information in a thread discussion i listed below additional references to online information in which i discussed those idea's with greater details - Soon we will publish more code examples and papers that illustrate more specifically how you take existing J2EE/Spring app and scale it without changing or with little change in your code. Three steps approach for scaling your tier based applications This presentation includes benchmark that we conducted comparing the before and after effect in terms of scalability, latency and performance and complexity when we used GigaSpaces over WebLogic implementation. In both cases Spring was used to abstract the code from the underlying runtime implementation and that's what helped us to keep the business logic pretty much the same. Scalable as Google Simple as Spring Online presentation from Spring ONE 2007. Code example for writing POJO/Spring based transactional applications and scale it out in a simple way. HTH Nati S.
  65. Re: Nati[ Go to top ]

    If you call eBay, Amazon, Yahoo, LinkedIn, Orbitz, ....couple of "Web 2.0", and if you think that what they developed is only few pieces of infrastructure on top of java - then i guess we have to define what you mean by "a couple" and a "something..".

    Just go through some of their slides in the last Qcon conference to see the vast investment and development they made on their architecture.
    Interesting list, since several of those companies are using Oracle Coherence in those architectures, and Orbitz even agreed to be a publicly referenceable account :-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  66. If you pay to use GigaSpaces now, you will continue paying to use GigaSpaces-H in the future because there'll be an Oracle-H which will buy the current GigaSpaces. I'll try my best to not use GigaSpaces just because of their open letter.
  67. Things happen[ Go to top ]

    Just write independent code and don't get fooled by candy that they sell with products and frameworks. So you like Weblogic Database Control? Don't! You like graphical pageflow? You like Weblogic Server? Do, but be ready to switch to anything, except .(dot). Weblogic customer
  68. Unlike most of others, I fully understand and support their decision of writing this open letter. Why not to let the world be acquainted with such a great solution? And does who neglect this, why don't you dare to see the world has other corners too? I came to know giga-spaces about four years ago, when I was working on my Jini-oriented master thesis, and just asked myself, how come the world of Java EE does not even know there is such a great solution? I do respect their decision to open-source and advertise open-spaces. Thanks to Nati and all of his active team.