In the classic (pre-EJB 3.0) session/entity-bean model, for a module…

Concept: In the classic (pre-EJB 3.0) Enterprise JavaBeans model, a session or entity bean exposing a single client view is not just a single compiled class — the container recognizes it as a matched set of artifacts: the bean's implementation class, a Home interface used to obtain/create/remove instances via JNDI, a separate Remote or Local component interface used to invoke its business methods, and an XML deployment descriptor (ejb-jar.xml) declaring the bean's type, transaction attributes, and security roles to the container.

Application: For this item, the bean under discussion follows exactly that classic single-client-view session/entity-bean packaging: one Home interface, one Remote/Local component interface, and one deployment descriptor. Because the stem scopes this to a module containing just this one bean, that single descriptor IS the bean's own accompanying XML file — two accompanying interfaces and one XML file.

Cross-check: Sun/Oracle's own J2EE Developer's Guide lists a session/entity enterprise bean's required elements as the bean class, its remote interface, its home interface, and the bean's entry in the deployment descriptor — independently confirming this two-interfaces-plus-one-descriptor packaging.

Scope note: This packaging describes the classic session/entity-bean model, a single client view, and a single-bean module — all scoped explicitly in the stem — matching standard J2EE/EJB coursework of this era. It does not describe every possible EJB variant: a message-driven bean has no Home or component interface; a bean exposing BOTH a local and a remote client view at once carries two interface pairs, not one; a module packaging several beans together would share one descriptor file across them (excluded here by the single-bean-module scope); and EJB 3.x's annotation-based, no-interface views can skip a hand-written XML descriptor altogether. Those variants are outside what this question is testing.