Relationship fields in entity beans

Discussion in 'Java' started by Taras_96, Apr 29, 2008.

  1. Taras_96

    Taras_96 Guest

    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
     
    Taras_96, Apr 29, 2008
    #1
    1. Advertising

  2. "Taras_96" <> wrote in message
    news:...
    > 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
     
    Arved Sandstrom, Apr 30, 2008
    #2
    1. Advertising

  3. Taras_96

    Taras_96 Guest

    On Apr 30, 1:56 pm, "Arved Sandstrom" <>
    wrote:
    > "Taras_96" <> wrote in message
    >
    > news:...
    >
    > 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.
    >


    >
    > > 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.


    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, May 4, 2008
    #3
  4. Taras_96

    Taras_96 Guest

    On Apr 30, 1:56 pm, "Arved Sandstrom" <>
    wrote:
    > "Taras_96" <> wrote in message
    >
    > news:...
    >
    > 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.
    >


    >
    > > 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.


    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, May 4, 2008
    #4
  5. Taras_96

    Taras_96 Guest

    On Apr 30, 1:56 pm, "Arved Sandstrom" <>
    wrote:
    > "Taras_96" <> wrote in message
    >
    > news:...
    >
    > 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.
    >


    >
    > > 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.


    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, May 4, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kabal
    Replies:
    0
    Views:
    945
    Kabal
    Jul 22, 2003
  2. MP
    Replies:
    2
    Views:
    2,619
    John C. Bollinger
    Nov 11, 2003
  3. Tim

    Entity beans

    Tim, Jan 25, 2004, in forum: Java
    Replies:
    4
    Views:
    576
    Ashton
    Jan 26, 2004
  4. Torsten Schmeissel
    Replies:
    0
    Views:
    432
    Torsten Schmeissel
    Apr 29, 2005
  5. markla
    Replies:
    1
    Views:
    563
    Steven Cheng
    Oct 6, 2008
Loading...

Share This Page