- EJB 3 Introduction
http://www.youtube.com/watch?v=W-Tq93LUdMM&feature=results_video&playnext=1&list=PLCAD48825EA5D4B49
stateless means you can call stateless session bean without having previous data
statefull means each user has its own session bean so you can keep track of what's going on
If the session bean is stateless one stateless session bean can be used by many users as it does not have previous information regarding the session.
in case of stateful session bean each user can use its own session bean.
- Enterprise Java Beans - Introduction
http://www.youtube.com/watch?v=3YwSY8joz20&feature=fvwrel
RMI is designed to invoke remote methods in remote JVMs.However effect is same as if calling a function which is local to our machine
why do we need stub and skeleton?
if we pass arguments to the same jvm by RMI we pass the arguments by reference
Does it make a sense to send memory references to another heap as above mentioned?
stub serializes objects and skeleton deserializes the objecst instead of sending one memory heap to other machine
- Enterprise JavaBeans
Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications
Types of Enterprise Beans
Session Beans that can be either "Stateful", "Stateless" or "Singleton" and can be accessed via either a Local (same JVM)
or Remote (different JVM) interface or
directly without an interface, in which case local semantics apply.
All session beans support asynchronous execution for all views (local/remote/no-interface).
Message Driven Beans (also known as MDBs or Message Beans).
MDBs also support asynchronous execution, but via a messaging paradigm.
Session beans
Stateful Session Beans
Stateful Session Beans are business objects having state: that is, they keep track of which calling client they are dealing with throughout a session and thus access to the bean instance is strictly limited to only one client at a time.
Examples
Checking out in a web store might be handled by a stateful session bean that would use its state to keep track of where the customer is in the checkout process, possibly holding locks on the items the customer is purchasing
Stateless Session Beans
Stateless Session Beans are business objects that do not have state associated with them. However, access to a single bean instance is still limited to only one client at a time and thus concurrent access to the bean is prohibited.
In case concurrent access to a single bean is attempted anyway the container simply routes each request to a different instance.This makes a stateless session bean automatically thread-safe
Instance variables can be used during a single method call from a client to the bean, but the contents of those instance variables are not guaranteed to be preserved across different client method calls.
Instances of Stateless Session beans are typically pooled.
If a second client accesses a specific bean right after a method call on it made by a first client has finished, it might get the same instance.
The lack of overhead to maintain a conversation with the calling client makes them less resource-intensive than stateful beans
Examples
Sending an e-mail to customer support might be handled by a stateless bean, since this is a one-off operation and not part of a multi-step process.
Fetching multiple independent pieces of data for a website, like a list of products and the history of the current user might be handled by asynchronous methods of a session bean as well (these calls are asynchronous because they can execute in parallel that way, which potentially increases performance)
Singleton Session Beans
Singleton Session Beans are business objects having a global shared state within a JVM.
Concurrent access to the one and only bean instance can be controlled by the container (Container-managed concurrency, CMC) or by the bean itself (Bean-managed concurrency, BMC
Examples
Loading a global daily price list that will be the same for every user might be done with a singleton session bean, since this will prevent the application having to do the same query to a database over and over again.
Message driven beans
Message Driven Beans are business objects whose execution is triggered by messages instead of by method calls.
The Message Driven Bean is used among others to provide a high level ease-of-use abstraction for the lower level JMS (Java Message Service) specification
Examples
Sending a configuration update to multiple nodes might be done by sending a JMS message to a 'message topic' and could be handled by a Message Driven Bean listening to this topic (the message paradigm is used here, since the sender does not need to have knowledge about the amount of consumers or their location or even their exact type)
Entity beans (deprecated)
Previous versions of EJB also used a type of bean known as an Entity Bean.
These were distributed objects having persistent state
Beans in which their container managed the persistent state were said to be using Container-Managed Persistence (CMP), whereas beans that managed their own state were said to be using Bean-Managed Persistence (BMP)
In EJB 3.0, Entity Beans were replaced by the Java Persistence API, which was completely separated to its own specification to allow the EJB specification to focus only on the "core session bean and message-driven bean component models and their client API"
http://en.wikipedia.org/wiki/Enterprise_JavaBeans
No comments:
Post a Comment