In order to add a bean to a container, files associated with the bean are packaged in a .jar file. Files include the bean class, home, remote, local home and local interfaces and the deployment descriptor. Beans need to be deployed into containers before be accessed by clients through containers as distributed components.
During deployment, EJB object and EJB home are automatically created (by J2EE servers) for entity and session beans.
The EJB object, which acts as a request interceptor, implements the bean's component interface and provides a reference to an invoked bean. The EJB home, which is an EJB object factory, implements the bean's home interface and is responsible for creating, removing, and locating enterprise beans.
As message-driven beans respond only to asynchronous messages, they do not have component or home interfaces and so have no corresponding EJB object or EJB home.
Wednesday, November 22, 2006
Tuesday, November 21, 2006
EJB 1-2-3
There are three types of Enterprise JavaBeans – entity, session, and message-driven. Entity beans model real-world business or data elements and can be accessed by multiple clients. Session beans represent processes and tasks. Entity beans are persistent, but session beans do not have a persistent state. A message-driven bean is a stateless bean that responds to requests placed by clients using the Java Message Service (JMS). Both message-driven and session beans can be used to perform tasks and manage interaction between enterprise beans. However, unlike session beans, message-driven beans don't have a component interface that defines what methods can be invoked.
To develop an EJB, you need to define a bean implementation class and, if using an entity bean, a primary key class. The component interface defines the bean's business methods, whereas the home interface includes the methods required to create, find, and remove a bean. A client accesses a session or entity bean indirectly through the EJB object, which is generated by the EJB home, an EJB object factory. In addition to referencing your bean, the EJB object takes care of system-level management tasks. The EJB object class – which implements the bean's component interface – and the EJB home – which implements the bean's home interface – are both automatically generated by the container during deployment.
To develop an EJB, you need to define a bean implementation class and, if using an entity bean, a primary key class. The component interface defines the bean's business methods, whereas the home interface includes the methods required to create, find, and remove a bean. A client accesses a session or entity bean indirectly through the EJB object, which is generated by the EJB home, an EJB object factory. In addition to referencing your bean, the EJB object takes care of system-level management tasks. The EJB object class – which implements the bean's component interface – and the EJB home – which implements the bean's home interface – are both automatically generated by the container during deployment.
Enterprise Components
Within the object-oriented process, objects are reusable at the class level. However, this level of encapsulation - problem solving with classes - is often two low for enterprise systems.
To meet the challenges of enterprise systems, components - which represent logical collections of finer-grained classes - have been developed to offer a higher or more coarse-grained level of encapsulation for partitioned problems.
Sun Microsystems's enterprise component model for component transaction monitors(CTMs) is based on CORBA and is called Enterprise JavaBean(EJB).
To meet the challenges of enterprise systems, components - which represent logical collections of finer-grained classes - have been developed to offer a higher or more coarse-grained level of encapsulation for partitioned problems.
Sun Microsystems's enterprise component model for component transaction monitors(CTMs) is based on CORBA and is called Enterprise JavaBean(EJB).
Friday, November 17, 2006
Coupling and Cohesion
Coupling refers to how tightly connected classes are. If a class is very dependent on other classes to carry out its functions, then it is strongly coupled.
Strongly coupled classes can lead to problems in program design. Because such classes are interdependent, they are difficult to extend, and bugs in one can affect others.
This interdependency can also make it difficult for other programmers to understand programs that contain such classes.
To perform adequately, classes must be connected to other classes. But you should choose a level of connection that doesn't make one class too dependent on another.
This is particularly important when you design for inheritance.
Though inheritance is a form of coupling, it can make programs easier to design and extend.
So when choosing classes, you need to balance the requirements of inheritance against the need for weak coupling.
Cohesion is a measure of how closely related the elements in a class are. These elements are the states, behaviors, and functionalities of the class.
A class whose members are simply grouped together and have little in common is only coincidentally cohesive. Such a class might have two unlinked functions, or it may group object states with unrelated object behavior.
Because its elements do not cohere to realize a single purpose, such a class is confusing, difficult to use, and often too complex to implement.
Let's say you used a class named BankEmployee to model how bank staff are paid and how they interact with customers.
Since the elements of these separate functionalities are unrelated, this class would be a bad abstraction.
Classes with good cohesion are well defined and contain elements that properly belong together.
Such classes are easy to understand and use because they serve a definite purpose – they have functional cohesion.
Strongly coupled classes can lead to problems in program design. Because such classes are interdependent, they are difficult to extend, and bugs in one can affect others.
This interdependency can also make it difficult for other programmers to understand programs that contain such classes.
To perform adequately, classes must be connected to other classes. But you should choose a level of connection that doesn't make one class too dependent on another.
This is particularly important when you design for inheritance.
Though inheritance is a form of coupling, it can make programs easier to design and extend.
So when choosing classes, you need to balance the requirements of inheritance against the need for weak coupling.
Cohesion is a measure of how closely related the elements in a class are. These elements are the states, behaviors, and functionalities of the class.
A class whose members are simply grouped together and have little in common is only coincidentally cohesive. Such a class might have two unlinked functions, or it may group object states with unrelated object behavior.
Because its elements do not cohere to realize a single purpose, such a class is confusing, difficult to use, and often too complex to implement.
Let's say you used a class named BankEmployee to model how bank staff are paid and how they interact with customers.
Since the elements of these separate functionalities are unrelated, this class would be a bad abstraction.
Classes with good cohesion are well defined and contain elements that properly belong together.
Such classes are easy to understand and use because they serve a definite purpose – they have functional cohesion.
Subscribe to:
Posts (Atom)