• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

ENTHUWARE Question

 
Ranch Hand
Posts: 393
  • 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?
 
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 ]
 
Enthuware Software Support
Posts: 4430
41
  • 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.
 
We're all out of roofs. But we still have tiny ads:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic