In my view, an interface defines a contract between the implementer and the
client of some functionality. A programming/runtime environment has to
ensure that this contract is met as far as it can (the semantic part of the
contract is not enforcable anyway). How it does this is irrelevant. In EJB
the client gets a reference to the Remote interface of the EJB and the
container is responsible for making sure that those methods are implemented
in the EJB implementation at deployment time. I think that's ok, what else
could be done to make sure the contract is met?
Some other things that have come up on the thread:
An EJB implementation class *can* implement it's Remote interface. There's
nothing that keeps it from doing so. It's just not necessary because the
contract is enforced via other means anyway.
David, if the implementation class implements the Remote interface (and
that Remote interface has a throws clause for RemoteException) this does
*not* mean that the implementation class needs to declare those exceptions
in it's throws clause as well. The throws clause of an interface is always
a superset of the throws clause of any implementation class. As I
understand it an EJB implementaion class *is* meant to be remotable since
you have to define a Remote interface for it that you specify in the DD
and/or in the implements clause.
As to the public private discussion: It is possible to define an interface
that is only accessable within the package in EJB. The only limit is that
this interface cannot be a Remote interface that is managed by the EJB
container (at least I think so). What I've been missing since Java came up
are the friend declarations of C++.
Alexander Jerusalem
At 11:30 25.03.01, David A. Ventimiglia wrote:
>My understanding of why the EJB implementation class doesn't implement the
>EJB's remote interface is that it's because the implementation class does
>not define a remotable object. For instance, if the implementation class
>did implement the remote interface, its implementation of business methods
>would need to throw javax.rmi.RemoteException, which is not something that
>should be thrown by an instance of the implementation class. Perhaps
>someone can comment on whether this is correct or not.
>
>Cheers,
>David
>
>----- Original Message -----
>From: "Guy Rouillier" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Saturday, March 24, 2001 8:59 PM
>Subject: Re: [JBoss-user] access modifiers lost in EJB programming ?
>
>
> > Interesting this topic should come up now. I've been wondering why EJBs
>are
> > not defined as implementing their remote interfaces. A session bean, for
> > example, is defined as implementing only SessionBean, and not its own
>remote
> > interface. I agree with your sentiment below, that an interface is a
> > specification. IMHO, EJBs should be defined as implementing their remote
> > interfaces, as that interface is the spec to which clients are written.
> > This would enable the compiler to ensure that the EJB has completely
> > implemented its remote interface.
> >
> > ----- Original Message -----
> > From: fractals <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, March 06, 2001 7:35 AM
> > Subject: Re: [JBoss-user] access modifiers lost in EJB programming ?
> >
> >
> > > I don't think of an interface as a "pattern specifically about the
> > publicly
> > > available views/facets of an object". You can define interfaces that are
> > > visible only from the package, and in fact, this is a feature that I use
> > > often in my designs. In my opinion, interfaces are a means for
> > > specification: they state what you have to implement if you want to be
> > > coherent with your designs. That is something that applies as well for
> > what
> > > you intend for the general public as for what you intend for your
> > > application's internals.
> > >
> > > In EJB, I see the home and remote interfaces for a specification as
>well:
> > > they state what features you want the container/application server to
> > > exhibit from a specification you give and partially implement. I the
>case
> > of
> > > ejb-references, you could want to make calls on remote objects that you
> > > wouldn't want others to see.
> > >
> > > But if I'd like to have something like this in j2ee, it's probably due
>to
> > > the fact that I'm a beginner in using those tools ;-)
> > >
> > > regards,
> > >
> > > candide
> > >
> > > > There is no way to define anything but public method in any interface.
> > > This
> > > > is not limited to remote interfaces or EJB. Interfaces are an OO
>pattern
> > > specifically
> > > > about the publicly available views/facets of an object. If you want to
> > > hide
> > > > some method of an EJB implementation then don't put the method in the
> > > > public interface. EJB adds the ability to restrict who can access the
> > > public
> > > > methods as well, so if the method should be available to some you have
> > > > this path as well.
> > > >
> > > > ----- Original Message -----
> > > > From: "fractals" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Monday, March 05, 2001 2:37 PM
> > > > Subject: [JBoss-user] access modifiers lost in EJB programming ?
> > > >
> > > >
> > > > > AFAIK, there's no way to make a method anything else than public in
>a
> > > remote
> > > > > interface. Sad, because I *would* like to hide some of the methods I
> > > define
> > > > > for some of my beans.
> > > > >
> > > > > Really, is there no way to get this cornerstone of OO programming
>back
> > > into
> > > > > the EJB realm ?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > candide
> > > > >
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > JBoss-user mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > >
> > >
> > >
> > > _______________________________________________
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > >
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
>
>
>_______________________________________________
>JBoss-user mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
