Explore topic-wise InterviewSolutions in .

Java Bean as is a PLAIN java class with MEMBER variables and getter setter methods. Java Beans are defined under JavaBeans specification as Java-Based software component model which includes the features like introspection, customization, EVENTS, properties and persistence.

Enterprise JavaBeans or EJBs for short are Java-based software components that comply with Java's EJB specification. EJBs are delpoyed on the EJB container and executes in the EJB container. EJB is not that SIMPLE, it is used for building distributed applications. Examples of EJB are Session Bean, Entity Bean and Message Driven Bean. EJB is used for server side programming whereas java bean is a client side. Bean is only development but the EJB is DEVELOPED and then deployed on EJB Container.

Java Bean as is a plain java class with member variables and getter setter methods. Java Beans are defined under JavaBeans specification as Java-Based software component model which includes the features like introspection, customization, events, properties and persistence.

Enterprise JavaBeans or EJBs for short are Java-based software components that comply with Java's EJB specification. EJBs are delpoyed on the EJB container and executes in the EJB container. EJB is not that simple, it is used for building distributed applications. Examples of EJB are Session Bean, Entity Bean and Message Driven Bean. EJB is used for server side programming whereas java bean is a client side. Bean is only development but the EJB is developed and then deployed on EJB Container.

These files are simply zipped file using JAVA jar tool. These files are created for DIFFERENT purposes. Here is the description of these files:
• .jar files: These files are with the .jar extension. The .jar files CONTAINS the LIBRARIES, resources and accessories files like property files.
• .war files: These files are with the .war extension. The war file contains the web APPLICATION that can be deployed on the any servlet/jsp container. The .war file contains jsp, html, javascript and other files for necessary for the development of web applications.
• .ear files: The .ear file contains the EJB modules of the application.

These files are simply zipped file using Java jar tool. These files are created for different purposes. Here is the description of these files:
• .jar files: These files are with the .jar extension. The .jar files contains the libraries, resources and accessories files like property files.
• .war files: These files are with the .war extension. The war file contains the web application that can be deployed on the any servlet/jsp container. The .war file contains jsp, html, javascript and other files for necessary for the development of web applications.
• .ear files: The .ear file contains the EJB modules of the application.

A WEB module may contain:
(a) JSP files,
(B) Java classes,
(c) gif and html files, and
(d) Web COMPONENT deployment descriptors.

A web module may contain:
(a) JSP files,
(b) Java classes,
(c) gif and html files, and
(d) Web component deployment descriptors.

A J2EE MODULE is a software unit that consists of one or more J2EE components of the same container type ALONG with one deployment DESCRIPTOR of that type. J2EE specification defines FOUR types of MODULES:
(a) EJB,
(b) Web,
(c) Application client, and
(d) Resource Adapter.

A J2EE module is a software unit that consists of one or more J2EE components of the same container type along with one deployment descriptor of that type. J2EE specification defines four types of modules:
(a) EJB,
(b) Web,
(c) Application client, and
(d) Resource Adapter.

It is better not to do it will make the Bean CLASS a remote object and its methods can be accessed without the containers security, and transaction implementations if our CODE by MISTAKE passed it in one of its parameters. Its just a GOOD design practice.

It is better not to do it will make the Bean class a remote object and its methods can be accessed without the containers security, and transaction implementations if our code by mistake passed it in one of its parameters. Its just a good design practice.

STATELESS - true always. Stateful - DEPENDS WHETHER the references POINT to the same SESSION object. Entity - Depends whether the primary key is the same and the home is same.

Stateless - true always. Stateful - depends whether the references point to the same session object. Entity - Depends whether the primary key is the same and the home is same.

A CLIENT program that is intended to be interoperable with all compliant EJB Container implementations must use the javax.rmi.PortableRemoteObject.narrow(…) METHOD to perform type-NARROWING of the client-side REPRESENTATIONS of the remote home and remote interfaces. Programs using the cast operator for narrowing the remote and remote home interfaces are likely to FAIL if the Container implementation uses RMI-IIOP as the underlying communication transport.

A client program that is intended to be interoperable with all compliant EJB Container implementations must use the javax.rmi.PortableRemoteObject.narrow(…) method to perform type-narrowing of the client-side representations of the remote home and remote interfaces. Programs using the cast operator for narrowing the remote and remote home interfaces are likely to fail if the Container implementation uses RMI-IIOP as the underlying communication transport.

You try to make all nontransient variables, which are not one of the FOLLOWING to null. For the given list the container takes care of SERIALIZING and restoring the object when activated. Serializable objects, null, UserTransaction, SessionContext, JNDI contexts in the beans context, REFERENCE to other beans, references to connection POOLS. THINGS that must be handled explicitly are like a open database connection etc. These must be closed and set to null and retrieved back in the activate method.

You try to make all nontransient variables, which are not one of the following to null. For the given list the container takes care of serializing and restoring the object when activated. Serializable objects, null, UserTransaction, SessionContext, JNDI contexts in the beans context, reference to other beans, references to connection pools. Things that must be handled explicitly are like a open database connection etc. These must be closed and set to null and retrieved back in the activate method.

EJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended to support to standard CORBA transport for these calls using RMI/IIOP. This design allowed for maximum flexibility in developing applications without CONSIDERATION for the deployment scenario, and was a strong feature in support of a goal of COMPONENT reuse in J2EE. Many developers are using EJBs locally - that is, some or all of their EJB calls are between beans in a single CONTAINER. With this feedback in mind, the EJB 2.0 expert group has created a local interface mechanism. The local interface may be defined for a bean during development, to allow streamlined calls to the bean if a caller is in the same container. This does not involve the overhead involved with RMI like marshalling etc. This facility will thus improve the performance of applications in which co-location is planned. Local interfaces also provide the foundation for container-managed relationships AMONG entity beans with container-managed PERSISTENCE.

EJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended to support to standard CORBA transport for these calls using RMI/IIOP. This design allowed for maximum flexibility in developing applications without consideration for the deployment scenario, and was a strong feature in support of a goal of component reuse in J2EE. Many developers are using EJBs locally - that is, some or all of their EJB calls are between beans in a single container. With this feedback in mind, the EJB 2.0 expert group has created a local interface mechanism. The local interface may be defined for a bean during development, to allow streamlined calls to the bean if a caller is in the same container. This does not involve the overhead involved with RMI like marshalling etc. This facility will thus improve the performance of applications in which co-location is planned. Local interfaces also provide the foundation for container-managed relationships among entity beans with container-managed persistence.

EJB 2.0 extends CMP to include FAR more robust MODELING capability, with support for declarative management of relationships between entity EJBs. Developers no longer need to re-establish relationships between the various beans that make up their application — the container will RESTORE the connections automatically as beans are loaded, allowing bean developers to NAVIGATE between beans much as they would between any standard Java objects.

EJB 2.0 also introduces for the first time a portable query language, based on the ABSTRACT schema, not on the more complex database schema. This provides a database and vendor-independent way to find entity beans at run time, based on a wide variety of search criteria.

EJB 2.0 extends CMP to include far more robust modeling capability, with support for declarative management of relationships between entity EJBs. Developers no longer need to re-establish relationships between the various beans that make up their application — the container will restore the connections automatically as beans are loaded, allowing bean developers to navigate between beans much as they would between any standard Java objects.

EJB 2.0 also introduces for the first time a portable query language, based on the abstract schema, not on the more complex database schema. This provides a database and vendor-independent way to find entity beans at run time, based on a wide variety of search criteria.

EJB 2.0 mandates integration between JMS and EJB. We have specified the integration of Enterprise JavaBeans with the Java Message Service, and have INTRODUCED message-driven beans. A message-driven bean is a stateless component that is invoked by the container as a result of the arrival of a JMS message. The goal of the message-driven bean MODEL is to MAKE developing an enterprise bean that is asynchronously invoked to handle the PROCESSING of INCOMING JMS messages as simple as developing the same functionality in any other JMS MessageListener.

EJB 2.0 mandates integration between JMS and EJB. We have specified the integration of Enterprise JavaBeans with the Java Message Service, and have introduced message-driven beans. A message-driven bean is a stateless component that is invoked by the container as a result of the arrival of a JMS message. The goal of the message-driven bean model is to make developing an enterprise bean that is asynchronously invoked to handle the processing of incoming JMS messages as simple as developing the same functionality in any other JMS MessageListener.

YES, an XSLT processor, BASED on APACHE’s Xalan 2.0.1 processor, in WEBLOGIC Server 6.1.

Yes, an XSLT processor, based on Apache’s Xalan 2.0.1 processor, in WebLogic Server 6.1.

Yes. BEGINNING with WebLogic Server version 6.0, EJBS must be homogeneously deployed across a cluster for the FOLLOWING reasons:

• To keep clustering EJBs simple.
• To avoid cross server calls which results in more EFFICIENCY. If EJBs are not deployed on all servers, cross server calls are much more likely.
• To ensure that every EJB is available locally.
• To ensure that all classes are loaded in an undeployable way.
• Every server must have access to each EJB’s classes so that it can be bound into the local JNDI tree. If only a subset of the servers deploys the bean, the other servers will have to load the bean’s classes in their respective system classpaths which MAKES it impossible to undeploy the beans.

Yes. Beginning with WebLogic Server version 6.0, EJBs must be homogeneously deployed across a cluster for the following reasons:

BEA RECOMMEND that you USE the TxDataSource for bean-managed PERSISTENCE.

BEA recommend that you use the TxDataSource for bean-managed persistence.

As such there is no LIMIT on the amount of information that can be saved in a Session Object. Only the RAM available on the server MACHINE is the limitation. The only limit is the Session ID length(Identifier), which should not exceed more than 4K. If the data to be store is very huge, then it’s preferred to save it to a temporary file onto hard disk, rather than saving it in session. Internally if the amount of data being saved in Session exceeds the predefined limit, most of the servers WRITE it to a temporary CACHE on Hard disk.

As such there is no limit on the amount of information that can be saved in a Session Object. Only the RAM available on the server machine is the limitation. The only limit is the Session ID length(Identifier), which should not exceed more than 4K. If the data to be store is very huge, then it’s preferred to save it to a temporary file onto hard disk, rather than saving it in session. Internally if the amount of data being saved in Session exceeds the predefined limit, most of the servers write it to a temporary cache on Hard disk.

Naming Interface- The naming interface organizes information hierarchically and maps human-friendly names to ADDRESSES or objects that are machine-friendly. It allows access to named objects through multiple NAMESPACES. Directory Interface - JNDI includes a directory service interface that provides access to directory objects, which can CONTAIN attributes, thereby providing attribute-based searching and schema support. Service Provider Interface - JNDI comes with the SPI, which supports the protocols PROVIDED by third parties.

Naming Interface- The naming interface organizes information hierarchically and maps human-friendly names to addresses or objects that are machine-friendly. It allows access to named objects through multiple namespaces. Directory Interface - JNDI includes a directory service interface that provides access to directory objects, which can contain attributes, thereby providing attribute-based searching and schema support. Service Provider Interface - JNDI comes with the SPI, which supports the protocols provided by third parties.

lookup() :attempts to find the specified object in the given context. I.e., it looks for a single, SPECIFIC object and either FINDS it in the current context or it fails.

list(): attempts to return an enumeration of all of the NameClassPair’s of all of the objects in the current context. I.e., it’s a listing of all of the objects in the current context but only returns the object’s name and the name of the CLASS to which the object belongs.

listBindings(): attempts to return an enumeration of the Binding’s of all of the objects in the current context. I.e., it’s a listing of all of the objects in the current context with the object’s name, its class name, and a reference to the object itself.

search(): attempts to return an enumeration of all of the objects matching a given SET of search criteria. It can search across multiple contexts (or not). It can return whatever attributes of the objects that you desire. It’s by far the most complex and powerful of these options but is also the most expensive.

lookup() :attempts to find the specified object in the given context. I.e., it looks for a single, specific object and either finds it in the current context or it fails.

list(): attempts to return an enumeration of all of the NameClassPair’s of all of the objects in the current context. I.e., it’s a listing of all of the objects in the current context but only returns the object’s name and the name of the class to which the object belongs.

listBindings(): attempts to return an enumeration of the Binding’s of all of the objects in the current context. I.e., it’s a listing of all of the objects in the current context with the object’s name, its class name, and a reference to the object itself.

search(): attempts to return an enumeration of all of the objects matching a given set of search criteria. It can search across multiple contexts (or not). It can return whatever attributes of the objects that you desire. It’s by far the most complex and powerful of these options but is also the most expensive.

The Java AUTHENTICATION and Authorization Service (JAAS) PROVIDES a way for a J2EE application to authenticate and authorize a SPECIFIC USER or group of users to run it. JAAS is a Java programing language version of the standard Pluggable Authentication Module (PAM) framework that extends the Java 2 platform security ARCHITECTURE to support user-based authorization.

The Java Authentication and Authorization Service (JAAS) provides a way for a J2EE application to authenticate and authorize a specific user or group of users to run it. JAAS is a Java programing language version of the standard Pluggable Authentication Module (PAM) framework that extends the Java 2 platform security architecture to support user-based authorization.

A URL INSTANCE represents the location of a resource, and a URLConnection instance represents a link for ACCESSING or communicating with the resource at the location.

A URL instance represents the location of a resource, and a URLConnection instance represents a link for accessing or communicating with the resource at the location.

Abstraction is removing some distinctions between objects, so as to show their COMMONALITIES. ENCAPSULATION is hiding the details of the implementation of an object so that there are no external dependencies on the PARTICULAR implementation.

Abstraction is removing some distinctions between objects, so as to show their commonalities. Encapsulation is hiding the details of the implementation of an object so that there are no external dependencies on the particular implementation.

WEB SERVERS can be clustered using Edge SERVER or DNS.

Web Servers can be clustered using Edge Server or DNS.

Identical DATASOURCE has to be CREATED in each clustered server instances and configure to use different CONNECTION pools.

Identical DataSource has to be created in each clustered server instances and configure to use different connection pools.

The data in SESSION should CONSIST only of SERIALIZED OBJECTS. Only setAttribute function should be USED to set objects in session.

The data in session should consist only of Serialized objects. Only setAttribute function should be used to set objects in session.

The workload MANAGEMENT service provides load balancing for the following types of enterprise beans: Homes of ENTITY or session beans, Instances of entity beans, Instances of STATELESS session beans.

The workload management service provides load balancing for the following types of enterprise beans: Homes of entity or session beans, Instances of entity beans, Instances of stateless session beans.

When Clones of an application SERVER are defined on multiple PHYSICAL m/c, it is called HORIZONTAL Scaling. The objective is to use more than ONE less powerful m/c more efficiently.

When Clones of an application server are defined on multiple physical m/c, it is called Horizontal Scaling. The objective is to use more than one less powerful m/c more efficiently.

When multiple server CLONES of an APPLICATION server are DEFINED on the same physical m/c, it is called Vertical SCALING. The objective is to use the processing power of that m/c more efficiently.

When multiple server clones of an application server are defined on the same physical m/c, it is called Vertical Scaling. The objective is to use the processing power of that m/c more efficiently.

There are TWO TYPES of SCALING: VERTICAL Scaling and HORIZONTAL Scaling.

There are two types of scaling: Vertical Scaling and Horizontal Scaling.

To SCALE the APPLICATION so that it is HIGHLY available and has HIGH THROUGHPUT.

To scale the application so that it is highly available and has high throughput.

The home and the remote interfaces, the implementation of the Naming Context Factory, the STUBS and SKELETONS. In some App servers the stubs and the skeletons can be DYNAMICALLY DOWNLOADED from the server.

The home and the remote interfaces, the implementation of the Naming Context Factory, the stubs and skeletons. In some App servers the stubs and the skeletons can be dynamically downloaded from the server.

An entity bean accesses related entity beans by means of the accessor methods for its container-managed relationship fields, which are specified by the cmr-field ELEMENTS of its ABSTRACT PERSISTENCE SCHEMA defined in the deployment descriptor. Entity bean relationships are defined in terms of the local interfaces of the related beans, and the view an entity bean PRESENTS to its related beans is defined by its local home and local interfaces. Thus, an entity bean can be the target of a relationship from another entity bean only if it has a local interface.

An entity bean accesses related entity beans by means of the accessor methods for its container-managed relationship fields, which are specified by the cmr-field elements of its abstract persistence schema defined in the deployment descriptor. Entity bean relationships are defined in terms of the local interfaces of the related beans, and the view an entity bean presents to its related beans is defined by its local home and local interfaces. Thus, an entity bean can be the target of a relationship from another entity bean only if it has a local interface.

Stateless Session : Does not do anything to the BEAN as moving the bean from FREE pool to CACHE are managed by the container depending on LOAD. Stateful Session: Removes the bean from the cache. ENTITY Bean: Deletes the bean (data) from persistent storage.

Stateless Session : Does not do anything to the bean as moving the bean from free pool to cache are managed by the container depending on load. Stateful Session: Removes the bean from the cache. Entity Bean: Deletes the bean (data) from persistent storage.

Entity BEANS that have container-managed relationships with other entity beans, MUST be accessed in the same local scope as those RELATED beans, and THEREFORE typically provide a local client view. In order to be the target of a container-managed RELATIONSHIP, an entity bean with container-managed persistence must provide a local interface.

Entity beans that have container-managed relationships with other entity beans, must be accessed in the same local scope as those related beans, and therefore typically provide a local client view. In order to be the target of a container-managed relationship, an entity bean with container-managed persistence must provide a local interface.

The idea of the Pooled State is to allow a container to maintain a pool of entity beans that has been created, but has not been yet synchronized or assigned to an EJBOBJECT. This mean that the instances do represent entity beans, but they can be used only for serving Home METHODS (create or findBy), since those methods do not relay on the specific values of the bean. All these instances are, in fact, EXACTLY the same, so, they do not have meaningful state. Jon Thorarinsson has also added: It can be looked at it this way: If no client is using an entity bean of a particular type there is no need for cachig it (the data is persisted in the database). Therefore, in such cases, the container will, after some time, MOVE the entity bean from the Ready State to the Pooled state to save MEMORY. Then, to save additional memory, the container may begin moving entity beans from the Pooled State to the Does Not Exist State, because even though the bean's cache has been cleared, the bean still takes up some memory just being in the Pooled State.

The idea of the Pooled State is to allow a container to maintain a pool of entity beans that has been created, but has not been yet synchronized or assigned to an EJBObject. This mean that the instances do represent entity beans, but they can be used only for serving Home methods (create or findBy), since those methods do not relay on the specific values of the bean. All these instances are, in fact, exactly the same, so, they do not have meaningful state. Jon Thorarinsson has also added: It can be looked at it this way: If no client is using an entity bean of a particular type there is no need for cachig it (the data is persisted in the database). Therefore, in such cases, the container will, after some time, move the entity bean from the Ready State to the Pooled state to save memory. Then, to save additional memory, the container may begin moving entity beans from the Pooled State to the Does Not Exist State, because even though the bean's cache has been cleared, the bean still takes up some memory just being in the Pooled State.

The EJB container maintains an INSTANCE pool. The container uses these instances for the EJB Home reference IRRESPECTIVE of the client request. while refering the EJB Object classes the container creates a separate instance for each client request. The instance pool maintainence is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to IMPLEMENT it. Having said that, yes most of the container PROVIDERS implement the pooling functionality to increase the performance of the application server. The way it is implemented is again up to the implement.

The EJB container maintains an instance pool. The container uses these instances for the EJB Home reference irrespective of the client request. while refering the EJB Object classes the container creates a separate instance for each client request. The instance pool maintainence is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to implement it. Having said that, yes most of the container providers implement the pooling functionality to increase the performance of the application server. The way it is implemented is again up to the implement.

The specification infers that the container never serializes an instance of an Entity bean (unlike stateful session beans). Thus passivation simply INVOLVES moving the bean from the ready to the pooled bin. So what happens to the contents of an instance variable is controlled by the programmer. Remember that when an entity bean is passivated the instance gets LOGICALLY DISASSOCIATED from it's REMOTE object. Be careful here, as the functionality of passivation/activation for Stateless Session, Stateful Session and Entity beans is completely DIFFERENT. For entity beans the ejbPassivate method notifies the entity bean that it is being disassociated with a particular entity prior to reuse or for the reference.

The specification infers that the container never serializes an instance of an Entity bean (unlike stateful session beans). Thus passivation simply involves moving the bean from the ready to the pooled bin. So what happens to the contents of an instance variable is controlled by the programmer. Remember that when an entity bean is passivated the instance gets logically disassociated from it's remote object. Be careful here, as the functionality of passivation/activation for Stateless Session, Stateful Session and Entity beans is completely different. For entity beans the ejbPassivate method notifies the entity bean that it is being disassociated with a particular entity prior to reuse or for the reference.

PERSISTENCE in EJB is taken care of in two ways, depending on how you implement your beans: container managed persistence (CMP) or bean managed persistence (BMP) For CMP, the EJB container which your beans run under takes care of the persistence of the fields you have declared to be PERSISTED with the database - this declaration is in the deployment descriptor. So, anytime you modify a field in a CMP bean, as soon as the method you have executed is finished, the new data is persisted to the database by the container. For BMP, the EJB bean developer is responsible for defining the persistence routines in the proper places in the bean, for instance, the ejbCreate(), ejbStore(), ejbRemove() methods would be developed by the bean developer to make calls to the database. The container is responsible, in BMP, to call the appropriate method on the bean. So, if the bean is being LOOKED up, when the create() method is CALLED on the Home interface, then the container is responsible for calling the ejbCreate() method in the bean, which should have functionality inside for going to the database and looking up the data.

Persistence in EJB is taken care of in two ways, depending on how you implement your beans: container managed persistence (CMP) or bean managed persistence (BMP) For CMP, the EJB container which your beans run under takes care of the persistence of the fields you have declared to be persisted with the database - this declaration is in the deployment descriptor. So, anytime you modify a field in a CMP bean, as soon as the method you have executed is finished, the new data is persisted to the database by the container. For BMP, the EJB bean developer is responsible for defining the persistence routines in the proper places in the bean, for instance, the ejbCreate(), ejbStore(), ejbRemove() methods would be developed by the bean developer to make calls to the database. The container is responsible, in BMP, to call the appropriate method on the bean. So, if the bean is being looked up, when the create() method is called on the Home interface, then the container is responsible for calling the ejbCreate() method in the bean, which should have functionality inside for going to the database and looking up the data.

An EJB server is an APPLICATION, usually a product such as BEA WebLogic, that PROVIDES (or should provide) for concurrent client connections and manages system resources such as threads, processes, memory, database connections, NETWORK connections, etc. An EJB container runs inside (or within) an EJB server, and provides deployed EJB beans with transaction and security management, etc. The EJB container insulates an EJB bean from the specifics of an underlying EJB server by providing a simple, standard API between the EJB bean and its container. A Connector provides the ability for any Enterprise INFORMATION System (EIS) to plug into any EJB server which supports the Connector ARCHITECTURE. See Sun's J2EE Connectors for more in-depth information on Connectors.

An EJB server is an application, usually a product such as BEA WebLogic, that provides (or should provide) for concurrent client connections and manages system resources such as threads, processes, memory, database connections, network connections, etc. An EJB container runs inside (or within) an EJB server, and provides deployed EJB beans with transaction and security management, etc. The EJB container insulates an EJB bean from the specifics of an underlying EJB server by providing a simple, standard API between the EJB bean and its container. A Connector provides the ability for any Enterprise Information System (EIS) to plug into any EJB server which supports the Connector architecture. See Sun's J2EE Connectors for more in-depth information on Connectors.

With the EJBHome version of the remove, you are able to delete an entity bean without first instantiating it (you can provide a PrimaryKey OBJECT as a parameter to the remove method). The home version only works for entity beans. On the other hand, the Remote interface version works on an entity bean that you have already instantiated. In addition, the remote version also works on session beans (STATELESS and STATEFUL) to inform the container of your loss of interest in this bean.

With the EJBHome version of the remove, you are able to delete an entity bean without first instantiating it (you can provide a PrimaryKey object as a parameter to the remove method). The home version only works for entity beans. On the other hand, the Remote interface version works on an entity bean that you have already instantiated. In addition, the remote version also works on session beans (stateless and stateful) to inform the container of your loss of interest in this bean.

An Entity BEAN REPRESENTS persistent data that is stored outside of the EJB Container/Server. The ejbFindBy PrimaryKey is a method used to locate and load an Entity Bean into the container, similar to a SELECT statement in SQL. By MAKING this method mandatory, the client programmer can be assured that if they have the primary key of the Entity Bean, then they can retrieve the bean without having to create a new bean each TIME - which WOULD mean creating duplications of persistent data and break the integrity of EJB.

An Entity Bean represents persistent data that is stored outside of the EJB Container/Server. The ejbFindBy PrimaryKey is a method used to locate and load an Entity Bean into the container, similar to a SELECT statement in SQL. By making this method mandatory, the client programmer can be assured that if they have the primary key of the Entity Bean, then they can retrieve the bean without having to create a new bean each time - which would mean creating duplications of persistent data and break the integrity of EJB.

In other WORDS whether a cache of the data in database will be maintained in EJB ? - Caching data from a database INSIDE the AAApplication Server are what ENTITY EJB's are used for.The ejbLoad() and ejbStore() methods are used to synchronize the Entity Bean state with the persistent storage(database). Transactions also play an important role in this scenario. If data is removed from the database, via an external application - your Entity Bean can still be alive the EJB container. When the transaction commits, ejbStore() is CALLED and the row will not be found, and the transaction rolled BACK.

In other words whether a cache of the data in database will be maintained in EJB ? - Caching data from a database inside the AAApplication Server are what Entity EJB's are used for.The ejbLoad() and ejbStore() methods are used to synchronize the Entity Bean state with the persistent storage(database). Transactions also play an important role in this scenario. If data is removed from the database, via an external application - your Entity Bean can still be alive the EJB container. When the transaction commits, ejbStore() is called and the row will not be found, and the transaction rolled back.

An entity bean REPRESENTS persistent global data from the database; a SESSION bean represents transient user-specific data that will die when the user disconnects (ENDS his session). GENERALLY, the session beans implement business METHODS (e.g. Bank.transferFunds) that call entity beans (e.g. Account.deposit, Account.withdraw).

An entity bean represents persistent global data from the database; a session bean represents transient user-specific data that will die when the user disconnects (ends his session). Generally, the session beans implement business methods (e.g. Bank.transferFunds) that call entity beans (e.g. Account.deposit, Account.withdraw).

Technically yes, spec. compliant NO! - The enterprise bean must not attempt to query a CLASS to obtain INFORMATION about the declared MEMBERS that are not otherwise accessible to the enterprise bean because of the SECURITY rules of the JAVA language.

Technically yes, spec. compliant NO! - The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language.

ENTITY Bean is a JAVA class which implements an Enterprise Bean interface and provides the implementation of the business methods. There are two types: Container MANAGED Persistence(CMP) and Bean-Managed Persistence(BMP).

Session Bean is used to represent a workflow on BEHALF of a client. There are two types: Stateless and Stateful. Stateless bean is the simplest bean. It doesn't MAINTAIN any conversational state with clients between method invocations. Stateful bean maintains state between invocations.

Entity Bean is a Java class which implements an Enterprise Bean interface and provides the implementation of the business methods. There are two types: Container Managed Persistence(CMP) and Bean-Managed Persistence(BMP).

Session Bean is used to represent a workflow on behalf of a client. There are two types: Stateless and Stateful. Stateless bean is the simplest bean. It doesn't maintain any conversational state with clients between method invocations. Stateful bean maintains state between invocations.

A message-driven bean combines FEATURES of a SESSION bean and a Java Message SERVICE (JMS) message listener, allowing a business component to receive JMS. A message-driven bean enables ASYNCHRONOUS clients to access the business logic in the EJB tier.

A message-driven bean combines features of a session bean and a Java Message Service (JMS) message listener, allowing a business component to receive JMS. A message-driven bean enables asynchronous clients to access the business logic in the EJB tier.

There are three kinds of ENTERPRISE beans:
1. SESSION beans,
2. ENTITY beans, and
3. message-driven beans.

There are three kinds of enterprise beans:
1. session beans,
2. entity beans, and
3. message-driven beans.

1. Rapid application development
2. Broad INDUSTRY adoption
3. Application portability
4. PROTECTION of IT investment.

1. Rapid application development
2. Broad industry adoption
3. Application portability
4. Protection of IT investment.

1. EJB COMPONENTS are SERVER-side components written entirely in the JAVA programming LANGUAGE.
2. EJB components contain business logic only - no system-level programming & services, such as transactions, security, life-cycle, threading, persistence, etc. are automatically managed for the EJB component by the EJB server.
3. EJB ARCHITECTURE is inherently transactional, distributed, portable multi-tier, scalable and secure.
4. EJB components are fully portable across any EJB server and any OS.
5. EJB architecture is wire-protocol neutral--any protocol can be utilized like IIOP,JRMP, HTTP, DCOM,etc.

1. EJB components are server-side components written entirely in the Java programming language.
2. EJB components contain business logic only - no system-level programming & services, such as transactions, security, life-cycle, threading, persistence, etc. are automatically managed for the EJB component by the EJB server.
3. EJB architecture is inherently transactional, distributed, portable multi-tier, scalable and secure.
4. EJB components are fully portable across any EJB server and any OS.
5. EJB architecture is wire-protocol neutral--any protocol can be utilized like IIOP,JRMP, HTTP, DCOM,etc.

Session Facade is a design pattern to ACCESS the ENTITY bean through local INTERFACE than accessing directly. It increases the performance over the network. In this case we call session bean which on TURN call entity bean.

Session Facade is a design pattern to access the Entity bean through local interface than accessing directly. It increases the performance over the network. In this case we call session bean which on turn call entity bean.

EJB stands for Enterprise JAVABEAN and is a widely-adopted server side component architecture for J2EE. It enables rapid DEVELOPMENT of mission-critical application that are VERSATILE, reusable and portable across middleware while PROTECTING IT investment and preventing vendor lock-in.

EJB stands for Enterprise JavaBean and is a widely-adopted server side component architecture for J2EE. It enables rapid development of mission-critical application that are versatile, reusable and portable across middleware while protecting IT investment and preventing vendor lock-in.

getSession(true) - This method will CHECK WHETHER already a session is EXISTING for the user. If a session is existing, it will return that session object, Otherwise it will create new session object and return taht object.

getSession(false) - This method will check existence of session. If session EXISTS, then it returns the reference of that session object, if not, this methods will return null.

getSession(true) - This method will check whether already a session is existing for the user. If a session is existing, it will return that session object, Otherwise it will create new session object and return taht object.

getSession(false) - This method will check existence of session. If session exists, then it returns the reference of that session object, if not, this methods will return null.