Enterprise Applications Flashcards
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.
