cloudMQ (Message Queing as a Service) announces user forum

Home

News: cloudMQ (Message Queing as a Service) announces user forum

  1. [Ed: This relates back to the original CloudMQ post from last week: http://www.theserverside.com/news/thread.tss?thread_id=53169 ] Over the past few days we had more than 3,000 subscribers obtain free cloudMQ accounts... We are kicking off cloudMQ User Forum. We would like to hear your thoughts and ideas on best uses of cloudMQ on our new user forum

    Threaded Messages (25)

  2. I'm a little confused, though. Cloud computing has always had messaging capabilities - and platforms like Terracotta provides messaging implicitly. GigaSpaces uses JavaSpaces as a messaging transport explicitly and implicitly. It's good that cloud computing is becoming more prevalent, but... I don't know how many more "firsts" there are.
  3. I'm a little confused, though. Cloud computing has always had messaging capabilities - and platforms like Terracotta provides messaging implicitly. GigaSpaces uses JavaSpaces as a messaging transport explicitly and implicitly. It's good that cloud computing is becoming more prevalent, but... I don't know how many more "firsts" there are.
    I believe they are referring to "Enterprise Messaging on the Cloud" , which is vastly different in features from Amazon's SQS or JINI based frameworks such as GigaSpaces... For example some of the features that you would get with Enterprise MOM's , such as IBM MQ, ActiveMQ , SonicMQ and cloudMQ are: - Pub/Sub - Message order preservation - Single-phase and two-phase transactions - Unlimited message sizes - JMS & AMQP support
  4. I'm a little confused, though. Cloud computing has always had messaging capabilities - and platforms like Terracotta provides messaging implicitly. GigaSpaces uses JavaSpaces as a messaging transport explicitly and implicitly. It's good that cloud computing is becoming more prevalent, but... I don't know how many more "firsts" there are.


    I believe they are referring to "Enterprise Messaging on the Cloud" , which is vastly different in features from Amazon's SQS or JINI based frameworks such as GigaSpaces...

    For example some of the features that you would get with Enterprise MOM's , such as IBM MQ, ActiveMQ , SonicMQ and cloudMQ are:

    - Pub/Sub
    - Message order preservation
    - Single-phase and two-phase transactions
    - Unlimited message sizes
    - JMS & AMQP support
    You get all of the above with GigaSpaces.
  5. Just a bit of a details...
    - Pub/Sub
    You can publish and subscribe (push/pull) to/from space. You also have fine grained control over message partitioning.
    - Message order preservation
    You get that with FIFO support. <blockquote- Single-phase and two-phase transactions</blockquote> GigaSpaces has some of the best support I've seen for distributed transactions. It's also completely abstracted behind Spring's transaction support APIs.
    - Unlimited message sizes
    That's a pretty basic requirement. In GigaSpaces you write POJOs as messages and they can be of any size. The only limitation might be the size of your JVM heap, since GigaSpaces operates in memory. They might have serialization features as well, I haven't checked in a while.
    - JMS & AMQP support
    GigaSpaces supports JMS.
  6. http://www.theserverside.com/discussions/thread.tss?thread_id=39700#205099 GigaSpaces JMS implementation is based on JavaSpaces API which brings it's own set of advantages and disadvantages. I think comparing the two is comparing apples and oranges. JavaSpaces provies a distributed object exchange and coordination mechanism (which may or may not be persistent) for Java objects. It is used to store the distributed system state and implement distributed algorithms. In a JavaSpace all communication partners (peers) communicate and coordinate by sharing state. cloudMQ is focus is to provide reliable message based integration layer. For example, cloudMQ writes data to multiple devices and supports both restart recover as well as media recovery of the transactions. cloudMQ persists the transaction during the fail-over. JavaSpaces can be used to achieve scalability through parallel processing, it can also be used to provide reliable storage of objects through distributed replication, while this won't survive a total power failure like a disk it is regarded by many as reliable as long as the power is reliable. Distribution can also be to remote locations however this is rare as JavaSpaces are usually used to low-latency, high performance applications rather than reliable object caching. cloudMQ positions itself more for B2B applications looking for enterprise grade integration platform with low barrier of access and high reliability. For example cloudMQ supports FIPS 140-2 cryptography. Automatic conversions across coded character sets and integer notations. Message arrival and consumption non-repudiation. Remote failure event notification as well as remote expiry. cloudMQ also seeks to be open enough to be integrated to work as a stand alone messaging provider(no installation or ec2 account necessary) or to be integrated as a JMS provider for any other application server including JBoss or WebSphere. It has a GUI management interface through which users can track connections and create queues. JavaSpaces is part of the Java Jini technology, which on its own has not been a commercial success. The technology has found and kept new users over the years and some vendors are offering JavaSpaces-based products. JavaSpaces remains a niche technology mostly used in the financial services and telco industries.
  7. The concern wasn't that CloudMQ == GigaSpaces or ActiveMQ or whatever. The concern for me was the description as "first cloud-based enterprise messaging platform." It makes perfect sense that CloudMQ is differentiated. That's fine; there's lots of room for feature sets in most things. But "first" cloud-based enterprise messaging platform? I don't think GigaSpaces could make that claim either - but considering that GigaSpaces is older than CloudMQ, and GigaSpaces can ALSO claim to be a "cloud-based enterprise messagin platform," I think the CloudMQ claim to that title would be rather invalidated.
  8. If cloudMQ infrastructure does lose one message, are you going to pay back money equal to the interest rate I could acquire for business value of message in question for given delay period?
  9. GigaSpaces JMS implementation is based on JavaSpaces API which brings it's own set of advantages and disadvantages. I think comparing the two is comparing apples and oranges.
    Not really, I don't think anyone cares what the internal implementation is based on, as long as they have a set of common APIs. If you can access a spaced based architecture using JMS apis, then how is it different than any other service that exposes JMS?
    JavaSpaces provies a distributed object exchange and coordination mechanism (which may or may not be persistent) for Java objects. It is used to store the distributed system state and implement distributed algorithms. In a JavaSpace all communication partners (peers) communicate and coordinate by sharing state.
    Ok, and what are you doing when you're publishing messages? You can call that sharing state as well. The format of the message is not a POJO, but who cares?
    cloudMQ is focus is to provide reliable message based integration layer. For example, cloudMQ writes data to multiple devices and supports both restart recover as well as media recovery of the transactions. cloudMQ persists the transaction during the fail-over.
    So does GigaSpaces.
    JavaSpaces can be used to achieve scalability through parallel processing, it can also be used to provide reliable storage of objects through distributed replication, while this won't survive a total power failure like a disk it is regarded by many as reliable as long as the power is reliable.
    Probably true, though I haven't touched GigaSpaces in a while. But this also buys you scalability, as objects are in memory and do not incur the disk IO overhead. Also, on EC2, using replication failover and striping, one can create a very highly available architecture. Yes, all 20 boxes can go down, but the chances of that happening is probably pretty equivalent of your disk failing and getting corrupted along with all the backups.
    Distribution can also be to remote locations however this is rare as JavaSpaces are usually used to low-latency, high performance applications rather than reliable object caching.
    I'm not sure what you mean by remote, are you talking WAN, or any remote. GigaSpaces runs fine on EC2 and will run fine in a high latency LAN environment. It would suffer from same issues as any other WAN distributed application. That's why partitioning is used to resolve this issue and bring data close to where it'll be processed, though once a data set is partitioned, the logical or physical partition within a LAN or within a single JVM can operate on that date with minimal or no latency. I'm sure you guys offer services that differentiate you from GigaSpaces. I'm actually looking for a simple queue services right now for an applications and Amazon SQS latency is not acceptable. I'll look closer at your service. I just wanted to point out that you're focusing on the wrong benefits. Posting this on TSS will get mostly negative responses especially when you claim to be the first to provide a service that's been available for years. Thanks. Ilya
  10. First of all GS does use JavaSpaces API api. See reference above. http://www.theserverside.com/discussions/thread.tss?thread_id=39700#205099 Secondly, I think people do care what the underlying implementation is because your persistence layer will primarily determine both performance and reliability. Here is an example. http://tech.groups.yahoo.com/group/jug-detroit/message/437 I think you're missing my point entirely. While cloudMQ and GS may have some features in common, cloudMQ is an internet scale messaging service with enterprise features. Our clients do not need to have their own expertise in caching or messaging infrastructures. It is an integration platform via cloud for enterprises. GigaSpaces is an application server. Most importantly from the business perspective it is a neutral platform that can be accessed for intra and inter organizational integration with no upfront effort while providing SLA as any service provider would.
  11. First of all GS does use JavaSpaces API api. See reference above. http://www.theserverside.com/discussions/thread.tss?thread_id=39700#205099
    Yes, and GigaSpaces also allows you to use a JMS adapter API to talk to the spaces. So I don't see your point. API is just that, an API. You can create adapters to adapt to an API, as long as it fulfills the basic requirements of the service.
    Secondly, I think people do care what the underlying implementation is because your persistence layer will primarily determine both performance and reliability.

    Here is an example.
    http://tech.groups.yahoo.com/group/jug-detroit/message/437
    Not sure what you're trying to prove by posting a link to a post I made a few days ago. I think as long as a service can make certain guarantees, unless you can prove these guarantees false by knowing the internal implementation, it shouldn't matter. If GS guarantees FIFO, they "guarantee" FIFO, regardless of global ordering algorithm they use. Yes, GS stores objects in memory and you can persist them in multiple ways to disk. Yes, if all of your power goes out and you don't have a redundant architecture, you can loose data, the same thing can happen if your disks go bad. I don't see your point. Durability guarantees != disk.
    I think you're missing my point entirely. While cloudMQ and GS may have some features in common, cloudMQ is an internet scale messaging service with enterprise features.
    I'm not missing the point, I even mentioned that I was planning on looking at your service for a project I was working on. I understand the benefits, but my concern just as Joseph's was the mention of ""first cloud-based enterprise messaging platform". First the term enterprise makes me want to laugh. Stop it, please. Maybe it helps you sell products to high level management, but this is TSS and most folks here have a clue. Second you're by far not the first, not even close. Now, you should be pushing the fact that it might be a service that allows a smaller learning curve, less or no administration, and no familiarity with caching/queuing architectures. That I think is a big plus. It is true that in some cases folks might not want to administer and manage their own messaging (what ever this messaging implementation is) infrastructure. I long thought about utilizing SQS, but it's latency is not acceptable for the high throughput application that we have. I'll definitely check out your service, but not because you're the first to provide "enterprise messaging" in the cloud. Ilya Our clients do not need to have their own expertise in caching or messaging infrastructures. It is an integration platform via cloud for enterprises. GigaSpaces is an application server.

    Most importantly from the business perspective it is a neutral platform that can be accessed for intra and inter organizational integration with no upfront effort while providing SLA as any service provider would.
  12. One other thing, check out http://www.gigaspaces.com/wiki/display/XAP66/JMS. Numerous APIs to access (POJOs, messages) in the space.
  13. First of all GS does use JavaSpaces API api.
    ... in addition to other APIs, including JMS, JCache, and JDBC. Just trying to keep the conversation accurate.
    I think you're missing my point entirely. While cloudMQ and GS may have some features in common, cloudMQ is an internet scale messaging service with enterprise features. Our clients do not need to have their own expertise in caching or messaging infrastructures. It is an integration platform via cloud for enterprises. GigaSpaces is an application server.
    GigaSpaces is also an integration platform via cloud for enterprises: that's my whole point. That's not a differentiator for CloudMQ yet.
    Most importantly from the business perspective it is a neutral platform that can be accessed for intra and inter organizational integration with no upfront effort while providing SLA as any service provider would.
    What does "neutral platform" mean? The way I understand "neutral platform," GigaSpaces would fit that just like Terracotta DSO and CloudMQ would.
  14. Also, on EC2, using replication failover and striping, one can create a very highly available architecture. Yes, all 20 boxes can go down, but the chances of that happening is probably pretty equivalent of your disk failing and getting corrupted along with all the backups.
    Or EC2 can become completely unavailable as S3 did for a number of hours about a year ago or your internet connection could go down. Oh man, I'm doing it again, talking reality and all. Forget I said anything. Put all your eggs in the cloud-basket. No one loses their connection to the internet, ever. Well, I did yesterday at work but I'm sure that's the last time anyone will. Nothing could ever go wrong with added multiple single points of failure. And even if it does, nobody will hold you accountable for it because it's the hot trend. The "8 Fallacies of Distributed Programming" are dead. It's like the new economy when P/E ratios can go infinite. Too dated? Let's see... Real estate never loses value. It's just like that. Anybody who questions these kinds of assertions is just a buzz-kill. I sincerely apologize to you all.
  15. Yes, your home built infrastructure could become completely unavailable as well. what's your point? Unless you work for a large company that can invest millions on dollars in building a resilient infrastructure, I'd argue that Amazon has more resources than my firm and I'd much rather trust them to keep it up and running. With that said, no one is saying put all your eggs in one basket. EC2 is a good way to scale up for startups and smaller companies that can't afford it otherwise, but I definitely wouldn't build the whole business model just on that. Ilya
  16. Yes, your home built infrastructure could become completely unavailable as well. what's your point?
    That is my point. If your 'home built' infrastructure fails to provide access to the internet, no amount of redundancy in the cloud is going to help you. And you are completely ignoring the differing odds different types failures.
    Unless you work for a large company that can invest millions on dollars in building a resilient infrastructure, I'd argue that Amazon has more resources than my firm and I'd much rather trust them to keep it up and running.
    That's a false dichotomy. You can have both local systems and remote redundancy. That's what we do where I work. Basic statistics: if you have two services with a .1 percent chance of failure over certain period of time, the odds that both will fail at once during that period is .01 (assuming the failures are unrelated to keep things simple). If you have local and remote systems, you would have to lose both the internet and your local systems at the same time. The odds of that happening are much lower than losing your connection to the internet.
    With that said, no one is saying put all your eggs in one basket.
    Of course people are. And why do people fly off of the handle every time I point our (purely factual) downsides of the cloud? You'd think I pissed in their cornflakes.
    EC2 is a good way to scale up for startups and smaller companies that can't afford it otherwise, but I definitely wouldn't build the whole business model just on that.
    I didn't say anything about business models. I'm talking about the kinds of things that technical professionals are suppose to know and consider in when making plans. These are purely technical considerations. I absolutely agree that toy startups that no one really depends on are fine for the cloud. Especially if you are talking about the typical billions-or-bust type startup. If you fail because of the cloud, well, you were probably going to fail for some other reason anyway. If you were going under for surgery, would you want hospital equipment to run off of the cloud? Would you like your bank account to be hosted on a big honey-pot cloud? How about all of your medical records and tax filings? Heartland gets hacked and doesn't bother to tell their customers for months. Oh well. Amazon fails to achieve their SLA and people pretend like it never happened. How long until Amazon has a breech? It's a very sweet target. The cloud is a great thing. But like any tool it's got negatives along with positives. I don't get the emotional attachment to the cloud. It's not your best girl. It's a computer architecture.
  17. James, I agree with the fact that both local and remote systems should be employed for redundancy. I never looked at EC2 as a sole provider of computing resources, but it's a great cost effective way to scale for businesses that can't afford to scale by buying physical resources.
  18. James, I agree with the fact that both local and remote systems should be employed for redundancy. I never looked at EC2 as a sole provider of computing resources, but it's a great cost effective way to scale for businesses that can't afford to scale by buying physical resources.
    Absolutely. I see myself taking advantage of it or something similar in the near future. Just because I recognize that there are challenges that come with the cloud doesn't mean I don't recognize opportunity that it provides. One of the great things I see the cloud providing is pay-as-you go capacity needs are high or when it can be had cheaply off hours. However, what I see is a lot of talk about the advantages of the cloud but very little about the risks and how to manage them. For example, people often talk about the redundancy you get with EC2 but neglect to take into consideration that they could lose contact with it. And there are people who straight-up tell you to put everything on the cloud. I apologize for giving the impression that I was accusing you personally of this. I suppose if your entire business is running on the cloud and it can run without you having contact with it, it's less of a concern but for most businesses, this is not realistic. We use a popular SaaS product and it's been pretty much a complete debacle. Aside from the ineptitude of the vendor, our connection to the internet goes down much more frequently than any of our internal systems (which almost never go down.)
  19. Yes, your home built infrastructure could become completely unavailable as well. what's your point?
    Perhaps you need to read my posts again. As James Watson implies everything has limitations and will possibly fail. GS, ActiveMQ, OpenMQ, SQS, cloudMQ. cloudMQ is enterprise Messaging as a Service platform. You can read this at the very top of our web page. If users want to deploy whatever container, caching solution or jms provider into the cloud and use it and put that is up to them. That is not our target customer base. We're interested in customers who are looking for messaging service which already leverages elastic resources of EC2 in a fashion that is transparent to them.
  20. I think you're missing the point. No one is discrediting some value that you provide and the fact that you're doing in in a cloud. James and I were talking about something completely different. I think the negative responses you received here had to do with your marketing message of first enterprise messaging solution for the cloud. That's just not true.
  21. In that case, can you please show me where Kathy or I have claimed cloudMQ to be the FIRST cloud based messaging solution. Here are Kathy's posts. http://www.theserverside.com/user/userthreads.tss?user_id=820003 Here are mine. http://www.theserverside.com/user/userthreads.tss?user_id=820589 Here is the eWeek article http://www.eweek.com/c/a/Application-Development/CloudMQ-Takes-Message-Queuing-to-the-Cloud/ Here is our website http://www.cloudmq.com Here is the twitter page http://twitter.com/cloudMQ Can you please show me where anyone has claimed cloudMQ to be first anything? The debate started with "Giga Space Me Too." Ok fine no problem. We're not a container for cloud or otherwise. At the cost/quality/85% market share WebSphere MQ beats the pants off just about any JMS provider. So now, we claim to be the first ones but that's not a claim we made either. Who did then? http://www.theserverside.com/news/thread.tss?thread_id=53443#303792 Don't let other people yank your chain, unless you're getting paid for it of course.
  22. The thread started off as "but... what's the differentiator?" and I still haven't quite been satisfied as to what the differentiators are.
  23. my guess is: "cloudMQ proudly announces first registered forum user"
  24. my guess is:

    "cloudMQ proudly announces first registered forum user"
    Agree. Come on now, on the main page of TSS we have to see 'news' like this. I wish all the best couldMQ crew, however, this was really not worth the main page.
  25. Difference with any JMS provider?[ Go to top ]

    After reading the documentation I still can't quite figure out what is the difference between cloudMQ and simply running ActiveMQ or OpenMQ JMS brokers on the cloud? What are the benfits? One can run OpenMQ on the EC2 in 20 minutes... Thanks, Nikita Ivanov. GridGain - Open Cloud Platform
  26. After reading the documentation I still can't quite figure out what is the difference between cloudMQ and simply running ActiveMQ or OpenMQ JMS brokers on the cloud? What are the benfits? One can run OpenMQ on the EC2 in 20 minutes...

    Thanks,
    Nikita Ivanov.
    GridGain - Open Cloud Platform
    Nikita, cloudMQ is quite different from OpenMQ or ActiveMQ. Most importantly, it is not a software but a managed internet scale service more similar to SQS but with enterprise features such as: Transactions Ordering (SQS does not guarantee messages will arrive on the queue in the same order producer intended) Media recovery (all transactions are stored and can replayed) Guaranteed delivery Coded character set conversion Integer notation Integrates into other app servers Support for FIPS 140-2 Encryption PKI Based Bi-directional Authentication Message encryption in transit and in storage Message delivery and consumption non-repudiation Isolated queue and topic namespaces Access Log Remote message processing failure notifications Remote message expiry notifications Most enterprise customers even with ec2 will not be able to scale messaging infrastructures to support large messaging volumes. cloudMQ addresses specifically those needs of the enterprises - an internet scale enterprise messaging service. HTH. Mikhail.