Thanks, for the reply. Again, I was expressing my understanding of the specification; certainly it's imperfect. BTW I meant adherence (not coherence)... your points are well taken nonetheless. Here's the issue we are trying to deal with. Our EJB-centric architecture ties in XML data via a publish-subscribe mechanism. We use an RMI-IIOP client of a stateless SESSION EJB (which is also a subscriber) to (a) accept the published XML messages and (b) convert them over to requests for invocation on the business methods of the foregoing EJB. We need to able to instantiate the said EJB home interface (obviously). It's seems (IF I understand the position on the EJB specification articulate in the response) then that standard establishes no specification for referencing EJB via a naming space from RMI-IIOP client, but does establish such a mechanism for referencing EJB within other EJB (<ejb-ref/>)? We understand that EJB 2.0 has the "message-driven" bean concept, but we are currently standardized on EJB 1.1, not EJB 2.0 (and besides is EJB 2.0 a final public draft). We want the solution for acquiring the EJB home interface to be as vendor-neutral as possible. Thus the specification in prejudicial against RMI-IIOP clients of EJB? The logical conclusion is that the specification treats non-EJB clients of EJB (including RMI-IIOP/COM-DCOM, and even CORBA) pejoratively (EJB referring to EJB are treated more kindly than other clients referring to the same EJB bean). As an architect, I would prefer equality rather that a preferential treatment; although I understand there are valid reasons for it in some cases, especially considering vendor idiosyncrasies and legacy issues. Perhaps this is one. Perhaps not. -----Original Message----- From: Rickard �berg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 21, 2000 10:54 PM To: [EMAIL PROTECTED] Subject: Re: XML DD Question: Vendor XML DD and EJB XML DD (EJB 1.1 specificat ion compliance question) On Tue, 21 Nov 2000 16:14:37 -0800, Richard Landon <[EMAIL PROTECTED]> wrote: >The following is a section from the final revision public draft of the EJB >1.1 specification document (Section 16.5): <snip> >This seems to imply the the Vendor (or runtime) EJB deployment descriptor >MUST support identification of the JNDI name >or the requirement in the foregoing specification can not be satisified >(that IS if the JNDI name, say <jndi-name/> XML element, is not supportted >by the vendor then the vendor has "architected a (sic) relationship between >the ejb-name and the JNDI name". Note that there is no requirement in the EJB specification for a JNDI namespace at all. It is common to have one, but not mandatory. >A particuliar vendor specific XML DD mapping does not support the JNDI name >element except in the <ejb-ref/> DD. Thus >since each session or entity EJB does not support an absolute JNDI name for >the bean, how does a RMI-IIOP client >of the bean access the home interface of the EJB via the look-up of the >initial context. In other words, there is >no way for the vendor in question to support a name change during the >assembly process, since the vendor does not >support the absolute JNDI name (outside of the <ejb-ref/> DD). This is a perfectly ok vendor decision. Not very flexible, but definitely ok from a spec compliance point of view. >I currently think this is a lack of coherence to the EJB 1.1 XML DD >specification, and would like any comments >you may have on this area. How can this be a lack of coherence? Again, note that the very notion of binding the beans in a global namespace is proprietary in the first place. And again, just because most (all?) vendors support it does not mean that it is mandatory. It would be perfectly legal to not do it, and I can see scenarios where it would even be a requirement that a global JNDI namespace is not available (for example in an embedded application). >For the reference implementation of the J2EE (from Javasoft) the vendor >(j2ee RI) XML DD specification requires >the specification of the absolute JNDI name using the <jndi-name/> element. >This is then accessed by performing >a lookup of the "java:/comp/env/ejb" subcontext in the JDNI. This is more counter-spec I think. Are you saying that the RI binds *all* beans into java:comp/env based on their JNDI name? That is wrong: it should only bind those that have been explicitly referenced to in ejb-ref's in the XML. BTW, when you say "lookup of java:/comp/env", is this by an application client or a bean? /Rickard -- Rickard �berg Email: [EMAIL PROTECTED] http://www.telkel.com http://www.jboss.org http://www.dreambean.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
