What is cloud computing?

Life before cloud computing

Traditional business applications—like those from SAP, Microsoft, and Oracle—have always been too complicated and expensive. They need a data center with office space, power, cooling, bandwidth, networks, servers, and storage. A complicated software stack. And a team of experts to install, configure, and run them. They need development, testing, staging, production, and failover environments.

When you multiply these headaches across dozens or hundreds of apps, it’s easy to see why the biggest companies with the best IT departments aren’t getting the apps they need. Small businesses don’t stand a chance.

Cloud-computing: a better way

Cloud computing is a better way to run your business. Instead of running your apps yourself, they run on a shared data center. When you use any app that runs in the cloud, you just log in, customize it, and start using it. That’s the power of cloud computing.

Businesses are running all kinds of apps in the cloud these days, like CRM, HR, accounting, and custom-built apps. Cloud-based apps can be up and running in a few days, which is unheard of with traditional business software. They cost less, because you don’t need to pay for all the people, products, and facilities to run them. And, it turns out they’re more scalable, more secure, and more reliable than most apps. Plus, upgrades are taken care of for you, so your apps get security and performance enhancements and new features—automatically.

The way you pay for cloud-based apps is also different. Forget about buying servers and software. When your apps run in the cloud, you don’t buy anything. It’s all rolled up into a predictable monthly subscription, so you only pay for what you actually use.

Finally, cloud apps don’t eat up your valuable IT resources, so your CFO will love it. This lets you focus on deploying more apps, new projects, and innovation.

The bottom line: Cloud computing is a simple idea, but it can have a huge impact on your business.

What is Cloud Computing?

Cloud computing is a paradigm of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.Users need not have knowledge of, expertise in, or control over the technology infrastructure in the "cloud" that supports them.
The concept generally incorporates combinations of the following:

* Infrastructure as a service (IaaS).
* Platform as a service (PaaS).
* Software as a service (SaaS).

The term cloudy is used as a metaphor for the Internet, based on how the Internet is depicted in computer network diagrams and is an abstraction for the complex infrastructure it conceals.

MDB Transaction Management & Acknowledge-Mode

"Message-driven beans should not attempt to use the JMS API for message acknowledgment. Message acknowledgment is automatically handled by the container. If the message-driven bean uses container managed transaction demarcation, message acknowledgment is handled automatically as a part of the transaction commit." CMT Acknowledge mode (Ref:EJB specs 2.0, section 15.4.8)

In JMS when you use distributed transactions (i.e. CMT) you cannot set the delivery mode, the message is acknowledged when the transaction commits successfully. That's why you shouldn't set acknowledge mode when using CMT.

When you use BMT the message is acknowledged when you return normally from the onMessage() method, i.e. that you do not throw a RuntimeException from inside the onMessage method. The difference between Auto-acknowledge and Dups-ok-acknowledge is that with Auto-acknowledge the bean provider is guaranteed that the message is only delivered once-and-only-once with Dups-ok-acknowledge you do not have that guarantee, and the bean provider should write could that can handle that the same message is delivered more than once. Dups-ok-acknowledge is supposed to be more performance efficient than Auto-acknowledge.

Best Practices for MDBs

• The following approaches and suggestions should be used during the development and deployment of MDBs:
• Consider using a session bean method for implementing and calling from onMesage()when business logic is complex.
• Avoid associating more than one MDB with the same JMS queue, because JMS does not define how messages are distributed between the queue receivers.
• Specify durability when using a topic with your MDB.
• If you want your MDB to be transactional, specify the transaction attribute to be Required . Only Required and NotSupported are allowed for container-managed transactions in MDB.
• Use the MessageSelector to filter out unwanted messages, leading to performance improvement.
• Specify acknowledgeMode when you use bean-managed transactions for your MDB. If you select Dups-ok-acknowledge, your MDBs must be able to handle duplicate messages correctly.
• When deciding on which flavor of connection-factories to use for lookup, you should use XA connection factories if your application components need to participate in a global transaction. Otherwise, use non-XA connection factories for better performance.
• To enable parallel processing of messages, define a value for activation-config-property named receiverThreads under the section where other properties are defined in ejb-jar.xml, e.g.:

Important Points

• Only REQUIRED or NOT_SUPPORTED transaction attributes are supported by the MBD.
• To deal with the poison messages, use delivery count and a dead message queue.
• MDB Callback methods are PostConstruct() and Predestroy()