• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ENTHUWARE Question

 
Nikhil Jain
Ranch Hand
Posts: 392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Enterprise bean environment mechanism tries to achieve which of the following objectives?

1) It allows to users of an Enterprise bean to customize its business logic without modifying the source code.

2) It allows an enterprise bean to modify its environment properties without knowing about them at the development time.

3) t allows an enterprise bean to customize its container in a standard way.

4) It allows an enterprise bean to locate external information without prior knowledge of how the information is named and organized in the target operational environment.

The correct answer to this question is 1,4.

Can anyone give me example of the 1. How can we modify business logic w/o modifying the code. Seconly, why is 2) not in the correct list. Are env properties same as env entries?
 
Wagner Danda Da Silva Filho
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anu Tilwalli:
The Enterprise bean environment mechanism tries to achieve which of the following objectives?

1) It allows to users of an Enterprise bean to customize its business logic without modifying the source code.

2) It allows an enterprise bean to modify its environment properties without knowing about them at the development time.

3) t allows an enterprise bean to customize its container in a standard way.

4) It allows an enterprise bean to locate external information without prior knowledge of how the information is named and organized in the target operational environment.

The correct answer to this question is 1,4.

Can anyone give me example of the 1. How can we modify business logic w/o modifying the code. Seconly, why is 2) not in the correct list. Are env properties same as env entries?


I've just stumbled upon the same question and I share the same confusion... Why option 1 is said to be correct? Is it really possible to an "application assembler" or "deployer" modify the source code of enterprise bean?

I guess the real question is the definition of the "customize an EJB business logic" statement... If you consider the fact that security and transaction attributes can be configured without modifying the EJB source code then that might be the reason for answer 1... Still not sure tough...
[ December 16, 2008: Message edited by: Wagner Danda ]
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anu Tilwalli:
The Enterprise bean environment mechanism tries to achieve which of the following objectives?

1) It allows to users of an Enterprise bean to customize its business logic without modifying the source code.

2) It allows an enterprise bean to modify its environment properties without knowing about them at the development time.

3) t allows an enterprise bean to customize its container in a standard way.

4) It allows an enterprise bean to locate external information without prior knowledge of how the information is named and organized in the target operational environment.

The correct answer to this question is 1,4.

Can anyone give me example of the 1. How can we modify business logic w/o modifying the code. Seconly, why is 2) not in the correct list. Are env properties same as env entries?


From EJB Core Spec Section 16.1:

The Application Assembler and Deployer should be able to customize an enterprise bean�s business logic without accessing the enterprise bean�s source code.
In addition, ISVs typically develop enterprise beans that are, to a large degree, independent from the operational environment in which the application will be deployed. Most enterprise beans must access resource managers and external information. The key issue is how enterprise beans an locate external information without prior knowledge of how the external information is named and organized in the target operational environment. The JNDI naming context and Java language metadata annotations provide this capability.
The enterprise bean environment mechanism attempts to address both of the above issues.


While the bean itself does contain business logic but that is not the only place where business logic exists. The idea is that the application assembler and deployer can mix-and-match individual beans to achieve the business logic of the system.

For example, a CreditCard bean contains BL for processing a credit card and ShippingBean contains logic for Shipping process. Both these beans can be used by another OrderBean that makes up the complete business logic of the final application. How and when the three interact can be customized by the assembler and deployer.

Answer 2 is wrong because bean cannot customize its environment. It gets whatever the assembler/deployer gives to it.

HTH,
Paul.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic