Malcom,
I concur with much of your analysis here, but there are various cases for
"application" wide settings. Consider for example a set of components that
represent a business framework. For example an Order Entry framework
would include Customer, Vendor, Product, Purhase Order, Invoice... One
can envision various roles for users of an application built from such a
frame
work, Order Entry, Order Approval, Invenory Management... This role
information is not per component, but spans several. The ACL's that allow
the permissions for a particuler role to perform a partcular function are
clearly not per component, but per framework.
For this and similar scenarios we at GemStone/J have provide an application
ACL concept that lives in JNDI and not necessarily within any particular
component.
Someday when the world can agree on the interfaces between components
the game may change here. But EJB has not addressed that. EJB has prescribed
the
interface between the EJB server/container and the components, but not
between
the components themselves. So the idea that I can buy Customer component
from vendor ABC and Order component from vendor XYZ is not practical at this
time. More likely we will see component vendors that offer a suite of
components
organized into a framework (see Theory Center).
-Chris.
PS: Glad to see you still active in industry at a personal level after the
Iona deal!
> -----Original Message-----
> From: Malcolm Sparks [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 10, 1999 9:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Customization & Introspection
>
> On Wed, May 19, 1999 at 09:42:08AM +0200, Rickard �berg wrote:
> > "Masters.Robert" wrote:
> > > Couldn't application wide resources (perhaps including "environment
> > > variables" be represented as objects stored in the JNDI namespace?
> that way
> > > both EJB and client objects could retrieve them? JNDI seems to be a
> nice
> > > solution for storing/searching etc for global objects?
> >
> > Asbolutely. But there is no way to do "application wide" settings with
> > the current EJB1.1 spec. This might change though(Vlada?).
> >
>
> I can't see how application-wide settings could be possible. Let me first
> reiterate what environment entries do:
>
> Each EJB queries environment entries that it understands. The Bean
> Provider wants an environment entry for "defaultCurrency" or
> "maxTotalOrder", rather than hard-coding these or putting in his own
> configuration scheme.
>
> By choosing to use environment entries, the Bean Provider is giving
> the Application Assembler (and potentially the Container vendor also)
> the chance to modify the values of these environment entries.
>
> Now, an application unit potentially consists of components from
> multiple providers. An environment entry used by Bean A will not make
> any sense to Bean B.
>
> Putting environment entries at the application scope is only useful in
> the special case where many of the Beans in the application unit
> arrive from the same Provider. To cater for this "special case"
> endangers the simplicity of the model.
>
> If a vendor believes it's market would enjoy such a feature, then it
> is free to implement this feature in any way it likes, without
> affecting the underlying deployment descriptor. For example, the
> Application Assembler's GUI tool could allow the user to click on
> multiple Beans and change values of common environment entry names.
>
> Malcolm
>
> ==========================================================================
> =
> 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".
