Relationship fields in entity beans

[Taras_96]

Hi all

I'm reading Enterprise JavaBeans, 4th Edition. To explain relationship
fields, they use the example of a CustomerBean having a 1-1
relationship with an AddressBean.

In Chapter 6.5, the book states that:

"The Address EJB is a fine-grained business object that should always
be accessed in the context of another entity bean, which means it
should have only local interfaces and not remote interfaces"

What does the author mean by fine grained?

The CustomerBean defines:

public abstract AddressLocal getHomeAddress( );

public abstract void setHomeAddress(AddressLocal address);

Later the book states that:

" The remote interface of a bean is not allowed to expose its
relationship fields. In the case of the homeAddress field, we have
declared the type to be AddressLocal, which is a local interface, so
the setHomeAddress( )/getHomeAddress( ) accessors cannot be declared
in the remote interface of the Customer EJB"

Now, is it not allowed to expose the relationship fields because
that's the way it was defined (the accessor methods take and return
AddressLocal interfaces), or because it is a requirement that *no*
remote interfaces expose relationship fields?

Thanks

Taras

 

[Arved Sandstrom]

Hi all

I'm reading Enterprise JavaBeans, 4th Edition. To explain relationship
fields, they use the example of a CustomerBean having a 1-1
relationship with an AddressBean.

In Chapter 6.5, the book states that:

"The Address EJB is a fine-grained business object that should always
be accessed in the context of another entity bean, which means it
should have only local interfaces and not remote interfaces"

What does the author mean by fine grained?

Fine-grained is a relative term. Think of fine-grained and coarse-grained as
meaning lightweight and heavyweight, in terms of functionality. At one end
of the spectrum, an Address object having fields for street number, street
name, municipality, state/province and zip/postal code, with accessor
methods, is a typical fine-grained object. Near the other end might be a
Customer object, with a need to define personal information, contact info
(including addresses), account information (many possible accounts),
purchasing preferences etc etc etc, with many methods. Customer is a typical
coarse-grained object.

The other feature of many fine-grained/lightweight objects is that often
they have little or no logical identity. That is, they are dependent on
other objects to define a context in which they make sense. An address just
by itself isn't exactly telling you very much...an address linked to a
customer is much more meaningful.

Note that in EJB 3.0 fine-grained objects would typically be entities, not
EJBs.

The CustomerBean defines:

public abstract AddressLocal getHomeAddress( );

public abstract void setHomeAddress(AddressLocal address);

Later the book states that:

" The remote interface of a bean is not allowed to expose its
relationship fields. In the case of the homeAddress field, we have
declared the type to be AddressLocal, which is a local interface, so
the setHomeAddress( )/getHomeAddress( ) accessors cannot be declared
in the remote interface of the Customer EJB"

Now, is it not allowed to expose the relationship fields because
that's the way it was defined (the accessor methods take and return
AddressLocal interfaces), or because it is a requirement that *no*
remote interfaces expose relationship fields?

The latter.

AHS

 

[Taras_96]

Fine-grained is a relative term. Think of fine-grained and coarse-grained as
meaning lightweight and heavyweight, in terms of functionality. At one end
of the spectrum, an Address object having fields for street number, street
name, municipality, state/province and zip/postal code, with accessor
methods, is a typical fine-grained object. Near the other end might be a
Customer object, with a need to define personal information, contact info
(including addresses), account information (many possible accounts),
purchasing preferences etc etc etc, with many methods. Customer is a typical
coarse-grained object.

The other feature of many fine-grained/lightweight objects is that often
they have little or no logical identity. That is, they are dependent on
other objects to define a context in which they make sense. An address just
by itself isn't exactly telling you very much...an address linked to a
customer is much more meaningful.

Thanks, this is an excellent explanation.

The latter.

Is there a reason for this? A possible reason that comes to mind is
that the resulting action that needs to be taken if relationship
fields are changed becomes too complicated/slow.

Taras

 

[Taras_96]

Fine-grained is a relative term. Think of fine-grained and coarse-grained as
meaning lightweight and heavyweight, in terms of functionality. At one end
of the spectrum, an Address object having fields for street number, street
name, municipality, state/province and zip/postal code, with accessor
methods, is a typical fine-grained object. Near the other end might be a
Customer object, with a need to define personal information, contact info
(including addresses), account information (many possible accounts),
purchasing preferences etc etc etc, with many methods. Customer is a typical
coarse-grained object.

The other feature of many fine-grained/lightweight objects is that often
they have little or no logical identity. That is, they are dependent on
other objects to define a context in which they make sense. An address just
by itself isn't exactly telling you very much...an address linked to a
customer is much more meaningful.

Thanks, this is an excellent explanation.

The latter.

Is there a reason for this? A possible reason that comes to mind is
that the resulting action that needs to be taken if relationship
fields are changed becomes too complicated/slow.

Taras

 

[Taras_96]

Fine-grained is a relative term. Think of fine-grained and coarse-grained as
meaning lightweight and heavyweight, in terms of functionality. At one end
of the spectrum, an Address object having fields for street number, street
name, municipality, state/province and zip/postal code, with accessor
methods, is a typical fine-grained object. Near the other end might be a
Customer object, with a need to define personal information, contact info
(including addresses), account information (many possible accounts),
purchasing preferences etc etc etc, with many methods. Customer is a typical
coarse-grained object.

The other feature of many fine-grained/lightweight objects is that often
they have little or no logical identity. That is, they are dependent on
other objects to define a context in which they make sense. An address just
by itself isn't exactly telling you very much...an address linked to a
customer is much more meaningful.

Thanks, this is an excellent explanation.

The latter.

Is there a reason for this? A possible reason that comes to mind is
that the resulting action that needs to be taken if relationship
fields are changed becomes too complicated/slow.

Taras