Messaging or RMI / IIOP in EJB2.0 system
The following is the advantage of Messaging, and the reason you need to use: 1. Database performance. If you go to finish a relational database, if you hold a order for a database, use Messaging more advantageous. Transfer a message to a secondary message queue to deal with the main database pressure at the peak moment later. In the morning load in the morning, when the traffic is relatively small, you can remove and process the message in the message queue, and insert the order into the database. Note that this is just a role in the user's success, if there is no need to answer immediately, if his credit card is detected.
2. Quickly react. A customer may not want to be blocked and wait for a non-existent reflection. For a way to return VOID values, you can only return or return an exception without anything. If the customer does not expect an exception, why do you have to block a reaction? Messaging allows customers to deal with other things while he is blocked to get a way back.
3. Smoothing load balance. Message-Driven Beans smoother than session and EntityBeans. With Session and Entity Beans, a load balance algorithm is smart to guess which server load is smaller. With Messaging, the minimal server will request message to get that message.
4. Request priority. Asynchronous servers can queue, set priority, and process them in different sequential sequences to the MEAAAsge. Some message systems allow messages to be sorted by business rules. For example, in a military tank, if all the requests for the system are sent to the centralized distribution queue asynchronous, the gun's command may be disaster after 100 communication messages. In the military system, the fire control and security messages will be handled more advantage before the communication message. A queue that sets the priority allows for message rearrangement in the queue to calculate the urgentity of fire control in the tank.
5. Fast collection separation system. Many existing systems are based on messaging middleware, and can easily interact with your J2EE system with Messaging. Messaging provides a rapid development environment for commercial processing and distributed node systems that must communicate with each other.
6. Loose susceptibility system. Messaging can loosen the application between applications. Applications do not need to know each other when they are compile. This makes you have "dynamic discovery" applications that may be useful in fast-oriented, service-oriented business environments.
7. Parallel processing. Messaging is a method of using pseudo threads in EJB release. You can start a series of messages and continue to process, and the distributed startup Many threads.
8. Reliability. Messaging is used even if the server is dropped. System-level errors (such as databases) usually do not affect the success of the operation, because the message is still in the queue until the system level error is resolved.
9. Multi-to-many communications. If you have many groups to communicate with each other, Messaging is suitable because it makes many producers and consumers to collaborate with each other, and RMI / IIOP is a single source single-purpose request model.
Here are the case you should not use Messaging: 1. When you are not sure if the operation is successful. The RMI / IIOP system throws an exception, while the Message-Driven Bean is not.
2. When you need to return the result. The RMI / IIOP system will return the result immediately because the request is executed immediately. Instead, you can eventually return the results through Messaging, but this is very depressed: you need to send a separated return message, and listen to them with the initial client.
3. When your operation is a larger part of a transaction. When you send a message to your destination, the received Message-Driven Bean cannot handle other messages until a future transaction. This is not suitable for a separate, atomic, part of a transaction to handle other operations. For example, when you operate a bank account transfer, this time you use RMI / IIOP to save money to a bank account is a bad idea, using messaging to pay money, because the money may fail. 4. When you need to pass the customer's secure ID to the server. Because Messaging does not pass the customer's security ID to the received Message-Driven Bean, you cannot easily guarantee your business operation security.
5. When you care about request performance. Messaging is born to RMI / IIOP because there is a daemon (JMS) between the sender and the recipient.
6. When you need a strong type, OO system. You send messages by using the Messaging API such as JMS. This is a smoothed API and is not an object. When you want to complete different operations, the server needs Crack to open the message, or filter it off. In contrast, RMI / IIOP allows you to call different business methods based on business operations you want. This is more intuitive; it is also easier to compile the language.
7. When you need more close, more direct systems. Synchronous release is more direct than Messaging. When do you have a huge freedom to send a data type, and you need to write the least amount of code. Debug is also directly directly. When using a fully synchronized service, each client controlling the thread has a separate path that can be tracked from the client to the server, and is also true. When there is a bug, it is also a minimum of efforts to track their efforts.
