EJB Structure used in Client-Server Program?
A typical Enterprise Java Bean consists of a
-EJB Home,
-EJB Interface
-EJB bean class
In a client-server environment that's NOT an Enterprise Java Bean or running on an Application Server but instead just a java application that runs on the server, why would someone follow a similiar structure in designing their classes to have a Home, Interface, and bean class?
For instance if a client application (non ejb) was designed utilizing the Model of the MVC design pattern, when creating the Modeling classes one would typically create 1 class modeling the data. But instead utilizing the EJB design, you could create a bean class modeling the data, and have an interface, and also a home class that instantiates a singleton of the bean class or home. This is one scenario.
What would be the reasoning for using a similiar approach to the way EJB has a Home, Interface, and Bean class in a java application (non-ejb app)? Is it because of possible future migration from a traditional client-server environment to an EJB like environment?
[1082 byte] By [
plandis98a] at [2007-9-27 23:50:11]
> A typical Enterprise Java Bean consists of a
> -EJB Home,
> -EJB Interface
> -EJB bean class
>
> In a client-server environment that's NOT an
> Enterprise Java Bean or running on an Application
> Server but instead just a java application that runs
> on the server, why would someone follow a similiar
> structure in designing their classes to have a Home,
> Interface, and bean class?
>
> For instance if a client application (non ejb) was
> designed utilizing the Model of the MVC design
> pattern, when creating the Modeling classes one would
> typically create 1 class modeling the data. But
> instead utilizing the EJB design, you could create a
> bean class modeling the data, and have an interface,
> and also a home class that instantiates a singleton
> of the bean class or home. This is one scenario.
>
> What would be the reasoning for using a similiar
> approach to the way EJB has a Home, Interface, and
> Bean class in a java application (non-ejb app)? Is
> it because of possible future migration from a
> traditional client-server environment to an EJB like
> environment?
>
Probably because it is a good client server idiom/pattern, it is not just EJB. RMI uses the same approach but slightly different terminology (skeletons and stubs). Indeed EJB is build on RMI.
CORBA and DCOM also use the same pattern.
