Enterprise Applications Flashcards
(44 cards)
Component
- A component is a self-contained, reusable software unit that can be integrated into an application.
- Clients interact with components via a well-defined contract.
components on enterprise space
In the enterprise space, components focus more on implementing business services, with the contract of the component defined in terms of the business operations that can be carried out by that component.
The traditional component model for Java EE has always been the EJB model, which defines ways to package, deploy, and interact with self-contained business services.
benefits that a well-defined set of business services brings to an application
- Loose coupling
- Dependency management
- Life cycle management
- Declarative container services
- Portability
- Scalability and reliability
Loose coupling
Using components to implement services encourages loose coupling between layers of an application. The implementation of a component can change without any impact to the clients or other components that depend on it.
Dependency management
Dependencies for a component can be declared in metadata and automatically resolved by the container.
Life cycle management
The lifecycle of components is well defined and managed by the application server. Component implementations can participate in lifecycle operations to acquire and release resources, or perform other initialization and shutdown behavior.
Declarative container services
Declarative container services: Business methods for components are intercepted by the application server in order to apply services such as concurrency, transaction management, security, and remoting.
Portability
Components that comply to Java EE standards and that are deployed to standards-based servers can be more easily ported from one compliant server to another
Scalability and reliability
Application servers are designed to ensure that components are managed efficiently with an eye to scalability. Depending on the component type and server configuration, business operations implemented using components can retry failed.
method calls or even fail over to another server in a cluster.
Session beans
- The client accessible operations supported by the service may be defined using a Java interface, or in the absence of an interface, just the set of public methods on the bean implementation class.
- the bean has access to a wide array of container services
- The significance of the name “session bean” has to do with the way in which clients access and interact with them. Once a client acquires a reference to a session bean from the server, it starts a session with that bean and can invoke business operations on it.
- There are three types of session beans: stateless, stateful, and singleton.
stateless session beans
a stateless session bean sets out to complete an operation within the
lifetime of a single method.
There is no state that carries over from one business operation to the other.
Stateless beans can implement many business operations, but each method cannot assume that any other was invoked before it.
Advantage:
Stateless session beans can scale to large numbers of clients with minimal impact to overall server resources
Singleton session beans
Singleton session beans can be considered a hybrid of stateless and stateful session beans.
All clients share the same singleton bean instance, so it becomes possible to share state across method invocations, but singleton session beans lack the conversational contract and mobility of stateful session beans.
Stateful session beans
a conversation that begins from the moment the client acquires a reference to the session bean and ends when the client explicitly releases it back to the server.
Business operations on a stateful session bean can maintain state on the bean instance across calls.
The only difference with the stateful session bean is that the server manages the actual object instance and the client interacts with that instance indirectly through a proxy object.
Defining a stateless session bean
A session bean is defined in two parts:
- Zero or more business interfaces that define what methods a client can invoke on the bean. When no interface is defined, the set of public methods on the bean implementation class forms a logical client interface.
- A class that implements these interfaces, called the bean class, which is marked with the @Stateless annotation.
Should we define interfaces for session beans?
Whether you want to front your session bean with an actual interface or not is a
matter of preference.
In terms of API design, using an interface is probably the best way to expose a
session bean’s operations, since it separates the interface from the implementation.
Session bean with interface
public interface HelloService {
public String sayHello(String name);
}
@Stateless
public class HelloServiceBean implements HelloService {
public String sayHello(String name) {
return "Hello, " + name;
}
}
This is a regular class that just happens to be an EJB.
Session bean with no interface
@Stateless
public class HelloService {
public String sayHello(String name) {
return “Hello, “ + name;
}
}
Under the covers, the client will be interacting with a proxy that extends the bean class and overrides the business methods to provide the standard container services.
EJB lifecycle callbacks
Problem :
The bean might have to acquire a resource, such as a JDBC data source, before business methods can be used. However, in order for the bean to acquire a resource, the server must first have completed initializing its services for the bean. This limits the usefulness of the constructor for the class because the bean won’t have access to any resources until server initialization has completed.
To allow both the server and the bean to achieve their initialization requirements,
EJBs support lifecycle callback methods that are invoked by the server at various points in the bean’s lifecycle
Stateless session beans callbacks
there are two lifecycle callbacks: PostConstruct and PreDestroy.
PostConstruct
The server will invoke the PostConstruct callback as soon as it has completed initializing all the container services for the bean. In effect, this replaces the constructor as the location for initialization logic because it is only here that container services are guaranteed to be available.
Predestroy
The server invokes the PreDestroy callback immediately before the server releases the bean instance to be garbage-collected.
Any resources acquired during PostConstruct that require explicit shutdown
should be released during PreDestroy.
Shopping Cart Using a Stateful Session Bean
@Stateful
public class ShoppingCart {
private HashMap items = new HashMap();
public void addItem(String item, int quantity) {
Integer orderQuantity = items.get(item);
if (orderQuantity == null) {
orderQuantity = 0;
}
orderQuantity += quantity; items.put(item, orderQuantity); }
public void removeItem(String item, int quantity) {
// ...
}
public Map getItems() {
// ...
}
@Remove
public void checkout(int paymentId) {
// store items to database
// ...
}
@Remove
public void cancel() {}
}
The first difference is that the bean class has state fields that are modified by the business methods of the bean. This is allowed because the client that uses the bean effectively has access to a private instance of the session bean on which to make changes.
The second difference is that there are methods marked with the @Remove annotation.
@Remove
These are the methods that the client will use to end the conversation with the bean. After one of these methods has been called, the server will destroy the instance, and the client reference will throw an exception if any further attempt is made to invoke business methods.
Every stateful session bean must define at least one method marked with the @Remove annotation, even if the method doesn’t do anything other than serve as an end to the conversation.
Passivation and activation
Passivation is the process by which the server serializes the bean instance so
that it can either be stored offline to free up resources or replicated to another server in a cluster.
Activation is the process of deserializing a passivated session bean instance
and making it active in the server once again.
