Thanks Rickard,
Rickard �berg wrote:
>
> Hi!
>
> Bill Petheram wrote:
> > In some examples I have seen it is possible for one EJB to do a
> > InitialContext.lookup of another EJB as a normal client can. If this is
> > valid what is the point of the ejb-ref and ejb-link in the deployment
> > descriptor?
>
> In my opinion, it is a huge difference. If you use direct access you are
> making the client/bean explicitly aware of where the bean is. If you
> change the location of that bean your code will have to be changed. If
> you use EJB-references you are using a more declarative approach: "I
> want a bean implementing this interface to be bound to this name". And
> then you can hardcode to this name everywhere in your bean code, not
> really caring about where it is located, but only that it implements the
> proper interface. The bean may be in the same application, or it may be
> in another application in another server. In the code you don't care,
> and this makes your bean less likely to break, and also makes it easier
> to adapt it to new situations.
>
> Also, if you port your app to another server the JNDI names that the
> beans are bound to may be different (as outlined in previous recent
> postings). To make it even worse: there may not even be a JNDI
> namespace, since this is not a mandatory thing to have!! Only the java:
> namespace is mandatory.
OK If an EJB get a new InitialContect it is the EJB server
implementation of JNDI which only has to implement the java: namespace.
>
> > I ask this because it seems to me that an EJB server cannot be regarded
> > as an application server because there are too many restrictions on an
> > EJB instance to allow it to represent a large chunk of application. i.e.
> > No sockets, thread, file access.
>
> EJB's rarely do system tasks (such as implement a database). They can
> use system modules to do that though. An EJB server is not necessarily
> an application server, but it can (as jBoss does) allow additional
> system modules to be added which may be used by EJB's.
>
> > If this is true I have been thinking about extending a Container or
> > adding Resource Factores to provide extra functionality for particular
> > types of bean but a bean has a very limited knowledge of it's container
> > or container capabilities.
> >
> > What do othe people think?
>
> Definitely use Resource Factories to do system functionality. Use EJB's
> to glue things together into an *appliction*. System modules can usually
> be reused for different applications, and do not contain any code that
> is specific to the particular application that you are implementing.
>
By System Modules do you mean ResourceFactories? aka J2EE Connector
Architecture?
What do you think of the idea of having different containers for
application specific beans? For example I have been working with e-speak
does it seem reasonable to think about an e-speak container that has
e-speak beans? This is surely similar to having a JMS container for the
JMS beans?
thanks
bill
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
